Notifications
Clear all
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.
NHIMG editorial — based on content published by WorkOS: MCP Night 2.0 Demo Recap: Block's Goose - The Layered Tool Pattern
By the numbers:
- Block’s Square API platform spans over 30 APIs with 200+ endpoints.
Questions worth separating out
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.
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.
Q: What breaks when every API endpoint becomes its own MCP tool?
A: The architecture becomes brittle, noisy, and hard to govern.
Practitioner guidance
- 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.
- 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.
What's in the full article
WorkOS's full recap covers the operational detail this post intentionally leaves for the source:
- The full demo sequence showing how Goose moved from discovery to planning to execution across the Square API platform.
- Richard Moot’s explanation of why endpoint-specific tool design caused repeated errors and context window waste.
- The live invoice-creation example that reveals how the layered pattern handles dependencies such as customers and orders.
- Additional context from the MCP Night 2.0 session and the broader demo recap.
👉 Read WorkOS’s recap of Block’s layered MCP tool pattern demo →
Layered MCP tool design: what it means for AI tool governance?
Explore further
08/06/2026 5:58 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Layered MCP tool design shows why endpoint mapping does not scale
