Tools, Resources, and Prompts

Every MCP server offers some mix of three primitives: tools (do something), resources (read something into context), and prompts (start from a reusable recipe).

Explain like I'm new to AI

If MCP is USB-C, the "device features" come in three kinds. Click each:

tools/call  name: "create_issue"  args: { title: "Login bug" }

• Tools — the model does something (create an issue, run a query). Same idea as function calling.
• Resources — the host reads data into the prompt (a file, a ticket, a schema). No side effect.
• Prompts — named templates the server authors ("review this PR", "onboard a new hire"). The user or agent picks one.

Most servers start with tools. Great servers also offer resources (so you can ground without granting write) and a few prompts (so people don't reinvent the same instruction).

Mental model

A restaurant:

• Tools = placing an order (something happens in the kitchen).
• Resources = reading the menu and the wine list (information, no order).
• Prompts = "the tasting menu" — a pre-designed sequence you start with one choice.

How it works

Tools have a name, description, and JSON Schema for arguments. The host puts that catalog in front of the model. A call is tools/call with name + arguments. Descriptions are how the model selects tools — write them like you would for function calling.

Resources have a URI (file:///…, ticket://142, db://schema/public). resources/read returns content the host can attach. Resources can be templates (a pattern with parameters). Prefer resources when the user should choose what enters context, or when you want read-only access.

Prompts are prompts/get with a name and optional arguments. They return messages ready to drop into the conversation. They're for UX and quality, not for side effects.

List endpoints (tools/list, etc.) now include cache hints. Keep names and descriptions stable — churning the catalog busts prompt caches and confuses tool selection.

Real-world example

A Postgres MCP server:

• Tool: query (run SQL — gated, maybe read-only).
• Resource: db://schema/public (the schema as context, no query run).
• Prompt: explain_slow_query (a recipe that pulls a query + schema and asks the model to explain).

The model isn't forced to query just to see the schema.

Technical explanation

Tools are the dangerous primitive: they have side effects. Design them small, orthogonal, and least-privilege. Return errors as structured results so the agent can recover. For long work, use the Tasks extension rather than blocking a single HTTP request forever.

Resources are closer to RAG than to function calling: they add context, they shouldn't mutate. Hosts may show a picker; agents may resources/read on their own depending on client policy.

Prompts are productized context engineering shipped next to the tools they complement. A good prompt names the goal, the inputs, and the constraints ("never run DELETE").

MRTR (input_required) can interrupt a tool call for confirmation — that's how "delete 1,000 rows" becomes a human-in-the-loop step without a session stream.

Common mistakes

• Vague, overlapping tool names — the same failure mode as bad function-calling descriptions.
• Prompts that secretly perform actions. Prompts should not mutate; tools should.

When to use it

• Tools for actions. Resources for readable context. Prompts for repeatable, high-quality starts.

When NOT to use it

• Don't invent a tool for something the host already does (plain file open in an IDE). Don't ship a prompt that is just "you are a helpful assistant."

Alternatives

• Function calling with no catalog (one app only); stuffing files into the prompt by hand (no resource protocol).

Quick quiz

Last reviewed: 2026-09-04 · Written by ByHeart AI · Reviewed by ByHeart AI