Governing Agent Sprawl with MuleSoft: One-Click Detection of Duplicate APIs, MCP Servers, and AI Agents

When a "Registry" Can't Solve Agent Sprawl

As enterprise investment in APIs, MCP servers, and AI agents accelerates, a largely overlooked problem is coming into focus: asset sprawl. Fasir, a tech lead at KPMG, put his finger on the core issue during a conversation: "Everyone treats a registry as the cure for agent sprawl, but nobody provides a way to actually find the sprawl."

His ask was straightforward: give me a button that tells me which assets are unique, which are redundant, and which fall into a gray area. The reason this matters is simple — every duplicate asset costs the organization twice: once to build it, and again to keep running and securing it.

Building on that insight, the solution described in this article is built around the MuleSoft Anypoint platform, with the goal of making sprawl visible and actionable.

Comparing Assets by Meaning, Not Wording

Traditional asset inventories rely on naming conventions and text matching — an approach that breaks down quickly in real environments. Two APIs with identical functionality might be treated as separate assets simply because different teams named them differently.

The key differentiator here is that the system compares assets by the semantic meaning of their capabilities, not by string matching. It reads every asset in Anypoint Exchange, extracts all of its capabilities — every API operation, every MCP tool, every agent skill — and compares them at the semantic level. For ambiguous edge cases that are hard to call, a dedicated AI model acts as a "judge" to make the final determination.

The judge model is configurable: Flash serves as the fast default, while Pro offers deeper reasoning for boundary cases that require more nuanced judgment.

Three-Step Workflow: Scan, Assets, Sprawl

The entire solution breaks down into three clear steps: Scan, Assets, and Sprawl.

Everything starts with scanning Exchange. Users can freely choose what to include in scope — REST APIs, MCP servers, agents. One notable engineering detail: many MCP servers are published without a tool list attached. When that happens, the scanner connects directly to the running server and retrieves the tools it actually exposes in real time. Scanning runs in the background — no waiting around — and a full scan typically takes a few minutes.

The result is a complete inventory covering every asset in the catalog. The "capability count" indicates how many distinct things an asset can do; "source" identifies where those capabilities came from — an API spec, MCP metadata, or a live server connection.

What is MCP (Model Context Protocol)? MCP is an open protocol released by Anthropic in late 2024, designed to standardize how AI models interact with external tools and data sources. An MCP server is essentially a tool host that exposes a set of callable "tools" to AI clients — each tool comes with a name, description, and input parameter schema. Because the MCP protocol itself doesn't mandate that servers publish a tool list at registration time, many MCP servers in API catalogs carry only basic metadata; the tools they actually expose can only be retrieved at runtime through a protocol handshake. This is precisely why the scanner needs to connect directly to live servers to pull tool lists in real time — and why MCP asset governance is more complex than traditional REST API governance.

Four Status Labels: Understanding Every Asset's Situation

Each asset is assigned one of several status labels — this is where the solution's value is most concentrated:

Redundant: For example, an API that handles both "submit a life insurance application" and "check status" is flagged as redundant because another "new business submission API" in the catalog does exactly the same two things — 2/2, 100% coverage. That's potential sprawl.

Unique: Some SAP or MCP servers expose only a handful of operations from an underlying system API. These assets are genuinely one-of-a-kind.

Facade: When a team intentionally wraps an API with MCP capabilities, the scanner recognizes that pattern and labels it as a "facade" rather than mistakenly flagging it as a duplicate. The same logic applies to agents that call their own MCP tools.

Gray Area / Gaps: Assets published without a tool list or spec give the scanner too little detail to assess uniqueness. These are the prime candidates for remediation.

The "Facade" Pattern The facade pattern is a common and intentional design in microservice and API architectures — teams deliberately build different interface layers on top of the same underlying capabilities, such as offering an MCP wrapper for AI model consumption while keeping the original REST API for legacy systems. Without recognizing this, a sprawl detector would mistakenly flag these "two faces of the same thing" as redundant assets, leading teams to retire valuable interfaces. By identifying and separately labeling facade patterns, the system distinguishes between "accidentally duplicated assets" and "intentionally designed polymorphic interfaces," preventing governance actions from inadvertently breaking existing architecture.

Seeing the Full Picture: Search, Recommendations, and Heat Maps

Sprawl only becomes fully visible when you look at all assets together. In one example, the system identified 85 redundant assets, 72 unique assets, 59 gray-area assets, plus a number of undocumented ones.

The solution provides several practical governance tools:

Search Before You Build: Before starting any new development, teams should search the catalog. For example, searching for capabilities related to "create a support ticket" — if existing APIs, MCP servers, or agents already provide that capability, reuse them instead of rebuilding. This should become standard practice for every team.

Cleanup Recommendations: The system generates a prioritized to-do list. For instance, if four MCP servers are found to expose identical capabilities, the recommendation is simply: "consolidate into one."

Overlap Heat Map: The heat map visually shows which assets overlap with each other — the darker the cell, the more two assets do the same thing. Dark squares are the first targets for investigation. Starred assets are the recommended ones to standardize around; the rest are candidates for retirement.

Gray Area Adjudication: For capabilities that are similar but not necessarily identical, the AI judge model reads the descriptions and delivers a verdict with reasoning. For example, two interfaces that both handle "reservations" might be judged as distinct assets if they serve entirely different business objects (a golf course vs. a restaurant).

Closing Thoughts: The Governance Value Behind One Button

This solution ultimately answers Fasir's original ask — a single button that shows which APIs, MCP servers, and agents across the enterprise are unique and which are redundant. In a world where AI agents and the MCP ecosystem are expanding rapidly, managing asset sprawl is no longer optional; it's a necessity for controlling costs and reducing security risk. The combination of semantic comparison and an AI judge gives enterprises a practical path from mere "inventory" to genuine governance.

Technical Background

The semantic comparison relies on vector embeddings: the system converts the description text of each API operation or MCP tool into a high-dimensional numerical vector, where semantically similar content sits closer together in vector space. Traditional string matching only captures surface-level similarity in wording, while vector similarity calculations (such as cosine similarity) can recognize cases where "create a ticket" and "open a new service request" mean the same thing despite being worded differently. When a similarity score falls in the fuzzy zone between clearly similar and clearly distinct, relying on a hard threshold cutoff is prone to false positives — which is exactly why a large language model is brought in as a "judge." It can apply business context for finer-grained semantic reasoning, rather than mechanically comparing numbers.