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

Last week 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 and information architecture that the team had been mapping out on a board. Then the Storyblok MCP took that content model and turned it into a real schema in the CMS. None of that was possible a year ago, and would have required hours of work between various members of the team.

The thing that changed is the Model Context Protocol. Anthropic’s homepage 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 now the agent can talk to those services on your behalf: query your database, read your design files, pull current docs, drive a browser, look at production errors, open a PR, and more.

When Steve Jobs launched the iPhone in 2007 with the phrase “there’s an app for that”, I feel there will soon also be an MCP for every scenario you could need one for.

I want to walk through the servers I actually use, the ones I’d add for a wider team, and then talk about how I structure projects around them so the agent stays useful as the codebase grows. The MCP ecosystem is moving fast and rebranding itself monthly, 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 AI agent acts as the MCP client, discovers those tools at runtime, and can call them when it decides they’re useful for the task at hand. Servers can be local processes the agent spawns over stdio, or remote services it connects to over HTTP. From your point of view as a developer, you install or connect them once and then the agent just has those capabilities.

Every major coding agent now supports MCP:

• Claude Code MCP docs
• Cursor MCP docs
• Windsurf MCP docs
• VS Code MCP server support

The protocol itself, plus a directory of official and community servers, lives at modelcontextprotocol.io.

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 that uses an API that was deprecated two versions ago, you know exactly the problem Context7 solves. I have a personal rule that says any time I ask the agent about a library, framework, SDK, API or CLI tool, it should pull current docs through Context7 first, even for things it definitely already knows, because what it knows might be stale. The cost is a small bit of extra latency. The benefit is that the suggestions actually compile.

The caveat is that Context7 only helps for things it has indexed, and the quality of the answer depends on the quality of the upstream docs. For business logic, refactoring, or general programming concepts, it doesn’t add anything. That’s not what it’s for.

GitHub MCP

GitHub’s official MCP server will quickly become invaluable to many teams. The agent can search code across repositories, read issues and PRs, comment on PRs, manage branches, trigger workflows, and read CI status. You can imagine a common use case to be “look at this open PR, summarise what’s changed, and tell me what’s worth pushing back on”. Paired with the local repo for diffs, the agent’s first-pass could be extremely useful, especially on the smaller PRs that would otherwise sit at the bottom of someone’s queue.

Docker MCP Catalog and Toolkit

The Docker MCP Catalog and Toolkit is Docker’s contribution to making MCP servers manageable at scale. It’s a catalogue of containerised, sandboxed MCP servers (browse them on Docker Hub) plus a Toolkit that handles install, OAuth and credential management across Claude, VS Code, Cursor, Windsurf, continue.dev and Goose. You need Docker Desktop 4.48 or newer.

What I like about it is the security posture. Every server runs in a container, with controlled credentials, and you can audit what’s actually being run. If you’re nervous about installing arbitrary MCP servers from arbitrary GitHub repos onto your dev machine (as you should be), the Docker catalogue is a much saner default.

Supabase MCP

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

Just remember to point this at a development project and never production. Recent versions of the server added a --read-only flag and default project scoping, but the rule is still: any MCP that can write to your database needs the same care you’d give any other tool that can write to your database. Supabase have been good about publishing guidance on prompt-injection risks too, so read their notes before connecting.

Cloudflare MCP

Cloudflare have released a handful of remote MCP endpoints, one per product area. The full list lives in their developer docs. The ones I use most are the Workers binding to surface what I’ve got deployed and what’s the config, the Observability MCP for logs and analytics, and the AI Gateway MCP for projects that put a gateway in front of an LLM. I manage a few sites that run on Workers via OpenNext, and so being able to ask “what’s the p95 latency on this route today” or “did that deploy go out clean” without leaving the editor, is pretty amazing.

Azure MCP

If your stack lives in Azure, Microsoft’s official Azure MCP Server is the equivalent of the Cloudflare entry above. It covers a long list of Azure services from a single server: Cosmos DB, App Configuration, Key Vault, AI Search, Azure Monitor, RBAC, Redis, the Azure CLI itself, and more. The GitHub repo is the installation reference, and Microsoft have first-party client support across VS Code, Visual Studio, Cursor, JetBrains, Windsurf, Cline and Eclipse. Given how much of my career has been Microsoft-focussed, this one is really powerful for me.

At Build 2026, Microsoft shipped a dedicated Cosmos DB MCP Toolkit that exposes Cosmos data directly to MCP-compatible agents, plus an Agent Memory Toolkit that uses Cosmos as the persistent memory layer for AI agents. Both are useful additions if you’re building agentic apps on Microsoft infrastructure.

Sentry MCP

With the Sentry MCP, the agent can read issues, events, stack traces and replays directly from Sentry, which means “this error fired in production overnight, can you look at the stack trace and propose a fix” is suddenly a single sentence. Sentry runs a hosted remote MCP at mcp.sentry.dev, OAuth based, so your org admins may need to enable it.

After a deploy, if anything fires in Sentry, you drop the issue ID into the agent and ask it to investigate. With access to the error, the stack trace, and the surrounding code in the repo, your agent can suggest the relevant fixes.

Playwright MCP

Playwright MCP is Microsoft’s official MCP for Playwright, the browser-automation library. It gives the agent a real browser to drive: navigate, click, type, screenshot, evaluate JS, run accessibility snapshots. There are two modes: snapshot mode (uses the accessibility tree, faster, no vision model needed) and vision mode (screenshot-based, slower but more flexible).

This gives your agent the ability to test UI changes against a real browser, where the agent loads the page, walks through the flow, and tells you what broke. It can also enable your agent to scrape or interact with web apps that don’t have an API. It’s much more reliable than asking the agent to “guess” what a page does.

Stripe MCP

Stripe’s MCP covers payments, subscriptions, customer lookup, refunds and the rest of their API surface, with read-only as the default. This can be used in debugging billing issues live. A customer reports something, you ask the agent to fetch the customer record and recent invoices, you get a clear picture without context-switching into the Stripe dashboard. Thankfully, the write access is fenced off behind explicit confirmation.

Firebase MCP

The Firebase MCP is bundled into the Firebase CLI. It lets the agent manage Firebase projects, Firestore, Auth, App Hosting, Crashlytics and Remote Config. If you’re running on Firebase, this is the equivalent of the Supabase MCP for the Google stack.

Chrome’s WebMCP

This one is interesting because it works the other way round to most things in this list. Instead of installing an MCP server on the agent side so the agent can reach into your tools, WebMCP is a proposed web standard for your website to expose its capabilities as MCP-style tools that an agent can discover and call directly. It is being driven by the Chrome team under the Web Machine Learning Community Group, available behind a Chrome feature flag for local development right now, with an origin trial planned.

The thinking behind this is that an agent driving your site through a real browser today is essentially doing image recognition and click-simulation. WebMCP lets the site say “here are my actions, with names, parameters and JSON schemas: invoke them directly”. For commerce, SaaS or anything with a structured user journey, that’s a significantly more reliable interaction model. This comes in two parts. An imperative JavaScript API and a declarative one based on HTML annotations, both gated by a tools Permissions Policy so the site is in control.

Servers worth knowing about for the wider team

The shift I find most interesting is that MCP isn’t just for developers any more. Designers, content people and project managers are all starting to plug their own tools into AI agents, and that has knock-on effects for how engineering teams work.

Figma: Dev Mode MCP Server

Figma ship an official Dev Mode MCP Server that runs locally inside the Figma desktop app. It exposes the currently-selected frames as structured design context (variables, components, code suggestions) to your agent. The result is that “build this component to match the design” actually has access to the design, including spacing, colours, variants and naming.

It needs the Figma desktop app and a Dev or Full seat, and at the time of writing parts of it were still beta-gated, so check current availability.

Sketch MCP Server

Sketch shipped an official MCP Server that runs as a lightweight local-only web server, letting AI agents like Claude interact directly with your Sketch documents. It can help with auditing components, exporting assets, generating screens from existing components, and asking the agent to spot inconsistencies across a file you’d otherwise have to walk through manually. Setup needs Sketch 2025.2.4 or later (the non-App Store version), and you point your MCP client at http://localhost:31126/mcp.

Storyblok MCP

Storyblok is a headless CMS I’ve been using on commerce projects, and their official MCP server gives agents semantic search across content, full CRUD on stories and components, and asset management, all with enterprise governance controls on top. I’ve been using Storyblok MCP alongside the Miro MCP to take an information architecture diagram off a Miro board and scaffold the actual component schemas straight from it. It’s been really useful to be able to say “here’s the IA (content model, etc), build me the content types”, and it’s been reliably generating Storyblok schema.

Other headless CMS MCPs

• Sanity MCP: official server from Sanity. Lets the agent interact directly with your Sanity projects. You can run GROQ queries, patch documents, manage releases, and work with schemas via the Sanity API. The writing section of this site is built on Sanity, and being able to scaffold a content type through MCP rather than hand-writing the schema is great.
• I’m sure all headless CMS offerings will eventually have an MCP if they don’t already.

Miro MCP

Miro have an official Miro MCP that bridges Claude, Cursor and other MCP-compatible agents directly with your boards. Once connected, the agent can summarise boards, create and modify layouts, search content, generate architecture diagrams, upload images and manage comments, without you having to navigate the board manually. It’s on the Enterprise plan only and admins need to enable the server before users can connect, but the connection itself is OAuth 2.1 and can be done from inside Claude’s connector UI or via the Claude Code CLI.

If you don’t have Enterprise, you can still use Miro to serve information to your agent. I’ve found that if you export your boards as CSV, Claude still does a fantastic job of interpreting the data, layout, relationships, etc.

Atlassian (Jira + Confluence) MCP

Atlassian launched their official Remote MCP Server in beta in May 2025, covering Jira and Confluence Cloud, with more Atlassian apps coming. It is OAuth-based and respects your existing permissions, so the agent never sees more than the user account does. For developers, you can ask the agent about ticket context, fetch acceptance criteria, drop work-in-progress notes into Confluence, without leaving your editor. For anyone who supports service-desk work as well as code, being able to triage tickets through the agent is great, too.

Linear MCP

Linear’s MCP is the equivalent for teams on Linear rather than Jira. Read and write access to issues, projects, cycles and roadmaps.

Notion MCP

Notion’s MCP gives the agent access to Notion databases and pages. Useful when your specs, ADRs, product notes or onboarding documents live in Notion rather than in the repo. I personally keep architectural decisions under /docs/ in the project itself, but plenty of teams use Notion for that.

Scoro MCP

Scoro have an official Scoro MCP that connects your Scoro workspace to Claude, ChatGPT and other MCP-compatible agents. It exposes read and write access for projects, tasks, calendar events, comments, time entries and contacts, plus read-only access to financial documents (invoices, bills, expenses, quotes). It’s available across all Scoro packages.

Structuring the project around the agent

The servers above are levers, but the leverage comes from how you set up the project so the agent uses them well.

Skills: keep specialised knowledge out of the main context

Claude Code Skills are small markdown files with frontmatter that auto-surface when they’re relevant to what you’re doing. Any time I find myself explaining the same set of conventions to the agent twice (“here’s how we add a new tool to the tools framework”, “here’s how we add a Sanity block”), I extract it into a skill. Next time the agent needs that knowledge, it gets loaded automatically without me pasting context every time.

This means your main agent context stays brief and the specialised knowledge only appears when it’s needed. Skills can be project-level or user-level. I keep mine project-level when they describe project-specific patterns, and user-level for things like “use Context7 for any library question”.

You can often get the agent to write the skill for you in the correct format, after explaining how you want it to approach a task.

Subagents: parallel work with isolated context

Subagents are where the architecture gets interesting. You can spawn a fresh agent with its own context window for a specific task, and the parent agent only sees the result. So for example, you could ask the subagent to research a specific topic (via Context7, perhaps), and the parent agent would only see the results of that research. The parent stays clean and the context window remains smaller than if the parent agent did that work.

Linting rules: let the toolchain teach the agent

If you have strong ESLint, Biome, eslint-plugin-react-hooks, TypeScript strict mode, and type-check, the agent will see errors and fix them on its own. Conversely, if your project is lax about lint, the agent will write code that you’ll have to clean up later. The linter is a very powerful tool.

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, what conventions matter, and why. For this site I have /docs/overview.md, /docs/writing.md, /docs/tools-framework.md. Each one explains a specific part of the system: what’s wired up, what the contract is, where to extend it.

Professionally, I have developed an entire Git repository of markdown ‘playbooks’ and skills to use consistently across all projects, to ensure the agent is given the same context for each project, regardless of the developer 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 itself.

A few tips:

• Split docs by feature, not by chapter. One file per cohesive concept is better than 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, AGENTS.md so they get loaded automatically.

Keep the context window small

Make sure you aggressively ‘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 both slower and more expensive than starting a fresh one with a focused goal and a couple of relevant files. The conversation history is not free. Or cheap!!

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

Final thoughts

The week I opened with at the start of this post isn’t magic (or particularly clever). The agent finally has the access to my tools and data in a way that empowers development, and a decent structure on top to use them sensibly.

The MCP ecosystem is still a bit messy. Some servers are official, many are community, some products have rebranded their MCPs multiple times. But the underlying direction is clear. AI agents are most useful when they can see your actual tools and data, and there is now a standard way to give them that access without coupling either side to a specific vendor.

If you’re new to this and the tooling feels like a moving target, install the ones that match your own stack and spend a week working through them. The ones I use most day to day are Context7 for current docs (install this first, regardless of stack), Supabase MCP for anything with a Postgres database underneath it, the Sketch and Miro MCPs for the design-into-IA pipeline, and either Storyblok or Sanity for content work. If you’re building Workers, the Cloudflare MCP is very useful. The compounding effect on day-to-day productivity is huge, and you only get to discover that by plugging the things in.