MCP Tools vs Resources vs Prompts: What Each Primitive Does

Most developers who start building with the Model Context Protocol wire up a tool, get it working, and stop there. Resources and prompts sit untouched. That's not a minor oversight - it's the difference between a brittle one-trick agent and a production-grade system that actually scales.

Here's the complete picture, without the 37,000-word detour.

---

TL;DR

• Tools = the action layer. The LLM calls them to change state in the world.

• Resources = the knowledge layer. The host loads them to give the LLM read-only context.

• Prompts = the workflow layer. The user selects them to enforce repeatable behavior. Most real-world MCP servers need all three. Each has a distinct control plane and a distinct job.

---

What Is MCP and Why Do Primitives Matter?

The Model Context Protocol (MCP) is an open standard - introduced by Anthropic in November 2024 - that gives language models a consistent, standardized interface to connect with external systems, data sources, and services. Think of it as USB-C for AI: one protocol, any integration. (For a full primer, see our Model Context Protocol overview.)

MCP defines three core primitives: tools, resources, and prompts. Confuse them and you end up with agents that use tools to read data (side-effect risk), ignore prompts entirely (inconsistent behavior at scale), or treat resources as live feeds (they're not). Getting the primitives right is the foundation of a well-designed MCP server.

---

MCP Tools - The Action Layer

A tool is an executable function the LLM can call to take action in the world.

Tools are the only MCP primitive that can change state. They call APIs, write to databases, send messages, trigger workflows. The LLM decides when to invoke them - with user permission - based on context and the task at hand.

What tools do:

• Execute actions with real-world side effects

• Accept typed inputs defined by a JSON Schema (see our deep dive on designing MCP tool schemas)

• Return structured or unstructured results

• Are discovered via tools/list and invoked via tools/call

Who controls them: The LLM (model-controlled). The LLM decides when a tool call is appropriate. Per the official MCP spec, there should always be a human in the loop with the ability to deny invocations. (For the inverse flow - a server requesting model completions - see the MCP sampling primitive.)

Real-world examples (plain English):

• send_email(to, subject, body) - sends an actual email via SMTP

• create_ticket(title, description) - opens a Jira ticket in your project tracker

• query_database(sql) - runs a SQL query and returns results

• update_crm_record(id, fields) - writes updated fields to a customer record

When to use tools: Any time the agent needs to do something - not just know something.

Callout: Tools are the only primitive that can change state. Use them for actions, not for reading data. Reaching for a tool when you just need context adds unnecessary side-effect risk to your agent.

---

MCP Resources - The Knowledge Layer

A resource is read-only data the host exposes to give the LLM context.

Resources answer the question "what does the agent know?" - not "what can it do?" They're identified by URIs, carry no side effects, and are controlled by the host application, not the LLM.

What resources do:

• Expose files, schemas, logs, records, and documents as context

• Are retrieved via resources/read using a URI identifier

• Support text and binary content (with MIME types)

• Can carry annotations: audience, priority, and lastModified timestamps

Who controls them: The host/client (application-controlled). The host decides what context is relevant and when to load it. The LLM doesn't autonomously pull resources - the application does.

Real-world examples:

• A company's internal knowledge base (product docs, runbooks)

• A live database schema the agent needs to write correct SQL against

• A user's recent activity log for personalization context

• A file or document the agent needs to reference before drafting a response

• An API response from another service, injected as structured context

When to use resources: Any time the agent needs to read or reference data without acting on it. If the agent needs to know the customer's account tier before responding, that's a resource - not a tool call. (When the server needs to ask the user for missing input mid-task, that's a different mechanism - see MCP elicitation.)

Callout: Resources are context, not commands. They answer "what does the agent know?" not "what can it do?" Don't use a tool to fetch read-only data - that's what resources are for.

---

MCP Prompts - The Workflow Layer

A prompt is a reusable, parameterized message template that guides the LLM through a specific workflow.

Prompts are the most underused MCP primitive. Most developers discover tools first, get them working, and never come back to prompts. That's a mistake - especially at scale, where inconsistent LLM behavior is one of the hardest problems to debug.

What prompts do:

• Define named, parameterized templates that return a list of messages (system + user)

• Enforce consistent tone, format, and reasoning patterns across interactions

• Are discovered via prompts/list and retrieved via prompts/get

• Can embed resources directly into the conversation flow

Who controls them: The user (user-controlled). This is the key distinction. The LLM doesn't pick prompts autonomously - a human explicitly selects them, typically via a UI command or slash command. The spec is explicit: prompts are "user-controlled."

Real-world examples:

• A code_review prompt template that structures exactly how the LLM reviews PRs - what to check, what format to use, what to flag

• A customer_support_response prompt that enforces brand tone, required disclaimers, and response length

• A summarize_meeting_notes prompt with a predefined structure: decisions, action items, open questions

• A generate_test_cases prompt that takes a function signature and outputs tests in a consistent format

Why they're underused: Prompts feel redundant when you're building a prototype. They become essential when you're running the same workflow 10,000 times and need every output to look the same. That's the gap most teams hit around month three of production.

Callout: Prompts are the only primitive the user explicitly selects. The LLM doesn't pick them - humans do. If you need consistent, repeatable LLM behavior at scale, prompts are not optional.

---

MCP Tools vs Resources vs Prompts - Side-by-Side Comparison

Here's the full picture in one place. This is the table you'll want to bookmark.

Feature	Tools	Resources	Prompts
Purpose	Execute actions	Provide context / data	Guide LLM behavior
Triggered by	LLM (with user permission)	Host / client application	User explicitly
Side effects	Yes	No	No
Read / Write	Write (+ read)	Read only	Neither
Protocol methods	tools/list, tools/call	resources/list, resources/read	prompts/list, prompts/get
Use when…	Agent needs to DO	Agent needs to KNOW	Agent needs to FOLLOW a workflow
Examples	API calls, DB writes, emails	Files, schemas, logs, docs	Templates, structured workflows

The control plane is the clearest differentiator: model-controlled, application-controlled, user-controlled. One primitive, one owner.

---

Which Primitive Should You Use? (Decision Framework)

Three questions. That's all you need.

01 - Does the agent need to change something in the world? Write a record, send a message, call an external API, trigger a workflow. → Use a Tool.

02 - Does the agent need to read data or reference context? Load a schema, fetch account history, pull a document, inject a log file. → Use a Resource.

03 - Does the agent need to follow a repeatable, structured workflow? Enforce a response format, standardize a review process, guide multi-step reasoning. → Use a Prompt.

---

Most real-world MCP servers use all three together. Here's a concrete end-to-end example - a customer support agent:

1. Resource → Load the customer's account history and subscription tier into context before the agent responds.

2. Prompt → Apply the customer_support_response template to enforce brand tone, required disclaimers, and response structure.

3. Tool → Call update_ticket_status(ticket_id, "resolved") after the agent sends its response.

Three primitives. Three distinct jobs. Clean separation of concerns.

---

Common Mistakes Developers Make With MCP Primitives

These are the patterns we see most often in poorly designed MCP servers.

01 - Using tools to read data. If there are no side effects, it's a resource. Wrapping a read-only database query in a tool adds unnecessary risk and muddies your agent's action surface.

02 - Ignoring prompts entirely. Works fine in a prototype. Breaks down at scale. When 50 different users trigger the same workflow and get 50 different response formats, you'll wish you'd defined a prompt template on day one.

03 - Treating resources as live feeds. Resources are snapshots. They reflect the state of data at the moment they're read. Don't architect your agent to expect real-time updates from a resource - that's a different pattern (subscriptions, if your server supports them).

04 - Overloading one tool with too many responsibilities. Keep tools atomic. A tool that sends an email, logs the event, and updates the CRM in one call is three tools pretending to be one. When it fails, you won't know which step broke.

Tool descriptions are also an attack surface: malicious instructions hidden in a tool's metadata can hijack an agent (we cover MCP tool poisoning attacks separately).

---

Key Takeaways

• MCP tools are model-controlled, have side effects, and are the only primitive that changes state. Use them for actions.

• MCP resources are application-controlled, read-only, and exist to give the LLM context. Use them for data.

• MCP prompts are user-controlled, stateless, and enforce consistent LLM behavior. Use them for repeatable workflows.

• The control plane is the clearest way to distinguish the three MCP primitives: model / host / user.

• Most production MCP servers combine all three - resources load context, prompts shape behavior, tools take action.

• The biggest mistake is treating MCP as a tools-only protocol. Resources and prompts are what make agents reliable at scale.

---

FAQ

What is the difference between MCP tools and resources?

Tools execute actions with side effects; resources provide read-only context. A tool might call send_email() or update_record() - it changes state in the world. A resource exposes a file, schema, or log for the LLM to reference without modifying anything. The other key difference: tools are triggered by the LLM, resources are loaded by the host application.

When should I use MCP prompts instead of tools?

Use prompts when you need consistent, repeatable LLM behavior - not when you need the agent to take action. Prompts don't execute anything. They're parameterized templates that shape how the LLM reasons and responds. If you're running the same workflow hundreds of times and need every output to follow the same structure, a prompt is the right primitive. A tool is the wrong one.

Can MCP tools and resources be used together?

Yes - and they should be. A common pattern: the host loads a resource (e.g., a customer's account data) into context, and the LLM then decides to call a tool (e.g., escalate_ticket()) based on what it read. MCP resources and prompts work together the same way - a prompt template can embed a resource directly into the conversation flow via the resource content type.

Are MCP prompts the same as system prompts?

No, though they overlap in purpose. A system prompt is a raw instruction injected into the LLM's context at the application level. An MCP prompt is a named, parameterized, server-defined template that returns a list of messages - it can include system-role messages, user-role messages, and embedded resources. MCP prompts are discoverable (prompts/list), reusable, and explicitly user-selected. System prompts are not.

What is the Model Context Protocol (MCP)?

MCP is an open standard for connecting language models to external systems, data, and tools. Anthropic introduced it in November 2024. It defines a JSON-RPC-based protocol that standardizes how MCP servers expose capabilities - tools, resources, and prompts - to MCP clients and host applications. The goal: make AI integrations interoperable, so the same server works with Claude, GPT-based agents, or any compliant host.

Which MCP primitive should I start with?

Start with tools - but don't stop there. Tools are the most intuitive primitive and the fastest path to a working agent. Once your tools are stable, add resources to give your agent the context it needs without overloading your tool surface with read-only calls. Add prompts last, once you've identified the workflows that need to be consistent and repeatable at scale.

---

Useful Sources

• MCP Tools - Official Specification
• MCP Resources - Official Specification
• MCP Prompts - Official Specification
• Anthropic - Introducing the Model Context Protocol
• MCP Getting Started Guide
• Composio - How to Effectively Use Prompts, Resources, and Tools in MCP

---

At Ginger Labs, we use all three primitives in production AI agents that automate complex SaaS workflows - and when teams ask which one gives them the most trouble starting out, the answer is almost always "prompts."