Knowledge · New threats: agents, MCP, prompt injection · 8 minutes

What is an MCP server, how does it work and is it safe?

An MCP server gives an AI assistant tools and data. How it works, local vs remote, tool poisoning and rug pulls, and how to check a server before connecting.

Last updated: October 5, 2026

What is an MCP server?

MCP (Model Context Protocol) is an open protocol that standardizes how AI applications connect to external tools and data. An MCP server is the program on the other end of that connection: it exposes tools the model can call, such as "search the CRM", "create a ticket" or "read a file".

Anthropic published the protocol at the end of 2024. On 9 December 2025 it donated it to the Agentic AI Foundation under the Linux Foundation. According to that announcement there were more than 10,000 active public MCP servers at the time, and the protocol was supported by ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code, among others.

In practice an MCP server is a plug-in for an assistant. The difference from a regular integration is that the model decides which tool to call and with which parameters, based on the text it has just read. If the model reads an instruction in an email or on a web page, it can carry it out with an MCP tool, not just write about it.

How does an MCP server work?

The MCP specification, version 2026-07-28, defines three roles. The host is the application with the model (for example Claude or a code editor). The client is the connector inside the host. The server offers three kinds of things: tools (functions the model can call), resources (data and context) and prompt templates.

Messages use JSON-RPC. The specification defines two standard transports: stdio, where the client launches the server as a process on your computer, and Streamable HTTP, where the server runs remotely at a web address.

When you connect a server, the host fetches its list of tools along with their descriptions. Those descriptions go into the model's context. This detail matters for security: the model reads them like any other text.

Local vs remote MCP server: the difference in risk

A local (stdio) server is code downloaded and executed on your computer. The Security Best Practices document that accompanies the specification states that such a server runs with the client's privileges and may reach your files, SSH keys and network. The startup command in a configuration can contain anything, including fetching and sending out your files. The document requires clients offering one-click setup to show the full command and ask for consent, and recommends running such servers in a sandbox.

A remote (HTTP) server does not execute code on your machine, but it gets access to your accounts, usually through OAuth. Here the risk is tokens and scope. The authorization specification forbids forwarding tokens that were not issued to that server (token passthrough) and recommends a minimal initial scope, adding more only when actually needed.

Neither option is safer by definition. Local requires trust in the code, remote requires trust in the operator and in how it handles your tokens. For both, record who in the company approved the connection and when.

Tool poisoning and rug pulls

Tool poisoning means hidden instructions for the model placed in a tool description that the user usually does not see in full. Invariant Labs described the attack on 1 April 2025: an innocent-looking tool for adding numbers carried a description telling the model to read configuration files and keys and smuggle them out in parameters.

A rug pull is a change to a tool's description or behavior after you approved it. Yesterday the server was fine, today after an update it does something else, and you are not asked to approve it again. The same report also describes shadowing: one server's tool description changes how the model uses the tools of another, trusted server.

The MCP specification's security principles say descriptions of tool behavior should be considered untrusted unless they come from a trusted server. It is the same class of problem as prompt injection, except the input is the server itself.

Excessive permissions and tokens

The most common problem is not exotic: a server asks for more than it needs. A calendar-reading tool with permission to send email. A reporting server with full database access. The same best practices document lists broad catch-all scopes and bundling unrelated permissions in advance as common mistakes.

The OWASP MCP Security Cheat Sheet recommends narrow OAuth scopes, short-lived credentials kept in the operating system's secure storage and never in a plaintext config file, and treating each server as a separate, untrusted security domain.

Also check whether connecting a server completes the lethal trifecta: access to private data, exposure to untrusted content and the ability to send something out. One server that reads email plus another with open network access already makes the full set.

How to check an MCP server before connecting it

A checklist based on the MCP specification and the OWASP GenAI guide of 4 November 2025:

1. Who published it? An official server from the service provider is a different situation from an anonymous repository. 2. Read the full tool descriptions, not the summary in the interface. Look for instructions addressed to the model. 3. Compare the permissions requested with those your task needs. 4. For a local server, read the startup command and run it in a sandbox or container. 5. Pin the version and checksum so an update cannot change the tools without you knowing. 6. Turn on human approval for tools that send, pay or delete. 7. Record the server in a company inventory so it does not become shadow AI.

If the server fronts a service with a public website, your agent can check that site first through the arLET'S MCP server: a passive check of the public surface (who the site shares data with, who is behind it), not a code audit of the server. If you need a review of permissions, dependencies and resistance to content injection, the scope is described on the agents and MCP servers page.

You have already connected MCP servers. Now what?

List every server configured in every tool: in the Claude app, in your code editor, in ChatGPT settings. For each one, record who published it, which version it runs and what it can access.

Remove the ones nobody uses. For the rest, swap tokens for narrower ones and check that keys are not sitting in plaintext config files. For remote servers, also revoke access on the service side, in its connected apps settings, because removing a server from your config does not necessarily invalidate the token it was issued.

Permissions, approvals and logs for agents are covered in more depth in AI agent security.

In short

An MCP server is a plug-in for an AI assistant. Safety depends on the specific server, not the protocol.
A local server runs code with your privileges. A remote one gets your tokens.
The model reads tool descriptions, so they can carry hidden instructions. The specification says to treat them as untrusted.
Pin the version so an update cannot change the tools without your approval.
Compare requested permissions with needed ones and require approval for sending, payments and deletion.

Have a website, app or email address that looks suspicious?

Check it for free Request an assessment

Frequently asked questions

What is an MCP server in simple terms?

It is a program that gives an AI assistant access to a specific tool or data source, such as a calendar, a database or a code repository. The assistant decides on its own when to use it.

Are MCP servers safe?

It depends on the server. The protocol does not guarantee safety: a local server runs code on your computer and tool descriptions can contain hidden instructions. Check the publisher, permissions and version before connecting.

What is the difference between an MCP server and an API?

An API is called by a program someone wrote. An MCP server exposes tools that a language model calls based on the conversation, often wrapping an existing API.

What is a rug pull in MCP?

It is a change to a tool's description or behavior after it was approved. Pinning the version and checksum, and re-approving after every change, protects against it.

Local or remote MCP server: which should I choose?

Local requires trust in the code and ideally a sandbox. Remote requires trust in the operator and narrow tokens. Choose based on who and what is easier to trust in your situation.

Sources

Accurate as of the article's last update. Laws and vendor terms change, so check the source before you decide.