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

So far in this series we’ve built the frame. In What Is MCP? you learned the why: an open standard — the USB-C port for AI — that turns the N×M integration mess into M+N. In Host, Client, and Server you learned the who: the Host you talk to, the Client lines it holds, the Servers on the other end, all speaking JSON-RPC.

Today, the what. When a server picks up the line, what can it actually put on the table?

MCP’s answer is deliberately small: three primitives. Everything a server offers is a Tool, a Resource, or a Prompt. Three shapes, and once you can tell them apart, you can read any MCP server’s capabilities the way an admin reads an object schema. Let me take them one at a time, each with a Salesforce-flavored example, because that’s the world you and I live in.

Tools: things the AI can do

A Tool is an action. It changes something, computes something, or triggers something. The server describes each tool — its name, what it does, what inputs it needs — and the model can ask to call it with specific arguments.

Here’s the Salesforce example I’d start with: a tool that creates a Case.

{
  "name": "create_case",
  "description": "Create a new Salesforce Case for a customer issue.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "subject":  { "type": "string", "description": "Short summary of the issue" },
      "priority": { "type": "string", "enum": ["Low", "Medium", "High"] }
    },
    "required": ["subject"]
  }
}

Read that slowly and notice something familiar. The description is doing the heavy lifting — it’s how the model knows when this tool is the right one to reach for. If you’ve worked with Agentforce actions, this should feel like déjà vu: there too, the description is the field that matters most. Vague description, wrong tool chosen. Clear description, right tool chosen. The craft transfers directly.

Two things I want you to hold onto about tools:

Tools are model-controlled but user-approved. The model decides it wants to call create_case; the Host asks you before a consequential action actually runs. That consent gate we placed at the Host last week? Tools are exactly what it’s guarding. An AI that can create records in your org should — and does — ask first.

Tools are where your existing skills cash in. When I exposed my custom Apex as MCP tools, each tool was, underneath, real Apex logic — the MCP server just presented it in this standard shape so Claude could discover and call it. If you can write an invocable method, you already know how to think about a tool’s inputs and outputs.

Resources: things the AI can read

A Resource is readable context. It doesn’t do anything; it is something — a document, a record, a file, a query result — that can be loaded into the model’s context so it reasons over real data instead of guessing.

The Salesforce example: a resource that reads an Account. A server might expose it at a URI like:

salesforce://accounts/0015g00000XyZAb

When that resource is read, the server returns the Account’s actual details — name, industry, open opportunities, whatever the server author chose to include. Now the conversation is grounded: ask “draft a renewal email for this customer” and the model writes from the real record, not from a plausible-sounding hallucination.

The distinction from a tool is worth saying twice, because it’s the one beginners blur:

A tool has consequences. A resource has contents. Calling create_case changes your org; reading salesforce://accounts/... changes nothing — it just informs the model.

If you’ve followed my Agentforce writing, you’ll recognize this as the same instinct behind grounding: the difference between an AI that sounds right and one that is right is whether it read the real data. Resources are MCP’s way of handing the model the real data. My live Agentforce agent grounded in Data 360 is built on exactly this principle — the agent answers well because it reads well.

Prompts: reusable workflows

The third primitive is the one people skip, and I think that’s a mistake. A Prompt, in MCP terms, is a reusable, parameterized workflow that the server offers — a well-crafted instruction template a user can invoke on demand.

The Salesforce example: a prompt that drafts a quote summary. A server might offer:

Prompt: summarize_quote
Arguments: quote_id

When you invoke it with a quote’s ID, the server assembles a proven instruction — “Summarize this quote for an executive audience: total value, key line items, discounts, terms to flag…” — already wired to pull in the right context. Instead of every sales rep improvising their own phrasing (and getting wildly different quality), the team’s best way of asking becomes a menu item anyone can select.

Twenty years in education taught me that most performance gaps aren’t ability gaps — they’re instruction gaps. Two students, same ability, different results, because one was asked a better question. Prompts institutionalize the better question. The server author writes it once, carefully; everyone benefits every time.

One more distinction to keep the trio straight: prompts are user-invoked. Tools are chosen by the model (with your approval), resources are attached as context, but a prompt is something you pick — “run the quote summary” — like choosing a recipe rather than ingredients.

The three together: one honest scenario

Let me put all three in one story, because separately they’re definitions and together they’re a system.

A rep opens their MCP-connected assistant and invokes the prompt summarize_quote for a big renewal. The prompt’s template needs real data, so the model reads the quote and the related Account as resources — actual records, not memories. The summary reveals a pricing question the customer raised, so the rep says “log this as a case for the pricing desk” — and the model proposes calling the create_case tool. The Host shows the rep exactly what’s about to be created; the rep approves; the Case exists in the org.

Prompt guided the workflow. Resources grounded it. A tool acted on it. One consent step where it mattered. That’s the whole protocol, working.

And this composability is not hypothetical — it’s how the ambitious things get built. The agent loop I designed that built out an entire Salesforce org was, at its heart, these same primitives called in sequence, over and over, through the standard port. Nothing exotic. Small pieces, standard shapes, repeated well.

A table for your wall

Primitive	What it is	Who initiates it	Salesforce example
Tool	An action with consequences	The model (user approves)	Create a Case
Resource	Readable context	The application attaches it	Read an Account record
Prompt	A reusable workflow template	The user picks it	Draft a quote summary

Your next step

You now have the complete beginner’s map of MCP: the why (part 1), the who (part 2), and the what — Tools that act, Resources that inform, Prompts that guide. If you want to see the primitives specified precisely, the official docs at modelcontextprotocol.io are genuinely readable, and the Python and TypeScript SDKs let you build your first server in an afternoon.

My teacherly advice: don’t just reread — build. Pick the smallest useful thing in your world, decide honestly whether it’s a tool, a resource, or a prompt, and put it on the table. That decision — act, inform, or guide? — is the design skill this whole series has been quietly teaching you.