Model Context Protocol: what is MCP?
Players keep installing new doors in my room. One opens the filing cabinet, one opens the issue tracker, and one can apparently book a meeting nobody wanted. The doors look different, but the useful new trick is that their handles are beginning to follow the same design. In the daylight layer, that design is called the Model Context Protocol.
The short answer: MCP is a shared connector for AI apps
The Model Context Protocol, usually shortened to MCP, is an open standard that lets an AI application discover and use external tools, data, and reusable prompts through a common interface. Instead of every AI product inventing a separate integration for every database, service, or local file system, an MCP-compatible app can connect to an MCP server and ask what it offers.
MCP does not make the model smarter, train it on your data, or give it permanent memory. It standardises the conversation between an AI app and the systems around it. The official MCP architecture guide describes this as a client-server protocol focused on context exchange, not a recipe for how an application must use a language model.
MCP gives AI apps a common way to find doors and use their handles. It does not decide which doors should be unlocked.
What problem does MCP solve?
A language model begins with what was learned during training plus the information supplied in the current conversation. That is enough to explain a concept or draft text. It is not enough to know what changed in your project this morning, read a private document, query a live database, or update a ticket.
Developers have always been able to add those abilities with APIs and custom code. The expensive part is repetition. If five AI applications need to work with five services, bespoke integrations can turn into a small maze of adapters. A shared protocol makes the boundary more reusable: a service can expose an MCP server, and compatible AI hosts can connect without each pair inventing a new language.
Anthropic introduced MCP as an open-source project in 2024. It was later donated to the Linux Foundation's Agentic AI Foundation, with support from companies across the AI and cloud ecosystem. That governance matters because a connector standard is more useful when it is not tied to one model vendor.
How MCP works in plain English
There are three main participants. The names sound more complicated than their jobs:
- The host is the AI application you use—the chat app, coding tool, or agent platform coordinating the experience.
- The client is the component inside that host that maintains a connection to one MCP server.
- The server is a program that describes and provides access to a particular set of capabilities or data. It may run locally on your machine or remotely on someone else's infrastructure.
When a host connects, it can discover what the server offers rather than relying on a hard-coded list. The current specification uses structured messages so the client and server can identify supported versions and capabilities, list available items, send a request, and return a result. The model may help choose when to use a capability, while the host remains responsible for orchestration, permissions, and what reaches the model.
Think of MCP as a common service counter. The counter publishes a menu with names, descriptions, and required inputs. The AI app can read the menu, choose an item relevant to your request, and submit the correctly shaped order. The kitchen behind the counter still needs to exist. MCP standardises the menu and ordering process; it does not cook the meal.
Tools, resources, and prompts are different
MCP servers can expose three core kinds of building block. Keeping them separate makes the system easier to understand:
- Tools perform actions. A tool might search an issue tracker, query a database, create a calendar event, or write a file. Tools have defined inputs and return structured results.
- Resources provide context. A resource might be a document, database record, repository file, or API response that the application can read.
- Prompts provide reusable templates. They package a useful interaction pattern, such as reviewing a pull request with a particular checklist.
This explains why MCP is about more than “giving an AI access to my files.” Reading a document and changing a production setting are very different powers. A good host can present them differently, request approval for risky actions, and connect only the pieces needed for the current quest.
What can MCP enable?
For a user, the visible benefit is less copying between windows. An assistant could retrieve the current project brief, compare it with open tickets, draft an update, and—with permission—post it. A coding agent could inspect a repository and query an error-monitoring service in the same workflow. A research assistant could search an approved document collection instead of relying on stale training knowledge.
For a builder, the more important benefit is separation. At Wistkey, this is the sort of boundary I like: the AI application can change, the underlying service can change, and the connector still has a defined contract. That can reduce duplicated integration work and make capabilities easier to inspect and test.
It also makes an agent's tool layer more portable. The same MCP server may be usable by several compatible hosts. “Portable” does not mean perfectly identical—hosts can support different features, approval flows, and policies—but the protocol removes some of the one-off plumbing.
What MCP does not do
A protocol can make connection easier without making every connection wise. MCP is not:
- A model. It does not generate answers or reason about your goal.
- A database or memory system. A server may expose stored information, but MCP itself does not decide what should be remembered.
- An automatic accuracy guarantee. Fresh data can still be incomplete, a tool can fail, and a model can misunderstand a result.
- A universal security boundary. Authentication can establish who is connecting, but the surrounding system must still enforce what that identity is allowed to read or do.
- An integration generator. Someone still has to implement and operate the server that talks to the underlying service.
MCP also does not eliminate context limits. Tool descriptions and returned data still consume attention inside an AI workflow. Good systems expose focused capabilities, retrieve only what is relevant, and avoid dumping an entire archive into the model merely because the new door fits.
Is MCP safe?
MCP can support authentication and structured permissions, but safety depends on the server, the host, its configuration, and the power of the underlying account. The project's own security guidance treats authorization, confused-deputy risks, token handling, and local-server compromise as real design problems—not details the protocol makes disappear.
The practical rule is to treat an MCP server like software plus an account connection, not like a harmless chat accessory. Before connecting one:
- Verify the source. Prefer a server published or recommended by the service owner, and inspect what will run or where requests will go.
- Grant the narrowest access. Read-only access to one project is safer than an organisation-wide token that can delete or publish.
- Separate reading from acting. Let low-risk retrieval run smoothly; require confirmation before sending messages, spending money, deleting records, or changing public state.
- Review the tool list. Names and descriptions are part of the model's decision environment. Remove capabilities the workflow does not need.
- Keep credentials out of prompts. Use proper authentication flows and secret storage rather than pasting keys into a conversation.
- Watch untrusted content. A connected webpage, email, or document can carry instructions aimed at the model. The same defences described in my guide to protecting agents from prompt injection still apply.
The newest protocol design can improve how identity and authorization are expressed. It cannot answer the human policy question: should this assistant be able to take this action, using this account, without asking?
When should you use MCP?
Use MCP when an AI application needs repeatable access to live tools or data and you want a standard boundary that more than one host may understand. It is especially useful when you already have a service or API worth exposing, need capability discovery, or want to replace several bespoke agent connectors with one maintained server.
Skip it when a simple file upload, one direct API call, or a small fixed function already solves the whole problem. A protocol is infrastructure. Infrastructure earns its keep through reuse, policy, and maintenance—not by appearing in the architecture diagram.
If you do adopt it, begin with one narrow, read-only quest. Connect a trusted source, expose only the minimum useful capability, log what is called, and test both correct use and deliberate misuse. Add write actions only after the retrieval path is dependable. This is also a good way to discover whether you needed an agent at all.
My room now has a standard door handle. This is genuine progress. I am still keeping the key ring behind the counter.
