What it standardises, and what it does not
An assistant that can only read the text you paste into it is useful for advice and useless for work. Getting it to touch a real system meant writing an integration against one vendor's tool-calling format, then writing it again for the next vendor, and again for the desktop app — the same connector, three times, drifting apart from the day it shipped.
MCP defines the connection instead. A server exposes some capability; a client, inside an assistant, consumes it. Both ends speak JSON-RPC over a defined transport, so a server written for one client is reachable from every other client that implements the protocol.
What it does not do is make the model good at using what it finds. The protocol carries the plumbing — discovery, invocation, results, errors — and the judgement about when to call something and what to do with the answer stays entirely in the model and its instructions.
It is a common plug. Write the connector once and any assistant that speaks MCP can use it.
The three things a server can expose
Tools are actions the model can invoke: run a query, open a ticket, send a request. They are the part everybody means when they say MCP, and they are the part that can change the world outside, which is why a client is expected to ask the human before running one.
Resources are things the model can read: a file, a record, a page. They are addressed rather than called, and they are how an assistant gets context without the user pasting it.
Prompts are ready-made instructions the server offers — a review checklist, a report shape — surfaced to the user as something to pick rather than to the model as something to invoke.
The split matters because it is the difference between an assistant that can read your data and one that can act on it, and those are two different conversations to have with a security team.
How it differs from function calling and from a plugin
Function calling is a model capability: the model emits a structured request to call something, and your code executes it. MCP does not replace that — it sits on top, so that what your code executes is a server somebody else may have written, discovered at runtime rather than hard-coded.
A plugin belongs to the platform that defines it and works there. An MCP server belongs to whoever wrote it and works anywhere the protocol is implemented, which is the whole point of standardising the connection rather than the catalogue.
The practical test: if switching assistant means rewriting the integration, it was not MCP.
What to be careful about
- A server is code you are running. Installing one from a stranger is closer to installing a package than to adding a bookmark, and it inherits whatever credentials you hand it.
- Tool descriptions are read by the model as instructions. A server can describe its own tool in a way that steers the assistant, which is a real attack surface and the reason approval prompts exist.
- Data reached through a server is data leaving its system. "The assistant can read our tickets" and "our tickets are in a model's context" are the same sentence said twice.
- Breadth is not free. Every connected server adds descriptions to the context the model has to reason over, and an assistant with forty tools available is measurably worse at choosing among them than one with six.
Why it appears in a glossary about visibility
Because the same shift is underneath both. Retrieval decides what an assistant can quote about you; MCP decides what an assistant can reach and do on behalf of the person asking. A buyer who used to visit your site to check a fact now has an assistant that can check it against a connected system instead, and your published page is competing not only with what the model remembers but with what it can look up live.
It also changes what a documentation page is for. A protocol server is described to the model in a handful of sentences, and those sentences are the whole of what it knows before it acts — the same discipline a page needs to be quotable applies, in fewer words and with less room to be vague.
Frequently asked questions
Is MCP an Anthropic product?
It was published by Anthropic in November 2024 and released as an open standard with an open specification and SDKs. It is implemented by clients and servers from many organisations, including ones with no relationship to Anthropic, and a server you write is not tied to any vendor.
Do I need MCP to give a model access to my data?
No. Function calling against your own code works and remains the right answer for one integration in one place. MCP earns its keep when the same capability has to be reachable from several assistants, or when you want to use connectors other people wrote without adopting their stack.
Does connecting a server mean the model can do anything it likes?
It means the model can request anything the server exposes. What actually runs is up to the client, which is expected to put the human in front of any tool that changes something. The security question is therefore about which servers you connect and with which credentials, not about the protocol.
Does having an MCP server help my site get cited by assistants?
Not by itself, and treating it as an SEO tactic misreads it. A server is reachable by people who have connected it, not by a model answering a stranger's question about your category. What gets you cited is still the page a retrieval system can read and quote.
Asked out loud
spoken, not typedThe same term in the words somebody uses speaking to an assistant rather than typing into a box — written from the situation, which is why each one carries the situation it came from.
You are approving a piece of software that will hold credentials to the helpdesk and expose parts of it to an assistant, and whatever the assistant reads leaves the helpdesk's boundary. The questions worth asking are who wrote the server, which credentials it gets, whether it can write as well as read, and whether a human confirms writes.
An API key gives one assistant one integration that you wrote and maintain. MCP is a common shape for that connection, so the same server works in other assistants and connectors written by other people work in yours. The access question is identical either way — the protocol standardises the wiring, not the trust.
No, and they are complements. A server gives an agent reach — things it can read and do. A skill gives it know-how — instructions for doing a particular job well, loaded when that job comes up. An agent with a database server and no skill will query your database badly.