Field note 03 · revised July 2026
The MCP adoption tax.
MCP standardizes how AI applications connect to tools and context. It does not run the production boundary around those connections. When every server team solves that boundary alone, adoption gets slower with each new server.
This is a planning model, not an industry benchmark. Set it to your server count below.
The claim
MCP defines the connection. Your company still has to operate it.
MCP defines lifecycle, capability negotiation, tools, resources, prompts, and transport rules. For remote HTTP servers, it also defines an authorization flow based on OAuth. It does not choose your access policy, broker downstream credentials, connect private networks, send evidence to your security tools, or run incident response. The adoption tax appears when every server team creates and reviews a separate answer to those production concerns.
Connection authentication
who is connectingDelegated authorization
who may act for whomCaller identity
owned and scopedTool access policy
rules for each actionCredential brokering
secrets stay controlledPrivate connectivity
reach internal systemsDiscovery controls
who can see which toolsAudit trail
record every decisionSecurity export
send evidence to the SIEMSession lifecycle
resume and revokeRate and cost limits
bound automated useHealth and metrics
operate the boundaryIncident controls
contain and recoverThese are work areas, not thirteen libraries.
Some belong in the host, some in the server, and some in shared infrastructure.
The repeated boundary creates the tax.
Who owns what
A shared boundary should centralize common controls, not absorb every decision.
A credible MCP platform has clear ownership. The host controls user consent and connection permissions. Each server keeps its domain rules and tool behavior. Shared infrastructure handles controls that should work the same way across every server.
- Choose which servers may connect
- Control which capabilities enter model context
- Ask for user consent when needed
- Apply approval rules to each call
- Define useful tool names and schemas
- Validate every input
- Enforce domain authorization
- Call downstream systems correctly
- Connect identity and policy systems
- Broker credentials and private routes
- Filter discovery and enforce common limits
- Record decisions and support revocation
MCP authorization applies to HTTP connections. Local stdio servers normally receive credentials from their environment. Both still need clear trust, access, and operating rules.
Planning model
Set your server count. Compare the operating models.
The model uses thirteen recurring work areas, sixteen illustrative engineer-weeks, and one review track for each independent server boundary. These numbers are placeholders. Replace them with your own build, integration, review, and operating estimates. The useful result is the multiplication.
the sprawl
Each independent server boundary repeats the same thirteen control and operating work areas shown above.Each column repeats the same thirteen control and operating work areas.
the model · per server
4 server review tracks to coordinate
Flip the switch. Amelfi centralizes common controls. Each server still owns its tool semantics, input validation, domain authorization, and downstream behavior.
See the controlsThis is not a benchmark or a promise of zero marginal work. A shared boundary reduces repeated control work and review effort. Server teams still build and operate behavior specific to their domain.
The full cost
Build time is only the first line in the budget.
The expensive part is repeated ownership. Every independent boundary needs integration, review, evidence, upgrades, support, and a way to revoke access. Teams also make different choices, so security and platform engineers must understand several control models instead of one.
- Connect identity and downstream systems
- Define policy and approval rules
- Complete security review
- Prove the server can be revoked
- Patch protocol and SDK changes
- Rotate credentials and certificates
- Monitor errors, latency, and usage
- Investigate policy and tool failures
- Find the affected callers and tools
- Stop new calls quickly
- Revoke sessions and credentials
- Export evidence for investigation
Official sources
Protocol facts and planning assumptions are separate.
The claims about MCP scope and authorization come from the official documentation. The effort numbers in the model are our assumptions. They do not come from these sources.
Share the common controls
Let server teams build capabilities. Give them one production boundary.
See how Amelfi centralizes policy, credentials, discovery controls, and audit evidence while each MCP server keeps its domain logic.