TL;DR: MCP feels like overhead on the first and second integration, but the economics flip around the third or fourth service as bespoke adapters, schema drift, and repeated auth flows compound across agent surfaces, according to Archestra research. The real value is shared discovery and reusable tooling, while the remaining tradeoff is that users must manage which servers the agent can access.
At a glance
What this is: This is an opinionated analysis of when MCP becomes worth the integration cost, with the key finding that the protocol starts to pay off after multiple agent integrations instead of a single one.
Why it matters: It matters because IAM and NHI teams need to judge whether repeated service integrations should stay as bespoke API calls or move into a governed protocol layer with shared access and schema handling.
Context
MCP creates a shared tool surface for AI agents, but that shifts the design question from whether a single integration works to whether repeated integrations can be governed consistently. The article frames the core tension as simple implementation convenience versus a reusable protocol layer that can scale across services and agent surfaces.
The governance issue is not protocol novelty on its own. It is whether teams are willing to move from hand-coded per-service access patterns to a shared MCP governance model that makes discovery, schema handling, and access control reusable rather than bespoke.
Key questions
Q: When does MCP become worth using instead of direct API calls?
A: MCP becomes more defensible when repeated integrations start to create duplicated auth handling, schema maintenance, and tool definitions across multiple services or agents. The tipping point is usually not the first integration. It is when the same patterns begin to repeat often enough that reuse, discovery, and shared governance reduce more work than direct calls save.
Q: Why do direct API integrations create more risk as agent use expands?
A: Direct integrations tend to scatter access logic and tool definitions across code, prompts, and service-specific adapters. As the number of agents and services grows, that makes schema drift, inconsistent permissions, and brittle retries harder to detect and govern. The risk is not just complexity. It is fragmented control over what the agent can actually do.
Q: What breaks when every agent integration is custom-built?
A: What breaks first is consistency. Each new service needs its own auth path, retries, and tool description, so changes in one place do not automatically propagate to the others. That leads to duplicated governance decisions and hidden regressions when upstream schemas change. The larger the environment, the less sustainable the custom model becomes.
Q: How should teams govern agent access when both CLI and MCP are available?
A: Govern them separately, because they expose different execution patterns. CLI is usually easier to inventory, validate, and retire, while MCP can preserve state across multiple actions and therefore needs tighter session controls. Access reviews should include interface type, exposed tools, and how state is retained or discarded.
Technical breakdown
Why direct API integrations stop scaling after a few services
A direct API call works well when one agent talks to one service, because the developer can hard-code auth, parameter shapes, and retries into a single path. The scaling problem appears when every service introduces its own auth flow, pagination, schema quirks, and retry behaviour. At that point, each integration becomes a one-off adapter, and every schema change risks silent drift in agent behaviour. The architecture is not failing because APIs are bad. It is failing because the agent has no shared tool contract and no reusable discovery layer.
Practical implication: treat the third and fourth service integrations as the point where bespoke adapters start becoming operational debt.
How MCP changes the tool surface for agents
MCP moves tool definitions out of scattered prompts and into a shared protocol layer with schemas and transport. That means the agent can discover available tools at runtime rather than relying on the application author to prewire each path. In practice, this changes the integration model from per-service glue to server reuse. The important distinction is that MCP does not remove the need for trust decisions. It changes where those decisions sit and how many times teams have to repeat them across services and agents. Read OWASP Agentic Applications Top 10.
Practical implication: centralise tool descriptions and access boundaries so multiple agents can reuse the same governed service surface.
Why the tradeoff shifts from engineering effort to access governance
Once MCP becomes the shared integration layer, the bottleneck is no longer just code maintenance. It becomes who can connect which servers, what the agent may discover, and how much scope each server exposes. The article notes that this can be a real onboarding cost for consumer use, but an acceptable governance tradeoff for internal tooling. In security terms, the protocol moves some control from the application codebase into the access model around servers and server selection. See the AI Agent Authorisation Guide.
Practical implication: define server allowlists and scoped access rules before you standardise on MCP for production agents.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MCP is becoming a governance layer, not just an integration convenience: The article shows that the protocol only looks optional when teams have one or two services and no reusable agent surface to govern. Once multiple agents consume the same service set, the control problem shifts from coding effort to consistent access and schema governance. The practitioner takeaway is that MCP should be evaluated as an identity and access boundary, not only as a developer convenience.
The real architectural break point is repeated service reuse: A hand-rolled adapter model can survive a single workflow, but it accumulates hidden complexity every time a new agent or service is added. That creates a shared tool surface problem, where the organisation needs one controllable integration layer instead of many fragile ones. The implication is that governance teams should watch for duplicated auth logic, duplicated schemas, and duplicated tool definitions before the sprawl becomes hard to unwind.
Protocol standardisation does not remove trust decisions, it relocates them: MCP does not eliminate the question of which servers an agent may see or use. It makes those choices more explicit and more reusable, which is useful only if access boundaries are defined with the same care as the tool schema. The practitioner conclusion is that protocol adoption without server governance simply creates a cleaner path to the same old sprawl.
Shared discovery changes the economics of agent scaling: The article’s central argument is that discovery becomes valuable when multiple agents need the same services and each new service no longer justifies bespoke code. That is the point where the protocol can replace a pile of custom integrations with a reusable operating model. Security teams should read that as a signal to align platform design, access policy, and tool lifecycle management before adoption spreads.
Archestra's analysis also exposes a nameable control problem: protocol sprawl debt: The article describes how scattered schemas, per-service auth handling, and duplicated tool definitions become harder to govern as the number of agent surfaces grows. That is not a product issue. It is a lifecycle issue in how tool access is introduced, reused, and maintained. Practitioners should treat that debt as part of the identity programme, not as a side effect of developer ergonomics.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Protocol sprawl debt: When every service gets its own schema, auth path, and retry logic, the hidden cost is not just code maintenance. It is the loss of a single governed surface for agent access, which makes scaling harder to control than to build.
MCP changes the programme question from 'can the agent call this service?' to 'who is allowed to discover and reuse this service surface?'. That shift matters because access governance now sits alongside integration design, not after it.
24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026. That figure reinforces why protocol adoption without secrets governance is not a neutral architectural choice.
For practitioners
- Map where bespoke adapters are already compounding Inventory agent integrations that each carry separate auth, pagination, and schema handling so you can see where maintenance cost is already repeating across services.
- Define server allowlists before standardising on MCP Set explicit rules for which servers each agent can discover and use, especially where internal tooling and consumer-facing workflows have different trust requirements.
- Separate tool schema governance from application code Move tool descriptions into a managed layer so schema changes do not depend on scattered prompt strings or one-off adapter logic.
- Review onboarding friction for non-technical users If end users must choose servers, document the approval and default-selection process so access decisions remain understandable and supportable.
Key takeaways
- MCP is most useful once repeated integrations create enough duplication that reusable discovery and shared schemas reduce real operational burden.
- The main governance issue is not whether one agent can call one service, but who can discover, reuse, and control a shared tool surface.
- Protocol adoption can simplify development while increasing the need for clear server allowlists, ownership, and access boundaries.
Related NHI Mgmt Group resources: OWASP Agentic Applications Top 10 · AI Agent Authorisation Guide · Agent Identity Standards Tracker
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | MCP servers create reusable non-human access surfaces that need explicit trust and ownership boundaries. |
| Recommendation — Treat shared MCP servers as governed non-human access surfaces and review their trust boundaries before reuse. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on how agent access and tool reuse expand the privilege surface across integrations. |
| Recommendation — Constrain agent tool access so privilege does not expand each time a new service is added. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about controlling who and what can access shared agent-facing services. |
| Recommendation — Define and enforce explicit permissions for every MCP server and agent interaction path. | ||
| NIST Zero Trust (SP 800-207) | least privilege — Least Privilege | MCP adoption changes how least privilege must be applied across shared service surfaces. |
| Recommendation — Apply least privilege at the server boundary so agent access stays scoped to specific tasks and services. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Tool Surface: The tool surface is the set of commands, APIs and connected services an AI agent can invoke at runtime. It is a governance boundary because each tool expands what the agent can do, and therefore expands what an attacker can abuse if they gain control of the runtime.
- Schema Drift: Schema drift is the mismatch between the attributes an IdP sends and the fields an application can store or interpret. It often appears as missing custom fields, inconsistent group data, or varying attribute names, and it undermines the reliability of lifecycle automation even when the core protocol works.
- Server allowlist: An approved list of servers or services an agent is permitted to discover and use. It is a governance control that narrows the agent's reachable surface, making access decisions explicit instead of leaving them implicit in default connectivity.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org