The MCP servers I actually run in production for client work are short: Filesystem, GitHub, Postgres or Supabase, a CRM connector (custom GHL or HubSpot), Notion or ClickUp, Playwright, and Context7. That's it. Everything else is a demo. If you're picking a stack to ship with, those seven cover 90% of real operational work and leave you with one console to debug, not twenty. At Formaum, every production AI build ships with a curated MCP stack wired to the client's actual systems.

What an MCP server actually is

Model Context Protocol is an open standard from Anthropic. An MCP server is a small process that exposes tools, resources, and data to an AI agent over a defined wire format. The agent can call those tools the same way it'd call functions, but the implementation lives outside the model. If you want the longer explainer, I wrote what an MCP server is and why it matters. The short version: it's the connector layer that lets your AI actually touch real systems instead of pretending it can.

The honest take on the MCP landscape

The list is exploding. There are thousands of MCP servers now. Most of them are weekend projects, demos, or thin wrappers that crash the second you put real load on them. Half the "best MCP servers" lists you'll find are written by people who installed twenty of them, took screenshots, and never shipped a client build with any.

My filter is brutal. An MCP server earns a slot in my stack if: it's vendor-maintained or has a serious community behind it, it handles real auth scoping, it doesn't fall over on long-running agents, and the work it unlocks is something I actually need on Tuesday at 3am when nobody is watching. Almost nothing passes that bar.

One more thing. There were 30+ CVEs filed against popular MCP servers in early 2026 and a remote code execution vulnerability in a server with 150M+ downloads. Vendor-maintained servers from GitHub, Microsoft, Supabase, Stripe, Cloudflare, Linear, Notion, and Sentry are the lowest-risk options. Scope your tokens narrowly even on those.

Top MCPs I actually run in production

Filesystem (official, Anthropic). The boring one. Read, write, search files inside a scoped directory. I use it on every client engagement. It's how the agent actually touches the codebase or the working folder. Don't skip it because it sounds basic. It's the foundation.

GitHub (official, GitHub). Issues, PRs, repos, commits, code search. Vendor-maintained, OAuth-scoped, hardened. I use it on every engineering build. It's how the agent reviews diffs, opens PRs, files issues, and reads code across the whole org. There is no real alternative that's this stable.

Supabase or Postgres. Live database queries from inside the agent loop. Supabase has a first-party MCP server, Postgres has a solid community one. I use this on any build with structured client data: lead pipelines, message logs, CRM mirrors. It's also how I debug production data without exporting CSVs.

Notion or ClickUp. Pick one. Notion for clients with documentation-heavy workflows, ClickUp for clients with operations-heavy workflows. Both have decent MCP servers. I use ClickUp on most engagements because that's where active tasks, change requests, and project state live. The agent can read a task, mark it done, and add a comment in one call.

Custom CRM connectors (GHL, HubSpot). For most of my client work, the CRM is the centre of gravity. GHL doesn't have a great off-the-shelf MCP server, so I built one. Same for HubSpot on a different engagement. This is where the use lives. If your client's whole business runs on a CRM, the agent has to touch it natively, not through Zapier glue.

Playwright (official, Microsoft). Browser automation. Click, fill, screenshot, extract. I reach for this when a SaaS platform doesn't have a real API and I need the agent to drive the UI directly. Also useful for end-to-end testing on client web apps.

Context7. Pulls up-to-date, version-specific documentation for thousands of libraries at query time. Solves the problem of the model remembering an old API. I have it on by default. It's saved me from shipping deprecated code more times than I can count.

MCPs that look good but I don't ship with

Slack MCP servers. The community ones are flaky. I use the Anthropic harness's built-in Slack tools instead. Less surface area, more reliable.

Generic "everything" servers. The all-in-one MCPs that promise 250+ integrations sound great. In practice they're slow, the auth is messy, and you can't scope permissions tightly. I'd rather have five sharp servers than one bloated one.

Most search MCPs. Exa is solid and I'll use it on research-heavy builds. Brave Search works. But for most operational client work, I don't need agentic web search. The model has plenty of training data and Context7 covers the documentation gap.

Figma MCP. Useful if you're doing design-to-code work. I'm not, most weeks. If you are, it's a real time-saver. If you're not, skip it.

Trendy AI memory servers. Persistent agent memory across sessions sounds powerful. In production it's usually a leak waiting to happen. I use project memory and skills inside Claude Code instead of a separate memory server.

Building your own MCP server

You should build a custom MCP server when the client's core system doesn't have a good off-the-shelf one and the agent needs to touch it constantly. That's where the real use is.

My rule is: if the agent is going to call the same API more than a hundred times in a working session, and the existing server is missing endpoints I need, I build my own. It's usually a few hours of work in Python or TypeScript. The MCP spec is small. The hard part isn't the protocol. The hard part is scoping auth correctly, handling rate limits, and writing tool descriptions that the model can actually understand.

I built a custom GHL MCP server for an engagement where the agent needed to read contacts, update custom fields, trigger workflows, and pull conversation history fluently. The off-the-shelf options didn't cover half of that. The custom build paid for itself in the first week of agent runs.

Common mistakes when picking MCP servers

Installing too many. Every MCP server you add is more surface area, more tool descriptions in the model's context, and more failure modes. I keep my active server list under ten. If a server isn't called in a real engagement that week, it gets disabled.

Picking unmaintained ones. A flashy community MCP with no commits in six months is a risk, not an asset. Check the repo. Check the issue tracker. If the last release was 2025, treat it as abandoned.

Skipping token scoping. An MCP server with full-access tokens is a credential leak waiting to happen. Scope every token narrowly. Read-only when you can. Per-project when you can. The vendor servers make this easy. The community ones often don't.

Treating MCP as a silver bullet. MCP servers are connectors. They don't make a bad agent good. The methodology, the prompts, the verification loops, and the skills around the agent are what make production work. The MCP layer is just plumbing.

Not building your own when you should. If a client's core system is the bottleneck and the off-the-shelf server is missing what you need, build one. It's faster than fighting around the gap for the next six months.

The short answer

Pick the boring vendor-maintained servers first. Filesystem, GitHub, Supabase or Postgres, Notion or ClickUp, Playwright, Context7. Build a custom server for your client's core CRM if there isn't a good one. Stop there. The infrastructure that wins is the one you can debug at 3am, not the one with the longest feature list.

⚖️

The honest take: The best MCP server is the one you'll actually use on a Tuesday under real client load. Most of the "top 25" lists are demos. Ship with seven and go deep.

Run on a stack that's holding you back?

Book a 45-minute discovery call. I'll map what moves, what stays, and what makes sense for your operation.

Book a call

Frequently Asked Questions

What is the best MCP server overall?
There isn't one. The best server depends on what you're building. For most operational client work, the Filesystem and GitHub MCP servers do the most heavy lifting. For data-driven builds, Supabase or Postgres. For CRM-centric work, a custom connector to whatever CRM the client runs on.
How many MCP servers should I run at once?
Fewer than ten in active use. Every server you add eats context window space with tool descriptions and adds a failure mode. I disable servers that aren't called in real client work that week. A tight stack is faster and easier to debug than a sprawling one.
Are MCP servers safe to use in production?
Vendor-maintained servers from GitHub, Microsoft, Supabase, Stripe, Cloudflare, Linear, Notion, and Sentry are the lowest risk. Community servers have had real security issues in 2026, including a remote code execution in a server with 150M+ downloads. Scope tokens narrowly on every server, vendor or not.
When should I build a custom MCP server?
When the client's core system doesn't have a good off-the-shelf one and the agent needs to touch it constantly. If you'll call the same API more than a hundred times a session and the existing server is missing endpoints you need, build your own. It's usually a few hours of work.
Do I need an MCP server to use Claude?
No. Claude works fine without any MCP servers. They're connectors that let the agent touch real systems: files, repos, databases, CRMs. If your work is conversational or pure code generation, you can skip MCP. If you want the agent to actually do operational work, MCP is how that happens.
Genevieve Claire
Genevieve Claire
Founder, Formaum — Claude Code Expert & Full-Stack AI Engineer

Builds bespoke AI automation systems for multi-location operations. Previously EA Sports FIFA ($7B franchise) and Film/TV VFX on Skyfall, Avengers, Game of Thrones. Based in Vancouver, BC.