Most people building an MCP server only ever touch one part of the spec: tools. That is not wrong — tools are the part that lets an AI model take action, and for a lot of servers they are all you need. But MCP defines two other primitives, resources and prompts, built for cases tools handle badly. Knowing the difference before you build saves you from cramming everything into one tool list that gets harder to use as it grows.
Tools: things the model decides to call
A tool is a named function with a JSON schema for its inputs, plus a description that tells the model what it does and when to use it. The model reads your tool list, decides (on its own, mid-conversation) whether a tool is relevant, and calls it with arguments it fills in. This is model-controlled: you write the tool, but the AI decides if and when to run it.
Tools are the right fit for actions: create a ticket, send a message, query a database, run a search. They are the wrong fit for large, static, or purely informational content — every tool you add is one more entry the model has to read and weigh before every decision, which is exactly the problem we covered in how many tools an MCP server should expose. Dumping a 40-page reference doc into a tool result, or exposing a "get_document" tool for every file in a wiki, is usually a sign you want a different primitive.
Resources: data the client can read without asking the model
A resource is a URI-addressable piece of data — a file, a database record, an API response, a log — that a client can list and read directly. This is application-controlled: your MCP client (Claude, or whatever host app you are building on) decides when to fetch a resource and hand it to the model as context, rather than the model deciding to call a tool for it mid-reasoning.
That distinction matters in practice. A resource like company-wiki://onboarding can sit in a client’s file picker or context menu, get attached to a conversation the way you’d attach a file, and never once show up in the model’s tool list. Nothing there competes for the model’s attention or gets called by accident. If what you are exposing is really "here is some content," a resource is usually the better-behaved choice over a tool that just returns a blob of text.
The catch: not every MCP client supports resources yet, and support for browsing or attaching them is less consistent across hosts than tool support is. If you need something that works everywhere today, a read-only tool is the safer bet even though a resource is the cleaner model for the data.
Prompts: templates the user picks, not the model
A prompt in MCP is a reusable, parameterized message template — something a user explicitly selects (often surfaced as a slash command or a menu item in the client), fills in a few arguments for, and triggers on purpose. This is user-controlled: the model never decides to invoke a prompt on its own, the way it can decide to call a tool.
Prompts are the right fit for a workflow you want to make repeatable and discoverable — "summarize this ticket in our incident-report format," "draft a release note from these commits" — where you would otherwise be asking the user to remember and retype the same instructions every time. They are underused relative to tools, probably because they are less visible: a tool shows up automatically once a server is connected, while a prompt usually needs the user to go looking for it.
Three controllers, one server
The useful way to remember which is which is who decides:
- Tools — the model decides.
- Resources — the client application decides.
- Prompts — the user decides.
A single server can expose all three. A GitHub-style server might use a tool for "create an issue," a resource for "the contents of this specific file," and a prompt for "review this PR using our house style." Nothing forces you to pick one primitive for the whole server — the mistake is defaulting to tools for everything because that is the primitive every getting-started guide leads with.
Why most servers still only ship tools
Tools are the primitive every client supports well, the one the getting-started docs cover first, and the one that maps most directly onto "wrap an API endpoint" — which is how most MCP servers get built, including the ones generated from an OpenAPI spec. If you are converting an existing REST API, its endpoints already look like actions, so they become tools almost by default. That is a reasonable starting point. It stops being reasonable once you notice half your tool list is really "fetch this reference data" in disguise, and the model’s tool-selection accuracy is suffering for it.
Building this yourself
If you are hand-writing a server with an SDK, resources and prompts are ordinary parts of the spec — check your SDK’s docs for resources/list, resources/read, and prompts/list handlers alongside the tool handlers you are probably already writing. If you are generating a server from an API spec with gate’s MCP server builder, it currently drafts tools from your API’s endpoints, which you review and edit before anything goes live — worth keeping in mind that a generated tool list is a starting draft, and endpoints that are really just data lookups are candidates to reconsider once you are reviewing that list, not necessarily what your final server should ship as-is.
Whatever you build, remember tool descriptions are the entire spec the model sees before deciding to call something — our guide to writing MCP tool descriptions covers that in depth once you have decided a tool is actually the right primitive.
The bottom line
Tools, resources, and prompts exist because "let the model decide" is not the right answer for every piece of a server. Actions belong in tools. Static or reference content belongs in resources when your client supports them. Repeatable workflows a user triggers on purpose belong in prompts. Defaulting everything into tools still works, but as your server grows, it is worth checking whether some of what you are exposing is really the other two primitives wearing a tool’s clothes. See our MCP server directory for examples of how existing servers structure their tool lists in practice.