Topic starter
08/06/2026 4:22 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “MCP Night 2.0 Demo Recap: Block's Goose - The Layered Tool Pattern”.
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.
Q: Why does layered tool design improve MCP governance?
A: Layered design improves governance because it separates visibility, workflow planning, and state-changing execution.
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.
Practitioner guidance
- 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.
Bottom line: Flat endpoint-to-tool mapping does not scale well once an API platform grows into hundreds of endpoints.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
08/06/2026 5:58 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Layered MCP tool design shows why endpoint mapping does not scale
This post was modified 3 days ago by NHI Mgmt Group