Tools, Resources, Prompts: What an MCP Server Actually Offers
Short answer: MCP tools, resources, and prompts are the three primitives an MCP server can offer, and they map to three different bosses. Tools are actions the model decides to call. Resources are data the application attaches to context. Prompts are templates the user picks from a menu. That is the entire menu, and in practice most servers you will connect in 2026 ship tools only.
If you are still fuzzy on the server side itself, start with [what an MCP server is](/blog/what-is-an-mcp-server) and come back. This post is about what a running server can actually expose.
MCP tools, resources, and prompts: sorted by who decides
The cleanest way to tell the three MCP primitives apart is not what they contain but who gets to use them.
| Primitive | Who decides | What it is | Concrete example |
|---|---|---|---|
| Tool | The model | An action with a typed input schema | create_ticket on a helpdesk server |
| Resource | The application | Readable data behind a URI | A database table schema |
| Prompt | The user | A reusable template with arguments | A packaged "review this PR" command |
That control hierarchy is the actual design idea behind the protocol, and it settles most "should this be a tool or a resource" debates.
Tools: the model pulls the trigger
A tool is a function the server describes with a name, a description, and a JSON input schema. The client hands that list to the model, and the model decides mid-conversation whether to call one and with what arguments.
Concrete example: a helpdesk server exposes create_ticket with fields for subject, body, and priority. You type "file a ticket about the broken CSV export, high priority", the model fills the schema, the client executes the call, and the ticket exists. You never touched the API.
You can try a live one today: Tulimoa's directory server at [mcp.tulimoa.com](/mcp) exposes search_listings as a read tool, no account needed. Ask your agent for "EU-hosted CRMs with MCP support" and watch it fill in the filters itself.
Resources: the application attaches context
A resource is a piece of data the server makes readable behind a URI: a file, a doc page, a schema, a log. Crucially, the model does not fetch resources on its own. The client (or you, through the client's UI) decides to attach one to the conversation, and the content arrives as context.
Concrete example: a Postgres server exposes each table's schema as a resource. Attach the orders schema before asking for a query, and the model writes correct SQL on the first try, with no tool call and no model decision involved. The context simply showed up, which is exactly the point.
Prompts: the user picks a template
A prompt is a reusable template the server ships, usually with arguments, that surfaces in the client as a menu entry or slash command. It is the server author packaging their own prompt engineering so users do not have to reinvent it.
Concrete example: a code review server ships a review_pr prompt that takes a PR number. The user picks it, the client pulls the diff into the template, and the model receives a well-structured review request instead of "look at this PR I guess".
Most real servers ship tools only. That is fine.
Scan any directory of MCP servers and count primitives: the overwhelming majority expose tools, no resources, no prompts. Three reasons, and none of them are laziness.
Client support is uneven. Every major client executes tools end to end. Resources and prompts are handled well in some clients and ignored in others, and a server author gets little back from building primitives half their users can never trigger. The split matters because primitives are a contract between two sides, and [the client and the server each own half of it](/blog/mcp-client-vs-mcp-server).
Tools can emulate the rest. A read-only tool like get_document delivers the same bytes a resource would. The difference is who initiates, and in an agent loop you usually want the model initiating anyway, because nobody is sitting there clicking attach.
The agent use case rewards model control. If the goal is an agent that does multi-step work on its own, the model-controlled primitive carries the load. Resources and prompts shine in chat UIs with a human in the loop, which is a different product.
So a tools-only server is not a half-finished server. For agent work, it is the main job done properly.
The catch: tool schemas cost context before anything happens
Here is the asymmetry worth knowing. Resources and prompts cost nothing until someone attaches or invokes them. Tool definitions are different: the name, description, and full JSON schema of every tool get loaded into the model's context up front, on every session, used or not.
The arithmetic adds up fast. A server with 20 tools at roughly 350 tokens per schema is about 7,000 tokens before your first word. Connect five servers like that and you carry about 35,000 tokens of catalog into every session. That standing charge is why [reducing MCP token usage](/blog/reduce-mcp-token-usage) is mostly about controlling which tool definitions get loaded, not about writing shorter prompts.
Frequently asked questions
What is the difference between MCP tools and resources?
Control. A tool is called by the model when it decides one is needed; a resource is attached by the application or the user. The same data can flow through either, so pick by trigger: model-initiated means tool, human-or-app-initiated means resource.
Why do most MCP servers only have tools?
Because tools are the only primitive every major client supports fully, a read tool can deliver anything a resource can, and agent workflows want the model in control. Building resources and prompts that many clients ignore is effort with little payoff for most server authors.
Do resources and prompts use up context like tool schemas do?
Not until they are used. Tool schemas load into context on every session; a resource only costs tokens once it is attached, and a prompt once it is invoked. A huge attached resource can still crowd your context window, but nothing is charged in advance.
How do I see which primitives a server supports?
During the initialize handshake, client and server exchange MCP capabilities, and the client then calls tools/list, resources/list, and prompts/list for whatever was declared. In practice: check the server's docs, or connect it and look at what your client shows.