TL;DR: Block’s Square API demo showed that mapping more than 200 endpoints to individual MCP tools does not scale well, and that a three-layer discovery, planning, and execution pattern can reduce errors and context window waste, according to WorkOS. The governance lesson is that MCP tool design is becoming an identity and authorisation problem, not just an integration pattern.
At a glance
What this is: WorkOS describes how Block reduced a large Square API estate to three MCP tools by separating discovery, planning, and execution.
Why it matters: For IAM, NHI, and agentic AI teams, this matters because tool design now affects authorization boundaries, workflow reliability, and how much autonomy an AI system can exercise safely.
Context
MCP tool design fails when every API endpoint is exposed as a separate tool, because the agent has to reason over too many options and too much parameter detail. In practice, that creates brittle workflows, wasted context, and more opportunities for wrong calls. For AI agent governance, the question is no longer just connectivity. It is how tool exposure shapes authorization, sequencing, and control.
Block's example is a large NHI and agentic AI design problem rather than a simple integration preference. When an agent can discover available services, plan the required sequence, and then execute the right calls, the control point shifts from static tool inventory to governed workflow access. That changes how teams should think about least privilege, tool scoping, and approval boundaries.
The article's core finding is typical for large API estates. Once a platform crosses into hundreds of endpoints, direct one-to-one tool mapping becomes an anti-pattern, and abstraction becomes a governance requirement rather than a developer convenience.
Key questions
Q: What breaks when too many REST endpoints are exposed as MCP tools?
A: When too many REST endpoints are exposed as MCP tools, the model gets a larger, less distinguishable action set and privilege becomes harder to reason about. Similar tools overlap, descriptions blur together, and the chance of unintended action selection rises. The result is not just clutter. It is an expanded agent-facing attack surface that is harder to review and govern.
Q: Why does layered tool design improve MCP governance?
A: Layered design improves governance because it separates visibility, workflow planning, and state-changing execution. That lets teams assign different permissions to each stage instead of giving a single identity broad access to everything it can discover. It also makes authorization decisions easier to bound around task intent rather than endpoint count.
Q: How should teams control AI agents that can discover and execute API workflows?
A: Teams should control them by limiting discovery to read-only visibility, constraining planning to approved workflow logic, and reserving execution for narrowly scoped side effects. The key is to prevent discovery from becoming implicit authority. Each stage should have its own access boundary and audit trail.
Q: What is the difference between discovery and execution in MCP tool design?
A: Discovery reveals what services and endpoints exist, while execution performs the actual action with validated inputs. They should not share the same authority because visibility alone does not justify state change. Separating them keeps AI agents from turning enumeration into uncontrolled action.
Technical breakdown
Why direct endpoint-to-tool mapping breaks down
A flat MCP design treats every API endpoint as if it were an equally valid tool choice. That works for small surfaces, but it breaks at scale because the agent must inspect too many options, carry too much schema detail, and retry too often when the first guess is wrong. In effect, the tool list becomes part of the prompt budget. The more endpoints you expose directly, the more the model spends attention on selection rather than task completion. Practical implication: collapse large API estates into fewer governed entry points instead of publishing every endpoint as an individual tool.
Practical implication: collapse large API estates into fewer governed entry points instead of publishing every endpoint as an individual tool.
How discovery, planning, and execution change agent behaviour
The layered pattern separates three decisions that are usually conflated. Discovery answers what exists. Planning determines what data, prerequisites, and parameters are needed. Execution performs the actual call with validated inputs. That separation matters because an AI agent can infer workflow dependencies at runtime rather than being preloaded with every step. In the Block example, the agent discovered that invoices required related customer and order objects before it could proceed. Practical implication: expose workflows through staged capabilities so the agent can reason about prerequisites without broadening direct execution authority.
Practical implication: expose workflows through staged capabilities so the agent can reason about prerequisites without broadening direct execution authority.
Why layered tool design is an authorization problem
Once an agent can discover, plan, and execute across multiple services, the security question becomes which layers are read-only, which layers can propose actions, and which layers can actually commit side effects. That is an identity and authorization boundary, not just an interface design choice. The governance risk is accidental privilege expansion if discovery quietly exposes functions that execution should not allow. Practical implication: define separate access rules for tool discovery, workflow planning, and state-changing execution so the agent does not inherit unnecessary authority.
Practical implication: define separate access rules for tool discovery, workflow planning, and state-changing execution so the agent does not inherit unnecessary authority.
Breaches seen in the wild
- Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
- Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Layered MCP design is a governance pattern, not a developer shortcut. The central insight is that tool abstraction determines how much authority an AI system can exercise with a given identity. When discovery, planning, and execution are separated, the platform stops forcing every endpoint into the same privilege model. Practitioners should treat that separation as part of identity design, not just interface ergonomics.
Endpoint sprawl creates an identity blast radius problem. A one-to-one endpoint map expands the agent's visible action surface far beyond what most teams can govern cleanly. That increases the chance of overbroad tool exposure, especially when workflows require multi-step chaining across services. The named concept here is the identity blast radius: the amount of unintended authority exposed when tool design mirrors raw API structure instead of bounded workflow intent.
Tool discovery must not become implicit execution authority. In a layered model, the fact that an agent can inspect available services does not mean it should be able to invoke them all. That distinction is critical for MCP, because authorisation has to remain explicit at each stage of the tool chain. Practitioners should preserve separate controls for visibility, planning, and commit rights.
Self-discovery reduces retry waste, but it also changes audit expectations. If the agent can resolve prerequisites dynamically, traditional review models that assume a fixed call path will miss the real decision points. The important governance question becomes whether the workflow was bounded before execution, not whether the final call succeeded. Teams should align MCP oversight to workflow intent rather than endpoint count.
Large API estates will push identity teams toward workflow-level control models. The article shows a broader category shift: as platforms grow, the useful control unit stops being the individual endpoint and becomes the governed task. That aligns better with NHI lifecycle thinking, where access should follow the minimum viable workflow. Practitioners should expect MCP policy to move from tool inventories toward workflow authorisation.
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.
What this signals
Identity blast radius: as API estates grow, the main risk is no longer the number of endpoints but how much unintended authority each exposed tool creates. A layered model keeps the agent's visible surface smaller and makes access boundaries easier to reason about.
MCP deployments should be designed around governed workflows, not exhaustive endpoint inventories. That shift matters because the control point moves from what the model can see to what it can actually commit.
The article reinforces a broader pattern already visible in NHI and agentic AI programmes: if tool exposure is not staged, authorization becomes implicit. In 2025 alone, 24,008 unique secrets were exposed in MCP configuration files, according to the State of Secrets Sprawl 2026, which shows how quickly protocol adoption can create unmanaged security debt.
For practitioners
- Bound MCP tools by workflow stage Group discovery, planning, and execution into separate permissioned layers so the agent cannot treat every available capability as a direct action surface.
- Separate read and write authority Allow tool discovery to enumerate services without granting the same identity permission to invoke side-effecting operations.
- Reduce endpoint-to-tool fan-out Replace endpoint-level tool publishing with higher-level abstractions when the API estate grows beyond a small, stable surface.
- Map workflow prerequisites explicitly Document which objects, parameters, and intermediate records must exist before execution so the agent does not improvise an uncontrolled sequence.
Key takeaways
- Flat endpoint-to-tool mapping does not scale well once an API platform grows into hundreds of endpoints.
- Separating discovery, planning, and execution gives agents enough structure to complete work without overexposing direct action rights.
- For identity teams, MCP governance needs workflow-level authorization boundaries, not just a larger tool catalogue.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The article is about how agents choose and use tools across workflow stages. |
| ASI03 — Identity & Privilege Abuse | Layered tool access changes where privilege should be granted and limited. | |
| Recommendation — Constrain tool use to approved workflows so agents cannot turn discovery into unauthorized execution. Separate discovery, planning, and execution permissions to prevent privilege from expanding across stages. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | The article centers on how exposed functions should be partitioned as APIs become tool surfaces. |
| Recommendation — Apply function-level authorization to each executable tool path rather than mirroring every API endpoint. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Tool stages map cleanly to authorization boundaries that need governance. |
| Recommendation — Define entitlements for discovery, planning, and execution separately and review them as distinct access paths. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Unbounded tool surfaces can widen the path from initial access to broader operational abuse. |
| Recommendation — Map agent tool exposure to credential access and lateral movement risks when workflows span multiple services. | ||
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.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Method-Level Authorization: Method-level authorization restricts access at the business method rather than only at the route or page level. Java frameworks use annotations such as `@PreAuthorize` and `@Secured` to enforce this. It is a defence-in-depth control that helps prevent users from reaching sensitive actions through alternative paths.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org