The Model Context Protocol (MCP) has arrived as a promising standard for connecting AI agents to external tools and systems. But enterprise MCP implementations face a critical gap between what the protocol provides and what real-world production applications actually need.
After working with teams implementing MCP in production environments, we’ve discovered that the most common architectural pattern—wrapping APIs directly as tools—creates more problems than it solves. Here’s what we’ve learned about building MCP architectures that actually work.
The Promise vs. The Reality
At its core, MCP is elegantly simple. It standardizes how LLM-powered applications discover and invoke tools, with servers exposing capabilities through a clean tools/list and tools/call interface. The protocol focuses on optimizing communication between clients and servers, enabling industry-wide interoperability.
But here’s the catch: making MCP useful happens entirely outside the protocol’s scope.
The protocol itself says nothing about authentication, authorization, logging, retry logic, business rules, or governance. These aren’t nice-to-haves. They’re the foundation of any production system. The hard work of making MCP enterprise-ready falls squarely on your shoulders.
This focused approach is intentional and beneficial. Recent developments like the MCP Apps extension demonstrate how the ecosystem can evolve through standardized extensions rather than bloating the core protocol. But each extension only solves specific problems—the architectural challenges of composing complex business processes remain yours to solve.
What Makes MCP “Enterprise”?
When we talk about enterprise MCP, we’re specifically referring to implementations that handle:
Multi-system orchestration (e.g. Salesforce, Stripe, ERPs, not just single APIs)
Production AI agents rarely interact with just one system. They orchestrate workflows across CRMs, payment processors, communication platforms, and legacy databases—each with its own authentication, rate limits, and failure modes.
Production-grade reliability (SLAs, monitoring, disaster recovery)
Unlike experimental demos, production systems need guaranteed uptime, transaction-level observability, automatic retry logic, and graceful degradation when external systems fail.
Governance and compliance (audit trails, access control, data residency)
Enterprise environments require detailed logs of who accessed what data when, fine-grained permission boundaries that respect organizational hierarchies, and data handling that complies with regulations like GDPR or HIPAA.
Dynamic, high-scale workloads (thousands of users, millions of operations)
What works for 10 concurrent users can break at 1,000. Production MCP architectures must handle variable load, peak traffic, and geographic distribution without manual intervention.
Real integration complexity (legacy systems, custom connectors, data transformation)
Real enterprises don’t have pristine REST APIs. They have 20+ year old SOAP services, mainframe integrations, custom file formats, data models that evolved over decades.
This isn’t about enterprise vs. startup—it’s about the architectural challenges that emerge when MCP connects to critical, real-world business systems rather than experimental APIs. The patterns in this post apply whether you’re a three-person team or a Fortune 500 company—as long as you’re building something people depend on.
Why Naïve Implementations Fail
The most intuitive approach to implementing MCP is to wrap your existing APIs as tools. After all, you already have APIs that do what you need, so why not expose them directly to the LLM?
This is what I call a “naïve MCP architecture,” as it breaks down quickly in real-world scenarios.
Consider an employee trying to file an expense report through an AI assistant. In a naïve implementation, the MCP server exposes tools mirroring an underlying API: createParentWithChild, batch_createParentWithChild, async_JobStatus, async_GetReport_byId. An agent must orchestrate low-level operations, manage async job polling, handle errors, and navigate complex dependencies.
The problem isn’t technical—it’s experiential. Enterprise SaaS APIs are complex, granular, and verbose by design. They weren’t built for conversational interfaces or multi-step business processes. When you couple these APIs directly with an LLM, you create overwhelmed agents and underwhelming user experiences.
Rethinking Separation of Concerns
The solution starts with reframing what each part of your system should handle.
Think about the fundamental difference between LLM capabilities and traditional software: LLMs are non-deterministic, while your backend systems need to be deterministic.
LLMs excel at non-deterministic tasks (high-entropy operations):
- Understanding user intent and input formatting
- Selecting the right tool for the job
- Predicting likely next steps in a workflow
- Handling ambiguity and natural language variation
Backends excel at deterministic tasks (low-entropy operations):
- Controlling system access and permissions
- Managing read/write operations reliably
- Handling batching, retries, and error propagation
- Enforcing business rules and state transitions
This isn’t just a philosophical distinction—it has practical implications. When you ask an LLM to orchestrate deterministic operations (like ensuring atomic database transactions or managing retry logic), you’re using a probabilistic tool for work that requires guarantees. When you ask your backend to parse natural language or select from dozens of ambiguous options, you’re fighting against what makes traditional software reliable.
A well-designed MCP architecture should leverage these complementary strengths. Instead of exposing raw API operations and forcing LLMs into deterministic orchestration, you compose them into higher-level skills aligned with actual user jobs-to-be-done—letting each system operate in its sweet spot.
Composable Architecture in Action
Let’s look at a concrete example: hotel operations at a fictional property called Dewy Resort.
When a front desk employee says, “Help me check out a guest,” this simple request triggers a complex business process spanning multiple systems. In the background, you might need to:
- Validate reservation and room status
- Process payment through a financial gateway
- Update room availability in the property management system
- Trigger housekeeping workflows
- Log the transaction for compliance
In a naïve architecture, the agent would need to orchestrate all of this, calling a dozen different API endpoints in the correct sequence while handling errors at each step.
In a composable architecture, the MCP server exposes a single tool: ‘Process guest checkout‘. The tool accepts high-level parameters (guest email, payment details, idempotency token) and the backend handles all the orchestration, including atomic automation jobs, business-ruled retry logic, cross-app authentication, and error handling.
The MCP layer becomes a collection of composed skills:
- Create contact if not found
- Submit maintenance request
- Check in guest
- Process guest checkout
- Submit guest service request
- Compensate checkout failure
Each skill abstracts significant backend complexity while exposing a clean, intent-aligned interface to the LLM.
The Real-World Impact
This architectural shift has profound implications across your organization:
| Stakeholder | Impact |
|---|---|
| Users | Interactions feel natural because tools align with their mental model of tasks, not with system architecture. |
| Agents | Decision-making stays focused on understanding intent and selecting appropriate actions, rather than managing technical minutiae. |
| Developers | Business logic and integrations are centralized in governed, reusable workflows that can be composed into multiple MCP skills. |
| Enterprises | You gain observability, governance, and the ability to enforce business rules without bloating your agent’s context. |
Three Principles for Composable Enterprise MCP Design
If you’re building MCP implementations for production systems, keep these principles in mind:
1. The protocol scope is focused—and that’s okay.
Don’t expect MCP to solve authentication, orchestration, or governance. These are your responsibility, and architectural decisions you make outside the protocol matter more than the protocol itself.
2. Real-world systems are intricate.
Your MCP architecture must handle this complexity somewhere. The question is whether you push it into the agent’s runtime context or abstract it in the backend.
3. Optimal tools follow the shape of user needs, not APIs.
Design your tool interfaces around jobs-to-be-done, then compose whatever backend complexity is required to fulfill them reliably.
See It In Action
Want to explore these principles hands-on? We’ve open-sourced the Dewy Resort sample application that demonstrates composable MCP architecture in a hospitality context.
The repository includes:
- Implementation of composed MCP skills* (guest checkout, maintenance requests, room management)
- Backend orchestration showing how to abstract API complexity
- Integration patterns across multiple systems (Salesforce, Stripe, IoT devices**)
- Architectural documentation for each skill (orchestration and atomic level execution)
Explore the code: github.com/workato-devs/dewy-resort
Whether you’re building your first MCP implementation or refactoring an existing one, the patterns in this sample app can accelerate your learning and help you avoid common pitfalls.
Moving Forward
As MCP adoption grows, the temptation will be to treat it as a simple API gateway. Resist this urge. The most successful implementations will be those that thoughtfully separate concerns, abstract complexity, and design tools that genuinely serve human needs.
The protocol gives us interoperability. The architecture we build on top determines whether we deliver underwhelming API wrappers or genuinely useful AI experiences.
The future of MCP in the enterprise is ours to build. What path will you choose?
*Final MCP server activation requires configuration (based on CLI functionality – see setup instructions)
**IoT skills are planned for future app releases