Model Context Protocol: Tools, Resources, and Prompts

An MCP tool acts. An MCP resource is read. An MCP prompt shapes what the model is asked. A single connection dialog tends to flatten those three into one.

The specification does not treat them as equals. Its security section says that “Tools represent arbitrary code execution and must be treated with appropriate caution”. That is the 2025-06-18 wording, and revision 2026-07-28 keeps the sentence's substance as a Key Principle under Tool Safety.

The dialog flattens it anyway. Reading a project file and invoking a write-capable operation arrive at the user as the same checkbox. The integration works when a user can see which MCP capability is being requested before a sensitive action goes through. It fails when the shared protocol is mistaken for a shared trust boundary. It is not one.

The read side is not the safe side by default either. CVE-2025-53109 and CVE-2025-53110 were both found in the project's own reference Filesystem server.

Host, client, server, capability: four named parts, and one boundary that does not sit evenly across them. The host is the program the user runs. The client is the connector it opens. The server is the thing on the other end, offering tools, resources and prompts.

Consent sits in exactly one of those four places. “Hosts must obtain explicit user consent before invoking any tool”, says the 2025-06-18 specification. Revision 2026-07-28 states the same principle: consent before invoking any tool, and before exposing user data to servers. Then it concedes the thing a reader of the diagram most needs to know. MCP itself cannot enforce any of this at the protocol level.

So the authorization boundary belongs to the host and the deployment, not to the wire format. Capability and the authorization boundary need separate owners and separate tests. A reader who cannot say which of the four parts grants consent has not yet understood the protocol.

The Model Context Protocol standardizes how an AI application can discover and use server-provided tools, resources, and prompts.

It makes tools easier to plug in. The host still decides what the user is asked to consent to, what the server is allowed to do, how the request is shown, how the server is walled off, and which policy applies.

The version is not a detail that can be rounded off to “current”. The present revision is 2026-07-28, published on 28 July 2026. Its own normative schema says so: LATEST_PROTOCOL_VERSION = "2026-07-28" and JSONRPC_VERSION = "2.0". A host does not have to believe a blog post about which protocol it speaks. It can read the constant.

Negotiation looks more instructive still from the operator's side. One endpoint can carry two revisions at once, and the choice is made per request. Eichenberger and Chang, writing about AgentCore Gateway the day the revision landed, put it plainly: “Clients select a version on every request. Adding 2026-07-28 to a gateway that also advertises 2025-11-25 does not change anything for clients that request the older version.”

A host is therefore not on the newer revision because the server offers it. Production systems should negotiate and test versions rather than assume timeless behavior.

The official MCP reference Filesystem server takes a list of allowed directories. Twice, it read outside them.

CVE-2025-53109 covers symlinks placed inside an allowed directory (CWE-59). CVE-2025-53110 covers a path whose prefix merely collides with an allowed directory (CWE-22). The record for the second states it without hedging: “Versions of Filesystem prior to 0.6.4 or 2025.7.01 could allow access to unintended files in cases where the prefix matches an allowed directory.” Both were published on 2 July 2025 by GitHub as CNA, and both carry a CVSS v4.0 base score of 7.3 (HIGH). GitHub's advisory for the symlink variant, dated 1 July 2025, names the package: @modelcontextprotocol/server-filesystem.

Notice where the failure sits. The user approved a set of directories. The host displayed that approval as one permission covering the whole connection. Nothing distinguished reading a project file from reading a file two directories away that happened to share a prefix. The boundary the user believed they were consenting to lived inside the server's path-validation code, in a package published by the protocol's own project. It was not the boundary being enforced. No part of the protocol was violated while this happened.

Before enabling an MCP connection, review it capability by capability rather than as a single switch. Five steps, and two of them now have citable content rather than advice.

Identify the server — operator, deployment location, transport, and update path. CVE-2025-6514 makes the update path a first-class question rather than hygiene. The distance between mcp-remote 0.1.15 and 0.1.16 is the distance between a client that executes a URL the server chose and one that does not.

Enumerate capabilities — separate reads, prompts, side effects, tasks, and extensions. Record which of them the connection dialog currently merges into one permission.

Map identities — determine whose credentials reach the server and downstream systems. Since revision 2026-07-28 this is normative, not a matter of house style. MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728). MCP clients MUST implement Resource Indicators for OAuth 2.0 (RFC 8707, February 2020) and send the `resource` parameter in both authorization and token requests. Servers MUST validate that access tokens were issued specifically for them as the intended audience. In the specification's own words, “MCP servers MUST NOT accept or transit any other tokens.” RFC 8707 gives the mechanism behind that rule: “When the authorization server is informed of the resource that will process the access token, it can restrict the intended audience of that token to the given resource such that the token cannot be used successfully at other resources.” That is what “isolate credentials” means concretely. An audience-bound token is one that a server cannot replay at another server.

Design consent — show capability-specific purpose, data access, and consequence. Then check the screen against the case above. Would it have told a user that an approved-directory list is enforced by the server's own path check?

Test upgrades — validate protocol version, schema changes, deprecations, and authorization behavior. Clients select a version on every request, so test every revision the endpoint advertises, not only the newest.

Teach MCP as an interoperability layer, not as an agent architecture. The host still needs its own runtime, state, evaluation, and governance.

The specification agrees, and says so against its own interest. It sets out consent and tool-safety principles as Key Principles, then concedes that MCP cannot enforce them at the protocol level. That concession is the whole argument of this lesson in one clause. The duty is written down in the protocol. The enforcement is not. It sits in the host: in the dialog it draws, the token audience it validates, the server version it pins, and the directory list it can actually prove is being honoured.

More than 10,000 MCP servers had been published by the December 2025 handover to the Agentic AI Foundation. Reviewing per server and per capability is therefore a volume problem, not a one-time exercise. Of the 1,899 servers in the study above, 7.2% carried general vulnerabilities. What the team owes its users does not change with the count: a clear view of which capability is being asked for before a sensitive action runs. The team that adopts the protocol owns the consent screen. The people who wrote the protocol do not.