The thesis: MCP servers are not free. Every one you connect consumes context and adds a surface where the agent can be misled. The right number for a working SaaS setup is small, maybe four or five, chosen because they answer questions the agent cannot answer from the repo alone. This is that shortlist, plus the argument that your own product should probably be one of them.
The rule for adding an MCP server
- State it up front: connect a server only when it gives the agent information that is not in the repo and that it would otherwise guess at.
- Argue the failure mode is context bloat, where twenty connected tools crowd out the code the agent actually needs to read.
- Add the second rule: prefer read-only scopes, because an agent with write access to production is a category of incident, not a productivity gain.
The servers that consistently earn their slot
Your database
- Argue this is the highest-value connection: real schema, real row shapes, real query plans, instead of the agent inferring from migration files.
- Insist on a read-only role against a development or branch database, never production write access.
- Cross-reference /blog/saas-database-decision-guide for why branchable databases make this safe.
Error tracking and logs
- Argue this closes the loop from "user reports a bug" to "agent reads the stack trace and reproduces it" without a human transcribing anything.
- Note this is where agents most clearly outperform, because the tedious part is correlating, not fixing.
Documentation for your exact versions
- Argue the single biggest cause of confidently wrong code is training-data drift against fast-moving SDKs.
- A docs server pinned to your versions is a cheap fix for a whole class of hallucinated APIs.
Your issue tracker
- Argue this earns its slot only if issues are written well enough to be specs, and is noise otherwise.
Browser or preview environment access
- For UI work, being able to load the running app and read the console turns a guess-and-check loop into a verification loop.
The servers that usually do not earn a slot
- Argue against connecting everything: broad search tools, chat platforms, and general-purpose file services usually add context cost without answering a question the repo cannot.
- Name the specific anti-pattern of connecting a server for a task you do once a month rather than enabling it on demand.
- Make the point that a lean, deliberately chosen set outperforms a maximal one.
Security, stated plainly
- Cover the real risks: over-scoped tokens, production write access, and prompt injection through data the server returns.
- Argue that content returned by an MCP server is untrusted input, and that an agent acting on instructions found inside a database row is a live risk, not a theoretical one.
- Give the mitigations: least privilege, separate credentials per environment, and human confirmation on anything destructive.
Shipping an MCP server for your own product
- Make the forward-looking argument: as buyers increasingly work through agents, a product an agent can call is a product that gets used inside workflows it otherwise would not reach.
- Cover what a good product MCP server exposes: the core actions, read access to the user's own data, scoped auth, and clear tool descriptions.
- Argue tool descriptions are user-facing copy now and deserve the same care as API docs.
- Link /blog/ai-agent-ready-boilerplate-checklist for the codebase side and /agents for the surrounding ecosystem.
How this fits the rest of the agent setup
- Position MCP as one layer among instruction files, skills, and subagents, and argue against reaching for MCP when a skill or a script would do.
- Reference /blog/setting-up-claude-code-for-a-new-project for the base setup and /claude-skills for the skills layer.
- Note that boilerplates are starting to ship MCP configuration, and point at /categories/Agent-Ready.
Frequently Asked Questions
How many MCP servers should I connect?
- Answer with a small number and the reasoning: each one costs context, so add on evidence of repeated need.
Is it safe to connect my database over MCP?
- Answer: yes with a read-only role on a non-production database, no otherwise, and explain the branch-database pattern.
Do I need MCP if I already use Claude Code well?
- Answer: not for code changes, yes for anything requiring live system state the repo does not contain.
Should my SaaS expose its own MCP server?
- Answer conditionally on whether your product has actions an agent would want to take on a user's behalf, and describe the minimum viable version.
What is the biggest MCP security mistake?
- Answer: over-scoped production credentials, followed by treating tool output as trusted instructions.
