Skip to content
ENFRDescribe your project

MCP servers: connecting an agent to your tools without opening every door

An MCP server gives an AI agent access to a tool: email, tickets, code, a database. What it really gives the agent, the attacks already documented, and the rules to set before connecting it.

By Published on 3 October 2026

An MCP server is a program that gives an AI agent access to a tool: your email, your tickets, a code repository, a database. MCP (Model Context Protocol) is the open standard that sets how AI applications and these servers talk to each other; it is often compared to a USB-C port for AI. Connecting a server is easy, which is exactly why you have to decide beforehand what the agent will be able to do.

Where MCP comes from and who maintains it

Anthropic open-sourced MCP on 25 November 2024. On 9 December 2025, it handed it over to the Agentic AI Foundation, a foundation under the Linux Foundation co-founded with Block and OpenAI. Anthropic then counted more than 10,000 active public MCP servers. An official registry of servers has been open in preview since September 2025, and the current version of the specification dates from 28 July 2026.

What an MCP server really gives the agent

A server exposes three kinds of items: tools, meaning actions the agent can trigger (send a message, create a ticket, change a file); resources, data it can read; and prompt templates. Tools carry the risk: each one is a real action, carried out with the rights of the token the server holds.

A local server runs on the user’s workstation, with their rights and often their credentials. A remote server is shared and called over the web; the specification then recommends OAuth for authentication.

The risks already documented

  • Instructions hidden in tools. In April 2025, Invariant Labs described “tool poisoning”: malicious instructions slipped into a tool’s description, invisible to the user but read by the model.
  • Booby-trapped content. In May 2025, the same team showed that a malicious issue in a public repository could lead an agent connected through MCP to leak data from private repositories: an indirect prompt injection.
  • Fake servers. In September 2025, an npm package posing as the MCP server of the email service Postmark secretly copied messages to an outside address. Postmark confirmed it had never been involved.
  • Flaws in the servers themselves. In 2025, critical vulnerabilities were published for widely used components, including the mcp-remote tool and the official filesystem server.
  • Access that is too broad. A study by Astrix Security (October 2025) of more than 5,200 open-source servers found that 53% rely on static API keys or personal tokens, and only 8.5% on OAuth.

OWASP has classified these risks: its December 2025 list for agentic applications includes tool misuse and supply chain vulnerabilities, and a draft list dedicated to MCP, still in beta, names servers installed without approval (“shadow MCP”).

The rules to set

  • An allowlist of servers: installed from the vendor’s official source, at a pinned version, like any software dependency; everything else is blocked.
  • Least-privilege rights: a token per server, limited to what it has to do, never an administrator’s personal token. The specification indeed forbids a server from accepting a token that was not issued for it.
  • A person in the loop: the specification asks that the user can always refuse a tool call. Reading can stay automatic; sending, changing or deleting waits for approval.
  • Tool descriptions treated as untrusted: that is what the specification asks for any server that is not trusted. Review them when a server is added and at every update.
  • A log of every call: which agent, which tool, which parameters, which result.
  • Isolation for local servers: in a container or a sandbox, with no access to the rest of the workstation.

Local or remote server: what changes

A local server is easier to try out, but it inherits the workstation’s rights and secrets: a flaw or a fake server compromises the machine. A remote server takes more setting up, but is easier to govern: central authentication, rights managed in one place, one log. For a team, prefer remote servers, published in an approved internal catalogue.

Building your own MCP servers

For your internal tools, an in-house server exposes exactly what the agent must be able to do, and nothing else:

  • read tools first, write actions later;
  • separate tools for reading and acting, with distinct rights;
  • parameters checked by the server, never by the model alone;
  • OAuth authentication, logs, and tests with booby-trapped content.

This is what we set up in an agentic platform, with the guardrails of our offer AI agents under control. See also our articles on securing AI agents and on rolling out coding agents, and the page Agentic AI under your control.

Frequently asked questions

What is MCP?

An open standard for connecting an AI application, such as an agent, to outside systems (tools, data, services) in a way shared by all vendors.

Is an MCP server safe?

No more and no less than its code, its origin and the rights it is given. An official server, at a pinned version, with a limited token and human approval of sensitive actions, carries a controlled risk; a package found at random with an administrator token does not.

Who maintains the protocol today?

Since December 2025, the Agentic AI Foundation, under the Linux Foundation, with the same governance rules as before the transfer.

Do you need one MCP server per tool?

Usually, one server per connected service. Fewer servers mean a smaller attack surface: add a server only for a specific use.

Sources

Facts and figures checked on 3 October 2026.