Lesson 3: Tools, Resources and Prompts

In this lesson you will:

• Learn the three building blocks an MCP server can offer: tools, resources and prompts.
• See who controls each one: the AI model, the app or you.
• Meet elicitation, the one feature a client offers back to servers.

In Lesson 2 you learned that a server is the bridge to a tool or data source. This lesson opens up that bridge and shows what travels across it. The "who controls it" idea is the key to judging risk later in the course.

1. The three building blocks at a glance

The server concepts page sums up the three features in one table. Here it is, lightly trimmed:

The specification puts it even more briefly. Resources are "context and data, for the user or the AI model to use." Prompts are "templated messages and workflows for users." Tools are "functions for the AI model to execute."

2. Tools: actions the model chooses

A tool is a single action with defined inputs. The docs say tools "can write to databases, call external APIs, modify files, or trigger other logic."

Each tool has a name, a description and an input schema. The schema lists what the tool needs. This example comes from the server concepts page:

{
  "name": "searchFlights",
  "description": "Search for available flights",
  "inputSchema": {
    "type": "object",
    "properties": {
      "origin": { "type": "string", "description": "Departure city" },
      "destination": { "type": "string", "description": "Arrival city" },
      "date": { "type": "string", "format": "date", "description": "Travel date" }
    },
    "required": ["origin", "destination", "date"]
  }
}

"Model-controlled" means the AI reads these descriptions and decides when a tool fits your request. That is powerful, and it is why tools carry the most risk.

The tools page of the spec says there "SHOULD always be a human in the loop with the ability to deny tool invocations." Apps meet this with approval dialogs, tool toggles and activity logs. You will set these up in Lesson 10.

Servers can also attach hints, called annotations, such as readOnlyHint or destructiveHint. The spec's schema warns these are only hints. Clients "should never make tool use decisions based on ToolAnnotations received from untrusted servers." See our tool annotations reference.

3. Resources: context the app pulls in

A resource is data the AI app can read for context. The docs say resources provide "read-only access to information," such as "file contents, database schemas, or API documentation."

Each resource has a unique address called a URI, such as file:///path/to/document.md, plus a file type. Some servers offer resource templates with blanks to fill in. The docs give travel://activities/{city}/{category} as an example.

"Application-controlled" means the app decides how to use resources. It might show them in a picker, search them, or include them automatically. In Claude, for example, the remote server guide shows resources and prompts appearing in an attachment menu for you to select.

4. Prompts: templates you choose

A prompt is a ready-made instruction template that a server author wrote. The docs say prompts are "user-controlled, requiring explicit invocation rather than automatic triggering."

You usually find them as slash commands. The docs mention typing "/" to see options like /plan-vacation. A prompt can ask for inputs, such as destination, number of days and budget, then run a consistent workflow.

Prompts are the lowest-risk building block on their own. They only shape what you ask. The tools they lead to still need your approval.

5. Seeing all three work together

The server concepts page walks through a travel planner with three servers: travel, weather and calendar/email. In short:

1. You pick a prompt: "Plan a vacation" to Barcelona, with dates and a budget.
2. You select resources: your June calendar, your travel preferences and a past trip to Spain.
3. The AI calls tools: it searches flights and checks the weather.
4. The AI asks before acting: it books a hotel, adds a calendar event and sends a confirmation email, "requesting approval from the user where necessary."

Notice the order. Prompts and resources set the stage. Tools do the work, and the risky ones wait for you.

6. What clients offer back: elicitation

Servers are not the only side with features. The architecture overview says clients can offer elicitation. It "allows servers to request additional information from users," such as missing details or "confirmation of an action."

For example, a server might pause a tool call to ask which account to use. The app shows you the question, and your answer goes back to the server. Lesson 4 shows how that round trip works, and our elicitation reference covers the details.

7. Deprecated client features

Older guides mention two more client features. As of protocol version 2026-07-28, the architecture overview marks both as deprecated:

• Sampling let a server ask the host's AI model for a completion. The docs say "new implementations should integrate directly with LLM provider APIs."
• Logging let a server send log messages to the client. New servers "should log to stderr (stdio transport) or use OpenTelemetry."

Deprecated means they still exist for now, but new projects should not rely on them. Our summary of the July 2026 spec changes lists everything that moved.

Try it

Classify each capability below as a tool, a resource or a prompt. Then name who controls it.

1. "Create a draft invoice in the accounting system."
2. "The database schema for the orders table."
3. "/weekly-report, which asks for a date range and builds a summary."
4. "Send a Slack message to a channel."
5. "The contents of last quarter's board deck PDF."
6. "Search the help desk for tickets matching a keyword."
7. "/onboard-client, a guided checklist with the client's name as input."
8. "Today's calendar for the sales team, available to attach to a chat."

Answers: 1 tool (model). 2 resource (application). 3 prompt (user). 4 tool (model). 5 resource (application). 6 tool (model): it is read-only, but the model decides when to run it. 7 prompt (user). 8 resource (application).

Bonus: which of the four tools would you want the app to always ask about? Most people pick 1 and 4, because they change something.

Recap

An MCP server can offer tools, resources and prompts. Tools are actions the model chooses, resources are data the app pulls in, and prompts are templates you pick. Clients can offer elicitation so servers can ask you questions. Sampling and logging are deprecated as of the 2026-07-28 spec. Knowing who controls each feature tells you where approvals matter most.

Course navigation

Previous lesson: Lesson 2: Hosts, Clients and Servers.

Next lesson: Lesson 4: Follow One Request From Prompt to Result.

Back to the Learn MCP course outline.

Frequently asked questions