MCP Resources vs Tools vs Prompts: Choose the Right Primitive

Use an MCP resource to expose addressable context, a tool to expose an operation with inputs, and a prompt to offer a reusable interaction template. The choice is about how a capability should be discovered and used, not whether its implementation touches a database. A read-only search can be a tool; a resource can represent dynamically generated content.

The server-feature overview for MCP 2026-07-28 describes resources as application-controlled, tools as model-controlled, and prompts as user-controlled. Those are interaction models, not permission grants. The host and server still need to enforce access and decide how content enters the conversation.

This guide follows one fictional support workflow through the three primitives. The examples describe interface design, not a deployed MCP Beast connector or complete wire messages.

Compare the job each primitive does

Start with the intended user experience. If a person should deliberately choose a standard review template, a prompt is a natural fit. If an agent needs to search by a query it constructs, a tool can expose that operation. If the host needs a stable reference to a particular document, a resource provides that identity.

An implementation can use the same backend for all three. Avoid inventing separate copies of the business logic merely because the interfaces differ. Keep authorization and data validation close to the underlying operation so a second interface does not become a bypass.

Step 1: expose a troubleshooting article as a resource

Imagine an approved support article identified by support://articles/reset-device. A host can select that resource as context for a case. The resources specification identifies resources by URI, supports text or binary content, and defines listing and reading operations. Resource templates provide parameterized addresses when a server needs to expose a family of related items.

A resource URI is an identifier, not an instruction to read an arbitrary local file or fetch any network address. Define which identifiers the server accepts and how they map to authorized content. In this fictional service, the support scheme is an application design choice; it is not a standard MCP scheme or a link readers can open.

For the support article, decide whether the address refers to the current approved revision or an immutable revision. Both can be useful, but they answer different questions. A current address helps the host obtain the latest guidance. A revision-specific address helps an operator explain which instructions were available when an earlier response was prepared.

Test a permitted resource, an unknown identifier, and a resource outside the caller's access. Check that the host presents a useful result without silently turning a denied read into an empty document. These are proposed acceptance cases; the exact error handling should follow the protocol revision and implementation you use.

Step 2: expose case search as a tool

The assistant may need to find similar cases rather than read a document whose identifier is already known. A fictional search_cases tool could accept a query and a bounded result limit. It is still a tool even though its intended behavior is read-only.

The tools specification defines discovery and invocation with named tools and input schemas. Tool metadata helps the host and model understand an operation. It does not replace validation of arguments or downstream permissions.

For this search interface, describe what collection is searched, which fields are returned, and what a missing match means. Avoid a broad operation that accepts arbitrary database text when a constrained case-search operation solves the task. If results contain confidential notes, enforce access before assembling the response; a natural-language description saying “public cases only” is not that enforcement.

A separate submit_reply operation has a different effect and should be reviewed separately. It needs an unambiguous destination, a response revision, and the required approval boundary. Do not combine search and send into one vaguely named tool merely to reduce the visible tool count. A compact catalog is useful only if the remaining operations remain understandable.

Step 3: offer a case-summary prompt

A support specialist may want a consistent starting point: summarize the issue, list supporting evidence, and identify unanswered questions. A prompt can provide that template with arguments such as a case identifier and intended audience.

The official Python SDK prompt guide demonstrates listing prompt arguments and rendering messages through prompts/get. It describes prompts as templates users choose and shows named string arguments rather than a tool input JSON Schema. This article uses that interface distinction without prescribing an SDK package version or executable decorator example.

Here is an original template sketch, not JSON-RPC and not a complete implementation:

Prompt: prepare_case_summary
Arguments: case_id, audience

Prepare a summary for the stated audience.
Separate reported symptoms from verified findings.
Identify the approved knowledge articles used.
List unresolved questions before proposing next steps.
Prepare a draft; do not submit a reply from this template alone.

A template can guide the response, but rendering it is not evidence that the user approved every subsequent action. Keep submission authorization separate. Also decide how the host obtains the case content: rendering a string containing an identifier does not automatically guarantee that the relevant resource has been read.

Combine the primitives without blurring their boundaries

In the hypothetical workflow, the user selects the summary prompt. The host supplies an approved article resource as context. The model uses a permitted search tool to gather related cases. The application presents a draft and, if sending is supported, applies its separate approval and execution controls.

Notice the decisions that remain outside the primitive names: which identity reads the case, how much content enters the model context, whether the result is current, and whether the user can approve a send. Use the access-control guide to trace those boundaries and the audit-evidence guide to distinguish the proposed action from the attempted and confirmed outcomes.

Complete this interface-choice worksheet for the intended host. The first row is a fictional design choice, not a supported-client claim; the remaining decision cells are blank for your workflow.

For each blank row, decide whether the caller knows an address, needs to supply operation inputs, or wants to select a reusable interaction. Verify the proposed presentation in the actual client, and include its version and protocol revision in the server-management inventory. An unavailable host feature may change the interface choice; it must not weaken shared backend authorization. Any fallback interface must enforce the same underlying data permissions and separate approval for sending.

Avoid three common design mistakes

First, do not equate resources with static files and tools with writes. A resource can be generated from live data; a tool can perform a bounded read. Choose the interface that fits addressing, inputs and the desired interaction.

Second, do not treat returned content as trusted instructions. An article or case note can contain text that tries to redirect the assistant. The host needs to preserve the distinction between retrieved material and the user's authority. A well-chosen primitive does not eliminate untrusted content.

Third, do not assume a protocol feature creates a specific client interface. A prompt may appear as a menu item in one host and be unsupported in another. Verify how the intended host discovers and presents it before promising that experience to users.

For a broader introduction to where these pieces fit, see what Model Context Protocol is. For this design decision, a small interface with clearly described behavior is more useful than exposing every backend function at once.

Frequently Asked Questions

What is the difference between MCP resources and tools?+

Resources expose context identified by a URI. Tools expose operations with inputs. A read-only search can be a tool, and a resource can contain dynamic data; the distinction is not simply reads versus writes.

What are MCP prompts used for?+

Prompts provide reusable interaction templates that users can select and supply arguments to. They help structure a conversation but do not independently authorize later tool actions.

Can one MCP server expose all three primitives?+

Yes. A server can expose resources, tools and prompts as supported capabilities. Verify that the intended client supports the features and interaction patterns your workflow needs.

Does a resource URI grant access to its contents?+

No. The URI identifies a resource. The server and underlying systems still need to enforce access for the requesting identity and handle unavailable or unauthorized content appropriately.

Choose one workflow and label each requirement as addressable context, an operation, or a reusable interaction. Then verify those choices in the actual host before expanding the server interface.