MCP Tools Resources Prompts Difference: A Production Guide

Understanding the mcp tools resources prompts difference is foundational to any production MCP deployment. The three primitives look superficially similar in a server manifest, but they carry different capability shapes, different security surfaces, and different token costs. Reach for the wrong one and you either over-expose your system or under-serve your model.

This guide unpacks all three, shows representative definitions, and maps them to the exam scenarios you will encounter in Domain 2: Tool Design and MCP Integration.

What Is the MCP Tools Resources Prompts Difference in Summary?

MCP defines three server-side primitive types. Each is surfaced differently to clients and consumed differently by models.

The initiator column is the sharpest dividing line. Tools are model-controlled: Claude decides when to call them. Resources and prompts are client-controlled: the host application decides when to load them.

What Are MCP Tools and When Should You Use Them?

Tools are executable functions the model can invoke to perform actions or retrieve computed information. They are the MCP primitive with the largest blast radius: a tool can write a file, send an email, or mutate a database record. Claude calls a tool by emitting a tool_use content block; the MCP client routes the call to the server; the server executes and returns a result; the client appends a tool_result block before the next model turn. See the tool result appending concept for how this interacts with the agentic loop.

A minimal tool definition in a server manifest:

{
  "name": "create_issue",
  "description": "Opens a new issue in the project tracker. Use when the user asks to file a bug or feature request.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "title": { "type": "string" },
      "body": { "type": "string" },
      "labels": { "type": "array", "items": { "type": "string" } }
    },
    "required": ["title", "body"]
  }
}

The description field is the primary routing mechanism. The model reads it to decide whether this tool fits the user's request. Vague descriptions are the most common source of tool misrouting in production. Our concept on writing effective tool descriptions covers the failure modes in detail.

Because tools can have side effects, they present the largest security surface of the three primitives. Every tool is a potential injection vector: a hostile document could instruct the model to call delete_records if the tool exists and the description does not constrain the call site. Least-privilege design, including splitting broad tools into narrow, constrained variants, is a core CCAR-F exam skill.

What Are MCP Resources and How Do They Differ from Tools?

Resources expose data without executing logic. They are read-only endpoints: a server registers a set of URIs and, when a client requests one, returns its content as text or binary. The model cannot invoke a resource directly; instead, the host application fetches the resource and injects the content into the context window.

A typical resource definition:

{
  "uri": "file:///etc/app/config.yaml",
  "name": "Application config",
  "description": "Current production configuration. Read-only.",
  "mimeType": "text/yaml"
}

Resources are well suited to static or slowly-changing data: configuration files, knowledge-base articles, database schema definitions, API reference documents. They are poorly suited to anything that requires computation at fetch time or that changes faster than a session boundary.

The token economics differ from tools. A tool result is injected as a tool_result block and is relatively compact. A resource load injects the full content of the URI, which can be substantial. For large content catalogs, lazy loading, where only the resource URIs are listed up front and content is fetched on demand, is preferable to eager pre-loading. Our concept page on MCP resources for content catalogs covers the tradeoffs.

Because resources are read-only and client-initiated, their security surface is narrower than tools. The main risk is information disclosure: a poorly scoped URI pattern can expose files the model should never see. Enforce path-level access controls at the server, not at the prompt layer.

What Are MCP Prompts and What Problem Do They Solve?

Prompts are the least understood of the three primitives. They are reusable message templates with named arguments that a server registers and a client can retrieve to seed a conversation. Unlike tools (model-controlled) and resources (client-controlled, data-only), prompts are user-facing: they typically appear in a slash-command palette or workflow picker in the host UI.

A prompt definition:

{
  "name": "summarise_thread",
  "description": "Generates a summary of a support thread.",
  "arguments": [
    {
      "name": "thread_id",
      "description": "The support thread identifier",
      "required": true
    }
  ]
}

When a user selects this prompt, the client calls prompts/get with the argument values, and the server returns a structured message sequence (system message, user message, or both) that the client inserts into the conversation. The model never sees the raw prompt definition; it only sees the rendered messages.

Prompts solve a specific problem: standardising complex, multi-step instructions across teams. Instead of each user typing a long directive by hand, the server encodes it once as a named, parameterised template. For compliance-heavy workflows, this creates an auditable artefact: the exact instruction set that initiated a conversation is logged at the server, not inferred from user messages.

The downside is prompt injection risk during prompts/get. If argument values are user-supplied strings, validate them server-side before interpolating into the returned messages.

Which Primitive Should You Choose?

The decision rule is mechanical once you know the initiator and side-effect profile.

Does the operation change state or call an external API with side effects?
  Yes --> Tool

Does the operation return data the model should read but not execute?
  Yes --> Resource

Does the operation produce a message sequence to seed or extend a conversation?
  Yes --> Prompt

Edge cases worth noting for exam scenarios:

• A search index is almost always a Tool, not a Resource, because the query is dynamic and computed at invocation time.
• A product catalogue loaded at session start is almost always a Resource, not a Tool, because it is static and the model reads it passively.
• A compliance disclaimer injected before every conversation is almost always a Prompt, not a system-prompt string, because it benefits from versioning and server-side logging.

For multi-server deployments where the same data could be exposed as either primitive, prefer the one that matches the access pattern rather than the data type. Our guide on MCP server integration best practices covers coordination across overlapping servers.

How Does the CCAR-F Exam Test These Distinctions?

Domain 2 (Tool Design and MCP Integration) carries 18% of the CCAR-F exam weight, per the official exam guide. The CCAR-F costs $125 per attempt with a passing score of 720 on a 100 to 1000 scale across 60 items in 120 minutes. Scenario items typically present a system design and ask which primitive best fits the described behaviour.

Common scenario patterns:

1. Misclassification: A team exposes a frequently-read reference document as a tool returning its content. The correct fix is to reclassify it as a resource, reducing the security surface and tool catalogue size.
2. Missing prompt abstraction: A team encodes a long compliance instruction in every user message. The correct fix is to move it to a server-registered prompt so it is versioned and auditable.
3. Resource vs. tool for dynamic data: A server registers a live price feed as a resource URI. The correct fix is to expose it as a tool because the data is computed at query time and resource caching introduces unacceptable staleness risk.

The exam consistently rewards designs that match the primitive to the access pattern. The tool descriptions as selection mechanism concept underpins most of these scenarios: a description that encroaches on resource or prompt responsibilities is a design smell the exam reliably penalises.

As of 3 June 2026, more than 10,000 individuals have earned a Claude certification. Knowing the precise mcp tools resources prompts difference distinguishes candidates who have built production MCP systems from those who have only read the documentation.

What Are the Token Costs of Each Primitive?

Token efficiency is a production concern the exam also touches. The three primitives inject tokens differently:

Resources carry the highest risk of context bloat. A server that pre-loads all registered resource URIs at session start can consume tens of thousands of tokens before the user types a single character. The mitigation is lazy loading: list resource URIs at startup and fetch content only when needed.

Tools inject tokens only when called and only for the specific result returned, making them more token-efficient for infrequently-accessed data. Prompts occupy the middle ground: the rendered message sequence is typically a few hundred tokens, injected once at conversation start rather than accumulated across turns.