Connect the robot to its tools, with MCP
MCP gives an AI application a shared way to communicate with servers that offer tools and context. The host still decides what reaches the model, what leaves the app and when an action needs our approval.
Let’s say some plans are finally gonna make it out of the group chat, and we’re catching up with our mates over dinner. We want to lock in a Thursday in the next couple of weeks. The dates are in a calendar, the guest list and dietary requirements are in a note none of us can find, and the restaurants are in a booking service. The plan is sitting in the chat, but the useful details we need to make it happen are everywhere else.
We could hand all of that to an AI assistant. It may understand exactly what we want, but it still can’t open the calendar, read the note or reserve a table just because we asked. To turn those plans into an actual dinner, it needs a reliable way to reach the information and actions sitting elsewhere, and that’s the useful place to start making sense of MCP.
MCP, short for Model Context Protocol, gives an AI application a shared way to communicate with servers that offer useful information and actions. Instead of inventing a completely different connection for every server, the application can use the same basic structure to find out what’s available, make a request and receive the result.
The name can make it sound as though the model is opening all these connections itself. In practice, the model works with the information and choices the application gives it. The application manages the MCP connections, and each server still decides what its own rules allow. We decide how much access and authority to give the arrangement in the first place.
One assistant on screen, a few parts underneath
The assistant may look like one tidy product, but MCP gives us names for a few parts we normally don’t see. The product coordinating the work is the host. It keeps hold of the conversation, gives the model the context it needs and manages the available connections.
Each connection gets its own client inside the host. The calendar connection uses one client, the notes connection another and the booking connection a third. Each client speaks to one server, and they can all sit behind the same screen. That’s why the assistant can feel like a single thing even when several separate conversations are happening underneath.
The server is at the other end of each connection. It tells the client what it can offer and handles the requests that arrive. It may run on the same computer as the host or somewhere else over the internet. Either way, the client is the host’s dedicated line to that server.
Now imagine the model sees a calendar option and suggests checking our free evenings. That suggestion is still only a proposal, so the host decides whether to send it through the calendar client. The calendar server then checks the request against its own permissions before returning anything. What looked like the assistant casually checking a date was really several smaller jobs passed along in order.
What can each server actually offer?
After the host connects to a server, it needs to know what that server can offer. MCP gives servers three especially useful ways to describe that: tools, resources and prompts.
A tool is something the server can do, such as find_free_evenings on our calendar server. The booking server might offer search_restaurants and create_reservation. Search and reservation deserve separate tools because looking at a list of restaurants is very different from committing us to a table.
A resource is information the server can make available for the host to read. Our notes server might offer the dinner note with the guest count and dietary requirements. That doesn’t tip the whole notes folder into the conversation. The host can request the relevant note and decide whether its contents should enter the model’s context.
A prompt is a reusable starting message written by the server for a person to choose. A booking server could offer one for comparing venues, with the same useful questions ready each time. We don’t need one for this dinner, and plenty of servers won’t offer all three.
Each one gives us a different next move: bring a resource into the conversation, choose a prompt to get started or ask a server to run a tool. The host presents the useful options, controls what reaches the model and decides which proposed tool requests can leave the application.
Let’s put the dinner request through it
We start by giving the assistant the next couple of weeks from the group chat. The host can ask its connected servers what they offer, or use descriptions it already has. It only needs to show the model the options that are useful for this dinner.
The model suggests find_free_evenings and supplies the dates. The host sends that request through the calendar client. If the calendar server accepts it, Thursday and Saturday come back. The host gives those dates to the model, and we’ve learned something without changing the calendar.
Now we need the note. The host requests it through the notes connection, and the notes server returns the part we’re allowed to read: six guests, one vegetarian and one guest with a nut allergy. Those details join the two open evenings in the model’s context. The rest of the folder stays where it was.
With a date, party size and dietary requirements, the model can suggest searching for restaurants on Thursday. The host sends the proposal through the booking client. Several matches come back, but the first venue can’t safely cater for the nut allergy, so the model can compare the remaining venues or suggest a different search. The host decides whether to send that next request and keeps hold of the larger dinner plan as results arrive from separate servers.
Suppose we choose a venue. Asking for a reservation has a real consequence, so create_reservation is a separate tool. Before anything leaves the application, the host can show us the restaurant, time, party size and cancellation terms. If we say no, the reservation request stops there. If we approve the booking, those details go through the booking client.
The booking server may confirm the table, tell us somebody else just took it or ask for a missing detail. The host shows us what came back and can then let the model suggest another step, send the work back to us or stop at a limit. MCP gives those requests and results a shared structure, and the host keeps control of the wider job.
Where does the API fit?
If the booking service already has an API for searching restaurants and reserving tables, what is MCP adding?
Both can be part of the same request because the booking client speaks MCP to the booking server, and that server can turn search_restaurants into a request the booking API already understands. For this exchange, the model remains with the host, suggesting the MCP tool and the details to send. The server handles the API exchange behind its own boundary.
Talk about different “types” of MCP server can get muddled because we may be asking three different questions. Does the server run on our computer or somewhere remote? Does it offer tools, resources, prompts or a mixture of them? And behind those capabilities, does it work with permitted files, calculations, a database or an API? Those choices can be mixed in plenty of ways, so the API wrapper in our dinner is one setup among many.
If an API does sit behind the server, the two boundaries keep their own access rules. A token meant for the MCP server stays with the MCP server. If the booking API also requires authorisation, the server uses a separate credential meant for that API. Passing one token straight through would treat two different services as though they were the same place.
The API guide follows a request across the service boundary behind the server. For our dinner, MCP covers the exchange between the host’s client and the booking server. The API covers the server’s next exchange with the booking service. If we only needed one narrow connection, a direct API integration might still be simpler. MCP becomes useful when several compatible hosts and servers can reuse the same kind of conversation.
A shared language still needs trust
Even when the host and server speak the same language, we’d still want to know which server we’re speaking to, what we’ve allowed it to reach and whether a proposed action should go ahead.
We choose whether to connect a server and how much access to grant. The host applies the connection rules, controls what reaches the model and decides which proposed requests may be sent. The server checks what arrives against its own permissions. Those layers are easy to blur when the whole experience appears in one assistant window.
We might be comfortable letting a connected calendar server read free and busy times without asking us again on every search. Reserving a table has a bigger consequence, so the host can pause and show us exactly what is about to happen.
The server also needs to check the request, enforce access controls and return a result in the expected form. A polished tool description only tells us what the server says it offers. Its implementation, permissions and any system behind it decide what will really be read, changed or returned.
The model can also choose an unhelpful tool or reason from incomplete information. A poor restaurant suggestion could begin with a vague note, the wrong tool, a server problem or weak model reasoning. MCP gives the host and server a request they can both understand. It can’t make every part of the arrangement reliable.
MCP and an AI agent also do different jobs. MCP can supply the tools and context, but the agent application carries the larger run: the goal, the loop for choosing next steps, the limits, the stopping conditions and the handback. The AI agents guide follows that larger run.
What “supports MCP” actually tells us
When a product says it supports MCP, we’ve learned something useful: it can speak this shared protocol with compatible servers. Its practical meaning depends on which host connects to which server and what that server offers.
What can enter the model’s context, and what can leave the application? Which tools only read, and which ones change something? If a request can make a booking, send a message or update a record, where do we get to see and approve it?
We’d also want to know what happens when a server fails, returns something suspicious or asks for more access. A useful product lets us see what happened, stop the next step and remove access we no longer want.
Back in our dinner plan, the assistant may appear to check our calendar, read the note and search for a restaurant. Underneath, the host keeps hold of the plan as separate clients speak to separate servers. The model suggests useful next steps, and the host and servers decide which requests can actually go through. Between each client and its server, MCP gives the two sides a shared way to describe capabilities and exchange requests. That shared structure makes each exchange more consistent, but we still decide what the connections may reach, what can happen without asking and when the work needs to come back to us.
Once the table is booked, we’ve pulled a date from the calendar, the dietary requirements from the note and a restaurant from the booking service, and we’ve finally ended up with plans that made it out of the group chat.