MCP tools, resources and prompts explained

MCP tools, resources and prompts are three ways a server provides capabilities to an AI host. Tools expose operations with structured inputs, resources expose addressable content, and prompts expose reusable message templates. The distinction describes the interaction model; it does not automatically classify an operation as safe, read-only or supported identically by every client.

Official documentation was checked on October 14, 2026. This article uses the current 2026-07-28 terminology while keeping conceptual examples separate from complete wire messages. A deployed client or server may implement an earlier revision.

MCP tools

A tool is a named operation that a host can invoke with arguments. The server supplies a description and an input schema so the host can represent the operation to the model. The model may propose a call, but the executor still decides whether to run it.

Clients discover operations through tools/list and invoke them through tools/call. The official tools chapter defines those requests. A complete request envelope also depends on the revision, so a partial JSON example should not be mistaken for a ready-to-send protocol message.

For example, an issue lookup might accept an identifier. The following is an illustrative input-schema fragment, not a complete tool definition or wire request:

{
  "type": "object",
  "properties": {
    "issue_id": {
      "type": "string",
      "description": "Identifier in the authorized project"
    }
  },
  "required": ["issue_id"],
  "additionalProperties": false
}

The schema constrains argument shape. The handler still needs to ensure that the issue belongs to a project the caller can access. A syntactically valid identifier does not establish authorization, and an authenticated account may still lack permission for that object.

Tools can read. A search operation or a calculation may leave external state unchanged. Other tools can create, update, send or delete. Classify behavior per operation rather than treating the whole primitive as a write category. Even read-only calls can disclose confidential content to the host or model provider.

Good descriptions state what the operation does, which inputs select the object and what the result means. They should not insert broad behavioral instructions such as asking the assistant to ignore user restrictions or pass unrelated data. Tool metadata is part of the untrusted external surface unless you have established the server’s trustworthiness.

MCP resources

A resource gives the host content through an addressable URI. It can represent a document, a configuration snapshot or another data object. The host chooses whether and how to bring that content into the model’s context, rather than presenting every retrieval as a model-selected action.

The resource family includes listing, templates and reading. The official resources chapter defines that interface. A template can expose a pattern such as a URI containing a parameter, while a concrete resource has an actual address.

A resource URI is an identifier in the server’s interface. It should not be treated as proof that the host can fetch the object directly through ordinary HTTP. The server may resolve it against a database, local file or upstream API while applying its own access checks.

The useful design question is whether the host should treat the content as an addressable context object. A project policy document might fit that model. A search with several user-chosen filters might be clearer as a tool. Both can read the same underlying system, and neither removes the need to enforce data access.

Resource content can contain malicious or irrelevant instructions. Loading it into context does not promote it to user authority. Keep the user’s task separate from external document text and restrict subsequent operations independently of whatever the resource says.

MCP prompts

A prompt is a named reusable message template. It can take arguments and return messages that a host presents or uses in its own flow. A review template might ask for a change summary and an associated issue, while a summary template might accept text to condense.

The protocol separates listing and retrieving prompts from invoking tools. The official architecture overview describes prompts as user-oriented reusable interactions. Hosts can expose them through different interfaces; a menu, slash command or another UI is an implementation choice.

A template is not a workflow execution guarantee. It can suggest a procedure, but the host and model still determine what happens next. If the procedure must perform deterministic steps with retries or scheduled execution, a workflow engine or application handler may be the right place for that logic.

Arguments also need care. A template receiving text from an external source should preserve that source’s status as content rather than silently treating it as authoritative instructions. Reusability does not make the template or supplied text trustworthy.

When publishing a template, explain its intended use and limits. A reader should understand whether it produces a draft, requests a review or asks the agent to use other capabilities. Avoid claiming that obtaining the prompt automatically authorizes any tool it mentions.

MCP resources vs tools: comparison table

Decision	Tools	Resources	Prompts
Main purpose	Execute a named operation	Retrieve addressable content	Retrieve reusable messages
Input shape	Structured operation arguments	URI or resource-template parameters	Template arguments
Typical selection	Model proposal through the host	Host context selection	User-oriented selection through host UI
Can involve a read?	Yes, such as search	Content retrieval is the central use	Template can include supplied content
Can change external state?	Depends on the operation	Do not infer tool-like writes from a URI	Retrieval itself is not a business workflow
Required review	Caller, account, object and side effects	Data access and content trust	Template source and later execution
Client presentation	Often shown as available operations	Context or attachment behavior varies	Menu/command behavior varies

These “controlled by” descriptions summarize intended interaction patterns. They are not security boundaries that every implementation enforces identically. A host can choose another UI, and a server’s capabilities do not establish how that UI behaves.

A practical choice is to start from the user’s interaction. If the assistant must choose an operation with arguments, use a tool. If the host needs a stable context object, use a resource. If the user needs a repeatable instruction template, use a prompt. Then validate whether the chosen client actually exposes that primitive usefully.

How Claude, Cursor and Codex use them in practice

The host bridges the server’s capabilities to the user and model. Tool definitions may be presented to the model, while resources and prompts can need separate UI support. Do not assume all named hosts render the three primitives identically simply because they advertise protocol support.

Use the current setup guidance for Claude, Cursor and Codex. Check transport, authorization and the specific capability you intend to use. A working tool call does not prove that the same host exposes a prompt picker or resource browser.

For a server trial, verify one example in each required family. List tools and call a harmless operation. Read one authorized resource if the workflow depends on resources. Retrieve one prompt with representative arguments if templates are required. Observe what the host actually makes available, not just what the server declares.

If a capability is unavailable, decide whether a different host or a different interface is appropriate. Wrapping every resource as a tool can work in some applications, but it changes the interaction and may increase repeated retrieval. Keep the workaround explicit rather than describing the primitives as interchangeable.

The client guide and architecture article provide the surrounding roles. The specification guide helps identify when an older example uses a different lifecycle or optional feature.

Tool permissions in practice

Authorize the actual operation against the actual account and caller. A read tool on a work account can have a different policy from the same operation on a personal account. A write also needs a clear destination and result, so review is about the proposed change rather than a generic service label.

AIPx’s permissions attach to tool × account × agent. Allow and Confirm are execution hints. Confirm advertises review intent through tool metadata, and whether the call is reviewed depends on the client. Hide is enforced server-side and removes the tool from the agent surface.

This policy model is about tools. It should not be described as a verified product permission system for every resource or prompt. Upstream scopes remain another constraint, and an allowed read can still return sensitive content. See MCP security before assuming approval labels solve prompt injection or disclosure.

Start narrowly. Hide operations the task does not require, choose low-risk accounts for a trial and test the actual host’s review behavior for a write. Inspect the audit record for the account, tool and outcome. If you only need one trustworthy official operation, direct server access may be simpler than adding a gateway.

For implementation, the Python server tutorial shows a small tested tool. Add resources or prompts only when they serve a real interaction, and keep every primitive’s data and execution boundary visible in the design.

Further reading

claude code MCP setup; mcp servers; what is an MCP server; what is mcp.