What MCP is, explained for people who do not write code
MCP, the Model Context Protocol, is a shared standard for how an AI app asks another program for information or gets it to do something. Before it, every AI product had to build a separate custom connection to every tool. With it, any app that speaks MCP can talk to any tool that speaks MCP. What changes in practice is that the assistant stops needing to be told your context and starts being able to fetch it, which is why answers stop going stale halfway through a conversation.
MCP appears in every AI product announcement and almost nothing explains it to someone who does not write software. The explanations that exist are either one sentence that assumes you already know, or a specification. Here is the version in between.
The problem it was invented for
A language model on its own knows nothing about your situation. It has no access to your calendar, your tickets, your documents or your files. So every AI product that wanted to be useful about your actual work had to build a connection to each tool by hand: one for Jira, another for Notion, another for your email. Each connection was custom, each was maintained separately, and each one broke on its own schedule.
That is the same problem printers had before USB. Every printer needed its own driver for every computer, so a new printer meant new work for everyone, and a new computer meant new work for every printer maker. The number of connections needed grows as the multiplication of both lists, and it becomes untenable long before anyone admits it.
MCP is the agreed plug. A tool implements it once and becomes reachable by every AI app that speaks it. An AI app implements it once and can reach every tool. The multiplication collapses into two additions.
What it actually does, concretely
An MCP server is a small program that publishes a list of things it can do, in a format an AI client understands. Each item has a name, a description in plain language, and a description of what information it needs.
When you ask a question, the client shows the model that list. If the model judges that one of them would help, it asks for it to be called, the server does the work, and the result comes back into the conversation. The model does not run anything itself and does not have access to your machine. It asks, the client decides whether to allow it, and the server does the work.
Fetching beats being told
Without tools, the way you give an assistant context is to paste it in. That works, and it has a failure mode nobody notices while it is happening: the pasted context is a snapshot. It was accurate when you pasted it and starts aging immediately. By the afternoon it describes a morning that has moved on, and there is no signal inside the conversation telling you which parts have gone stale.
It also costs the same on every question. Whether you are asking something that needs your project background or something that does not, the paste sits there being paid for.
A tool call reverses both. The context is fetched at the moment it is needed, so it reflects five minutes ago rather than nine this morning, and questions that do not need it do not pay for it. That is the whole difference, and it changes a conversation more than it sounds like it would.
What MCP is not
- It is not automation. MCP does not run on a schedule and does not trigger on events. Nothing happens unless a conversation is happening and the model asks for it. If you want something to run every Monday, you want a workflow, not an MCP server.
- It is not an app store. There is no marketplace you browse. A server is a program you already have, or one you install deliberately, and connecting it is a decision you make.
- It is not a model. It has no intelligence of its own. It is the wiring between a model and a tool, and it works the same whichever model is on the other end.
- It is not automatically safe. A server can be given the ability to write, not only read. What protects you is how that particular server is built, which is worth one question before you connect anything.
The safety question, in plain terms
Reading and writing are not the same risk and should not be treated as one. A server that can only read can, at worst, put something in front of the model that you did not intend. A server that can write can change things in your systems, and "the model decided to" is not a comfortable reason for a ticket to have been closed.
So the questions to ask about any MCP server you are about to connect are short. Can it write, or only read? If it can write, is there a limit on how often, a record of what it did, and something that tells you at the time? A server that answers all three is one you can leave connected without thinking about it again.
Setting one up without editing a config file
Most MCP documentation shows you a block of JSON to paste into a file whose location you have to look up. That is a fine instruction for a developer and a wall for everybody else. It is also usually avoidable: an app that provides a server can write that entry itself.
Install the app that provides the server
MCP servers usually ship inside a normal desktop app rather than being installed on their own.
Open its MCP or Integrations screen
Look for a section listing AI clients: Claude Desktop, Codex, Cursor and similar.
Toggle your client on
The app writes its own entry into that client's configuration. There is no path to find and no file to edit.
Restart the AI client
MCP servers are read at startup, so a client that was already running will not see the new one until it reopens. This is the step people skip.
Ask something only the tool would know
The client will show that it called a tool to answer. That is the confirmation that the connection is live.
If you want the worked example rather than the general shape, the walkthrough for connecting a work session to Claude Desktop is here, and what Khint exposes is on the MCP page.
Is this worth your attention?
If you use an AI assistant occasionally, for self-contained questions, it changes nothing and you can safely ignore it.
If you have noticed yourself re-explaining the same project at the start of every conversation, that habit is the exact thing MCP removes, and the setup is one toggle and a restart. That is the whole population for whom this matters, and it is a larger one than the word "protocol" suggests.