Most teams approaching MCP ask the wrong question:
Should we run one MCP server or ten?
The real question is:
Where are your trust boundaries?
After looking at dozens of MCP deployments, I've noticed that server count is rarely the actual problem.
The problem is governance.
When AI agents gain access to tools, an MCP server stops being just an integration layer. It becomes a capability boundary.
A single MCP server might expose:
- customer data
- billing operations
- infrastructure controls
- support workflows
From a developer perspective, that feels convenient.
From a security perspective, it's a nightmare.
The Common Mistake
Many teams organize MCP servers around technical convenience:
- one server per API
- one server per agent
- one giant "tools" server
This works during experimentation.
It starts breaking down once:
- multiple teams are involved
- approvals are required
- audit logs matter
- production systems are connected
At that point, the important question becomes:
Who owns these tools?
Who approves access?
What credentials do they use?
What happens if an agent makes a mistake?
The Pattern That Makes Sense
The model I've seen work best is:
Split MCP servers by business domain.
For example:
Engineering MCP
- GitHub
- CI/CD
- deployment status
Support MCP
- customer lookup
- ticket history
- draft responses
Billing MCP
- invoices
- subscriptions
- refund requests
Then separate dangerous actions from read-only tools.
Read access scales differently from write access.
A tool that reads an invoice and a tool that issues a refund should rarely live in the same trust boundary.
What Changes In Production
As MCP deployments grow, architecture decisions become security decisions.
The conversation shifts from:
"How do we generate tools?"
to:
"How do we control them?"
That's where concepts like:
- tool permissions
- approval workflows
- audit logs
- credential isolation
- side-effect detection
become more important than tool generation itself.
The hardest production problems aren't technical.
They're governance problems.
My Rule Of Thumb
For most teams:
- Prototype → 1 MCP server
- Internal pilot → 1–3 MCP servers
- Production → split by domain and risk
Not because more servers are inherently better.
Clear boundaries are easier to understand, audit, secure, and operate.
The best MCP architecture isn't the one with the fewest servers.
It's the one where every server has:
- a clear purpose
- a clear owner
- a clear permission model
- a clear audit trail
That's what scales.
Full article:
👉 https://www.mcpforge.tech/blog/how-many-mcp-servers-should-you-run
Top comments (0)