MCP Resources vs Tools vs Prompts: Which Should You Build?

When you build an MCP server, one design decision shapes the entire experience: should a piece of functionality be a resource, a tool, or a prompt? They may all help an AI application work with your system, but they serve different roles.

The practical rule is simple: use resources to expose context, tools to let a model request an operation, and prompts to offer a reusable interaction that a person chooses. Choose based on who should control the interaction and whether the server is exposing information, performing work, or packaging instructions.

The difference at a glance

• Resources — application-driven data identified by a URI. Examples include a project README, a database schema, or a current build report.
• Tools — model-controlled callable functions. Examples include searching records, calculating a value, opening a ticket, or running a validated operation.
• Prompts — user-controlled templates that a client can present for explicit selection, such as “review this pull request” or “summarize this incident.”

These control labels come from the official MCP server feature overview. They describe the intended interaction model, not a guarantee that every client presents the features in exactly the same way.

1. Use MCP resources for information and context

A resource gives a client a stable way to discover and read information from your server. Each resource has a URI and may include a name, description, MIME type, and other metadata. The content can be text or binary data.

For example, a developer-support server might expose resources such as:

• project://billing/architecture — the current architecture overview.
• database://billing/schema — a readable schema description.
• build://latest/report — the latest build report.

A client discovers available resources with resources/list and reads a particular resource with resources/read. If the URI represents a family of related items, a server can expose a resource template—for example, a template for a particular project or report ID.

Resources are useful when the main job is to make data available as context, not to ask the model to execute a business action. The client decides how that context is selected or included; MCP does not mandate one universal resource-picker interface.

Implementation note: servers must validate resource URIs, and sensitive resources should have appropriate access controls. A URI is an identifier, not authorization. See the official Resources specification for resource listing, reading, templates, subscriptions, and security considerations.

2. Use MCP tools for operations

A tool exposes a callable operation with a name, description, and input schema. A compatible client can make that tool available to the model, which may request it when relevant. Tools can retrieve information, perform calculations, call APIs, or change external state.

For the same developer-support server, possible tools might be:

• search_issues — search issue records using validated filters.
• compare_releases — compare two release identifiers and return a structured summary.
• create_issue — create an issue after validating the project, title, and permissions.

The key distinction is that a tool call requests work. Even a tool that only retrieves data is still an operation the model can choose to invoke. A tool that writes data or triggers an external action needs appropriate authorization, input validation, and a clear user-approval experience where risk warrants it.

Do not rely on the tool description alone to enforce policy. Check permissions on the server, validate every argument, limit credentials, and make side effects observable. The official Tools specification recommends that applications make exposed tools and invocations clear to users and retain a human ability to deny calls.

Read the MCP Tools specification for tool discovery, input schemas, invocation, notifications, and security guidance.

3. Use MCP prompts for reusable, user-selected workflows

A prompt is a named template of messages and instructions that a client can list and retrieve. It may accept arguments so a person can tailor the template to a task. Prompts are designed around explicit user choice, often through a menu item or slash command.

In the developer-support example, prompts could include:

• review_pull_request — asks for a review using a supplied pull-request URL or summary.
• investigate_failed_build — structures an investigation around a build report and relevant logs.
• prepare_release_notes — gives the user a consistent release-note workflow with version and audience arguments.

A prompt is not itself a tool that performs the workflow. It packages a repeatable way to ask for work. The model may still need resources for context and tools for actions. For example, a release-note prompt could guide the conversation, a release report resource could provide the facts, and a compare_releases tool could fetch missing details.

Prompts are discovered through prompts/list and retrieved through prompts/get. Validate prompt arguments and outputs, and do not treat prompt text as an access-control boundary. See the official Prompts specification.

A practical decision workflow

For each capability you plan to expose, answer these questions in order:

1. 1. Is the primary goal to make a piece of information discoverable and readable? Start with a resource.
2. 2. Does the model need to request an operation, search, calculation, or external action? Use a tool.
3. 3. Is the goal to give a person a repeatable, parameterized way to start a conversation or task? Use a prompt.

Then check whether the client you support implements the capability and how it presents it. MCP standardizes protocol messages and capability negotiation; it does not force all clients to use identical menus, context-selection behavior, or approval screens.

Example: building a release assistant

Imagine a release assistant that helps a team prepare a production deployment. A clean design separates the context, action, and reusable workflow:

• Resource: release://v2.4/checklist exposes the approved checklist and release metadata.
• Tool: run_release_checks executes automated checks and returns results. The server enforces which user and environment are allowed.
• Prompt: prepare_release_review gives the user a consistent review template with version, audience, and change summary arguments.

This separation makes the interface easier to understand. The resource is the information, the tool is the operation, and the prompt is the repeatable way to start the task. The prompt can refer to the resource and suggest using the tool, but the server must still enforce access and execution rules independently.

Common design mistakes to avoid

• Exposing every data lookup as a write-capable tool. If the client mainly needs a stable document or schema as context, consider a resource instead.
• Putting business logic only in a prompt. Prompts guide interaction; they do not enforce permissions or guarantee that an action happens.
• Assuming all clients display every capability. Test the target clients and versions, and handle unsupported capabilities gracefully.
• Treating readable context as trusted. Resources may contain stale, sensitive, or untrusted content. Validate access and consider how retrieved data could influence subsequent actions.
• Skipping protocol and configuration checks. If your server is not discoverable, first verify that the relevant capability is declared and that the client connection works. For configuration troubleshooting, see our guide MCP Server Config Not Working? Common JSON Mistakes.

Testing checklist before shipping

Use this checklist when reviewing an MCP server:

• Confirm the server declares the capabilities it actually supports.
• Verify that resources have unique, valid URIs and that reads enforce access controls.
• Give each tool a precise description and input schema; validate arguments on the server.
• Add authorization, confirmation, and audit behavior appropriate to the risk of tool side effects.
• Make prompts understandable, give arguments clear names, and validate their inputs.
• Test listing and invocation in every client you intend to support, including error cases and unsupported features.

Re-test after changing server capabilities or the implementation. A correct manifest or configuration does not prove runtime behavior is safe.

Frequently asked questions

Can an MCP server use resources, tools, and prompts together?

Yes. They serve complementary purposes. A server can expose readable context as resources, callable operations as tools, and user-selectable workflows as prompts. The client may support some or all of these capabilities.

Are MCP resources always static?

No. A resource may provide changing information. MCP also supports optional subscriptions to resource updates when the server and client support them. Resources are about exposing context, not promising that content never changes.

Can a prompt call a tool automatically?

A prompt returns messages and instructions to the client; it is not itself a tool invocation. The model may decide to request an available tool during the resulting interaction, subject to the client's behavior and controls.

Should every data query be a resource?

No. Use a resource when the data is naturally exposed as addressable context. Use a tool when the model needs to request a query operation with parameters, filtering, computation, or other behavior. The best design depends on how clients should discover and use the capability.

Do these MCP primitives provide security by themselves?

No. They define interaction patterns, not a complete authorization system. Validate input, enforce permissions on the server, protect sensitive data, and require appropriate review for risky actions.

Official references

MCP Server Feature Overview — the control model for prompts, resources, and tools.

Resources Specification — resource URIs, listing, reading, templates, subscriptions, and security.

Tools Specification — tool discovery, schemas, calls, and user-safety guidance.

Prompts Specification — user-controlled templates, arguments, retrieval, and validation.