Your MCP Stack

Module 5: Your MCP Stack

Having one MCP server is useful. Having twenty is a problem.

When Claude has too many tools to consider, two things happen. First, it takes longer to decide what to use — all those tools get evaluated for relevance on every response. Second, it makes mistakes more often — similar-sounding tools from different servers create ambiguity, and Claude occasionally picks the wrong one.

The goal isn’t the most servers. It’s the right servers.

The Design Principles

One server per domain. Don’t install two different calendar servers. Don’t install a file search server and a separate code search server if they’re solving the same problem from different angles. Each domain should have a single, authoritative server. When you find a better option, replace rather than supplement.

Prefer narrow over broad. A server with five focused tools is better than a server with twenty that happen to touch the same service. Narrow tools have clearer use cases. Claude can choose between them more confidently. You can reason about what they’ll do more easily.

Tools should do one thing. get_events_for_date_range is a good tool. get_events_and_summarise_and_create_followup_tasks is not. Composition belongs at Claude’s level — give it the primitives and let it combine them. If you find yourself building complex logic into a tool, split it into smaller tools.

Name tools to avoid ambiguity. If you have a file server and a database server both with a search tool, Claude will guess which to use based on context and sometimes guess wrong. Prefix with the domain: fs_search, db_search. Or use different verbs: search_files, query_database. Ambiguity in tool names causes errors that are annoying to debug.

The Stack I Actually Run

For reference, here’s what I use:

Filesystem — The reference server covering my Dev directory and a few other locations. Daily use for reading code, checking file contents, finding things.

mcp-fantastical — Calendar access via Fantastical. I ask about my week, check availability, get Claude to draft invites with accurate dates. Would use multiple times a day if I did more scheduling.

Brave Search — Web search for things Claude wouldn’t know from training data. Used when I’m researching something current or want to verify a claim.

mcp-kit — My own server for reusable utilities: storing notes between sessions, looking up tool configurations, a few other things that come up often enough to automate. The kind of personal tooling that doesn’t need to be published but makes daily work smoother.

GitHub — Repository access for when I’m working on code and want Claude to check issues, PRs, or commit history without me switching to the browser.

That’s five servers with around twenty-five tools total. That’s comfortable. Claude can reason about that set without confusion.

When MCP Is the Wrong Choice

MCP isn’t always the answer. Three situations where something else is better:

When you’re better off with a CLI tool. If you already have a good command-line interface for something, an MCP server just adds a layer. I use the kit CLI directly from Claude Code’s terminal access rather than building an MCP server around it. Same for obsidian, reminders, and a few others — the CLI is the server.

When a direct API call is simpler. For one-off data needs, you can often just have Claude write a bash command that calls an API with curl. No server needed, no configuration required. This is especially true for things you’ll only do occasionally — the overhead of installing and maintaining a server isn’t worth it for a task you do twice a month.

When the latency matters. MCP tools add a round-trip: Claude decides to call the tool, the server executes, the result returns, Claude continues. For operations where speed matters or where you’ll be doing many calls in a sequence, think about whether that overhead is acceptable. Usually it is. Sometimes it isn’t.

Maintaining Your Stack

MCP servers need attention like any other dependency. Things that go wrong:

API changes break servers. Services update their APIs. Server code that worked six months ago may throw errors today. When a server starts failing mysteriously, check whether the underlying service changed. Sometimes there’s a newer version of the server package that handles it.

Credential rotation. API keys expire or get rotated. If a server stops working and was fine before, check your credentials. Add a reminder when you generate an API key to revisit it before it expires.

Version drift. Server packages get updates that add tools, fix bugs, or change behaviour. Running npm outdated in the directory where you’ve installed servers (or checking npm for packages you’re using via npx) will show you what’s behind.

Unused servers. Review your stack every few months. If you haven’t used a server’s tools in weeks, remove it. The configuration entry costs you nothing, but the cognitive overhead of maintaining a mental map of what’s available adds up.

Evolving the Stack

The right stack today won’t be the right stack in six months. Your work changes. Better servers get published. Things you thought you’d use turn out to be impractical; things you added tentatively become essential.

Build a habit of noticing when you’re copying information into Claude that you do repeatedly. That’s a signal that something should be an MCP server, or at least a CLI tool. Each time you automate that copy-paste, you get a small, permanent improvement to every future session.

That’s how the stack compounds. Not by installing everything at once, but by adding the right thing at the right time and keeping the noise down.

---

You now have the full picture: what MCP is, how to install servers, which ones are worth installing, how to build your own, and how to design a stack that works. The rest is practice.