MCP Resources and Prompts Beyond Tools: When to Use Each

MCP Resources and Prompts Beyond Tools: When to Use Each

In the Model Context Protocol (MCP), tools are actions the model decides to call, resources are data the application exposes for reading, and prompts are instruction templates the person chooses to use. The difference matters because who controls each piece changes the risk: a resource delivers context without executing anything, while a tool can change systems. When the goal is only to give the model information, exposing a resource is usually safer than building a tool.

Key takeaways

• Tools, resources and prompts have different owners: the model triggers tools, the application decides how to use resources, and the person picks prompts.
• A resource is read-only content identified by an address (a URI). It does not perform actions, so its risk surface is smaller than a tool's.
• If the need is to look up stable information (a policy, a catalog, a manual), start with a resource. Reserve tools for what must write, send or calculate on demand.
• MCP prompts standardize the team's recurring instructions, with arguments, instead of each person improvising their own text.
• A resource does not remove risk: the content it delivers can carry malicious instructions, and personal data stays subject to data protection law.

What is the difference between tools, resources and prompts in MCP?

The official Model Context Protocol documentation describes MCP as an open standard for connecting AI applications to external systems. Within it, a server can offer three kinds of capability, and the most useful way to tell them apart is to ask who controls each one.

• Tools: controlled by the model. The model sees the list of tools, decides which to call and with which arguments. Examples: create a ticket, send a message, look up an order by filter.
• Resources: controlled by the application. The server exposes data identified by a URI, and the client (the application hosting the model) decides which ones to include in the context. Examples: a document, a record, a configuration file.
• Prompts: controlled by the person. These are reusable message templates with arguments that the user selects explicitly.

This split turns the design choice into a governance decision, not just a technical one. The more autonomy the model has over a capability, the more limits, logs and approvals it needs. If you are still setting up your environment, the guide to configuring MCP in Claude Code explains which scope each server should live in.

What is a resource in practice?

A resource is content that an MCP server makes available for reading, with an identifier in URI format. It can be fixed, like the company's support manual, or parameterized by a URI template, like a product record looked up by its code.

Three characteristics define how resources are used:

• They are read-only. The resources part of the protocol exists to fetch content, not to cause effects in other systems.
• The application or the person decides what goes into the context, not necessarily the model on its own. This depends on the client you use, so check the documentation for the version you run to see how it handles resources. In clients such as Claude Code, for example, resources and prompts from MCP servers usually appear for the person to choose, but the exact behavior can vary between versions.
• Content has a type and a description. This helps the application show what exists and filter what makes sense for each task.

In practice, think of a resource as a labeled shelf. The person or the application takes what it needs from that shelf, and the model works with the material it is handed. Nothing on the shelf walks off and changes the system.

When is exposing data as a resource safer than building a tool?

Mainly when the need is context rather than action. Many MCP servers start with a generic tool like "search_anything" or "run_query" just so the model can read information. That design gives more power than the problem calls for.

Reasons to prefer a resource:

• Smaller action surface. By how it is used, a resource has no side effects, so there is no risk of sending something twice, deleting a record or spending credit by mistake.
• Explicit scope. You publish exactly the documents and records the task needs, instead of handing over a tool that queries everything and relies on the model behaving well.
• Simpler review. It is easier to audit a list of exposed URIs than the behavior of a tool with many free-form parameters. The guide on how to audit an MCP server before installing it covers this kind of check in detail.
• Control over who decides. Because the application or the person selects what enters the context, there is a human or deterministic step before the model sees the data.

Illustrative scenario: a services company wants its internal assistant to answer questions about the refund policy and service deadlines. The first idea is to build a "query_knowledge_base" tool with free search across the entire shared drive. The safer alternative is to publish just two or three reviewed documents as resources (refund policy, deadline table, escalation script). The assistant answers from those, and no other file is within reach. If tomorrow someone needs to open a ticket, a small tool with human approval can be added then, kept separate from the reading.

A rule of thumb: if the question the model must answer is "what does the rule say?", use a resource. If the request is "do this now", you are talking about a tool.

What are MCP prompts for?

Prompts are instruction templates published by the server, with a name, a description and arguments. The person picks one, fills in the arguments, and the client assembles the message. It is MCP offering ready-made workflows instead of each user typing their own text.

Good uses:

• Standardizing repeated tasks, such as "summarize this ticket in the team's format" or "prepare a complaint reply in the company's tone".
• Combining instruction and context. A prompt can already reference resources, so the person only supplies the argument (for example, the order code).
• Reducing variation between people. The instruction is written by whoever understands the process, not by each agent in the moment.

There is a link to tools your team may already use. In coding environments, the conceptual equivalent is skills in Claude Code: reusable instructions that carry the team's method. For customer support, the article on how to write instructions for an AI support agent helps you decide what goes into the template.

One caution: a prompt is not a security control. A well-written instruction guides behavior but does not prevent an action that a tool allows. Real limits live in permissions, validation and approval, as described in guardrails for AI agents.

Decision guide: tool, resource or prompt?

Use this sequence of questions when designing or evaluating an MCP server.

• Does the model only need to read information that already exists? Expose it as a resource.
• Does the information change per request (for example, a specific customer's order)? Use a URI template with a restricted parameter, or a read tool with closed filters, and log every access.
• Does the task create, change, send or delete something? Use a tool, with minimal permissions, argument validation and human approval for sensitive actions.
• Is the difficulty that each person asks for the same thing in a different way? Create a prompt with arguments.
• Does the data contain personal or confidential information? Before choosing the type, define who can see it, for how long and what gets logged.
• Torn between two types? Start with the less powerful one (resource or prompt) and promote it to a tool only when the need is proven.

If your question is broader, about which integration to use with systems like a CRM, the article on integrating AI with your CRM through API, webhooks or MCP compares the paths.

What risks remain with resources?

Exposing a resource reduces the risk of unwanted action, but it does not eliminate risk. Three points deserve attention.

• Prompt injection through content. If a resource contains text written by third parties (emails, reviews, customer messages), that text can carry disguised instructions. OWASP's prompt injection prevention cheat sheet treats retrieved content as untrusted input, and that is the right stance here too. A resource with third-party text should not sit alongside action tools that lack safeguards.
• Personal data. A resource with a name, phone number or purchase history is still personal data processing under Brazil's LGPD. Publish the minimum necessary, mask what is not needed, and confirm the legal basis with your legal lead. Brazil's data protection authority, the ANPD, is the official reference for guidance.
• Overexposure. A server that lists too many resources becomes broad access again, just under another name. Review the URI list the way you would review an access permission, following the least privilege principle described in OWASP's authorization cheat sheet.

It is also worth remembering that MCP and other protocols solve different problems. If your question is how agents talk to each other, see the comparison of A2A vs MCP.

How to apply this with the map, limit, pilot and transfer method

Juan Carlo's working method for AI systems fits the design of an MCP server well.

• Map: list the real questions and tasks in the process and classify each one as a read, an action or a recurring instruction. That list becomes the inventory of resources, tools and prompts.
• Limit: publish only the resources that are needed, with minimal data, and give tools narrow permissions and human approval for sensitive actions.
• Pilot: run a single real workflow, with logs of what was read and what was triggered, and a success metric agreed beforehand. Only then decide whether to expand.
• Transfer: hand over the documentation of the resource list, the prompts and the permissions, so the team knows how to review and maintain them. In the end, the decision is to expand, adjust or stop.

The expected result is a small, explainable server in which every capability has a reason and an owner.

Frequently asked questions

Is an MCP resource the same thing as RAG? No. RAG is a technique for retrieving relevant passages and handing them to the model, while a resource is a protocol mechanism for exposing content identified by a URI. An MCP server can use resources as part of a retrieval solution, but the two concepts are not equivalent.

Can I use only tools and ignore resources and prompts? You can, and many servers do, but you lose more controlled ways to deliver context and standardize instructions. It is also common for simple reads to end up implemented as broad tools with more power than needed. Checking whether each read could be a resource is a good review exercise.

Can the model read any resource on its own? It depends on the client and the configuration. The protocol puts resources under the application's control, which means the application decides how and when to include them in the context. Check the documentation of the client you use to see how this works, and test before assuming a behavior.

Does an MCP prompt replace the company's AI use policy? No. A prompt standardizes a task, but rules about which data can be used, by whom and with what review belong in the internal policy. Those rules should be defined first and reflected in the server's technical limits.

Sources

• Model Context Protocol: introdução
• OWASP: prevenção de prompt injection
• OWASP: guia de autorização
• Anthropic: Writing effective tools for agents