Integrating MCP at Scale: What Changes After the First 100 Users
The first MCP integration feels magical. A handful of users connect an agent. A few workflows work. Leadership asks when you can "roll it out."
After the first hundred agent users, the questions change.
This post is for founders and product owners who need scalable MCP integration — not another protocol deep dive.
What "scale" means for MCP
Scale is not "more endpoints." Scale is:
- More concurrent agent sessions
- More tenants with different data boundaries
- More tool calls per workflow
- More ways to fail in public
If your design only works when one engineer is watching, it isn't scaled. It's staged.
What breaks after ~100 agent users
Tool sprawl becomes a product bug
Agents choose poorly when they see too many tools. Support tickets sound like "it used the wrong action." The fix is product discipline: fewer tools, clearer names, workflow-shaped design.
Token cost shows up on the P&L
Huge responses are fine in a demo. At volume they inflate AI bills and slow agents down. Return only the fields that matter. Paginate. Treat response size like UX.
Auth and tenancy stop being theoretical
Wrong-customer data is an existential risk. Every call needs a clear tenant boundary. Shared "company" API keys across customers will eventually hurt you.
Sticky sessions become infra tax
Older MCP designs pinned clients to a server instance. That forces sticky load balancers or Redis session stores. Instance death equals broken sessions. At scale, that's downtime you can't explain to customers.
The 2026-07-28 specification removes that tax by making MCP stateless. Plan for it now — details in The Stateless Evolution of MCP and the buyer-facing migration guide below.
Support load shifts shape
Users stop saying "the button is broken." They say "the agent did the wrong thing." You need logs, ownership, and recovery paths — or MCP becomes a reputation risk.
Principles for scalable MCP
- Any request, any server — no session pinning
- State in your product — IDs in tool args, workflows in your DB
- Follow-ups as round trips — confirmations without open connections
- Long work as tasks — don't block HTTP for minutes
- Curate relentlessly — 5–10 tools beat 50
- Measure one outcome — successful workflows, not vanity call counts
A practical scale roadmap
| Stage | Users | Focus |
|---|---|---|
| Pilot | <25 | Prove 3–5 workflows + auth |
| Early | 25–100 | Add observability, rate limits, support owner |
| Scale | 100+ | Stateless infra, tenancy hardening, cost controls |
| Expansion | 500+ | More workflows only after the core set is boring |
Don't expand the tool surface to celebrate growth. Expand when the current surface is reliably dull.
What to send your team (or vendors)
Ask for a plan that covers:
- Workflow list (not endpoint list)
- Auth + tenancy model
- Stateless hosting target
- Rate limits and rollback
- Support ownership
- Cost controls for response size
The free MCP Production Playbook packages those into checklists you can forward. Enter your email and we'll send the guide.