MCP Servers: The Integration Layer AI Agents Were Missing

If you sit anywhere near a technology budget, you have probably heard the acronym MCP three times this quarter: once from a vendor, once from a developer, and once in a slide deck. Most explanations either drown you in protocol details or wave it away as plumbing. Neither helps you decide whether it matters for connecting AI to the systems your business actually runs on.

Here is the practitioner version. MCP is the integration layer AI agents were missing, it is a standard rather than a product, and building servers against it well is quickly becoming its own engineering discipline. We build these for clients. This is what the work really looks like.

The problem MCP was invented to solve

Before MCP, connecting an AI assistant to an internal system meant bespoke glue code, and the shape of that glue depended on both ends: the assistant's function-calling format on one side, your ERP or CRM's API on the other. Connect three AI tools to four internal systems and you are maintaining twelve integrations, each with its own auth handling, error mapping, and schema quirks.

Worse, the glue kept breaking. Providers changed their tool-calling conventions, SDKs deprecated methods, and every model upgrade meant re-testing every connector. The moment you evaluated a different model, the integration layer had to be rebuilt from scratch. Integration work was disposable by design.

That N×M explosion is the real problem. It was never that AI could not reach your data; with enough custom code it always could. It was that every path from a model to a system was a one-off that nobody else could reuse.

What the Model Context Protocol actually is

MCP, the Model Context Protocol, is an open standard for exposing capabilities to AI applications. It originated at Anthropic in late 2024 and has since been adopted far beyond it; the major model providers, the serious IDEs, and most agent frameworks all speak it now. The specification is public and the SDKs are open source.

An MCP server is a small program that sits in front of a system you own and advertises three kinds of things to any MCP-capable client:

• Tools — actions the model may request: look up an order, create a ticket, draft an invoice.
• Resources — readable data the client can pull in as context: a price list, a policy document, a customer record.
• Prompts — reusable, parameterised instructions the server offers, such as a standard renewal-summary template for an account.

The USB-C comparison you keep hearing is accurate in exactly one way: the standard decouples the two sides. Device makers stopped building a charger per laptop; you stop building an integration per assistant. One server, any compliant client. That is the whole trick, and it is enough.

Anatomy of a minimal, useful MCP server

The servers that earn their keep are usually small. A first server for a distribution business might expose exactly two tools:

• get_order_status(order_id) — reads from the ERP; returns status, line items, and expected dispatch date.
• create_support_ticket(order_id, summary) — writes a ticket into the helpdesk, tagged as AI-created and routed to a human queue.

That is a few hundred lines of code including plumbing, and it already changes how a support team works. Instead of alt-tabbing between the ERP and the helpdesk, they ask the assistant; the assistant calls the server; the answer comes from live data instead of memory.

Around those two tools sits the unglamorous seventy percent of the work:

• Auth. The server holds the ERP credentials, not the model and not the chat client. Remote servers authenticate clients with OAuth; the model never sees a key.
• Schemas. Every tool declares typed inputs and outputs. Vague schemas produce vague calls. The schema is half the prompt.
• Error surfaces. The model will eventually pass a malformed order ID. The server should return something it can act on, like a note that order IDs look like SO-XXXXX, not a stack trace.

The three patterns clients actually ask us for

1. Read-only lookup servers

ERP and CRM lookups: order status, stock levels, customer history, invoice ageing. No writes at all. Nearly every engagement should start here, because the failure mode of a bad read is a wrong answer, while the failure mode of a bad write is a wrong action in your system of record.

2. Action servers with approval gates

Tools that change state: create a ticket, draft a purchase order, move a CRM stage. Anything irreversible gets a human confirmation step in front of it. The pattern that works in practice: the model proposes, the server stages the action as a draft, and a person approves it inside the system they already use. These pair naturally with the workflow-shaped agents we described in AI agents as automation workflows.

3. Internal-knowledge servers

Policies, SOPs, product documentation, and contract templates exposed as resources with a search tool on top. This is cheaper to build and far easier to keep current than fine-tuning a model, and every answer can cite the live document instead of a training-data snapshot.

Security is the whole game

An MCP server is an API gateway with a language model on the other end, and language models can be manipulated by the text they read. If you take one thing from this post, take the design rules:

• Least-privilege tools. Expose get_order_status, not run_query. Each tool should do one narrow thing the business actually needs.
• Reads and writes live under different rules. Reads can be autonomous. Writes need a human confirmation, an approval gate, or at minimum a reversible staging step.
• Audit everything. Log every tool call with arguments, caller identity, and result. When someone asks what the AI did last Tuesday, that log is the answer.
• Scope credentials per server. Each server runs as a service account with exactly the permissions its tools require, nothing inherited from an admin.
• Treat retrieved content as untrusted. A supplier email or a scraped page can contain instructions aimed at the model. A read result must never be allowed to auto-trigger a write.

If a tool accepts raw SQL, you have not built an integration. You have built an incident that ships with its own JSON schema.

Building one that survives production

The gap between a demo MCP server and one you can leave running is discipline, not cleverness. Our working rules:

• Start read-only. Ship lookups first, watch how people actually use them for a few weeks, and add write actions only where users keep asking for them.
• Version your tool contracts. Tool names and schemas are an API. Renaming a parameter silently breaks every client and prompt built against it, so make additive changes and deprecate slowly.
• Write descriptions like prompts. The model chooses tools by reading their descriptions. If two tools sound alike, it will pick the wrong one at the worst time.
• Eval tool-calling accuracy. Keep a test set of realistic requests and assert which tool gets called with which arguments. Run it on every server change and every model update, the same eval discipline we apply to voice agents.
• Review the logs weekly at first. Early usage tells you which tools are confusing, which are missing, and which nobody needed.

Why this changes the integration economics

The commercial argument is short. Before MCP, an integration budget bought glue for one assistant, and evaluating a second one meant paying again. Now the server outlives any single client. The connector you build so a support assistant can read the ERP is the same one your developers use from their IDE and the same one your background agents call at 2 a.m. The automation patterns we covered in how Claude is changing business automation all get cheaper once the connectors are standard instead of bespoke.

It also changes vendor risk. When the integration layer speaks an open protocol, switching or mixing models stops requiring an integration rewrite, which means the largest hidden lock-in cost in most AI stacks simply goes away. And it changes how we scope agent projects: in our AI agent development engagements the MCP server is frequently the first deliverable and the agent comes second, because an agent with clean, narrow, well-described tools is dramatically easier to make reliable than one wired straight into raw APIs.

On effort: the read-only lookup servers we scope against systems with a sane API usually land in the one-to-three-week range; action servers with approval gates and audit logging tend to run three to six weeks. The multiplier is on your side of the table, because the second and third AI use case reuses the same server for close to zero additional integration cost.

Where to start

• Find the twenty-times-a-day question. Whatever your team looks up most often across systems, that lookup is your first read-only tool.
• Check the target system has an API worth fronting. MCP standardises access to a system; it cannot conjure access to one nothing can talk to. If the ERP has no API, fix that first.
• Ship one server with two or three tools. Resist the platform-building instinct. Small, boring, and live beats comprehensive and stalled.
• Gate every write behind a human until months of logs prove the model calls it correctly, and keep the gate anyway for anything irreversible.
• Apply the decision rule. If you will only ever embed one AI feature in one product, a direct integration is fine and MCP is overhead. If you expect assistants, agents, or IDE access to touch more than one internal system, build MCP servers, because that is the moment integration work stops being disposable and starts compounding.

Frequently asked questions

Related reading

• How Claude AI Is Changing Business Automation
• Multi-Agent Orchestration with LangGraph