MCP servers worth your time: a working developer's setup for 2026

Earlier this year I spun up a new Next.js app and let the agent do most of the heavy lifting. Context7 fed it the current Next 16 docs so it wasn’t starting out three versions behind. The Sketch MCP let it peek at the team’s designs and pull the base Tailwind styles straight off the canvas. The Miro MCP handed it the content model the team had been mapping out on a board, and the Storyblok MCP turned that into a real schema in the CMS. A year earlier, that would have meant hours of work passed between various members of the team.

The thing that changed is the Model Context Protocol. Its own site describes it as “a USB-C port for AI applications”, which sounds glib until you’ve seen it in motion. You install MCP servers into your coding agent, and the agent can then talk to those services on your behalf: query your database, read your design files, pull current docs or open a PR. Anthropic created it, but since December 2025 it has belonged to the Linux Foundation’s Agentic AI Foundation.

Apple spent 2009 telling us “there’s an app for that”, and I expect MCP to get there too, with a server for almost anything you’d want an agent to reach.

Below are the servers I actually use, a few I’d add for a wider team, and the setup that ties them together. The ecosystem rebrands itself regularly, so check the official source for each one before you commit to it.

What an MCP server actually is

An MCP server is a small program that exposes a set of tools (and sometimes resources and prompts) over a defined protocol. Your agent acts as the MCP client, discovers those tools at runtime and calls them when it decides they’re useful. Servers can be local processes the agent spawns over stdio, or remote services it connects to over HTTP.

The 2026-07-28 specification made MCP stateless: there’s no session or initialisation handshake any more, and every request carries its own protocol version and capabilities, which makes remote servers easier to scale. Tasks, for long-running work, moved out of the core into an official extension, and Roots, Sampling and Logging are now deprecated. If you only consume servers you’ll barely notice, but read the changelog before building one.

Every major coding agent now supports MCP:

• Claude Code MCP docs
• Cursor MCP docs
• Devin Desktop (formerly Windsurf) MCP docs
• VS Code MCP server support

To find servers, start with the official MCP Registry. The old servers repository on GitHub now only holds reference implementations.

Servers I use day to day

Context7

Context7 fetches version-current documentation for libraries and frameworks at the moment the agent needs it, which fixes the biggest weakness of any LLM: an out-of-date training cut-off.

If you’ve ever had an agent confidently write code against an API that was deprecated two versions ago, you know the problem. I have a personal rule that any time I ask the agent about a library, framework, SDK or CLI tool, it pulls current docs through Context7 first, even for things it definitely already knows. It costs a little extra latency, and in return the suggestions actually compile.

Context7 only helps with things it has indexed, and the answer is only as good as the upstream docs, so it adds nothing to business logic or refactoring work.

GitHub MCP

GitHub’s official MCP server lets the agent search code, read and comment on issues and PRs, and manage branches. CI status lives in the actions toolset, which is off by default, and there’s a read-only mode, which is where I’d start. Asking it to summarise an open PR and flag what’s worth pushing back on gives a useful first pass on the small PRs that would otherwise sit at the bottom of someone’s queue.

Docker MCP Catalog and Toolkit

The Docker MCP Catalog and Toolkit pairs a catalogue of containerised servers (browse them on Docker Hub) with a Toolkit in Docker Desktop that handles install and credentials across a long list of clients. The current docs describe Docker Desktop 4.62, which adds an MCP Gateway and Profiles for switching between named sets of servers.

Every server runs in a container with controlled credentials, so if you’re nervous about installing arbitrary MCP servers from arbitrary GitHub repos (as you should be), it’s a much saner default.

Supabase MCP

The Supabase MCP lets the agent introspect your Postgres schema, run SQL, manage migrations and generate TypeScript types. Ask for “a feature where users can save articles to read later” and it can design the table, write the RLS policies and generate the migration in one go.

Point it at a development project, never production. The hosted server at mcp.supabase.com/mcp takes query parameters: read_only=true runs every query as a read-only Postgres user, project_ref pins it to one project, and features limits the tool groups. Read Supabase’s prompt-injection guidance before you connect.

Cloudflare MCP

Cloudflare used to run a handful of MCP servers, one per product area. They now point everyone at a single Cloudflare API MCP server at mcp.cloudflare.com/mcp, which is the one I use. Instead of hundreds of tools it uses Code Mode: the agent searches a typed spec of the whole API, then writes a small script that runs in a sandbox, all for roughly a thousand tokens of context. I manage a few sites on Workers via OpenNext, so asking “did that deploy go out clean?” from the editor saves a lot of tab-switching.

Azure MCP

If your stack lives in Azure, the Azure MCP Server is the equivalent. Version 2.0 went generally available in April, covering Cosmos DB, Key Vault, AI Search, Azure Monitor and plenty more from one server, and there’s an Azure plugin for Claude Code. Given how much of my career has been Microsoft-focussed, this is one I value a lot.

Microsoft’s other servers (Fabric, Microsoft 365, Azure DevOps and the like) are catalogued at github.com/microsoft/mcp, and the Cosmos DB MCP Toolkit is now generally available too.

Sentry MCP

With the Sentry MCP, the agent can read issues, events, stack traces and replays, so “this error fired in production overnight, can you propose a fix” becomes a single sentence. The hosted server at mcp.sentry.dev/mcp uses OAuth and can be scoped to one organisation and project by adding them to the URL.

Playwright MCP

Playwright MCP gives the agent a real browser to drive, so it can load a page, walk through the flow and tell you what broke instead of guessing. It works from the accessibility tree by default, and screenshot-based tools are opt-in with --caps=vision.

For coding agents, the README now points to the Playwright CLI plus skills as an alternative.

Stripe MCP

Stripe’s MCP covers the whole Stripe API, and it isn’t read-only. It exposes generic read and write tools, and only risky writes such as refunds and outbound payments need you to click a confirmation link. It’s handy for debugging a customer’s billing without opening the dashboard. From December 2026 it stops accepting full-access secret keys, so connect with OAuth or an agent API key.

Firebase MCP

The Firebase MCP is bundled into the Firebase CLI and covers Firestore, Auth, Crashlytics and most of the rest of Firebase. It’s the Google-stack equivalent of the Supabase MCP.

Chrome’s WebMCP

This one works the other way round. WebMCP is a proposed web standard that lets your website expose its actions as tools, with names, parameters and JSON schemas, so an agent can call them directly instead of doing image recognition and click-simulation. The Chrome team are driving it under the Web Machine Learning Community Group, and there’s now an origin trial from Chrome 149.

Sites opt in through an imperative JavaScript API or declarative HTML annotations, both gated by a tools Permissions Policy, so the site stays in control.

Servers worth knowing about for the wider team

MCP isn’t just for developers any more. Designers and content people are plugging their own tools into agents, which changes how engineering teams work with them.

Figma MCP Server

Figma’s MCP server gives your agent structured design context (variables, components, code suggestions), so “build this component to match the design” actually has the spacing, colours, variants and naming to hand.

The remote server at mcp.figma.com/mcp is now the recommended option and needs no desktop app. It can also write to the canvas, which is in beta and free while it stays there.

Sketch MCP Server

Sketch’s official MCP Server runs locally inside the app and lets the agent audit components, export assets or generate screens from existing components. It needs Sketch 2025.2.4 or later (not the App Store version), and you point your client at http://localhost:31126/mcp.

Storyblok MCP

Storyblok is a headless CMS I’ve been using on commerce projects. Their official MCP server can fetch and publish stories, manage component schemas and handle assets. Alongside the Miro MCP, I’ve used it to turn an information architecture diagram on a board into component schemas, and it has reliably produced usable Storyblok schema.

Sanity MCP

The Sanity MCP lets the agent run GROQ queries, patch documents, manage releases and work with schemas. The writing section of this site is built on Sanity, and scaffolding a content type through MCP rather than hand-writing the schema is great.

Miro MCP

The official Miro MCP lets the agent summarise and search boards, generate architecture diagrams and manage comments without you navigating the board yourself. It now works on every Miro plan, free teams included, and connects over OAuth.

Atlassian Rovo MCP Server

Atlassian’s server is now the Rovo MCP Server, covering Jira, Confluence, Jira Service Management, Bitbucket and more. It uses OAuth and respects your existing permissions, so the agent never sees more than you do. Pulling acceptance criteria or dropping notes into Confluence without leaving the editor is the obvious win.

Linear MCP

Linear’s MCP is the equivalent for teams on Linear, with read and write access to issues, projects and cycles. There’s a separate read-only endpoint at mcp.linear.app/mcp/readonly, and the old SSE endpoint is deprecated.

Notion MCP

Notion’s MCP gives the agent your Notion pages and databases, which helps when specs or ADRs live there. I keep architectural decisions under /docs/ in the repo itself, but plenty of teams use Notion.

Installing them

All the servers I run are remote, so adding one to Claude Code is a single claude mcp add command, using the URLs each vendor documents:

# Current docs (the API key is optional and raises the rate limit)
claude mcp add --scope user --header "Authorization: Bearer YOUR_API_KEY" \
  --transport http context7 https://mcp.context7.com/mcp

# The whole Cloudflare API via Code Mode (OAuth)
claude mcp add --transport http cloudflare-api https://mcp.cloudflare.com/mcp

# Sanity (OAuth)
claude mcp add Sanity -t http https://mcp.sanity.io --scope user

# Supabase, pinned to one project and read-only (OAuth)
claude mcp add --scope project --transport http supabase \
  "https://mcp.supabase.com/mcp?project_ref=YOUR_PROJECT_REF&read_only=true"

# Sentry, scoped to one organisation and project (OAuth)
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp/YOUR_ORG/YOUR_PROJECT

# Stripe (OAuth)
claude mcp add --transport http stripe https://mcp.stripe.com/

The OAuth servers ask you to sign in on first use; run /mcp inside Claude Code if one doesn’t. Anything added with --scope project lands in a .mcp.json file at the root of the repo, which you commit so the whole team gets the same servers:

{
  "mcpServers": {
    "supabase": {
      "type": "http",
      "url": "https://mcp.supabase.com/mcp?project_ref=${SUPABASE_PROJECT_REF}&read_only=true"
    },
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/mcp/${SENTRY_ORG}/${SENTRY_PROJECT}"
    }
  }
}

Claude Code expands ${VAR} references from each developer’s environment, so nobody’s project IDs are hard-coded. Both servers sign in with OAuth, which keeps secrets out of the file entirely.

Keeping it safe

Simon Willison’s lethal trifecta is the best framing I’ve found for the risk: an agent with access to private data, exposure to untrusted content and a way to send data out can be tricked into leaking it. Most useful MCP setups tick every box, so I stick to a few habits:

• Read-only endpoints where they exist. GitHub and Linear have dedicated ones, Supabase has its read_only flag, and most of what I ask for is reading anyway.
• Approval kept on for writes. I don’t auto-approve tools that change anything, and Stripe’s confirmation links stay on.
• The narrowest token scopes I can get away with. One project rather than the whole account, and OAuth over long-lived keys wherever a server supports it.

Structuring the project around the agent

The servers give the agent reach, but how well it uses them depends on how you set up the project.

Skills: keep specialised knowledge out of the main context

Claude Code Skills are small markdown files with frontmatter that load automatically when they’re relevant. Any time I find myself explaining the same conventions to the agent twice (“here’s how we add a Sanity block”), I extract them into a skill. Skills are now an open standard too, so the same files work in Cursor, Codex, GitHub Copilot and Gemini CLI.

I keep skills project-level when they describe project-specific patterns, and user-level for things like “use Context7 for any library question”. The agent can usually write the skill for you once you’ve explained how you want a task approached.

MCP servers versus a CLI and a skill

Some vendors now offer a CLI and a skill as an alternative to their MCP server. Playwright is one, and Context7 has its own ctx7 CLI, which npx ctx7 setup installs along with a skill that drives it. I use both routes for Context7, depending on the tool I’m working in. An agent with a shell can call the CLI directly and only loads the skill when it’s relevant, while the MCP server works in any client that speaks the protocol, shell or not.

Subagents: parallel work with isolated context

Subagents are where the architecture gets interesting. A subagent gets its own context window for one task, and the parent only sees the result, so a research job (via Context7, perhaps) comes back as findings rather than every page it read along the way.

Linting rules: let the toolchain teach the agent

With strict ESLint or Biome rules and TypeScript strict mode, the agent sees errors and fixes them on its own. If your project is lax about lint, the agent will write code you’ll have to clean up later.

Architecture docs under /docs/: write the why down

In any new project, I write a small set of markdown files under /docs/ describing how the codebase is structured, which conventions matter and why. This site has /docs/overview.md, /docs/writing.md and /docs/tools-framework.md, among others.

Professionally, I’ve built a Git repository of markdown playbooks and skills that I use across all projects, so the agent gets the same context whichever developer is working on the repository.

The agent reads these (or has them surfaced via @-imports from CLAUDE.md and the memory file system) and gets the architectural context that doesn’t live in the code. A few tips:

• Split docs by feature, not by chapter. One file per cohesive concept beats a giant ARCHITECTURE.md.
• Update them as you go. Stale docs are worse than no docs, because the agent will trust them.
• Reference them from CLAUDE.md or AGENTS.md so they get loaded automatically.

Keep the context window small

Prune what the agent is carrying. If you’ve been bouncing around the codebase for an hour and the conversation is now a million tokens long, it’s slower and more expensive than a fresh one with a focused goal and a couple of relevant files.

MCP servers used to add to that, because every tool definition sat in context from the first message. Claude Code now uses tool search by default, loading only tool names at the start and fetching a full definition when the agent needs it, so another server costs very little context.

Practise starting a new conversation per logical task: hand it the relevant skill, docs and files, do the work, commit it, and start again for the next thing.

Final thoughts

The project I opened with wasn’t magic, or particularly clever. The agent finally had access to the tools and data the team was already using, with enough structure around it to use them sensibly.

What surprised me when I came back to refresh this post was how much had moved in four months. Seven of the server write-ups needed correcting, and the protocol underneath them went stateless. The agent copes with that churn because it reads current docs instead of trusting what it remembers, and this post now works the same way, with an update box at the top that probably won’t be the last.