What is MCP (Model Context Protocol)?
MCP is an open protocol that lets an AI application call tools and read data from any server that speaks it. What a server exposes, how the transports work, who supports it, and what to watch.
The Model Context Protocol is an open standard for connecting an AI application to the outside world. It was published by Anthropic in November 2024 and has since been adopted well beyond Anthropic's own products. Before it, every assistant needed its own integration with every tool: a Slack plugin for one product, a different Slack plugin for the next, and nothing in between. MCP replaces that with one contract. A tool is written once as an MCP server; any application that contains an MCP client can use it.
Clients, servers and hosts
The protocol has three parts, and the names are easy to muddle.
- A host is the application a person is using: a desktop assistant, a coding agent in the terminal, an editor. The host decides which servers are connected and which model answers.
- The host contains one or more clients, each holding a connection to one server. The client speaks the protocol on the host's behalf and hands the model whatever the server offers.
- A server is the thing being connected to. It can be a small local process that reads files, or a remote service in front of a database, a CRM or an entire company's systems.
The model never talks to a server directly. It sees a list of what the server offers, asks the host to use one of those things, and the host relays the call and the result.
What a server offers
A server advertises three kinds of capability.
Tools are functions the model may call: each has a name, a description the model reads to decide when it is relevant, and an input schema in JSON Schema. A tool might search tickets, read an invoice, or post a message. Tools are what nearly every server is used for, and the description is the most important line in it: a vague description makes a tool invisible to the model, a misleading one makes it misused.
Resources are things the model can read without calling anything: a file, a record, a page of documentation, addressed by a URI.
Prompts are reusable templates a host can offer the user, with arguments filled in.
A server can also ask the host for things in the other direction, such as asking the model to complete a piece of text, but that is rare in practice.
Transports
A client and server exchange JSON-RPC messages over one of two transports.
stdio runs the server as a local child process and talks to it over its standard input and output. It is the simplest arrangement and the right one for a tool that only makes sense on your own machine.
Streamable HTTP is the transport for remote servers: the client sends requests to one URL, the server answers directly or streams events back on the same connection. It replaced an earlier server-sent-events transport, which some clients still accept. A remote server authenticates the caller the way any web API does, typically with a bearer token in a header or an OAuth flow, and it can serve many people at once, each seeing only what they are allowed to.
Who supports it
Most coding agents and desktop assistants now contain an MCP client: Claude Desktop and Claude Code, Cursor, Windsurf, Zed, OpenCode, Cline, Goose and the agent mode of Visual Studio Code among them, and the major agent SDKs can connect to a server from your own code. The servers side is wider still, from single-purpose local tools to hosted services, which is why "is there an MCP server for X" is now a routine question.
What to watch
Permissions. A tool that writes is a different thing from a tool that reads. Good servers mark the difference and good hosts ask before acting; a server that exposes "send email" with the same ease as "search email" is one bad prompt away from an incident.
Tool results are untrusted text. Whatever a tool returns is read by the model as if it were part of the conversation, so content from the outside world, a web page, an email, a ticket, can carry instructions the model may follow. The protocol does not solve this; the host and server have to.
Too many tools. A model given a hundred tools chooses among them worse than one given ten. Servers that curate what they expose, and hosts that let people switch sets on and off, work better than the kitchen sink.
Who is calling. A remote server used by a team has to know which person is behind each request, both to apply their permissions and to attribute what was done.
Where Memtro fits
Memtro is an MCP server over Streamable HTTP: one URL, a bearer key, and in return the memory tools and every connector tool the key's owner has been granted, with the same permissions and grants that apply in the dashboard. That makes it a single server standing in for 144 systems rather than a server per system. The MCP pages list what each connector exposes, and the documentation has the setup for each client.