Lesson 15.1 gave you the tool shelf: an agent discovers capabilities through an MCP server instead of learning every service's private dialect. Now comes the mistake almost every beginner makes — treating everything on that shelf as though it *does* something.

It does not. Some things on the shelf are for reading. Some are for doing. Some are instructions for how to work. Confuse them and your agent will try to "read" a bulldozer or "drive" a book.

The library comparison

Picture a library:

• A resource is a book you can read. You open it, you learn something, nothing in the world changes.
• A tool is a service-desk action you can request. "Print this document." "Order that book from another branch." The world changes — paper is used, a request is sent, money may move.
• A prompt (or prompt template) is a reusable work instruction. "Here is how to prepare a release checklist from any repository." It tells the agent *how* to work, step by step, with blanks to fill in.

MCP servers can offer all three. The agent discovers all three through the same connection. But what the agent is allowed to cause is completely different in each case.

Precise examples

Keep one product scenario in mind — a small store app — and see how the same world looks three ways:

Notice the pattern. Resources answer "what is true?" Tools answer "do this and report back." Prompts answer "here is how to do this kind of job."

More examples from real agent work:

• Resource: a project's current deployment status, a read-only product catalog, the contents of a notes file.
• Tool: create a preview deployment, run a bounded query, send a draft (not publish — Lesson 15.4 explains why that boundary matters).
• Prompt: "prepare a release checklist from this repository," "summarize this filing in the house format."

Tool schemas: named fields, not vague prose

Every tool tells the agent, up front, what inputs it expects and what result shape it returns. This description is called the tool's schema.

A schema is the same idea you met in Class 3 with JSON: named, validated fields instead of a vague sentence. Compare:

• Vague: "Deploy the new version sometime."
• Schema-shaped: create_preview_deployment({ branch: "checkout-fix", environment: "preview" }) → returns { preview_url, deployment_id, status }.

The agent does not guess what "deploy" means. It fills in the named fields, the server validates them, and the result comes back in a predictable shape the agent can use in its next step. If a required field is missing or mistyped, the call fails cleanly *before* anything happens — the same way a malformed API request from Class 13 returns a 4xx error instead of doing something random.

This is also why tool choice matters. When a server exposes ten overlapping tools with fuzzy names — deploy, deploy_now, deploy_final — the agent must guess which one you meant. When it exposes one narrow tool with a clear name, clear inputs, and a clear result, the agent chooses correctly and you can review what happened.

Why good tool design matters

Two rules carry the whole lesson:

1. Narrow, clear tools are easier for an agent to choose. One tool, one job, named fields. "Send a draft email" beats "handle communications." 2. Narrow, clear tools are safer for a human to review. You can look at a proposed call — tool name plus field values — and decide in seconds whether it is fine. A vague super-tool hides its consequences.

This connects directly to Class 14's "small key ring" rule. Least privilege is not only about *which* service the agent can reach; it is about *how much* each reachable action can do. A read-only query tool is a small key. A tool that can migrate, delete, or publish is a large one.

A preview of where this goes: in the later Agents part of the course, these tools become steps inside loops — the agent inspects, acts, checks the result, and continues. Loops multiply the effect of every tool. A slightly-too-broad tool inside a loop is how a small mistake becomes a large one. Narrow tools keep loops controllable.

Check your understanding

1. Your agent needs "the current price list." Is that a resource, a tool, or a prompt? Why? 2. Your agent needs to "refund a customer." Which category must that be, and what named fields should its schema require? 3. Why does a vague tool name make an agent *less* reliable, not more flexible? 4. What happens when a tool call is missing a required field — and why is that a safety feature?

Exercise: three bounded capabilities

Turn "help me manage my store" into three bounded MCP capabilities:

1. One resource (read-only information). 2. One read-only tool (an action that gathers but does not change anything important, such as running a bounded query). 3. One action tool (something that changes the world, such as creating a draft).

For each, specify in plain English: its name, its inputs, and its expected output.

Finish line: three short paragraphs, each labeled resource, read-only tool, or action tool, with inputs and outputs stated. Keep the action tool modest — a draft, not a publish. Lesson 15.3 will teach you to inspect a real server before you connect anything.