Skip to main content

Command Palette

Search for a command to run...

Tools, resources and prompts are not interchangeable

Choosing the wrong primitive hands the model authority a person was supposed to hold.

Updated
2 min readView as Markdown
Tools, resources and prompts are not interchangeable
V
I’m Vamsi, a builder focused on production AI systems. I write Production AI Field Notes to break down the architecture behind reliable LLM apps, RAG, agents, multi-agent workflows, evaluation, observability, safety, and governance. My goal is simple: help builders move beyond impressive AI demos and design systems that can be tested, operated, trusted, and improved in the real world.

Almost every MCP server I have looked at exposes everything as a tool.

It is the path of least resistance, and it silently moves control from the person to the model.

Three primitives, three different people in charge

Primitive Who invokes it Typical use
Tool The model Actions with side effects
Resource The host application Read-only context
Prompt The user, deliberately Reusable workflow templates

That middle column is the whole point. It is not a taxonomy of what the capability does, it is a statement about who decides it happens.

Expose a customer record lookup as a tool and the model can pull records whenever it judges that useful. Expose it as a resource and your application decides what enters context. The underlying query is identical. The control model is not.

The same applies to prompts. A workflow template offered as a prompt is something a user picks knowingly. The same template buried in a tool description becomes invisible product behaviour that nobody reviewed.

Schemas are the actual guardrail

Once something is a tool, its schema is the only thing standing between a plausible-sounding model argument and a real side effect.

Broad schemas invite guessing. A query field typed as a free string will eventually receive something nobody designed for. Narrow, typed, server-validated inputs turn that into a clean rejection rather than an incident.

Two habits that pay for themselves:

  • Validate on the server, always. Client-side or prompt-level validation is a suggestion, not a control.
  • Return structured errors the model can act on. "Invalid date range, expected ISO 8601" produces a correction. "Error" produces a retry loop.

And return enough metadata with results to make review possible later: source, timestamp, status. Without it you cannot reconstruct why the system did what it did, and every evaluation you try to run afterwards is guesswork.

Pick the primitive before you name the capability. It is a permissions decision wearing the costume of an API design choice.

Part 3 of 5 Days of MCP for Production AI.

5 Days of MCP for Production AI

Part 3 of 3

What the Model Context Protocol actually standardises, and what it leaves to you. Hosts, clients and servers, the three primitives, transport as an ownership decision, and when a direct API is the better call.

Start from the beginning

What the MCP protocol actually standardises

It settles how capabilities are described and discovered. Every decision about whether to trust them is still yours.