Beyond API Wrappers: Building State-Driven MCP Servers for Long-Horizon Agent Orchestration

When MCP launched, everyone rushed to wrap their favorite APIs. GitHub servers, Slack integrations, database connectors—the ecosystem exploded with what could be called "API wrapper syndrome." But that's just scratching the surface of what the Model Context Protocol can actually do.

If you see MCP servers as wrappers around APIs, then sure, most of the ones you'd want already exist. It was the obvious first move, the low-hanging fruit. But there's a fundamentally different way to think about MCP that opens up possibilities we're barely exploring.

The API Wrapper Trap

The rush to create MCP servers for every popular service made perfect sense. Need to let Claude access your GitHub repos? Build a GitHub MCP server. Want Slack integration? Another server. Database queries? You get the idea.

This approach works because it maps cleanly to how we already think about tool integration. Each API becomes a set of MCP tools, each endpoint becomes a method call. The mental model is familiar, the implementation is straightforward, and the value is immediate.

But here's what we're missing: MCP servers don't have to wrap existing APIs at all.

What I think the second phase of MCP could be about is moving beyond the API wrapper pattern to orchestrating multiple teams of highly specialized agents through the complex phases of long-horizon projects like building an n-tier enterprise system or producing game level, script or conversation history. Something that you might be able to describe in a state machine.

State Machines as Dynamic Resources

Instead of wrapping APIs, I've been reading code in AI projects where there is an orchestration layer agent. Routing to different specialized agents, I'm thinking those agents can be MCP servers that solves a problem by working a state machine. Each State has a different set of actions (think tools). There's no external API being adapted—just state machines to manage, agents that can subscribe to those states, and validation prompts that help teams verify their work before triggering transitions.

Here's how I'm thinking about it: imagine you're building an e-commerce order system. The flow might be: user adds to cart, user checks out, order created, payment processed, payment success, order set to paid, fulfillment started, item shipped, delivery confirmed. Each state could require different specialized agents—inventory checkers, payment processors, fulfillment coordinators, shipping agents.

Rather than manually coordinating these agents, the MCP server could maintain the order's state machine. Agents could even subscribe to the states relevant to their expertise. When the payment processor completes successfully, it triggers a state transition that notifies the fulfillment team. But here's what I think could be the key part: the transition includes validation prompts.

Before moving from payment success to paid status, the server could prompt an LLM: "Does this payment confirmation match the order total and payment method?" If not, the transition fails and the order gets flagged for review.

This isn't just workflow automation—it could be intelligent orchestration where the state transitions themselves become checkpoints for quality and consistency across the order lifecycle.

The server exposes tools for agents to query current order state, subscribe to state notifications, propose state transitions, and access validation prompts specific to their role. But more importantly, it exposes resources that represent the evolving order data, the relationships between states, and the accumulated context from previous states.

The Endless Possibilities

When you stop thinking of MCP servers as API wrappers, you start seeing them as systems that can expose any kind of tool, resource, or prompt to an LLM. Sure, some of those tools might call APIs, but they can just as easily invoke an Agent, functionality within the server itself. (Note: if a human is involved in the loops you'll have to figure out real time status updates to keep the user engaged. Or a work queue they can check back on.)

And servers can act as clients to other servers. I'm imagining a state machine server that coordinates with specialized model servers, data processing servers, and validation servers to create orchestration networks that could handle complexity far beyond what any single API wrapper could achieve.

The possibilities aren't just endless—they're largely unexplored. We've built the infrastructure for something revolutionary and collectively decided to use it mostly as a better way to call REST endpoints.

What purpose-built custom host for MCP clients might you write? What state machines could orchestrate the complex work in your domain? What kind of intelligent validation could ensure quality as projects flow through phases?

The low-hanging fruit has been picked. Now it's time to see how high this tree actually grows.