Your AI assistant suddenly reads your calendar, queries a database and files tickets. Behind that there is usually no magic, just a small protocol with a long reach – and every server you connect gets a seat at the table.
The short answer
The Model Context Protocol (MCP) is an open protocol that connects LLM applications to external data sources and tools in a standardized way [1]. What does that mean in practice? An application, the host, talks through built-in clients to MCP servers; the messages are JSON-RPC 2.0, and servers offer tools, resources and prompts [1][2]. The current protocol revision is 2026-07-28 (as of 25 Oct 2026) [3]. Our assessment: MCP makes integrations easy, which is exactly why you should treat every server like software you install, not like a harmless plug-in.
How it works
- Three roles. Hosts are LLM applications that start connections, clients are connectors inside the host, and servers provide context and capabilities [1]. MCP takes inspiration from the Language Server Protocol, which standardized how development tools support programming languages [1].
- What a server offers. Resources are context and data for the user or the model, prompts are templated messages and workflows, and tools are functions the model can execute [1]. In the other direction, a client can offer elicitation: the server asks the user for missing information [1].
- Stateless since 2026-07-28. All messages follow JSON-RPC 2.0 [2]. The current revision removed the old initialization handshake, so every request now carries its protocol version and client capabilities itself [2][4]. It also deprecated the Roots, Sampling and Logging features [4].
- Local or remote. Most local servers use the stdio transport: the host starts the server as a child process and talks to it over standard input and output. A remote server over Streamable HTTP runs no code on your machine and uses the protocol's authorization flow [5]. For HTTP-based transports the specification defines an authorization framework, while stdio servers take their credentials from the environment [2].
- Who maintains it. On 9 Dec 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation; the maintainers keep deciding the technical direction [6].
- The risk. The specification says tools represent arbitrary code execution and that tool descriptions should be considered untrusted unless they come from a trusted server; hosts must obtain explicit user consent before invoking any tool [1]. A local server is an ordinary process with your account's rights: it can read your files, environment variables and SSH keys and connect anywhere [5]. Tool names and descriptions are instructions the model reads, so a malicious server can even steer how the agent uses the tools of other servers [5].
A practical example
Automation tools speak MCP in both directions. In n8n, the MCP Server Trigger node turns n8n into an MCP server that makes selected tools and workflows available to MCP clients, over Server-Sent Events or streamable HTTP, with optional Bearer or header authentication [7]. The MCP Client node does the opposite and runs the tools of an external MCP server as steps in a workflow [8]. Before you connect an assistant to such an endpoint, switch on authentication, read every tool description and give the workflow only the accounts it needs. This is a generic walk-through, not a report from our own setup.
Checklist
- Check who publishes a server and pin its version before you install it [5].
- Read the tool descriptions and remove any server whose descriptions contain instructions unrelated to its job [5].
- Run third-party local servers in a container or VM that only sees the directory they need [5].
- Give each server its own narrowly scoped token instead of a global one from your shell profile [5].
- Require authentication on every MCP endpoint you expose, for example in n8n [7].
- Approve tool calls yourself instead of letting the host run them unattended [1].