Tools, Resources and Prompts: The Three Building Blocks of MCP

Learn how Tools, Resources and Prompts differ, who controls each one, and how to design an MCP Server that combines all three.

Many people build an MCP Server and turn everything into a Tool: searching, reading documents, ready-made instructions. The model ends up guessing a lot, users lose control, and the context fills with data nobody needed. The root cause is not seeing that MCP deliberately splits a Server's capabilities into three types.

What are the three building blocks?

The MCP Server Concepts documentation draws a clear line, and the key question is "who is in control?"

• Tools: functions the model calls to take action, controlled by the model
• Resources: data read as context, controlled by the application
• Prompts: ready-made instruction templates, controlled by the user

Tools: letting AI act

A Tool is an action with clear inputs and outputs, such as searching flights, sending email or writing to a database. Each tool declares its input with JSON Schema, and the model discovers tools by requesting the tool list.

Mechanics worth knowing

• A tool can declare an output schema to return structured results that the app can validate and reuse easily
• Tools can carry annotations describing behaviour, such as whether they are read-only. The spec warns that clients must treat annotations as untrusted unless they come from trusted servers
• Because the model can call tools on its own, the spec recommends a human in the loop who can always deny a call

Resources: providing context

A Resource is passive data, such as file contents, a database schema or API documentation. Each resource has its own URI and declares a MIME type.

Two common patterns

• Direct Resources: a fixed URI pointing to one piece of data
• Resource Templates: a URI with parameters, such as city and category, for fetching many data sets, with support for parameter completion

The benefit is that the app decides which parts of the data go to the model: a subset, an embedding search, or everything. That gives better control of context than letting the model call a file-reading tool itself.

Prompts: shortcuts the user invokes

A Prompt is a template with fields to fill in. The user always invokes it explicitly; it never runs automatically. Apps often show prompts as slash commands, where you type "/" and pick one. Prompts make repeated tasks consistent and teach users how the Server is meant to be used.

Example: a tour company in Chiang Mai

A tour company wants its sales staff to plan trips for customers with AI, so it designs a Server like this.

• Resources: all tour packages, plus a template for activities by district and type, such as nature or cafés
• Tools: check seat availability, create a quotation, and book a van, which requires staff confirmation first
• Prompt: "/plan-trip", with fields for number of days, budget and interests

A staff member invokes "/plan-trip" and enters 3 days, a 15,000 baht budget, and a love of nature. The app attaches the relevant package resources, the model calls the availability tool, then drafts a quotation for staff to review before sending it to the customer.

Things to watch out for

• Do not make everything a Tool. Reference data that rarely changes fits better as a Resource.
• Apps differ in support. Some clients handle Tools well but present Resources or Prompts differently. Test in the app your users actually use.
• Resource content may hide instructions. Text in a fetched document may try to command the model. Treat it as data, not instructions.
• The spec changes between versions. Some client-side features have been deprecated in newer versions, so check the latest docs before relying on them.

Tools let AI act. Resources let AI know. Prompts let people set the direction.

How to get started

1. List what you want the Server to do, then sort each item into "action", "data" or "repeated task"
2. Actions become Tools, reference data becomes Resources, repeated tasks become Prompts
3. Write descriptions that someone unfamiliar with the system could understand
4. Test in the client your team really uses to see how it presents all three

If you have never built a Server, read Building your first MCP Server first, then get hands-on with the course ลองใช้ MCP เชื่อม AI กับเครื่องมือจริง on Plants.work Learn.