MCP Night 2.0 Demo Recap: Block's Goose - The Layered Tool Pattern

This post is part of our ongoing MCP Night 2.0 series, highlighting the impressive demonstrations from the event. Check out our full event recap and other demo spotlights to see how the Model Context Protocol ecosystem is evolving.

At MCP Night 2.0, Richard Moot from Block took the stage to demonstrate how they solved a complex challenge: how do you create an MCP server for a massive API platform? Block's solution introduced an elegant approach they call the "layered tool pattern" that reduced their entire Square API platform—over 30 APIs with 200+ endpoints—down to just three tools.

The Challenge of Scale

Block, the company behind Square, has built an extensive API ecosystem over nearly a decade. Since launching their APIs in 2015, they've grown to encompass payments, banking, and numerous other services across more than 200 different endpoints. When MCP arrived on the scene, the Block team immediately saw the potential but quickly ran into a fundamental problem.

"We really quickly realized that REST endpoints is not a good format for tool design," Moot explained. Their initial attempts to create specific tools for different workflows resulted in frequent errors and excessive context window consumption. The traditional approach of mapping each API endpoint to individual tools simply didn't scale.

Enter the Layered Tool Pattern

Rather than continuing down the path of endpoint-specific tools, Block discovered a pattern that elegantly abstracts their entire API platform into three conceptual layers:

Discovery - A tool that helps the AI agent explore available services and understand what endpoints exist within the Square ecosystem.

Planning - A tool that determines what data and parameters are needed to execute a specific workflow, mapping user requirements to API specifications.

Execution - A tool that actually makes the API calls with the properly formatted data and parameters.

This layered approach transforms how AI agents interact with large API platforms. Instead of needing to understand hundreds of specific endpoints upfront, the agent can dynamically discover what's available, plan its approach, and execute accordingly.

Seeing It in Action

Moot demonstrated the pattern with a practical example: creating an invoice through natural language. He asked Goose to "create an invoice charging me for two hours at $250 an hour on consulting for the Square MCP server."

The process unfolded beautifully. Goose first used the discovery tool to find the invoices service. Then, through the planning phase, it realized that creating an invoice requires additional setup—customers and orders need to exist first. The agent didn't need explicit instruction about this dependency; it discovered the requirements dynamically.

What followed was a self-directed exploration where Goose called the tools multiple times, discovering that it needed to create a customer record, then an order, and finally the invoice. The agent determined the proper sequence entirely on its own, executing all the necessary API calls in a single, coherent workflow.

The Power of Self-Discovery

This self-discovery process eliminates many of the pain points that plague traditional API integrations. Context windows no longer get cluttered with failed attempts and retries. The system can adapt to API changes without requiring tool updates. Most importantly, complex multi-step workflows can be executed through simple natural language requests.

"We went from having tons and tons of errors and eating up the context window with a lot of failures or try and repeats and we actually have like a fairly consistent workflow," Moot noted. "We can actually change our API anytime we want and it will still successfully be able to get to the end because of this self-discovery process."

A Pattern Worth Repeating

The layered tool pattern proved so effective that Block discovered they had unconsciously implemented the same approach in Goose itself. When users want to use an extension that's installed but not enabled, Goose can search through available tools, find what it needs, and enable it automatically.

This suggests the pattern has broader applications beyond API platforms. Any system with complex, interconnected functionality could potentially benefit from this discovery-planning-execution abstraction.

Key Takeaways

Block's presentation revealed several important insights for MCP developers:

The one-to-one mapping of REST endpoints to tools doesn't scale effectively for large platforms. Complex systems benefit from higher-level abstractions that allow for dynamic discovery and planning. Self-discovery patterns can significantly reduce context window consumption and improve reliability. The same architectural patterns often emerge naturally in different parts of a system when they solve fundamental problems.

For organizations with extensive API platforms, the layered tool pattern offers a compelling alternative to traditional integration approaches. Rather than building hundreds of specific tools, three well-designed layers can provide access to an entire ecosystem while maintaining the flexibility and intelligence that makes AI agents so powerful.

Watch the full presentation: Block's Goose Demo

Learn more about the layered tool pattern in Block's blog post (referenced in the presentation)