Back to Blog

MCP in Production: Building AI Agents with Model Context Protocol

What Is Model Context Protocol and Why Does It Matter for AI Agents?

If you've attempted building AI agents, you've likely encountered a recurring challenge: every new tool requires fresh custom integration work. Connecting your agent to Salesforce means writing a connector. Integrating with your internal CRM requires another. Adding Slack means another integration entirely. Each remains bespoke, each needs separate authentication logic, and each breaks differently when upstream APIs change.

Model Context Protocol (MCP) is Anthropic's open standard designed to address this exact problem. Consider it the USB-C equivalent for AI tool integrations. Before USB-C standardisation, every device manufacturer maintained proprietary ports. After USB-C, one standard worked across manufacturers and use cases. MCP applies this same principle to AI agents: it defines a standard method for agents to discover, invoke, and receive responses from external tools, data sources, and services.

MCP operates through three core components:

MCP Hosts are the AI applications or agents requiring external tools. Your LangChain agent, Claude-based assistant, or custom agent harness would all be MCP hosts.

MCP Clients are the protocol libraries embedded in the host that manage connections to MCP servers.

MCP Servers are lightweight services exposing capabilities — querying databases, calling REST APIs, searching documents, or executing code.

When your agent needs information, it sends a standardised tool call request to the MCP server. The server handles the actual integration logic, returns a structured response, and the agent proceeds. The agent doesn't need to understand the underlying system; it only needs to know what tools are available and what parameters each expects.

How MCP Changes AI Agent Architecture

The distinction between pre-MCP and post-MCP agent architecture is substantial, particularly when managing multiple agents across enterprise environments.

The architectural shift matters most in organisations scaling beyond single agents. One agent may not justify MCP overhead. Five agents needing overlapping system access make the case clear: the MCP server layer becomes shared infrastructure rather than per-agent expense.

What We Actually Encounter When Deploying MCP in Enterprise Systems

Setup documentation is thorough. Anthropic's guides walk you through basic MCP server implementation in an afternoon. Real enterprise deployment challenges differ significantly.

Challenge 1: Context Window Pressure from Enterprise Data Sources

Enterprise databases rarely return minimal, clean responses. A customer record query through an MCP server connected to a CRM might include hundreds of fields, nested objects, historical records, and metadata the agent doesn't require. When that payload enters the LLM's context window directly, two outcomes occur: context budget burns quickly, and signal-to-noise ratio degrades for the LLM.

Our experience shows the right pattern involves building a summarisation or filtering layer inside the MCP server itself. The server queries the upstream system, applies field selection and business rules to trim responses, and returns only what the agent actually needs.

Challenge 2: Authentication Complexity in Enterprise Environments

Consumer MCP demonstrations typically use API keys. Enterprise deployments are considerably more complex. Your MCP servers need to integrate with existing identity providers: Azure AD, Okta, or in regulated environments, on-premises identity management systems. They need role-based access control so agents running in customer-facing contexts cannot call MCP tools exposing sensitive internal financial data.

They also require audit logging. In regulated industries, every tool call the agent makes — including inputs, outputs, and the identity context of the call — needs logging in formats compliance teams can review.

Challenge 3: Tool Schema Design Is Harder Than It Looks

The tool schema describes what the MCP server exposes to the agent: what the tool does, what parameters it expects, and what it returns. Vague or ambiguous schemas cause LLMs to call tools with incorrect parameters, misinterpret results, or make sequential calls when one would suffice.

Significant iteration time refines tool schemas in enterprise projects. Practical lessons include: be extremely specific about parameter types and constraints; include concrete examples in schema descriptions for non-obvious parameter formats; and design tools to do one thing well rather than combining multiple operations.

Real-World Example: Complex Multi-Tool Integration

One instructive example is a B2B WhatsApp Order Agent we built for a client with operations across multiple markets and three languages. The agent needed to query product catalogues, check inventory, process orders, and handle returns through natural-language WhatsApp conversations.

This required orchestrating multiple MCP servers: one for product data, one for inventory, one for order management, and one for returns workflows. Getting tool schemas right so the agent could reason across these tools cleanly — without misrouting queries or making redundant calls — required significant iteration. The outcome was 60% order processing time reduction, 40% error reduction, and full trilingual support.

MCP vs Direct API Integration: When to Use Each

MCP isn't universally appropriate. The decision depends on integration reusability needs and how many agents will consume it.

Compliance and Security Considerations for MCP in Enterprise

Compliance requirements vary by region and industry. However, MCP's centralised architecture actually makes compliance more tractable than distributed custom integrations when proper instrumentation is built from the start.

EU AI Act (Germany and broader EU): High-risk AI systems under the EU AI Act require audit trails for automated decision-making. MCP's structured tool call logging, when properly implemented, can serve as the evidentiary layer for audit requirements.

SOC 2 (US FinTech and SaaS): SOC 2 Type II audits require demonstrating that systems accessing customer data have appropriate access controls and logging.

MAS TRM Guidelines (Singapore): The Monetary Authority of Singapore's Technology Risk Management guidelines require that AI systems in financial services demonstrate resilience and tested fallback mechanisms.

What MCP Means for AI Development Cost and Timeline

"In our experience, the first MCP implementation is the expensive one," says Malay Parekh, CEO of Unico Connect. "You are not just building an integration; you are building shared infrastructure."

Here's how MCP affects timeline in practice:

First MCP server implementation: Add roughly two to three weeks to the project timeline relative to direct API integration.

Subsequent agents using the same MCP server: In our experience, integration time drops 30 to 50 percent.

Maintenance advantage: When an upstream API changes, you fix it once in the MCP server. Without MCP, each agent calling that API needs its own fix.

Frequently Asked Questions