Model Context Protocol (MCP)

Every agent in this course so far has reached the outside world through tools, and those tools came from the agent's own software. The lesson on tools showed the rule: the software holds a list of things its code can do, and the model can ask only for what is on that list. Agents, and the harnesses behind them, are built around that list.

A fixed list has a clear limit. If the people who built the application did not write code for something, the agent cannot do it. A chat app that ships with web search and file reading cannot check your order at an online shop, however capable its model is.

The Model Context Protocol, shortened to MCP, removes that limit. It is a standard way of connecting an AI application to outside services, so that tools can be added after the application was built, by people who did not build it. After this lesson you can explain what MCP standardises, what an MCP server is, what it means to use one and to offer one, and why it matters that the protocol is open.

1. What a fixed tool list feels like

Take an assistant whose application ships with three tools: web search, reading a file, and running code. A person asks it about a parcel.

tools available: web search, read a file, run code

[you]    Has my order shipped yet?

[model]  I have no way to reach your orders from in here.

This reply has nothing to do with what the model can understand. The model understood the question. The limit is the list it was handed. No tool on the list can reach the shop's order system, so the model has nothing to ask for.

Without a shared standard, there is one fix. The people who built the application had to write new code for the shop, then for the next service, then for the one after that. Every pairing of an application and a service needed its own custom work.

2. A socket in the application

MCP changes the shape of the application. An application without it is a sealed box: it contains the tools it shipped with, and nothing can be added from outside. An application with MCP has a socket.

flowchart LR
    subgraph A["The agent software"]
        direction TB
        t1["Web search"]
        t2["Read a file"]
        t3["Run code"]
    end
    O["Something from outside<br/>tools the application<br/>never had code for"] -- "plugs in through MCP" --> A

The diagram shows the application on the left with its three built-in tools, which are everything it shipped with. On the right is something from outside: tools the application never had code for. MCP is the socket between them. Capabilities are added from the outside, and the application does not have to be rebuilt.

A familiar comparison is the USB port on a computer. The computer's maker does not know which keyboard, printer, or camera will be plugged in. It only promises that anything following the USB standard will work. MCP plays the same role for AI applications and outside services. The comparison stops being accurate in one place: a USB device is a physical object next to the computer, while an MCP server is a program that can run on the same computer or on another one across the internet.

3. What a protocol is and what this one fixes

A protocol is an agreed set of rules for how two programs talk to each other. A protocol does not do any work itself. It fixes the form, so that two programs written by different people, who never met, can understand each other.

The central thing MCP fixes is the form of a description. Here is a tool, described:

name: place_order
description: Place an order for the
  items already in a basket.
input:
  basket_id    string
  address_id   string

And a resource, described:

name: order_history
description: A customer's past orders,
  newest first.
returns:
  a list of orders

These are simplified samples. Real descriptions are written in a stricter data format, with similar parts.

The two samples show the two main things a server can offer:

• A tool is an action. place_order does something. Its description gives its name, what it does in plain words, and the inputs it needs. Here the inputs are basket_id and address_id, and "string" means each one is a piece of text.
• A resource is data to read. order_history does not change anything. Its description says what it is and what it returns.

The descriptions have the same shape whoever wrote them and whoever reads them. That sameness is the entire point. An application that knows how to read one MCP tool description can read every MCP tool description, from any server.

MCP also fixes the messages around the descriptions: how an application asks a server which tools it has, how it asks for a tool to be run, and how the result comes back.

4. The provider side: putting up an MCP server

Suppose you run an online shop. You already built a shopping service with a catalogue, an order system, and delivery tracking. You want AI agents to be able to use it.

flowchart LR
    A["An AI agent<br/>somebody else's"] -- "through the protocol" --> S["Your MCP server<br/>search_items<br/>place_order<br/>track_parcel"]
    S --> B["Your shopping service<br/>catalogue, orders, delivery"]

You set up an MCP server. This is a program that sits in front of your service and offers some of its abilities as tools. In this example it exposes three: search_items, place_order, and track_parcel.

Three points about this arrangement:

• The service stays as it is. The shopping service is the thing you already built. The MCP server is a thin layer in front of it.
• You choose what to expose. The server offers certain tools, not everything the service can do. A shop might expose searching and ordering and keep refunds and price changes private.
• The agent belongs to somebody else. You did not build it and do not control it. Through the protocol it can now act on your service.

5. The consumer side: connecting to a server

From the other end, using an MCP server is a setting, not a building project. In the application, it looks roughly like this:

Before the connection, the agent's tools were web search and reading a file. After it, the list also contains search_items, place_order, and track_parcel.

Now the earlier question has an answer. The person asks whether the order has shipped. The model sees track_parcel on its list and asks for it. The application passes the request to the shop's MCP server, the server asks the shopping service, and the result travels back to the model as text.

The model's situation has not changed at all. As in every earlier lesson, it sees tool descriptions in its context and writes a request. It does not know or care whether a tool is built into the application or comes from a server on the other side of the world. The difference is in who runs the code: for a built-in tool it is the application, and for an MCP tool it is the server.

6. Two ends of the protocol

The protocol has two ends, and most people only ever stand at one of them.

A person who adds a calendar server to their chat app is a consumer. The company that built and runs the calendar server is a provider. A company can be both: it offers a server for its own product and connects its internal agents to servers from others.

7. A second way into the same service

For a business, an MCP server is a second entrance to a service that already has one.

flowchart LR
    C["A customer<br/>a person, clicking"] --> W["Your website"]
    W --> S["Your shopping service"]
    CA["A customer's agent<br/>theirs, not yours"] --> M["Your MCP server"]
    M --> S

The top path is the entrance the shop always had. A person opens the website, clicks through pages, and places an order.

The bottom path is new. A customer's AI agent, which belongs to the customer and not to the shop, connects to the shop's MCP server and places the order through the Model Context Protocol.

Both paths end at the same shopping service. There are two ways in and one service. The website is built for human eyes and clicks. The MCP server is built for agents, which work better with named tools and clear descriptions than with web pages designed for people.

8. What the protocol standardises

The table below states what MCP fixes and what it leaves open.

MCP does not supply the tools. The shop's place_order and a bank's get_balance do entirely different things, and each provider writes its own. What MCP fixes is the way a tool is written down and called.

This solves a counting problem. Without a standard, 10 applications and 50 services need up to 500 custom connections, one per pair. With a standard, each application supports the protocol once, each service offers one server, and any of the 500 pairs can be connected without new custom code.

9. An open protocol

MCP was published by the AI company Anthropic in late 2024 as an open standard. "Open" has specific consequences.

• It is not one application's feature. The ChatGPT application and Claude are examples of applications that can connect to MCP servers at the time of writing. The protocol does not belong to either.
• Any AI application can implement it. Support is something a program's developers choose to add.
• That includes an agent you write. A person building their own agent can make it speak the protocol, and it can then use the same servers as the large products.
• Whoever uses it chooses the servers. The person or company running the application decides which servers to connect.

The result is that people can extend an agent in directions its builders never planned. An application can be connected to servers its makers have never seen, for work they did not anticipate.

10. Limits and risks

Connecting a server adds real abilities, so it adds real risks.

• A connected server is trusted software. Its tools can take actions, and the text it returns goes into the model's context, where it can influence what the model does next. So a server from an unknown source is a risk, and the choice of which servers to connect is a trust decision.
• Actions can have consequences. A place_order tool spends money. Many applications ask the person to approve such calls, and a provider should require proper sign-in and permissions on its server.
• Tool descriptions use context. Every connected tool adds a description to each request. Connecting dozens of servers fills the context with descriptions, which costs tokens and contributes to context rot.
• The application must support MCP. A program that has not implemented the protocol cannot use MCP servers.

Interview points

• MCP, the Model Context Protocol, is an open standard for connecting AI applications to external tools and data sources.
• Without MCP, an agent is limited to the tools its own software was built with, and each new integration needs custom code in the application.
• An MCP server is a program a service provider runs. It exposes selected capabilities of a service as tools, which are actions, and resources, which are data to read.
• The protocol standardises how tools and resources are described, listed, and called. It does not define what any tool does.
• From the model's point of view nothing changes. MCP tools appear as tool descriptions in the context, and the model requests them like built-in tools. The server, not the application, runs the code.
• A consumer connects an application to an existing server by configuration. A provider builds and runs a server so that other people's agents can use the service.
• For a business, an MCP server is a second entrance to an existing service, built for agents, next to the website built for people.
• A shared standard turns many pairwise integrations into one implementation per application and one server per service.
• MCP is open: any application can implement it, including a custom agent, and users choose which servers to connect.
• Risks include trusting third-party servers, tools with real side effects, and context space used by many tool descriptions.

Summary

• MCP lets an AI application gain tools after it was built.
• A service provider offers tools and resources through an MCP server.
• A user connects an application to a server with a setting, without writing code.
• The protocol fixes how tools are described and called, not what they do.
• The model still only reads descriptions and writes requests.
• One service can have two entrances: a website for people and an MCP server for agents.
• The protocol is open, so any application or custom agent can support it.
• Connected servers must be trusted, because their tools act and their output reaches the model.