Most enterprise AI pilots stall in the same place.
The model is capable. The use case is clear. The APIs are connected. And yet the agent behaves inconsistently — sometimes picking the right action, sometimes not, often in ways that are hard to explain or reproduce.
Teams spend weeks debugging prompts, swapping models, adjusting temperature settings. The behavior improves slightly, then regresses. Eventually, someone asks the uncomfortable question: is this actually production-ready?
In most cases, the answer is no. And the reason isn’t the model.
It’s the design of the tools the model is working with.
What we Learned Building 25+ MCP Servers
Over the past year, Workato has built and launched more than 25 pre-built MCP servers for enterprise systems — Salesforce, Workday, GitHub, Zendesk, Gmail, Slack, and more. Each one had to meet a high bar: not just functionally correct, but reliably usable by any AI agent, out of the box, in production.
That process surfaced a consistent set of design principles. The servers that worked had them. The early drafts that didn’t work violated them — often in subtle ways that looked fine on paper.
We turned those principles into a four-part series called How We MCP. This post summarizes what we found, and what it means for enterprise teams evaluating or building on top of MCP today.
The Core Insight: Design for Reasoning, not Execution
Most developers approach MCP server design the same way they’d design an API. It’s a natural instinct — the surface looks similar. Tools resemble endpoints. Parameters look like request bodies. Responses look like API outputs.
But there’s a fundamental difference in who’s consuming them.
An API is consumed by a developer who can read documentation, learn edge cases, handle errors, and write logic to control behavior. If something’s unclear, they go look it up.
An LLM can’t do any of that. It only sees what you give it: tool names, descriptions, parameters, and outputs. If something isn’t made explicit there, it effectively doesn’t exist. And when things aren’t clear, the model doesn’t fail gracefully — it guesses. And guessing is where enterprise reliability goes to die.
This is the shift that most teams miss: MCP servers are not execution interfaces. They are reasoning interfaces. That changes what good design looks like at every level.
The Four Principles
Through building and iterating on 25+ servers, four principles emerged as non-negotiable for production-grade reliability.
Clarity over completeness. The instinct is to expose everything — every endpoint, every option, every edge case. Resist it. When multiple tools look similar, the model has to choose between them probabilistically. Anthropic’s own testing found that Claude Opus 4, given a large ambiguous toolset, achieved only ~49% tool selection accuracy. The fix isn’t a better model. It’s fewer, clearer tools with unambiguous scope.
Cohesion over convenience. Grouping everything from one system into one server feels efficient. It creates a reliability problem. When a single server handles sales workflows, support tickets, and admin operations, the same request can map to multiple valid interpretations. The model picks one. It’s often wrong. Servers scoped to a single persona and purpose eliminate that ambiguity entirely.
Explicitness over inference. What’s obvious to the developer who built the tool is invisible to the model using it. Hidden side effects, undocumented limits, implicit prerequisites — every assumption you leave unstated is a place where the model will guess. Document it, or it doesn’t exist.
Determinism over cleverness. “Smart” tools that return different data based on context feel powerful. They’re reliability killers. If the same inputs can produce different outputs, the model can’t form stable expectations. Multi-step workflows — where the output of one tool feeds the next — break completely. Variation is fine. Hidden variation is not.
What this Means for Enterprise Buyers
If your organization is evaluating MCP-based AI solutions, these principles are your evaluation framework.
Ask whether the servers you’re considering were designed around personas and workflows, or just ported from existing APIs. Ask how tool descriptions handle edge cases and failure modes. Ask whether outputs return bounded, structured data — or raw dumps that require downstream interpretation.
The difference between a demo that works and an agent that’s actually production-ready often comes down to these questions.
Pre-built servers — designed specifically for enterprise reliability from the start — can compress months of iteration into days. Workato’s MCP server catalog was built with these principles from the ground up, which is why they work at the scale and governance requirements enterprise deployments demand: Verified User Access, tool-level RBAC, immutable audit trails, and composable cross-system orchestration built in.
The Bottom Line
AI agents are only as reliable as the tools they work with. Building those tools for LLMs — not for developers — is what separates the pilots that stall from the systems that ship.
We put everything we’ve learned into a four-part field guide. It covers MCP server design from first principles through individual tool design, with concrete examples at every step.