"An MCP server offers three kinds of things: actions it can take, data it can share, and prompts it suggests. Master these three and you can build anything."
Level: Intermediate · Time: ~12 min · Prerequisites: Module 24
Learning Objectives
By the end of this module, you will be able to:
- Define tools, resources, and prompts in MCP
- Tell them apart and know when to use each
- Understand who controls each one
- See them in a real server
1. The Three Capabilities
Every MCP server can expose three kinds of capability:
| Capability | What it is | Controlled by | Example |
|---|---|---|---|
| Tools | Actions the model can invoke | The model (with approval) | create_issue, send_email |
| Resources | Data the app can read | The application | A file, a database record |
| Prompts | Reusable prompt templates | The user | "Summarize this PR" |
Explain like I'm new: Picture a workshop. Tools are the power tools you can use (they do things). Resources are the materials on the shelves (they're information). Prompts are the printed recipe cards (ready-made instructions). A good server offers all three.
2. Tools: Actions (Model-Controlled)
Tools are functions the LLM can call to do something — query an API, run a search, create a file. Like function calling (Module 18), the model requests the tool and the host executes it (ideally with user approval for risky ones). Each tool advertises a name, a description, and a schema for its inputs, so the model knows exactly what it does and what arguments to supply — the same discipline you saw with LangChain's @tool.
Key idea: Tools are model-controlled — the AI decides when to use them. That power is why tool design and permissions matter so much for safety (Module 28). Give each tool the least access it needs.
3. Resources: Data (App-Controlled)
Resources are read-only data a server exposes — file contents, database rows, documentation. They're application-controlled: the app decides which resources to pull into context, not the model. Resources are how a server shares knowledge without taking actions.
Real-world use case: A "company docs" MCP server exposes each policy document as a resource. The host loads the relevant ones into the LLM's context (grounding it, RAG-style) — data sharing, no side effects.
4. Prompts: Templates (User-Controlled)
Prompts are reusable, parameterized instructions a server offers — like slash-commands. User-controlled: the person picks one. A GitHub server might offer a "review this pull request" prompt that expands into a detailed, well-crafted instruction. This lets an expert bake their best wording into the server once, so every user gets a polished, consistent prompt instead of typing their own from scratch each time.
Concept: The three control models map neatly to who is trusted with what: the model drives actions (tools), the application decides what data to surface (resources), and the user chooses which canned instructions to run (prompts). This layering is a safety feature — the most powerful capability (taking action) is also the one you'll most want to gate with approval.
Common mistake: Making everything a tool. If the model just needs to read data, expose it as a resource (app-controlled, safer) rather than a tool (model-controlled, more powerful). Match the capability type to who should be in control.
Hands-On: Try This
Try this: For a "calendar" MCP server, classify these: "list today's events," "book a meeting," "weekly-review prompt." Which is a resource (read data), a tool (take action), a prompt (template)? Sorting them teaches you the control model instantly.
✅ Checkpoint
- What are the three MCP capabilities?
- Who controls tools vs. resources vs. prompts?
- When should data be a resource, not a tool?
Answers: 1) Tools, resources, prompts. 2) Tools = model-controlled; resources = app-controlled; prompts = user-controlled. 3) When the model only needs to read it (no action).
Key Takeaway: MCP servers expose three building blocks: tools (actions, model-controlled), resources (read-only data, app-controlled), and prompts (reusable templates, user-controlled). Matching each capability to who should control it is key — expose read-only data as resources, reserve tools for genuine actions, and offer prompts as ready-made commands.
Further Learning
Adapted from Microsoft's MCP for Beginners (MIT License).