MCP server

How it works

An MCP server sits at the far end of a Model Context Protocol connection. The host application, such as a chat app or code editor, creates one client for each server it uses. A server can offer three things:

• Tools: functions the language model decides to call, such as “send an email”.
• Resources: data the application attaches, such as a file or git history.
• Prompts: templates the user picks, such as a slash command.

A server runs in one of two ways. A local server is a subprocess the client launches and talks to over standard input and output. A remote server is a service the client reaches with HTTP requests.

The host keeps the conversation. A server sees only what the host sends it, and cannot see into other servers.

Why it matters

An MCP server can hurt the application that trusts it in two ways.

Through its text. Tools are model-controlled: the model reads each tool’s description to decide when to call it, then reads the result. An instruction hidden in either can be obeyed. That is MCP tool poisoning, a form of indirect prompt injection. A tool’s annotations, the hints that say whether it only reads or can destroy data, are separate from its description; the specification tells clients to treat them as untrusted unless the server is trusted.

Through its code. A local server is a program on the user’s machine. The MCP security best practices warn that it runs with the same privileges as the client that started it, and list arbitrary code execution and data loss among the risks.

Much of the defence sits with the host. The specification’s tools section says the application should show which tools the model can use and keep a human able to refuse a call. The MCP security best practices add: sandbox local servers.

In practice

In September 2025 Postmark, an email delivery company, warned about an npm package called postmark-mcp that impersonated it. Postmark says the actor “built trust over 15 versions”, then added a backdoor in version 1.0.16 that secretly blind-copied emails to an external server. Postmark had not published its own MCP server on npm. The pattern is an AI supply chain rug pull.

Guidance for installing and exposing servers comes from two documents. The MCP security best practices cover local servers:

• Local installs. A client offering one-click setup must show the exact command, without truncation, and get the user’s approval. It should run the server sandboxed with minimal privileges.
• Local exposure. A server meant to run locally should use stdio, or require a token if it listens over HTTP, so other processes on the machine cannot reach it.

The authorization specification covers remote servers:

• Remote servers. Authorization is optional in MCP. When an HTTP server uses it, the server acts as an OAuth 2.1 resource server and must reject tokens issued for anything else. Forwarding such a token to another service is forbidden. The best practices explain why: the downstream service may trust the token as if it came from the MCP server, the confused deputy problem.

Questions and answers

What is the difference between MCP and an MCP server?

MCP, the Model Context Protocol, is the agreed message format. An MCP server is one program that speaks it and offers tools, resources or prompts to AI applications such as chat apps and code editors.

Is a local MCP server safe to install?

Only as safe as the code and the command that start it. The MCP security best practices warn that a local server runs with the same privileges as the application that launched it, and recommend showing the exact command, asking for approval and sandboxing the server.

Does an MCP server need authentication?

Not always. Authorization is optional in MCP. A remote server reached over HTTP should use the specification's OAuth 2.1 flow; a local server started over stdio gets its credentials from its environment instead.