MCP Is Making API Sprawl Worse

Art Anthony · rss · 2025-01-01 source ↗ Reader 🖥️

Agent Governance (Internal)Agent Security API Products & Sprawl MCP (Model Context Protocol)

MCP introduces a new abstraction layer over APIs that amplifies existing API sprawl and governance challenges rather than solving them, because each MCP server becomes an additional unmanaged surface; but the same agentic AI driving the problem could also power the automated discovery, cataloging, and governance needed to finally bring sprawl under control.

practical · conference-talk recap / industry analysis — summarizes Rogier van Boxtel's (Axway) talk at the 2025 Nordic APIs Platform Summit on how MCP amplifies API sprawl — Primarily a journalist synthesis of a conference presentation, supplemented with survey data (VansonBourne, Traceable, Metosys). Genre: trade-press industry analysis with embedded vendor perspective.

Structure

Part	Role
API sprawl is a huge problem	Establishes the baseline: enterprises already do not know how many APIs they have (80% per VansonBourne), and microservices have made the problem exponentially worse.
Ongoing API governance challenges at scale	Quantifies the consequences: 55% of orgs manage 500+ APIs, 57% experienced API-related breaches in two years, and governance at scale is already failing.
Automating API analysis	Introduces agent-based automated discovery and service registries as a partial solution, while acknowledging that MCP's immaturity and multi-platform reality limit what automation can cover.
AI could be the sugar and the medicine	Frames the duality: MCP creates managed, third-party, and unmanaged server tiers that mirror today's API categories, but expose actions rather than just data — raising stakes. Simultaneously, agentic systems could enforce governance at scale.

Key terms

API sprawl API Products & Sprawl
The uncontrolled proliferation of APIs across an organization to the point where no one has a complete inventory, leading to security, quality, and governance blind spots.
MCP (Model Context Protocol) MCP (Model Context Protocol)
An emerging protocol that allows AI agents to interact with backend systems through a standardized interface, introducing a new abstraction layer on top of existing APIs.
API sprawl squared API Products & Sprawl
Axway marketing's characterization: MCP doesn't just add APIs, it multiplies the sprawl problem by adding a whole new layer of unmanaged endpoints (MCP servers) on top of existing API surfaces.
federated API management layer API Products & Sprawl
A governance architecture where a unified policy/discovery layer spans multiple underlying API gateways, event platforms, and legacy systems — providing a single view despite heterogeneous infrastructure.
shadow APIs / unmanaged MCP servers MCP (Model Context Protocol)
APIs or MCP servers deployed without going through formal governance processes — invisible to security, compliance, and inventory systems.

Propositions

explicitdevelopedAlmost 80% of enterprise decision-makers do not know how many APIs their organization has, which means they also cannot assess the quality, security, or necessity of those APIs.conf: high
extends ←Coherence, Connections, and… Spacetime Crystals · p5 — Faull's prescription that mapping is a necessary first step directly addresses the diagnosed problem in the other document — that ~80% of enterprises don't even know how many APIs they have, i.e. lack the basic visibility mapping requires.
explicitdevelopedMCP introduces a new abstraction layer over APIs, and when we introduce more abstraction we risk losing sight of the systems operating below the surface.conf: high
extends ←Presentation: APIs for Agents: Rethinking API Programs in the MCP Era · p1 — Both agree MCP layers a new abstraction over APIs; this talk adds the practitioner claim that the protocol layer itself is trivial and the real cost is orchestration/abstraction management, not the protocol.
explicitdevelopedWhere APIs expose data, MCP exposes actions — and that comes with a very different (higher) risk profile.conf: high
refines ←AAIF's MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening · p2 — Answers the action/write-risk warning by specifying the remedy: mutations must live in a deterministic action layer, never in the LLM's probabilistic reasoning.
extends ←AAIF's MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening · p2 — Takes the 'MCP exposes actions, not just data' risk observation and prescribes the fix: mutations must live in a deterministic action layer, not the LLM.
extends ←MCP Is Not Just Another API Standard · p5 — Extends the 'MCP exposes actions, not just data, so it carries a higher risk profile' claim by locating the mechanism specifically in who composes integration logic and when (runtime agent composition vs. pre-agreed contract), rather than just the action-vs-data distinction.
explicitestablished43% of MCP servers are vulnerable to authentication flaws and 33% allow unrestricted network access.conf: medium
supports ←Agent Tools & Interoperability · p9 — The empirical finding that 43% of MCP servers carry authentication flaws backs up this whitepaper's best-practice warning to audit public MCP servers and avoid trusting unverified community endpoints in production.
supports ←AAIF's MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening · p5 — Summit's finding that DNS-rebinding-class vulnerabilities are systemic (protections off by default in the SDK) corroborates the earlier statistic that 43% of MCP servers have auth flaws.
explicitestablishedThe same agentic AI systems that are making sprawl worse could also be used to monitor and enforce governance at scale — automated discovery pushing assets into service registries.conf: medium
extends ←Fighting Tool Sprawl: The Case for AI Tool Registries · p2 — Develops the registry suggestion into a full thesis: a centralized tool registry is the precondition for coordinating agent-tool security at all.
supports ←Fighting Tool Sprawl: The Case for AI Tool Registries · p2 — A centralized registry as a precondition for security concretizes the idea that pushing assets into service registries is the means to enforce governance at scale.
extends ←Google and Industry Partners Announce Agentic Resource Discovery Specification for AI Agents · p2 — Van Boxtel speculated that agentic AI could power 'automated discovery pushing assets into service registries' as a future governance mechanism. ARD's catalog-and-registry design is a standardized, multi-vendor realization of exactly that speculative mechanism, now formalized as an open spec rather than a hoped-for capability.
supports ←AAIF's MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening · p1 — The summit confirms the registry-based governance that the sprawl piece predicted agentic systems could enforce at scale — gateway+registry is now the consensus control plane.
explicitdevelopedMCP's formal governance model was still evolving as recently as July 2025, which means observability tools cannot yet rely on a consistent interface across different MCP implementations.conf: high
refines ←AAIF's MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening · p1 — Updates the governance-immaturity picture: the gateway-plus-registry consensus now supplies the consistent control-plane interface the earlier article said was still missing.
explicitThe pattern of managed, third-party, and unmanaged MCP servers will mirror today's API sprawl categories — but with higher stakes because MCP exposes actions.conf: high
implicitAdditional layers of developer accountability (such as the Shell anecdote where scheduled reviews caused APIs to be voluntarily rolled back) can improve API quality even without technical enforcement.conf: medium
explicitThe trends shaping 2026 (agentic AI, event-driven chaining, MCP proliferation) threaten to make the outcomes of failing to address API sprawl far more catastrophic than in earlier eras.conf: medium
explicitcontestedYou cannot easily automate the entire API governance process because MCP is still an emerging standard and multi-platform IT landscapes resist single-layer governance.conf: high
contradicts ←AAIF's MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening · p1 — The summit reports enterprise consensus on a single gateway+registry control plane for all agent interactions — the single-layer governance the sprawl piece claimed multi-platform landscapes resist.
contradicts ←Presentation: APIs for Agents: Rethinking API Programs in the MCP Era · p8 — That proposition holds API governance can't easily be automated given how emergent MCP still is; this talk's account of compressing time-to-production from six months to one to two weeks via automated security approvals is a concrete counter-example within a single, controlled enterprise estate.

Arguments

MCP amplifies API sprawl rather than solving it. strength: medium

Explicit premises:

API sprawl is already severe — 80% of enterprises lack full API inventories.
MCP adds a new abstraction layer on top of existing APIs.
New abstraction layers increase the number of unmanaged endpoints.
MCP servers will follow the same managed/third-party/unmanaged pattern as APIs.

Implicit premises:

Organizations that cannot govern existing APIs will not spontaneously develop the capacity to govern an additional MCP layer.
Abstraction layers compound rather than replace governance burdens.

Inferences:

Since organizations already cannot manage their API inventories, adding MCP servers on top will make the governance gap worse, not better.

MCP's exposure of actions (not just data) raises the risk profile compared to traditional API sprawl. strength: medium

Explicit premises:

Traditional APIs expose data.
MCP exposes actions — agents can take actions on behalf of users.
43% of MCP servers have auth flaws; 33% allow unrestricted network access.
Agentic AI has a reputation for acting unpredictably.

Implicit premises:

Unauthorized actions are more damaging than unauthorized data reads.
The combination of unpredictable agents and insecure action-oriented endpoints creates a multiplicative risk.

Inferences:

Unmanaged MCP servers are more dangerous than unmanaged REST APIs because they enable autonomous action, not just data exposure.

Automated, agent-based governance may be the solution to the problem agents are creating. strength: low

Explicit premises:

Manual API review does not scale (Shell anecdote shows it works but is labor-intensive).
Automated discovery using agents can push assets into service registries.
A federated management layer can provide unified visibility across heterogeneous platforms.

Implicit premises:

The same AI capabilities that drive MCP adoption can be repurposed for governance enforcement.
Service registries and marketplaces can provide the organizational visibility that is currently missing.

Inferences:

If the governance problem is fundamentally one of scale and discovery, then agent-based automation is a natural fit — making AI both the cause and the cure.

Narratives

A senior manager at Shell pushed all APIs through a DevOps pipeline and scheduled follow-up meetings about security and business impact. Many APIs were voluntarily rolled back before the meetings took place.
→ Illustrates that governance through social accountability (scheduled scrutiny) can be effective even without technical enforcement — but implies this approach cannot scale.
The historical arc from SOAP to REST to microservices to MCP — each era solving one problem while creating new sprawl.
→ Frames MCP not as a unique disruption but as the latest iteration of a recurring pattern: each abstraction layer solves integration problems at one level while creating ungoverned proliferation at the next.

Questions addressed

✅ How does MCP relate to existing API sprawl?
MCP is the next layer of API sprawl — it adds abstraction on top of existing APIs, creating new unmanaged surfaces while the underlying sprawl persists.
✅ Why is MCP sprawl potentially worse than traditional API sprawl?
Because MCP exposes actions rather than just data, combining with unpredictable agentic behavior and widespread auth vulnerabilities to create a higher-stakes risk profile.
⭕ Can automation solve the governance problem at scale?
Partially — agent-based discovery and service registries are proposed, but MCP's immaturity and multi-platform heterogeneity limit current automation capabilities. Full automation is not yet achievable.
⭕ What specific governance architecture should organizations adopt for the MCP era?
A diagram is shown (federated gateway + service registry + marketplace) but no implementation guidance, case studies, or evaluation criteria are provided.
⭕ Is MCP itself the problem, or is the underlying organizational dysfunction the real issue?
Not directly addressed — the article treats MCP as an amplifier but does not explore whether fixing organizational governance would neutralize MCP-specific risks.

Gaps

implicit premiseThe article assumes that MCP servers will proliferate in the same uncontrolled way that REST APIs did. But MCP is more centralized by design (MCP servers mediate access to tools rather than each tool exposing its own endpoint). The sprawl dynamic may be structurally different — fewer but more powerful servers rather than many small endpoints. The 'sprawl squared' framing may overstate the problem if MCP consolidates rather than fragments integration points.
Read next: Analysis of actual MCP deployment patterns in enterprises; comparison of MCP server proliferation rates vs. REST API proliferation rates in early adoption.
closed byAAIF's MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening — Reports actual enterprise MCP deployment patterns: the ecosystem is consolidating behind gateways and registries as a single control plane rather than fragmenting into uncontrolled REST-style sprawl.
missing evidenceThe core claim — that MCP is making sprawl worse — is supported by analogy and projection rather than empirical data. No organization is cited as having experienced MCP-specific sprawl. The Metosys vulnerability statistics are about MCP server security, not about proliferation/sprawl specifically.
Read next: Early case studies of enterprise MCP adoption; data on MCP server counts vs. API counts in organizations that have adopted both.
closed byFighting Tool Sprawl: The Case for AI Tool Registries — Provides the missing empirical grounding: Gravitee survey data (88% incident rate, 14.4% full security approval) and documented duplicate-tool dynamics show agent-tool sprawl materializing in enterprises.
unasked questionThe article never asks whether MCP might actually reduce sprawl by consolidating many point-to-point API integrations behind a smaller number of MCP servers. If an MCP server wraps 50 APIs into a coherent tool interface, the total integration surface might shrink even as a new layer is added. The article's framing assumes addition without considering consolidation.
Read next: MCP architectural patterns; whether organizations deploying MCP servers reduce their direct API-to-API integration count.
closed byAWS MCP Server Reaches GA with Full API Coverage and IAM-Based Governance — Instantiates the gap's unasked consolidation hypothesis at the largest possible scale: a single hosted MCP server wrapping AWS's entire API surface, shrinking agent integration points rather than multiplying them.
vendor perspectiveThe primary expert voice (Rogier van Boxtel) is from Axway, an API management platform vendor. The 'API sprawl squared' framing directly supports the business case for purchasing API governance tooling. The article does not flag this conflict of interest or seek counterbalancing perspectives from organizations that view MCP as simplifying their integration landscape.
Read next: Non-vendor perspectives on MCP governance; open-source governance approaches; perspectives from organizations that adopted MCP and found it reduced complexity.
closed byAAIF's MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening — Supplies the requested non-vendor MCP governance perspective: a standards-body summit converging on gateway+registry control planes, SEP proposals, and working-group hardening rather than a single API vendor's framing.
tensionThe article concludes optimistically that the pressure of MCP-amplified sprawl 'may be just the pressure that teams need to finally bring API sprawl under control.' But the entire preceding argument establishes that organizations have failed to solve sprawl for over a decade despite growing consequences. No mechanism is identified that would make this time different beyond 'the stakes are higher now.'
Read next: Research on organizational behavior under existential vs. incremental risk; whether catastrophic failure scenarios actually drive governance adoption or just insurance purchases.

MCP Is Making API Sprawl Worse

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents