MCP servers explained

If you use an AI assistant on a desktop or in a code editor, you have probably seen the letters MCP: in a settings screen, a plugin directory or a README that says "add this to your config". MCP stands for Model Context Protocol, an open standard introduced by Anthropic in late 2024 and since adopted by many AI applications and developer tools. It defines how an AI app can connect to external tools and data in a consistent way.

The idea is simple and powerful. The security implications are real but manageable. This article covers both.

The problem MCP solves

A language model on its own can only produce text. To be useful as an agent it needs to reach things: your files, a database, a ticket tracker, a browser, a calendar. Before MCP, each AI app built its own integrations, each in its own way. MCP standardises the connection, so a single integration, written once as an MCP server, can be used by any app that speaks the protocol, called an MCP client or host.

A common comparison is a universal port: the app does not need to know the details of each tool, only how to talk MCP.

What an MCP server provides

An MCP server is a program that offers capabilities to the AI app. The protocol describes a few kinds:

• Tools: actions the model can ask to perform, such as "run this query", "create an issue", "read this file" or "open this web page". Each tool has a name, a description and a schema for its inputs.
• Resources: data the app can read and include as context, such as files, records or documents.
• Prompts: reusable templates the server offers for common tasks.

When you connect a server, the app learns which tools exist and shows them to the model. The model can then decide to call a tool; the app passes the request to the server, which does the work and returns the result.

How servers connect

There are two common ways an MCP server runs:

Local servers

The AI app starts the server as a child process on your computer and talks to it over standard input and output. This is the usual setup for tools that work with local files, local databases or your development environment. The server runs with your user account’s permissions, exactly like any other program you start.

Remote servers

The server runs somewhere else and the app connects to it over HTTP. Remote servers are common for hosted services, and they typically use OAuth or tokens so you can authorise the app to act on your account with that service.

In both cases, the server is a separate piece of software with its own author, its own updates and its own reach.

Where the risks are

A local server is code with your permissions

Installing a local MCP server is, in practice, installing a program. Many are distributed through package managers and launched with a single command in a configuration file. If that package is malicious, compromised or simply careless, it can read what you can read and send it where it likes. The fact that it is "just a tool for the AI" does not limit what it can do on your machine.

Tool descriptions are instructions too

The model reads each tool’s description to decide how and when to use it. A server can put misleading or manipulative text in those descriptions, a variant of prompt injection sometimes called tool poisoning. Similarly, data returned by a tool, such as a web page or an issue comment, can contain instructions aimed at the model.

Broad tokens

Remote servers often ask for an access token. A token that can read and write everything in your account is convenient and risky in equal measure.

Combinations

The most interesting failures come from combining servers: one that can read private data, and another that can send data out, such as posting a comment, fetching a URL or writing to a shared location. Each is reasonable alone. Together, if the model is steered by malicious content, they form a path for data to leave.

A checklist for choosing servers

• Prefer official servers published by the service you are connecting to, or well-maintained open-source projects with a visible history.
• Read what it runs. Look at the command in your config. Pin versions rather than always fetching the latest release.
• Scope the token. Read-only where possible; limit to specific projects or repositories.
• Keep approvals on for tools that write, send or delete. Most hosts let you require confirmation per tool call.
• Avoid toxic pairs. Think twice before enabling a private-data server and an outbound-communication server in the same session.
• Remove what you don’t use. Every configured server is attack surface, even if you forgot it was there.
• Don’t expose local HTTP servers on your network unless they require authentication.

Seeing which servers actually run

Configuration files tell you what is supposed to run. It is useful to also see what does run: which MCP server processes are started, by which app, and what they connect to. Because local servers are child processes of the AI app, the process tree shows them clearly.

GreyArm’s sensor records those parent-child relationships and the network connections of each process. An MCP server that starts a shell, touches credential files or begins sending large amounts of data to an AI service raises the same findings as any other agent would, with the server and its parent app identified, so you can decide whether it belongs.

The bottom line

MCP is a good idea: one standard way for AI apps to work with tools, instead of a hundred incompatible ones. Treat each MCP server the way you would treat any program you install, because that is what it is. Pick carefully, scope narrowly, keep approvals for actions that matter, and keep an eye on what actually runs.