MCP (Model Context Protocol)

The interesting question about an assistant stopped being how clever it is and became what it can reach. A model with no access to your calendar, your files or your customer records can only talk about work; one that can reach them can do some. That access used to be the expensive part, because every product built its own integrations and you were limited to whichever ones it had chosen. A shared standard changes the economics of that, and it is the main reason connecting an assistant to your own systems has become a configuration question rather than a development project.

The arrangement has two sides. A server exposes something useful, a set of files, a database, an issue tracker, a calendar, and describes what it offers. A client is the assistant or the application wanting to use it. The standard defines how the two introduce themselves, how capabilities are described and how requests and results travel between them.

The description is the important part. A server does not merely offer functions; it says what each one is for, what it needs and what it returns, in terms a model can read. That is what allows an assistant to work out which tool suits the request in front of it rather than being told explicitly, and it is why a server can be added without first writing instructions that explain each tool to the model.

Three kinds of thing are typically offered. Tools are actions the assistant can invoke, such as creating a ticket. Resources are material it can read, such as a document or a query result. Prompts are prepared instructions the server suggests for common jobs. Most of what you meet in practice is the first two.

Servers can run locally or remotely. A local one runs on your own machine and reaches things only you can reach, which is why file access and personal note-taking connections tend to work this way. A remote one runs as a service and is shared, which suits company systems. The distinction matters for privacy, because it decides where your data has to travel to be useful.

The standard defines the plumbing and not the permissions. What an assistant is allowed to do with a connected system is decided by the credentials it is given and by whatever the server chooses to expose, exactly as with any other integration. Connecting something read-only is a different proposition from connecting something that can send, delete or pay, and the standard does not make that judgement for you.

Every result comes back into the same fixed budget as the rest of the request. A server returning a large document consumes the space the conversation needs, which is why well-built ones return summaries, extracts or the specific fields asked for rather than everything they hold. A connection that floods the assistant with material can make answers worse rather than better.

Being open is a claim about the specification rather than about any product. Anyone may implement it, in either role, without permission or a licence fee, which is what allows a small tool to be reachable by assistants its makers never contacted. It is not a promise that any particular assistant supports it, nor that a given server is safe to trust with your data.

• Connect an assistant to a folder on your own machine so it can read the documents you point it at, with the connection running locally and nothing uploaded.

  Claude

• Give a coding assistant reach into your issue tracker or your build dashboard through the standard, so it can read a ticket or check a run instead of you pasting either into the conversation.

  Claude Code

• Expose an internal system to assistants through a self-hostable automation platform, where you decide what is offered and what stays hidden.

  n8n

• Reach a company knowledge source from an assistant rather than searching it separately, so the material arrives inside the conversation you were already having.

  Glean

What does MCP stand for?

Model Context Protocol. Protocol because it is an agreed way for two pieces of software to talk; context because what it supplies is the material and capabilities a model needs to be useful about your particular situation rather than in general. The name describes the job accurately, which is unusual.

Do I need to understand MCP to use AI at work?

Not to use assistants. It becomes worth knowing when you want one connected to your own systems, because the question shifts from what a product integrates with to what you can connect yourself. Buyers evaluating tools increasingly ask whether a product supports the standard for that reason.

Is it safe to connect our systems this way?

As safe as the permissions you grant and the server you trust, which is the same answer as for any integration. The standard does not vet what a server does. Start read-only, connect one system at a time, and treat anything able to send, delete or spend as needing the scrutiny you would give any other software.

Does every AI assistant support it?

No. Support is growing across assistants, development environments and platforms, but it is not universal, and an assistant may support acting as a client without offering everything the standard allows. Check the specific product rather than assuming, particularly where an integration is the reason you are buying.

What should I ask a vendor about their support for it?

Which side they implement, since acting as a client is different from offering a server. Then what a connection can actually reach, whether permissions can be limited to read-only, and where a server runs. Those four answers tell you more about a product's usefulness and its risk than the number of integrations it advertises.

How is this different from a plugin?

A plugin is usually built for one product's own extension system and works only there. A connection built to this standard is meant to work with any client supporting it, so the same server can serve several assistants. In practice that is the difference between building once and building per product.

• MCP is an open standard for connecting assistants to outside tools and data, not a model or a product.
• A server exposes capabilities and describes them in terms a model can read; a client is the assistant using them.
• It changes the arithmetic from one connection per pair to one connection per system.
• It defines the plumbing and not the permissions: what a connection may do is still your decision.
• Results come back into the same fixed budget, so well-built servers return extracts rather than everything.

• Claude

  Connects to local and remote servers, so both arrangements are visible in one product.

• Claude Code

  Reaches outside systems through the standard, alongside the files and shell it handles natively.

• n8n

  Self-hostable, so what an internal system exposes is decided by you.