MCP servers expose three main capability shapes: tools for actions, resources for readable context, and prompts for reusable model interaction templates. Choosing the wrong type causes confusion, weakens security review, and makes host behavior harder to predict.
This page is the primary home for the distinction itself. Later pages go deeper on each capability in isolation.
| Capability | Primary Use | Side Effects | Typical Caller |
|---|---|---|---|
| Tool | Perform an action or computation | Possible | Model or host |
| Resource | Read context or content | Should not | Host or user flow |
| Prompt | Provide reusable message templates | No direct side effect | User or host UI |
Tools are the action surface of an MCP server. They search, create, update, analyze, summarize, or trigger some backend operation. Because a tool may cause cost, latency, or state change, tools demand the strongest validation and authorization discipline.
Good tool design is narrow. Instead of one do_anything tool, design discrete tools whose names reveal intent and whose schemas describe exactly what inputs are expected.
Resources are for reading known content through stable URIs. They are ideal for files, runbooks, generated reports, policy pages, records, and other reference data that a host may include in model context or display to a user.
A resource should feel like something a host can fetch intentionally. It is not a general search command and it should not produce hidden side effects.
Prompts are reusable interaction templates exposed by the server. They are especially useful when domain experts want to standardize how a host frames a task, such as reviewing a deployment diff or summarizing a policy for a given audience.
Prompts should never be mistaken for authorization. They improve consistency, but they do not grant permission and they do not replace server-side checks.
A strong server often uses all three. A docs server may expose search_docs as a tool, policy:// URIs as resources, and summarize_policy_for_employee as a prompt. Each capability type handles a different stage of the user task.
The protocol works best when those roles stay separate. Searching is not the same as reading, and reading is not the same as templating a model interaction.
Tool:
search_policies(query, limit)
Resource:
policy://security/password-rotation
Prompt:
summarize_policy_for_employee(policy_uri, employee_role)The easiest way to choose between tools, resources, and prompts is to start with the user intent. If the user needs the model to perform or request an operation, use a tool. If the user needs approved context, use a resource. If the user needs a reusable language workflow, use a prompt. The categories overlap in product experience, but they should stay distinct in server design.
Do not mirror your backend API blindly. A backend may have twenty endpoints for tickets, but the MCP server might expose one search resource, one read resource, one create-draft tool, and one update-status tool. The MCP surface should be shaped for safe model use, not for internal service convenience.
A strong capability surface is small, legible, and intentionally redundant only where risk differs. For example, split `draft_email` from `send_email` because approval, audit, and failure handling are different. Split `search_documents` from `read_confidential_document` because discovery and read authorization differ.
Before publishing a capability, review it from three viewpoints: the model, the user, and the operator. The model needs a clear name, description, schema, and output shape. The user needs to understand consequences and trust boundaries. The operator needs logs, metrics, error classes, and rollback controls.
If a capability fails one viewpoint, redesign it before shipping. A tool that is easy for the model but impossible for users to approve safely is not production-ready. A resource that is convenient for the model but impossible to audit will become a compliance problem. A prompt that sounds elegant but has no test cases will drift over time.
Choosing between tools, resources, and prompts becomes easier when you ask who controls the capability. If the model may request an operation, design a tool. If the host attaches approved context, design a resource. If the user invokes a reusable task template, design a prompt. The same product feature may involve all three, but each should keep its role clear.
For example, a database assistant might expose a schema as a resource, a query-planning prompt as a prompt, and a read-only query executor as a tool. The resource gives context, the prompt guides interaction, and the tool performs the bounded operation. Blurring those roles creates confusing security and UX.
The most common mistake is turning backend endpoints directly into tools. Backend APIs are built for services, not for model planning. MCP capabilities should be shaped for model use: clear names, narrow inputs, bounded outputs, and explicit descriptions of when to use or not use them.
Review every capability by asking what the model sees, what the user understands, what the server validates, and what operators can audit. If one of those views is weak, the capability needs redesign before production.
Take one backend feature and design it three ways: as a tool, as a resource, and as a prompt. Then choose the correct MCP primitive by asking who should control it and what risk it carries.
This comparison prevents common design mistakes. If it changes state, it is probably a tool. If it supplies context, it is probably a resource. If it packages a repeatable user workflow, it is probably a prompt. Some product flows need all three working together.
Tools, resources, and prompts all use list operations for discovery, and large collections may be cursor-paginated. A client must treat cursors as opaque, continue until no next cursor remains, and bound how much metadata enters model context. Discovery is an inventory operation; it is not permission to invoke or read every listed item.
Servers can advertise `listChanged` support for a capability family and then emit the corresponding list-changed notification. On receipt, the client should refresh that inventory, reapply host policy, and update the model-facing view. It must not retain a removed write tool or expose a newly added tool before policy review.
Choose the primitive by control and effect. A tool represents model-requested execution, a resource represents application-provided context identified by URI, and a prompt represents a user-selectable reusable interaction template. Combining all three in one workflow is valid only when each keeps a distinct contract and authority path.
Names and descriptions are part of model usability, while titles and icons primarily support display. Keep stable machine identifiers distinct from localized presentation text. Metadata received from an untrusted server must be escaped before rendering and must never be interpreted as host policy.
The same domain can expose different MCP primitives for different interaction semantics.
{
"tool": "search_policies(query)",
"resource": "policy://security/password-rotation",
"prompt": "explain_policy_for_role(policy_uri, role)"
}Yes. That is often preferable when the result is large and should be fetched separately instead of embedded directly.
Yes. MCP prompts can embed resource content as part of their returned messages.
Explore 500+ free tutorials across 20+ languages and frameworks.