What is MCP?

The short answer

MCP, the Model Context Protocol, is a standard for how an AI application talks to external tools and data. Instead of writing a bespoke connector for every model and every system, you expose a system once and any compatible client can use it.

It is plumbing, in the way HTTP is plumbing. Unglamorous, and it decides how much of your integration work you have to redo the next time something changes.

The problem it solves

Without a standard, connecting M models or applications to N systems is M times N pieces of custom glue. Each one has its own auth, its own error handling, its own idea of what a tool description looks like, and each one breaks separately.

With a standard, it becomes M plus N. You expose your database, your ticketing system, your internal API once, and anything that speaks the protocol can consume them. That is the entire pitch, and it is the same reason every other integration standard existed.

How it works

There are two sides. A server wraps a system you own and exposes what it can do. A client lives inside the AI application and consumes those servers.

Servers expose three things. Tools are actions the model can invoke, like creating a ticket or running a query. Resources are data the model can read, like a document or a record. Prompts are reusable templates the server suggests.

The client asks the server what it offers, passes those descriptions to the model, and when the model chooses to call one, the client routes the call and returns the result. The model never touches your system directly.

What it is not

It is not a model, and it does not make a model smarter. It is not an agent framework, and it does not decide what to do next. It does not give you memory, planning, or orchestration.

Most importantly, it is not a substitute for deciding what the system should do. A protocol tells you how to connect things. It has nothing to say about which decision is worth automating, which is the part that determines whether any of this was worth building. We covered that in what an AI agent is.

Where it fits in a production stack

Usually at the boundary between the AI application and everything you already own. The model reasons, the client mediates, the server enforces what is allowed, and your system does the actual work.

The practical value shows up on the second and third integration, not the first. If you are connecting one internal API to one application, a direct integration is faster and you should probably just write it. The standard pays off when the number of both sides is growing and you do not want the maintenance to grow with the product.

The security surface nobody mentions

You are giving a model the ability to invoke functions in your systems. That deserves the same paranoia as any other privileged interface, and it usually gets less.

Scope every server to the minimum it needs, and carry the requesting user's permissions through rather than running everything as a service account with broad rights. Treat tool descriptions as untrusted input, because a description is text that reaches the model and text that reaches the model can attempt to steer it. Log every invocation with enough context to reconstruct what happened.

And be deliberate about third party servers. Installing one is granting code you did not write the ability to act on data you own.

Build your own or use an existing one

Use existing servers for commodity systems, the ones where thousands of teams need the same integration and your version would not be different. Build your own for anything that touches your internal domain, because the tool boundary is a design decision about what the model is allowed to do, and that is not something to inherit from a stranger.

That split is the same one we described in build vs buy. Rent the commodity layer, own the layer that encodes how your business works.

What changes in your architecture

The useful shift is that capability becomes declarative. Adding an ability stops being a code change inside the AI application and becomes exposing a tool on a server, which is a smaller and safer change.

The cost is a layer of indirection. Debugging now spans the model, the client, the server, and the underlying system, which makes end to end tracing not optional. If you cannot follow a single request across all four, you will spend your incidents guessing.

Do you need it yet

If you have one application and one integration, no. Write the direct connection and move on. If you have several systems and expect more consumers over time, or you want to avoid rewriting connectors when you change model provider, then yes, and adopting it early is cheaper than retrofitting.

The honest framing is that MCP reduces integration cost. It does not create value on its own. The value still comes from the decision you automate, which is why we start there when we build production AI, end to end.