Layered MCP tool design shows why endpoint mapping does not scale

At a glance

What this is: This is a recap of Block’s MCP Night 2.0 demo showing that a layered tool pattern can collapse a 200-plus endpoint API surface into three MCP tools.

Why it matters: It matters because IAM teams now have to govern how AI agents discover, plan, and execute against tools, not just how credentials are issued to them.

By the numbers:

• 30 APIs with 200+ endpoints.

👉 Read WorkOS’s recap of Block’s layered MCP tool pattern demo

Context

MCP tool sprawl becomes a governance problem when every API endpoint is exposed as a separate action surface for an AI agent. The primary issue is not just usability, but control of what the agent can discover, combine, and execute at runtime across the Model Context Protocol layer.

Block’s example shows why conventional endpoint-by-endpoint mapping is a poor fit for large API estates. Once tool design begins to mirror the underlying API surface too closely, teams inherit excessive context consumption, brittle workflows, and a wider review burden for both NHI and agentic access.

The result is a clearer pattern for practitioners: treat MCP tool design as a policy and workflow boundary, not a simple wrapper around existing APIs. That distinction matters for any programme that has to govern machine access, delegated permissions, and AI-driven execution together.

Key questions

Q: How should security teams govern MCP tools for large API platforms?

A: Start by treating MCP tools as governed task boundaries rather than direct API mirrors. Limit discovery surfaces, keep execution tools narrow, and separate validation from action so that the agent cannot freely assemble high-risk workflows from low-level endpoints. This makes the control model easier to review, audit, and change.

Q: Why do large MCP tool catalogs create identity and access risk?

A: Large catalogs increase the chance that an agent can discover more than it should, combine permissions across services, or consume so much context that operators lose clarity over what was actually invoked. The risk is not just scale. It is uncontrolled composition of delegated access across multiple tools and systems.

Q: What breaks when every API endpoint becomes its own MCP tool?

A: The architecture becomes brittle, noisy, and hard to govern. Operators inherit excessive tool counts, more failed calls, and more review burden because the agent is forced to navigate technical surface area instead of business tasks. Over time, that weakens both reliability and authorisation discipline.

Q: How can organisations balance MCP flexibility with control?

A: Use a small number of layered tools for discovery, planning, and execution, then define which combinations are allowed within policy. That preserves flexibility for the agent while keeping the final action path auditable and bounded. The goal is controlled delegation, not unrestricted endpoint exposure.

Technical breakdown

Why endpoint-to-tool mapping breaks down in MCP servers

A direct mapping from REST endpoints to MCP tools exposes too much implementation detail to the agent and to the operator who must govern it. In a large API estate, that creates noisy tool catalogs, repeated failed calls, and inflated context usage. The problem is structural: the agent is forced to reason over low-level service boundaries instead of business tasks, which makes both orchestration and oversight harder. For identity teams, this is the point where tool design starts to shape the effective permission model.

Practical implication: reduce exposed tool count by grouping related actions into governed task layers instead of publishing every endpoint separately.

How the discovery, planning, and execution layers change agent behaviour

The layered tool pattern separates three decisions that are often collapsed into one. Discovery tells the agent what exists, planning determines the required inputs and dependencies, and execution performs the action with validated parameters. That separation reduces blind retries because the agent can resolve sequence and dependency before calling the transactional tool. From a governance perspective, the model creates a clearer control plane because policy can sit differently at each layer, rather than being smeared across hundreds of endpoints.

Practical implication: place tighter authorization and validation on execution tools than on discovery tools, and log each layer separately.

MCP tool design is becoming a delegated identity control problem

When an AI agent can independently discover services, plan multi-step work, and execute actions, the practical question is no longer just what the API can do. The question becomes what the delegated identity is allowed to infer, assemble, and trigger in sequence. That makes tool design part of the authorisation boundary, especially where an agent can chain requests across systems. In other words, the control gap is not only access to a tool, but the composition of action from multiple tools.

Practical implication: review MCP architectures as delegated access chains and define which combinations of tool use remain within policy.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Layered MCP design is a tool-governance pattern, not a convenience pattern. The core value of Block’s example is that it redefines the control surface around tasks rather than endpoints. That is a better fit for large API estates because it reduces the number of exposed actions without requiring every underlying service to become a first-class tool. Practitioners should treat this as a design principle for governing tool sprawl in AI-connected environments.

Tool granularity is becoming part of the privilege model. If an agent can see 200 endpoints, the governance problem is not just scale, but the opportunity for unnecessary discovery and chaining. The more granular the surface, the more likely the operator will need to certify exceptions, review dependencies, and police combinations of actions. Practitioners should align tool boundaries with the minimum meaningful task.

Discovery and planning are the new pre-authorisation layers. In a layered MCP architecture, the agent does not jump straight to transaction. It first learns what exists, then infers what is needed, then executes. That means policy has to account for intermediate reasoning surfaces, not just the final API call. Practitioners should govern these layers as distinct identity touchpoints.

Identity controls must follow the composition path, not only the credential issuer. This pattern shows how non-human access can move from a single entitlement into a compound workflow across customer, order, and invoice actions. That is the point where traditional point-in-time approvals become less useful than task-scoped controls and auditable execution boundaries. Practitioners should review where composition itself creates excess privilege.

Layered tool architectures will accelerate pressure for explicit MCP governance models. Once teams start abstracting large platforms into discovery, planning, and execution, they are effectively defining an internal policy language for machine use. That will force IAM, platform, and application teams to agree on how much autonomy to delegate to the agent. Practitioners should expect MCP governance to move from implementation detail to operating model.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• For a broader view of AI-driven tool risk, see OWASP Agentic Applications Top 10 for the control failures that emerge when agents can chain actions across tools.

What this signals

Layered MCP design: as teams compress many endpoints into a few governed tools, they are really redesigning the delegation model for AI access. That will push platform teams to define which actions may be discovered, which may be planned, and which may actually execute. The practical shift is toward policy at the composition layer, not just the credential layer.

The access-scoping gap in MCP deployments is already large enough to matter, and it will widen if teams treat tool catalogs as mere developer convenience. As machine access expands, practitioners should expect more pressure to align MCP governance with established NHI control patterns and with the agent-specific risk patterns documented in the OWASP Agentic AI Top 10.

For identity programmes, the real signal is that AI-connected platforms are making task design inseparable from access design. Teams that can model tool composition, review delegated chains, and separate discovery from execution will have a clearer path to governing both NHI and agentic workloads without overexposing the underlying API estate.

For practitioners

• Collapse endpoint sprawl into governed task layers Define a small number of discovery, planning, and execution tools for each major workflow instead of exposing every REST endpoint separately. Keep the transaction layer narrow and make the task boundary the unit of review.
• Separate policy by tool layer Apply lighter visibility controls to discovery and stricter validation to execution, then log each stage independently so reviewers can reconstruct the agent’s path through the workflow.
• Review delegated action chains for composition risk Map which tool sequences can be combined by an agent to create outcomes that were never individually approved, especially where customer, order, and billing operations can be chained together.
• Treat MCP tool catalogs as identity surfaces Include MCP tools in access reviews, service ownership, and change management because the catalog itself defines what a delegated identity can discover and trigger at runtime.

Key takeaways

• Mapping every API endpoint directly into MCP tools does not scale well for large platforms and creates a harder governance problem.
• A layered discovery, planning, and execution model reduces context waste and makes delegated machine access easier to control.
• Identity teams should treat MCP tool design as part of the authorisation boundary, not as a purely technical integration choice.

Key terms

• Layered Tool Pattern: A design approach that groups many low-level API capabilities into a small number of higher-level tools. In MCP settings, it reduces tool sprawl and makes machine access easier to govern because discovery, planning, and execution can be controlled separately.
• MCP Tool Catalog: The set of tools exposed to an AI agent through the Model Context Protocol. It is more than a developer convenience list because it defines what the agent can discover, combine, and attempt, making the catalog a practical identity and access surface.
• Delegated Access Chain: A sequence in which a non-human actor discovers, assembles, and triggers actions across multiple tools or systems under one delegated identity. The security concern is not any single call, but the combined path the actor can take across services.

Deepen your knowledge

MCP tool governance and delegated machine access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI-connected platforms and large API estates, it is worth exploring.

This post draws on content published by WorkOS: MCP Night 2.0 Demo Recap: Block's Goose - The Layered Tool Pattern. Read the original.