What Is the Model Context Protocol? A Practical Guide for Engineering Leaders

Most enterprise AI projects do not fail because the model is not good enough. They fail at the seam between the model and everything else - the ERP, the ticketing system, the twelve-year-old claims database that only three people understand.

The Model Context Protocol is an open standard for that seam. This guide covers what it is, how an integration is actually structured, and - the part most write-ups skip - when it is the wrong tool.

The problem MCP solves

A language model on its own is a text function. It knows what was in its training data and what you put in the prompt. It cannot read yesterday's order volume, look up a customer's contract terms, or file a ticket.

The obvious fix is to write glue code: a function the model can call that queries your database, another that hits your CRM, another that posts to Slack. This works. It is also where the cost quietly accumulates.

Every integration is bespoke. The tool definitions, the auth handling, the error semantics, the way results get formatted back into the context window - all of it gets written per model, per framework, per application. Build a second AI application and you write it again, because your first one's tools are welded to its framework. Switch model providers and you write it again. Six months in, most teams have several near-identical integrations against the same internal systems, each drifting independently.

That is an interface problem, and interface problems get solved with standards.

What the Model Context Protocol actually is

MCP is an open protocol, originally developed by Anthropic and now with implementations across multiple vendors, that standardises how AI applications connect to external systems.

The useful mental model: MCP is to AI applications what a database driver is to applications. Before standard drivers, every application wrote bespoke code per database. The driver interface did not make databases interchangeable - it made the connection uniform, so the application stopped caring which database sat behind it.

MCP does the same for AI. It defines a client-server architecture:

An MCP server wraps a system you own - a database, an internal API, a file store, a SaaS product - and exposes its capabilities in a standard shape.
An MCP client lives inside the AI application and speaks the protocol.

The server is written once against your system. Any MCP-speaking client can then use it. Your CRM integration works with a chat assistant, an autonomous agent, and an IDE, without being rewritten for each.

The protocol handles capability discovery, structured invocation, and error semantics. The client asks the server what it can do; the server answers in a standard format; the model chooses from that list.

The three primitives: tools, resources, and prompts

MCP servers expose three kinds of thing, and the distinction matters more than it first appears.

Tools are actions the model can invoke - create_ticket, run_query, send_notification. They are model-controlled: the model decides when to call them based on the task. Tools are where side effects live, which is exactly why they need the tightest permissioning.

Resources are data the model can read - a document, a table, a config file. They are application-controlled: your application decides what to expose, not the model. A resource is addressed by URI and returns content. Use resources for context the model should read; use tools for things it should do.

Prompts are reusable templates the server offers - a structured way to invoke a common workflow. They are user-controlled: typically surfaced as something a person explicitly picks. Prompts are the least-used primitive and the most underrated, because they let the system owner encode the right way to ask a question rather than hoping the model guesses it.

Getting this split right is most of the design work. A common early mistake is exposing everything as tools, which hands the model a large action surface when much of what it needed was read-only context.

How an MCP integration is structured

A production MCP integration has more moving parts than a tutorial suggests.

The server. Wraps one system. Keep the boundary tight - one server per system, not one server for the whole company. A large server exposing forty tools makes tool selection harder for the model and makes permissioning coarse.

The tool surface. This is a design decision, not a mechanical export of your API. An internal API with 200 endpoints should not become 200 tools. Model the tasks, not the endpoints. find_overdue_invoices_for_account is a better tool than a generic query that takes raw SQL — it is easier for the model to choose correctly, easier to permission, and easier to audit.

Auth and identity. The hard part, and where most designs need rework. The question is whose permissions apply when the model calls a tool. If the server holds one service account, every user gets that account's access, and your careful row-level security is gone. Production integrations propagate the end user's identity to the underlying system, so existing access controls still apply.

Observability. Every tool invocation is an action taken by a non-deterministic system against your data. Log the call, the arguments, the caller identity, and the result. When something goes wrong - and it will - this is the only way to reconstruct what happened.

Error semantics. Return errors the model can act on. Error 500 teaches it nothing. No account found with that ID; try searching by company name lets it recover on the next turn. Well-written errors measurably reduce retry loops.

What MCP does not do

Overstated expectations are the main reason MCP projects disappoint.

MCP does not make your model smarter. It gives the model access. If the model reasons poorly about your domain, better plumbing will not fix that.

MCP is not a data pipeline. It is a request-time interface. If your data is stale, scattered, or contradictory, MCP will surface that faithfully. It is not a substitute for the integration work you have been deferring.

MCP is not a security layer. It is a transport and interface standard. Authentication, authorisation, rate limiting, and audit are your responsibility. An MCP server carelessly exposing an internal database is a data breach with a standard interface.

MCP does not remove the need for evaluation. Giving a model tools expands what it can do, including what it can do wrong. Tool-using systems need harder testing than text-generation systems, not easier.

When MCP is the right choice

MCP earns its cost when several of these hold:

You have more than one AI application, or expect to. The economics are in reuse. One application against one system does not need a protocol.
The same systems get accessed repeatedly. If every AI initiative needs the customer database, wrapping it once pays back quickly.
You want to stay portable across models. A standard interface means changing model providers does not mean rewriting integrations.
The systems are yours and are staying. MCP is explicitly a no-migration approach. It reads the systems you already run rather than requiring you to move data somewhere an AI tool prefers.
You need auditability. A standard invocation layer is a natural place to log and enforce.

When it is not

Be honest about these:

One model, one system, one use case. A direct function call is simpler. Do not add a protocol to save work you will never repeat.
The bottleneck is data quality, not access. Fix the data first. MCP will only make the problem more visible, faster.
Latency budgets are very tight. Every hop costs. A synchronous user-facing path measured in tens of milliseconds may not tolerate the round trip.
Nobody will own the servers. An MCP server is production infrastructure. Without an owner it rots like any other service, and a rotting server that models call autonomously is worse than no server.

Getting started

A sensible first project:

Pick one system and one real task. Not a demo. Something a person currently does by hand.
Design the tool surface around that task. Three to five well-named tools beat thirty generic ones.
Solve identity properly from day one. Retrofitting per-user permissions onto a service-account design means starting over.
Instrument everything before you widen access. You want the logs in place before the interesting failures happen.
Evaluate on real inputs. Collect the messy real-world cases and check behaviour against them, especially the ones where the right answer is to do nothing.

Then, and only then, add the second system. The value compounds from there - but only if the first one is genuinely solid.