Concept card

MCP Resources vs Prompts vs Tools — When Each Surface Wins

As of 2026-07-24T14:00:00Z

Edited by Cédric-Olivier Mâry, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is MCP Resources vs Prompts vs Tools — When Each Surface Wins?

The most common MCP design mistake is forcing every capability into a tool — the right surface follows who decides when: the model chooses tools, the host app attaches resources, the human triggers prompts.

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.

What each surface is for

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.
MCP Resources vs Prompts vs Tools — When Each Surface Wins is mastered only when it changes a named buyer decision.
Start with the semantic contract and control model before demonstrating the tool.
Use current SAP, analyst, study, KG, and news signals as evidence, not decoration.
Separate verified facts from directional trends and modeled assumptions.
Define owner, metric, threshold, support path, and rollback before scaling.

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.
Decision owner: The accountable person who accepts the trade-off and funds the next action.
Semantic contract: The shared definition of business terms, metrics, entities, and access rules used by tools and teams.
Control plane: The layer that applies policy, access, lineage, monitoring, and escalation across the operating model.
Evidence grade: A label that separates verified fact, directional signal, modeled assumption, and field observation.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →