MCP Primitives Explained: Tools, Resources, and Prompts With Real Examples

If you have worked with the Model Context Protocol you might have seen a pattern. Most tutorials start by saying “lets build an MCP server”.. They do not explain what they are building. They show you a @mcp.tool() line and a @mcp.resource() line. Then they move on. They do not tell you why the protocol has three building blocks.

These building blocks are not different ways of saying the same thing. MCP tools, resources and prompts are different. Each one is controlled by a thing. It could be the model. It could be the host application.. It could be the user. If you pick the one your MCP server might not work well. It could cost much.. It could be confusing.

This guide will explain each of these building blocks. It will show you what they look like. It will give you a framework. You can use this framework to decide which one to use. MCP tools are controlled by the model. MCP resources are controlled by the host application. MCP prompts are controlled by the user. You need to choose the one for the job. That is what this guide is, for.

What are MCP Primitives?

In MCP a primitive is a capability that a server can offer to a client. The Model Context Protocol defines three types on the server side:

• Tools: these are functions that an AI model can use to perform actions or computations.
• Resources: this is read- data that an application can use as context.
• Prompts: these are -written templates that help a user or model approach a task.

Think of it like this: Tools are actions you can take Resources are information you can look at and Prompts are templates you can use again. Every MCP server tells a client which primitives it supports when they first connect. Each primitive has its way of discovery like tools/list, resources/list and prompts/list and its own way of use like tools/call resources/read and prompts/get.

The tricky part is understanding who decides when to use each primitive. It all comes down to who’s in control. This is the key to understanding MCPs design. It is also the idea that runs through every section below. MCP primitives are used by server and client. The server provides MCP primitives to the client. The client uses MCP primitives. MCP primitives help in communication, between server and client. MCP server and client use MCP primitives.

MCP Tools: The Building Blocks for Actions

The AI model uses tools to get things done. Like getting data doing a calculation or writing to a database. It can even call an API. The model is in charge of these tools. It decides when to use a tool and what information to give it based on what the user asks for and what the tool can do.

Each tool has a name, a description that people can understand and a set of rules that says what information it needs to work. These rules are written in a format called JSON Schema. The rules tell the model what information is required what type of information it should be and what is optional. If a tool needs a piece of information like a city name and the user does not give it the model will ask for it instead of making a guess. For example if the user asks “what’s the weather, like” and the tool needs a city name the model will ask “which city” to get the answer.

A simple tool definition looks like this:

{
  "name": "search_web",
  "description": "Search the web for current information on a given topic.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "The search query." },
      "max_results": { "type": "integer", "description": "Number of results to return." }
    },
    "required": ["query"]
  }
}

Example: A Web Search Tool

Imagine an MCP server that wraps a search API. It exposes a single tool, search_web, with the schema above. When a user asks “what’s the latest on the RBI’s repo rate decision,” the model recognizes that it needs current information, calls search_web with {"query": "RBI repo rate decision"}, and incorporates the returned snippets into its answer. The model — not the server, not the user — made the call to invoke this tool.

Example: A File Reader Tool

Now picture a tool called read_file that takes a file path and returns its contents. If a user says “summarize the contents of report.pdf,” the model decides on its own to call read_file with that path, gets the text back, and summarizes it. This is still action-oriented — the tool is doing something (reading a file) on demand — which is why it belongs in the Tools bucket rather than Resources, even though it’s “just” returning text.

The general rule for spotting a Tool: if invoking it could have side effects, requires parameters the model has to figure out, or represents a “do this” instruction, it’s a Tool.

MCP Resources: Giving Models Context to Understand

Resources are data that a server wants to share with a client. This data can be files, information from a database, settings or even answers from an API. They provide background information. They don’t do anything on their own. Unlike Tools Resources are controlled by the application. This means the application, like Claude Desktop or a custom agent decides when to use a resource, not the model.

Each resource has an address called a URI. This resource can contain text or pictures. When a model reads a resource the answer will look something, like this:

{
  "contents": [
    {
      "uri": "postgres://crm/customers/schema",
      "mimeType": "application/json",
      "text": "{ \"table\": \"customers\", \"columns\": [\"id\", \"name\", \"signup_date\"] }"
    }
  ]
}

How Resources Differ From Tools

This is where people usually get confused. It is worth explaining clearly. A Tool is something that the model chooses to use during a conversation like when it calls a function. A Resource is something that the application loads, often before the conversation even starts or when a user does something like clicking “attach” in Claude Desktop. Resources are meant to be used for reading and should not change anything on the server. If something needs to be changed that is what a Tool is for even if the information looks similar to a Resource.

There is a reason for this difference. If all information was available as a Tool the model would have to decide to get information every time, which would waste time and slow things down. Resources let the application load information ahead of time like a customers information, a file that is being edited or a part of a knowledge base that is relevant. This way the model does not have to guess what information it needs and Resources like the customers record or the open file, in an editor can be used without the model having to ask for them.

Example: Exposing a Database as a Resource

Lets say we have a server that focuses on Customer Relationship Management. This server might share a database with a link that looks like crm://customers/{id}. When a support agent is working on a customers case in the application the app can read that database and load the customers information into the conversation automatically. The support agent does not need to make a request to get this information and the system does not need to make a decision about what to do. The information is there when the conversation starts.

Example: Exposing a Document as a Resource

Something can happen with a server that shares documents. This server might share a document with a link like docs://api/authentication. This document has information about how to authenticate with the system. A developer who is working in an integrated development environment that knows about this system might choose this document from a list. The environment will add the documents content to the conversation before the next response. The system does not need to ask for this document. It is given the content directly.

One thing to keep in mind if you are building one of these servers: the way resources are shared is not the same across all systems. Some systems need the user to choose the resources manually some systems try to guess which resources to use. Some systems are still experimental and let the model ask for resources. If you are sharing resources you should plan for all of these behaviors rather than assuming that all systems will work the same way.

MCP Prompts: Reusable Templates for Consistent Interactions

MCP Prompts are like templates that have already been written. They help guide how a model works on a task. The user is in control of these templates. They can be accessed with a command or by choosing from a menu. The user decides when to use a prompt than the system deciding on its own.

The point of MCP Prompts is to make things more consistent. Of every user typing out their own version of “please review this code for security issues” a server can create a single template that always asks the right questions in the right order with the right information. This is especially important when people are working together as a team. A prompt template can include the practices of the organization so the quality of the work does not depend on how well an individual user asks for something.

A definition of a prompt, with arguments looks like this:

{
  "name": "review-pr",
  "description": "Review a pull request for code quality, security, and style issues.",
  "arguments": [
    { "name": "pr_number", "description": "The pull request number to review", "required": true },
    { "name": "focus_area", "description": "Optional area to emphasize, e.g. 'security'", "required": false }
  ]
}

Example: A Code Review Prompt Template

A code review server can show a template for a review. When a developer picks this template and gives a number, for the review the server gives them a set of instructions. It includes the changes made to the code a style guide to follow and a checklist of things to do. The server gives all this to the model as if the developer had written it themselves. This way the reviews are always good and consistent. Nobody has to remember the correct template every time.

There are examples of this. For instance a database server can have a template to help find queries. An observability server can have a template to summarize what happened when something went wrong. A companies human resources server can have a template to help new employees get started. In all these cases a person starts the process. It helps make sure that things are done the same way every time, which is a good thing.

Tools vs Resources vs Prompts: Comparison Table

How MCP Primitives Map to Real Use Cases

It is easier to understand theory when you see it in life situations. Here are three situations and how MCP Primitives work in these situations.

Scenario 1: A customer support assistant. The assistant needs to do a things: look up a customers order history issue a refund and follow a standard de-escalation script for angry customers. The order history is a Resource because it is background information that the application loads automatically when a ticket opens. The assistant does not need to ask for it. Issuing a refund is a Tool because it is something the model does when it decides to. The de-escalation script is a Prompt because the support agent chooses it when they need it.

Scenario 2: A database-developer tool. Looking at the schema of a table is a Resource because it is information that provides context. The model does not need to decide to show it. Running a query is a Tool because the model does it based on what the developer asks. A debug-slow-query template is a Prompt because the developer chooses it and it helps them debug queries.

Scenario 3: A content platform like a blog or knowledge base. Having a style guide document that the model can look at is a Resource. Publishing an article is a Tool because it is something the model does. A write-seo-brief template is a Prompt because the content writer chooses it to help them write a brief.

You can see a pattern here: MCP Primitives like actions are Tools MCP Primitives like data are Resources and MCP Primitives like templates are Prompts. The question of who decides what to do usually helps clear up any confusion, about MCP Primitives.

Common Mistakes Developers Make With MCP Primitives

The most frequent mistake is using a Tool where a Resource would be more appropriate. If a piece of data is relatively static and doesn’t require the model to “decide” anything — a schema, a config file, a style guide — wrapping it in a Tool just forces the model to make an unnecessary decision on every relevant turn, adding latency and token overhead for something that should simply be present in context.

A close second is treating Prompts like Tools. Because prompts can accept arguments and return structured content, it’s tempting to build them as if the model will call them autonomously. In practice, Prompts are meant to be human-triggered, and many MCP clients — Claude Desktop included — only support selecting prompts from a menu rather than letting the model invoke them on its own. If you design a prompt expecting model-initiated execution, you’ll be confused when it never gets called the way you expect.

A third mistake is building Resources that aren’t actually read-only, or that have side effects hidden inside a “read.” Since hosts assume resource reads are safe to call freely (including subscribing to updates), violating that assumption can produce surprising or duplicated effects.

Finally, many developers skip JSON Schema discipline on Tools, leaving out required fields, types, or descriptions. The schema isn’t just documentation — it’s what the model uses to decide whether it has enough information to call the tool safely, or whether it needs to ask the user a clarifying question first. A loose schema means more hallucinated parameters and more failed calls.

Watch: YouTube Videos That Explain MCP Primitives Well

If you’d rather see these primitives in action before writing code, these walkthroughs are worth your time:

• The Ultimate MCP Crash Course – Build From Scratch by Web Dev Simplified — a 75-minute, code-first build that covers server-side Tools, Resources, Resource Templates, and Prompts back to back, so you can see the implementation differences directly.
• MCP Agentic AI Crash Course With Python by Krish Naik — a Python-focused walkthrough of building MCP clients and servers that expose resources, prompts, and tools using the official SDK.
• MCP Crash Course: What Python Developers Need to Know — a more conceptual pass through MCP’s architecture before getting into implementation, useful if you want the “why” before the “how.”

Conclusion

MCPs three basics fit well with a question you likely already ask when designing APIs. Is this something that performs an action? Is it a piece of data? Is it an instruction? Tools take care of actions they are controlled by the system. Are used for performing tasks. Resources are for data they are controlled by the application. Are used to provide information that can be read. Prompts are, for instructions. They are controlled by the user. Are used for interactions that are repeatable and follow a standard format. When you understand this choosing which one to use becomes straightforward.

If you are still trying to figure out what the Model Context Protocol is and why we have it you should start with our guide to the Model Context Protocol before you come back to this page. The Model Context Protocol is important to understand. Once you understand the Model Context Protocol and you are comfortable with Tools and Resources and Prompts the next step is to try it out for yourself. Our guide, on building your Model Context Protocol server will show you how to use Tools and Resources and Prompts in a real project. This guide will walk you through the process of implementing Tools and Resources and Prompts in working code for your Model Context Protocol server.

Popular Posts

• MCP Primitives Explained: Tools, Resources, and Prompts With Real Examples
• How to Build an MCP Server in Python (Step-by-Step)
• How to Evaluate Your AI Agent: Metrics, Tools, and Frameworks That Actually Work
• The 6 Security Dangers of Autonomous AI Agents: Why Every Developer Needs to Understand Them Now
• Build an AI Agent with Real Memory Using Mem0, LangChain, and Groq

FAQ

Is an MCP Tool the same as a function call? Conceptually, yes — a Tool is a function the model can invoke, defined with a JSON Schema input definition, very similar to function calling in LLM APIs. MCP standardizes the format so the same tool definition works across any MCP-compatible client.

Can the model decide to read an MCP Resource on its own? Not by default. Resources are application-controlled, so most clients require the host app or the user to select a resource explicitly. Some experimental clients allow model-initiated resource access, but it isn’t the standard pattern.

Do I need all three primitives to build an MCP server? No. A server can expose just Tools, just Resources, just Prompts, or any combination. Most simple servers start with Tools and add Resources or Prompts only when there’s a clear need for read-only context or repeatable templates.