An agent can only do what its tools let it do. The Model Context Protocol, MCP, is an open standard for adding tools without the agent having to know anything about them in advance.
The problem it solves
Before MCP, every combination was bespoke. Wanting your agent to read your issue tracker meant somebody writing an integration between that specific agent and that specific tracker. N agents times M tools is N times M integrations, and almost none of them get written.
MCP makes it N plus M. A tool provider writes one server. Any agent that speaks MCP is a client and can use it.
How it works
A server exposes some combination of:
- Tools, things the agent can call, with typed arguments. "Create an issue." "Run this query."
- Resources, things the agent can read. A document, a schema, a file.
- Prompts, pre-written prompt templates the user can invoke.
The client connects, asks what the server offers, and adds those tools to the ones it already gives the model. From the model's point of view there is no difference between a built-in tool and one that arrived over MCP.
Transports are stdio, where the client launches the server as a subprocess and talks over standard input and output, and HTTP, for a server running somewhere else.
What it is not
- Not a model API. It sits between a client and a tool, not between a client and a model.
- Not an agent framework. It does not run a loop or decide anything.
- Not a sandbox. This is the important one.
The security question
An MCP server is a program that runs on your machine, or an endpoint you send your data to.
A stdio server is a command your agent's client will execute, usually with your full user privileges, usually at startup, and often written by someone you have never met. Adding one to your config is the same class of decision as adding a line to your shell profile.
Three things worth asking every time:
- Where did this definition come from? One you wrote is one you chose. One that arrived inside a repository you cloned is untrusted content, exactly like any other file in that repository. It should not run because a file said so.
- What can it reach? A server with a database credential can read the database. A server that fetches URLs can be pointed at your internal network.
- What can it feed back into the conversation? Anything an MCP server returns becomes context the model acts on. A tool that reads issue comments is a tool that will read whatever an attacker wrote in an issue comment. Prompt injection through a legitimate tool is the realistic attack here, not a malicious server.
A reasonable policy
- Servers you configured yourself: trust them the way you trust your shell profile, which is to say a lot, having chosen them.
- Servers a repository declares: off by default, on only after you have read the definition.
- Approve the definition, not the name. If approval is remembered as "the user allowed
linear", then editing that entry's command later inherits the approval silently. The command, the arguments and the environment are the thing being trusted.
Where Fleet fits
Fleet is an MCP client. It runs its own in-process server, which is where an orchestrator's tools come from, and it will run yours over stdio, HTTP or SSE.
It applies exactly the policy above: your servers are enabled, a repository's arrive disabled, the repository file's own enabled flag is ignored because it is not the party being trusted, and approval is keyed to a fingerprint of the definition rather than to an identifier. See MCP servers.