Tools, resources, and prompts

An MCP tool is an operation a server exposes for invocation. A tool has a name and descriptive metadata, and it can describe accepted input. The host may make selected tools available to a model so the model can propose a call, or the host may invoke one through deterministic application logic.

Tools are a natural fit for parameterized work: search for documents, query an approved dataset, calculate a value, or create a draft issue. Some tools are read-only, while others create side effects. The category “tool” does not itself imply safety or permission. A search tool and a delete tool both require deliberate policy, but their approval and recovery requirements should differ.

Descriptions and input schemas help a host understand how to call a tool. They are not proof that arguments are safe. The host should validate model-produced inputs and apply policy before invocation; the server should validate again and enforce its own authorization.

Use a tool when the central idea is perform this named operation with these arguments.

An MCP resource represents content identified by a URI. Resources suit material that can be read or referenced: a document, schema, repository file, configuration description, or another server-defined item. Servers can support listing known resources, templates for parameterized resource identifiers, or direct reads, depending on their capabilities.

Resources make provenance more explicit than copying anonymous text into a prompt. A host can retain the identifier, display where content came from, and decide when to fetch it. The content is still untrusted. A document can contain outdated claims or prompt-injection instructions, so the host must distinguish retrieved data from authoritative application instructions.

A resource is not necessarily public, static, or harmless. Reading a payroll document can be more sensitive than running a public search tool. Authorization should follow the underlying content and user identity.

Use a resource when the central idea is read this addressable piece of context.

An MCP prompt is a server-provided prompt template or reusable interaction pattern that a user can select or that an application can present. It can accept arguments and produce messages or structured prompt content for a workflow.

Prompts are useful when a capability provider knows a good way to frame a recurring task. A documentation server might offer “summarize changes for a role” or “prepare a migration checklist,” while the host controls how that prompt appears and whether it is used.

Do not confuse server-provided prompts with top-priority application instructions. A prompt received from a server is input from that server's trust domain. The host should not allow it to override system policy, silently invoke tools, or bypass consent. The application decides where it sits in the instruction hierarchy.

Use a prompt when the central idea is offer this reusable way to begin or structure an interaction.

The three primitives also suggest different user experiences. Tools are often model-controlled or application-controlled after the host approves their availability. Resources are often application-selected or user-selected as context. Prompts are commonly user-selected templates. These are useful defaults, not universal laws.

The host remains the orchestrator. It can require a user to choose every tool manually. It can fetch a resource automatically under a narrow policy. It can ignore all server prompts. The server advertises possibilities; the host decides how they enter the product.

This distinction prevents a common mistake: assuming that because a server exposed something, the model must receive it. Discovery should feed a policy and presentation layer. It should not directly become unrestricted model authority.

Return to the documentation example:

• search_docs(query, product, version) is a tool because it performs parameterized retrieval.
• docs://handbook/security/access-control is a resource because it names readable content.
• prepare_release_review(audience, version) is a prompt because it offers a reusable interaction structure.

There can be overlap. A server might expose read_page(uri) as a tool even though direct resource reads are also available. The better design depends on client support, auditing needs, access checks, and whether the operation has domain logic beyond reading.

Prefer semantics that communicate the capability honestly. Do not disguise a write as a resource read or label a high-impact action as a harmless prompt. Clear primitives improve interfaces and policy decisions.

Avoid making one giant tool such as do_anything(action, payload). It weakens descriptions, schemas, permissions, logging, and user confirmation. Narrow operations let the host distinguish search_docs from publish_doc and assign different controls.

Avoid returning huge resources “just in case.” Fetch the minimum relevant context, preserve source identifiers, and respect data boundaries. More context can increase cost, expose sensitive data, and make injection attacks harder to contain.

Avoid treating prompt libraries as trusted policy. A prompt can improve task quality, but deterministic authorization must live in code and service controls. “The prompt says not to delete production” is not a permission boundary.

Finally, avoid assuming every compatible host renders each primitive identically. Design descriptions and behavior to remain understandable without depending on one application's interface.