MCP Resources vs Prompts vs Tools — When Each Surface Wins

What it is

The single most common design mistake when building a Model Context Protocol server is forcing every capability into a tool. The specification deliberately exposes three distinct surfaces — tools, resources and prompts — precisely so that three different parties, the language model, the host application and the human user, each control the thing they are best placed to control. Collapsing all three into "just make it a tool" is convenient early on, but it burns tokens, slows down response time, and, critically, degrades the model's ability to pick the right tool at all, because every misplaced resource or prompt sitting in the tools list is one more option the model has to read and discard on every single call.

Why it matters

• Wrong surface burns tokens, slows responses, and degrades selection accuracy even when every handler is correct.
• Resources (config, manifests, glossaries) are host-attached at session start, cheap to read, no LLM call needed.
• Prompts are user-triggered deterministic templates (e.g. "analyze market position") — not model-decided functions.

Key points

• Tool — model-controlled action (search, fetch, write); LLM decides when and with what arguments.
• Resource — application-controlled context (config, manifest, glossary); host attaches at session, LLM reads passively.
• Prompt — user-controlled template (slash command); human triggers, server returns multi-turn instruction.
• Decision rule — who decides when? Model → tool. Application → resource. Human → prompt.
• Mis-classification cost — tokens burn, latency rises, selection accuracy drops; the #1 production mistake on MCP servers.
• Elicitation (spec 2026-07-28) — a fourth, distinct control locus: the SERVER decides mid-task that it needs one more fact, but the CLIENT decides how and whether to collect it from the human; not a resource, tool or prompt.
• Skills over MCP (community extension, spec 2026-07-28) — structured, human-discoverable playbooks layered on the triad; closer to a prompt in who invokes it, richer in structure than either a resource or a prompt.

Terms used on this page

Model-controlled surface

An MCP server surface (tools) where the LLM decides at reasoning time whether and how to invoke the call, based on the description and JSON Schema input spec.

Application-controlled surface

An MCP server surface (resources) where the host application (Claude Desktop, Cursor, Claude Code) decides which URI-addressable documents to attach to the LLM's context window.

User-controlled surface

An MCP server surface (prompts) where the human user explicitly triggers a named template — usually via a slash-command menu — and the server returns a structured multi-turn message sequence.

Everything-as-tool anti-pattern

The most common MCP-server design failure: lumping configuration documents, methodology notes and templated workflows into tools, which inflates the tool-selection space and degrades LLM accuracy.

Elicitation

A client feature formalized in the MCP specification (2026-07-28): the server initiates a mid-task request for one more piece of information from the user; the client — not the model, not the server alone — decides how and whether to surface that request. Distinct from all three original surfaces because the trigger is server-side but the fulfilment is client-mediated.

Skills over MCP

An optional MCP extension (community working group deliverable, spec 2026-07-28) exposing rich, structured, human-authored instructions for agent workflows through the protocol — a curated playbook layer, discoverable and human-invoked like a prompt but carrying more internal structure than a template.

Completions utility

An MCP server utility (spec 2026-07-28, server/utilities/completion) that lets a server suggest valid argument values for a prompt or resource template as the user types — an application-controlled affordance, not a model decision.

Sources

1. MCP specification — Architecture overview
2. Anthropic MCP examples repository
3. Model Context Protocol — Specification index, revision 2026-07-28
4. Model Context Protocol — Server Features: Tools (spec 2026-07-28)
5. Model Context Protocol — Server Features: Resources (spec 2026-07-28)
6. Model Context Protocol — Server Features: Prompts (spec 2026-07-28)
7. Model Context Protocol — Extensions overview (spec 2026-07-28)
8. Model Context Protocol — Skills extension overview
9. Model Context Protocol — MCP Apps extension overview
10. Model Context Protocol — Understanding MCP clients (elicitation, roots and sampling as client features)
11. Model Context Protocol — Client Best Practices (progressive discovery and context cost of tool definitions)
12. Claude Platform Docs — Tool search tool (native search over large tool catalogues)
13. CIO — If AI makes the decision, who owns the consequence? (decision rights and authority drift, 28 Sep 2026)
14. SiliconANGLE — Komprise combats ‘MCP bloat’ with a universal interface for AI agents to access enterprise data (metadata-first pattern, 29 Sep 2026)