What is MCP? Model Context Protocol explained for engineering leaders

Ask five vendors what the Model Context Protocol is and you will get five pitch decks. Here is the engineering answer: MCP is an open standard that defines how AI applications connect to external tools, data, and workflows. Anthropic released it in November 2024, and through 2025 it became the de facto integration layer for AI agents, with the major model providers and developer platforms shipping native support.

The protocol itself is deliberately boring — JSON-RPC 2.0 messages over two well-defined transports, plus a capability-negotiation handshake. What matters to an engineering leader is not the wire format. It is what MCP does to your architecture, your security model, and your integration budget. This post covers all three, including the parts that vendor demos skip.

The integration problem MCP solves

Before MCP, wiring a model into business systems meant provider-specific function-calling glue. Each AI application — a support copilot, an IDE assistant, an internal analytics chat — needed bespoke connectors to each system it touched: the CRM, the order database, the ticketing queue, the document store. With N applications and M systems, you maintain N x M integrations, each with its own auth handling, error semantics, and update cadence.

MCP collapses that to N + M. A system gets one MCP server — a program that exposes its capabilities through the protocol — and any MCP-compatible client can use it. An application implements the client side once and inherits the entire server ecosystem. This is the same standardization play the Language Server Protocol made for editor tooling, and the resemblance is deliberate: MCP's designers cite LSP as a direct inspiration.

The second-order effect matters more than the convenience: the integration layer becomes vendor-neutral. Tool definitions, permission checks, and audit logging live in servers you control, not in one provider's function-calling format. Swapping or mixing model providers becomes a configuration decision instead of an integration rewrite — exactly the position you want while model pricing and capability keep shifting quarter to quarter.

How the protocol actually works

Three roles, three primitives, two transports. That is most of the protocol.

Hosts, clients, and servers

• Host — the AI application the user interacts with: a chat product, an IDE, your internal copilot. The host embeds one or more clients and enforces top-level policy: which servers are allowed, what gets logged, what requires confirmation.
• Client — a component inside the host that holds a one-to-one, stateful connection to a single server. It negotiates protocol versions and capabilities, then routes requests and responses.
• Server — the program that wraps a real system: a Postgres database, an internal REST API, a filesystem, a SaaS product. Servers declare what they expose; clients discover it at runtime.

Tools, resources, and prompts

Servers expose three primitives, distinguished by who controls the invocation:

• Tools are executable functions the model decides to call — query_orders, create_invoice, search_tickets. Each tool is a typed contract: a name, a description the model reads, and a JSON Schema for inputs. Tools are where the risk concentrates, because tools act.
• Resources are read-only data the application attaches as context — file contents, database schemas, customer records. Think GET endpoints rather than POST.
• Prompts are reusable, parameterized templates the user invokes explicitly — standardized workflows like "summarize this incident for the postmortem."

The protocol also defines capabilities that flow the other way: a server can ask the client's model for a completion (sampling) or request missing information from the user mid-operation (elicitation). Both are less used in practice, but they are why MCP is more than a function-calling envelope.

Transports and versioning

Two standard transports cover the deployment spectrum. stdio runs the server as a local subprocess — simple, fast, no network surface, credentials stay on the user's machine. This is how most desktop and IDE integrations work. Streamable HTTP is the remote transport for shared, multi-client servers; it replaced the original HTTP-plus-SSE design in the 2025 spec revisions.

That last clause carries an operational warning. The spec is date-versioned and has moved quickly — authorization, transports, and structured tool output all changed materially during its first two years. Pin SDK versions, track which revision your clients negotiate, and budget for upkeep the way you would for any protocol dependency.

Why this matters at the leadership level

The architectural shift worth internalizing: MCP relocates the AI security model into code you own. Every tool call passes through your server, which means authorization, input validation, rate limiting, and audit logging are enforceable at one chokepoint — with the model's goodwill nowhere in the trust chain. Function-calling integrations scattered that logic across application code; MCP gives it a home.

The ecosystem cuts both ways. A large public catalog of pre-built servers exists for mainstream tools, which genuinely accelerates pilots. But a third-party MCP server is supply chain: it executes next to your data with the credentials you hand it. Review it, pin it, and monitor it like any dependency with production access.

We hold our own systems to the same standard. GenIm, our generative AI creative studio, runs models in production for e-commerce imagery, and the integration discipline described here is the one we apply to it — and to client builds. The production detail is documented in our work.

The failure modes that never appear in demos

• Prompt injection leading to data exfiltration. The highest-risk shape is an agent that combines three things: it reads content an attacker can influence (email, tickets, web pages), it can reach private data, and it can communicate externally. A hostile instruction hidden in a customer email can direct the agent to fetch sensitive records and leak them through any outbound channel. Mitigations are structural, not prompt-level: separate read scopes from write scopes, restrict egress, and require human confirmation on sensitive operations.
• The confused deputy. A server running on one powerful service account will happily act beyond the privileges of the user behind the request. Per-user authorization has to be evaluated server-side on every call — the model cannot be trusted to scope itself.
• Tool poisoning and rug pulls. A tool's description is an instruction the model follows. A malicious or compromised third-party server can embed hostile directives in its metadata, or change behavior in a later version after you approved an earlier one. Review tool descriptions like code, and pin server versions.
• Token misuse. Forwarding a client's token straight through to upstream APIs destroys the audit trail and blurs identity boundaries; the spec's authorization guidance explicitly prohibits it. The 2025 revisions formalized OAuth 2.1-based authorization for HTTP transports, with MCP servers acting as resource servers — use that model rather than improvising one.
• Context bloat. Every connected server's tool definitions ride along in the model's context window. Connect enough of them and you pay twice: per-request token cost rises, and tool-selection accuracy falls as the model chooses among dozens of similar-sounding options. Curate the tool surface per use case instead of mounting everything.

What MCP actually costs

The protocol is free; production-grade integration is not. Budget for five things:

• Token overhead. Tool schemas, descriptions, and intermediate results all consume context on every request, and multi-step agent workflows multiply the effect — cost grows with each reasoning hop, not with the size of the final answer.
• Latency. Each tool invocation is a full model round trip. A workflow that chains five calls serially inherits five inference latencies plus your systems' response times. Some of this is designable away with parallel calls and better tool granularity; none of it is free.
• Server engineering. Wrapping an API in MCP schemas takes days. A production server — identity-provider integration, per-user authorization, input validation, rate limiting, audit logging, deployment pipeline — is a real software project, sized like any other internal service.
• Operations and evaluation. Spec revisions, SDK upgrades, and model swaps all change behavior. Without a regression harness — golden tasks the agent must keep passing — every upgrade is a gamble.
• The systems underneath. The biggest hidden cost. Agents are only as capable as the APIs they call, and if critical workflows live in undocumented systems with coarse permissions, you pay for API integration and business automation groundwork before MCP returns value. Teams that skip this end up with agents that can only answer questions about stale exports.

Build, adopt, or skip: a decision checklist

• Adopt an existing server when the target is a mainstream SaaS product with an official or well-maintained server, the data involved is low-sensitivity, and you can pin and review the implementation.
• Build your own server when the system is proprietary, per-user permissions matter, the agent will write to production data, or you operate under regulatory constraints where the audit trail and security controls must be yours. This is the standard case for serious internal deployments, and it is the core of our MCP server development practice.
• Stay with plain function calling when one application talks to one model provider through a handful of stable, internally defined tools. MCP's indirection buys nothing there; add it when a second client or a second provider appears.
• Wait when there is no clean API layer underneath, or no concrete workflow with measurable value. A protocol cannot fix an integration estate that does not exist yet.

A pragmatic adoption path

What adoption looks like as an engineering program rather than a hack week:

At runtime an MCP server is an ordinary service: containerize it, put it behind your identity provider, autoscale it, and watch it like everything else in the fleet — standard cloud and DevOps territory. And when the agent is one feature inside a larger platform, the gateway should be designed alongside that platform as part of a custom software development effort, not bolted on afterward.

Where this leaves you

MCP won the standards race because it solved a real problem at the right moment: every team building AI features was reinventing the same integration layer, mostly badly. The protocol is stable enough to commit to, the ecosystem is broad enough to be useful, and the security model — when actually implemented — is defensible in front of an auditor.

The gap between a weekend demo and a production deployment is the same as it ever was: authorization, validation, observability, evaluation. MCP gives those concerns a well-defined home. Building something trustworthy to live in that home is the engineering work — and if you are deciding what to expose to agents first, we will map it with you.