MCP servers expose capabilities through three core server primitives. This page follows the official Understanding MCP servers guide and the 2025-11-25 specification pages for each primitive.
Official control model
From the server-concepts comparison table:
| Feature | What it is | Who controls it (official docs) |
|---|---|---|
| Tools | Functions the LLM can call to take actions | Model |
| Resources | Passive data sources for context (often read-only) | Application |
| Prompts | Pre-built instruction templates | User |
Source: Understanding MCP servers.
The high-level architecture overview describes the same three primitives servers can expose, plus separate client primitives (sampling, elicitation, logging) that servers may request from the client.
Tools
Definition
The Tools specification (2025-11-25) states that servers expose tools language models can invoke to interact with external systems (databases, APIs, computations). Each tool has a unique name and metadata including an input schema.
Tools are designed to be model-controlled (the model can discover and invoke them from context). The protocol does not mandate a single UI pattern.
For trust and safety, the tools spec says there SHOULD always be a human in the loop who can deny tool invocations, and applications SHOULD make tool exposure and invocations visible (UI indicators, confirmation prompts).
Protocol operations
| Method | Purpose |
|---|---|
tools/list | Discover tools (supports pagination) |
tools/call | Execute a tool |
notifications/tools/list_changed | Server notifies that the tool list changed (if listChanged capability was declared) |
Servers that support tools MUST declare the tools capability during initialization.
Tool definition highlights (spec)
name, optionaltitle,descriptioninputSchema— JSON Schema object (MUST be valid; notnull)- optional
outputSchema,annotations,icons,execution - Tool names SHOULD be 1–128 chars; case-sensitive; limited character set (letters, digits,
_,-,.)
Results use a content array (text, image, audio, resource links, embedded resources) and may include structuredContent / isError.
Security (tools spec): servers MUST validate inputs, implement access controls, rate-limit invocations, and sanitize outputs. Clients SHOULD confirm sensitive operations, show inputs before calls, validate results, timeout calls, and log usage.
Full detail: Tools — 2025-11-25.
Resources
From server concepts:
- Resources expose data (files, APIs, databases, etc.) as context
- Each resource has a URI and MIME type
- Direct resources — fixed URIs
- Resource templates — parameterized URI templates
| Method | Purpose |
|---|---|
resources/list | List direct resources |
resources/templates/list | Discover templates |
resources/read | Read contents |
resources/subscribe | Monitor changes (when supported) |
Resources are application-driven: the host decides how to fetch, filter, and present them (browse UI, search, auto-include, etc.). The protocol does not mandate a specific UI.
Spec: Resources — 2025-11-25.
Prompts
From server concepts:
- Prompts are structured templates (often parameterized)
- They are user-controlled — explicit invocation, not automatic model firing
- They can reference tools/resources to encode domain workflows
| Method | Purpose |
|---|---|
prompts/list | Discover prompts |
prompts/get | Retrieve full prompt + arguments |
Typical host UX (from the docs’ guidance, not mandated): slash commands, command palettes, buttons, context menus.
Spec: Prompts — 2025-11-25.
Design rules of thumb (grounded in the specs)
- Prefer clear tool names and descriptions — discovery is via
tools/listmetadata the model sees - Keep destructive actions obvious; honor human-in-the-loop guidance from the tools spec
- Put large reference material in resources, not giant tool return blobs
- Use prompts for repeatable, user-selected workflows
- Treat tool annotations as untrusted unless the server is trusted (tools spec warning)
Product note (MCPLambda)
When you deploy on MCPLambda, tool-usage analytics focus on tools (call volume, errors, latency) because that is where production agent failures usually surface first. That is product telemetry, not part of the MCP specification.
Worked scenario: Everything was a tool (until it was not)
An early server exposes “get schema,” “get runbook,” and “get policy” as tools. The model calls them constantly, blowing context with huge JSON. Latency tanks.
You move static/read-heavy material to resources, keep side-effecting actions as tools, and add a prompt template for “triage with policy + schema” that users invoke explicitly. Tool count drops; clarity rises; the model stops “searching” documents via tool calls.
You also split destructive tools and ensure descriptions state when not to use them.
Checklist for this topic
- Tools for model-invoked actions with side effects
- Resources for application-provided context data
- Prompts for user-selected templates/workflows
- Tight inputSchema; clear names/descriptions
- Prefer isError with actionable text on failures
- Do not put multi-MB blobs in tool results
Topic-specific failure modes
| Failure | Likely cause | Fix |
|---|---|---|
| Context bloat | Docs as tools | Use resources |
| Accidental deletes | Unscoped destructive tools | Separate + human approval |
| Model never picks tool | Bad description | Rewrite description; simplify catalog |
| Untrusted annotations | Treating annotations as gospel | Trust only trusted servers |
Related guides
First server · Observability · Server concepts
Sources
- Understanding MCP servers
- Architecture overview — primitives
- Tools — specification 2025-11-25
- Resources — specification 2025-11-25
- Prompts — specification 2025-11-25
Next steps
Build your first MCP server using the official SDK quickstart patterns, then package for production.
