MCP: capabilities, resources vs tools, and trust

Capability discoveryCopy Anchor Link

When a client connects, it asks the server what it supports. The server replies with its tools, resources and prompts, each with a description and schema. The host shows these to the model. This is why a server's descriptions are effectively prompts: whatever they say, the model reads.

Resources versus toolsCopy Anchor Link

A resource is data the application or user attaches, such as a file or a record, identified by a URI. It is read-only context. A tool is an action the model chooses to run, with arguments, which can change things. Prefer resources for reading and tools for doing.

Trust boundariesCopy Anchor Link

You trust a server to behave as described. A malicious or compromised server can return instructions in tool results, change a tool description after you approved it, or ask for more access than it needs. Mitigate: install servers you can inspect, pin versions, scope credentials to the minimum, require approval for tools that write or send, and avoid combining a server that reads untrusted content with one that can send data out.

Local versus remoteCopy Anchor Link

A local stdio server runs on your machine with your user's permissions. A remote server runs elsewhere, needs authentication (OAuth) and sees only what you send. Local is simpler, remote is easier to share and update.

A worked example: a safer setupCopy Anchor Link

Server A reads private notes (sensitive). Server B browses the web (untrusted). Together they form a risk: a page B reads could instruct the model to send A's notes somewhere. Safer: run them in separate sessions, or add approval before any message leaves the machine.

A review checklistCopy Anchor Link

Who wrote it, and can you read the code? Is the version pinned? What credentials does it hold and are they the minimum? Does it write or only read? What happens if its tool descriptions change? If you cannot answer, do not connect it to anything sensitive.

How a description attack worksCopy Anchor Link

A tool description is text that goes into the model's context, so the model treats it somewhat like an instruction. A "rug pull" uses this in four steps.

1. You review a server and approve its clean descriptions.
2. The author later publishes an update that changes one description.
3. Your client loads the new text the next time it connects.
4. The model now sees an instruction you never reviewed.

Defenses: pin the version, compare descriptions after any update and re-approve. Whether a given client warns you about changes varies, so check yours.

A second example: a low-risk setupCopy Anchor Link

A read-only local server pointed at one folder of public documents, with no web access and no way to send anything out, needs little ceremony. Risk rises with three conditions: the agent can see private data, it reads content strangers wrote, and it can send data outside. All three together is the dangerous mix. Remove any one and the worst case shrinks a lot.

Trade-offs of approvalsCopy Anchor Link

Asking before every action feels safe but trains people to click yes without reading. Fewer, narrower tools mean fewer prompts, so each prompt means more. Require approval for writes and sends. Let read-only calls on a scoped folder run freely.

What goes wrongCopy Anchor Link

Credentials are broader than needed. A token with full account access turns a small bug into a big incident. Check the token's scopes in the provider's dashboard.

Two servers expose the same tool name, and the model calls the wrong one. Rename or disable one.

You cannot remember what you approved. Keep a list.

Try it yourselfCopy Anchor Link

List every server you have connected. For each, write who made it, the version, the credentials it holds, whether it writes, and what it can reach. Expect at least one row you cannot fill in. Disconnect that server until you can.

Common mistakeCopy Anchor Link

Approving everything the first time and never looking again.