What is MCP (Model Context Protocol) and why does it matter?

The Model Context Protocol (MCP) is an open standard that lets an AI application connect to external tools and data through one common interface, instead of a custom integration for every pairing. It uses JSON-RPC 2.0 messages between a host application, a client inside it, and a server that exposes capabilities. If your team is building AI features or agents that need to read from or act on real systems, MCP is the plumbing worth understanding first.

What problem does MCP solve?

Before a shared protocol, every AI application that needed to read a calendar, query a database, or file a ticket needed its own glue code for each system. Five applications and ten systems meant up to fifty integrations, each with its own auth, error handling, and quirks.

MCP turns that into a contract. A system exposes itself once as an MCP server. Any MCP-capable application can then discover what it offers and call it. The official specification says it draws inspiration from the Language Server Protocol, which did the same for programming language support across editors.

For a CTO the practical gain is that an integration you build once can serve a chat assistant, an IDE, and an internal agent, without three rewrites.

How does MCP work?

The protocol defines three roles.

Messages are JSON-RPC 2.0. The spec defines two standard transports: stdio, where the client launches the server as a subprocess, and Streamable HTTP, where each message is an HTTP POST to a single endpoint. Local tools usually use stdio. Remote, shared servers use HTTP.

One detail matters if you read older tutorials. Earlier revisions used a connection-scoped session with an initialize handshake. The latest revision describes stateless, self-contained requests with per-request capability negotiation, and it documents a backward-compatibility path. Check which revision your client and server libraries target before you debug a mismatch.

What can an MCP server expose?

The specification lists three server features, and the difference is about who is in control.

1. Resources. Context and data for the user or the model to read, such as a file, a database row, or a document.
2. Prompts. Templated messages and workflows that a user picks, such as a "summarize this incident" template.
3. Tools. Functions the model can decide to execute, such as create_ticket or search_orders.

Tools get the most attention because they let a model take action. Each tool has a name, a description, and a JSON Schema for its input, and optionally a schema for its output. The model reads the description to decide when to call it, so the description is part of your product, not documentation. Our post on tool calling design for agents covers how to write them well.

Is MCP the same as function calling or an API?

No, though they sit close together. An API is how software talks to your system. Function calling is how a model asks the host application to run something. MCP is the standard layer between the host and the systems it wants to reach.

If only one product uses the tool and you control both sides, a function inside your service is simpler and has fewer attack surfaces. Reach for MCP when reuse across applications is real, or when you want to plug into clients you do not control.

What are the security basics?

The specification is direct about this. It describes tools as representing arbitrary code execution and says hosts must obtain explicit user consent before invoking any tool. It also says descriptions of tool behavior, including annotations, should be treated as untrusted unless they come from a trusted server. And it states that MCP itself cannot enforce these principles at the protocol level.

That means the controls live in your implementation: validate every tool input, enforce access control on the server, rate limit, and keep a human able to deny risky actions. We cover the attack classes in MCP security risks.

How do you start with MCP in a real product?

A sensible first project is small and measurable.

1. Pick one workflow. Choose a task where a person currently copies data between two systems.
2. Expose two or three tools. Prefer a narrow, task-shaped tool over a thin wrapper around every endpoint.
3. Start read-only. Add write actions only after you have seen the model behave on real inputs.
4. Write evals. Build a set of real tasks and score whether the model picks the right tool with the right arguments.
5. Log every call. You need an audit trail of what the model asked for and what the server returned.

Our lessons from doing this are in building an MCP server.

Frequently asked questions

Takeaway

MCP is a useful standard, not a strategy. It earns its place when several AI applications need the same capability and you want to build the integration once. Want this built for your team? Book a free 30-minute call.