Concept card

MCP Server Architecture — Tools, Resources, Prompts

As of 2026-07-23

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 Server Architecture — Tools, Resources, Prompts?

The architecture decision that defines a good MCP server is which of three surfaces — model-controlled tools, application-controlled resources, or user-controlled prompts — each capability lives on, and getting it wrong frustrates every agent that touches the server.

What it is

An MCP server exposes exactly three primary surfaces to a calling agent: tools, resources and prompts. The architecture decision that defines a good server is which surface each piece of functionality lives on — getting this wrong is the difference between a server an LLM can drive autonomously and one that frustrates every agent that touches it.

Tools are model-controlled: the LLM decides when to call them, with what arguments. They are functions with side effects or non-trivial computation — find firms, get firm profile, search news in the Analytics Legends server. Each tool declares a JSON Schema input spec (C224), a description the model reads, and returns structured content. Resources are application-controlled: the host application (Claude Desktop, Cursor) decides which to attach to context, the LLM reads but does not request them by name. They are URI-addressable read-only documents — about.json, agent.json, llms-full.txt in our server. Prompts are user-controlled: the human picks a prompt from a slash-command menu; the server returns a templated message sequence the LLM then runs as if the user typed it. analyze market position and draft outreach are our two.

Why it matters

Tools are model-controlled (the LLM decides when to call them); resources are application-controlled (the host decides what to attach); prompts are user-controlled (picked from a slash-command menu) — three genuinely different control loci, not interchangeable labels.
Logs must go to stderr, never stdout, because stdout is reserved exclusively for JSON-RPC frames — a common rookie mistake that corrupts the wire.
Tool handlers should never throw; returning { isError: true, content: [...] } lets the LLM react to the failure instead of the transport silently breaking.

Key points

Tools = model-controlled — JSON-Schema-typed functions the LLM calls (find_firms, get_firm_profile, search_news in the platform charter).
Resources = application-controlled — URI-addressable read-only docs the host picks (about.json, agent.json, llms-full.txt).
Prompts = user-controlled — slash-command templates the human triggers (analyze_market_position, draft_outreach).
Operational invariants — lazy JSON cache module-level, logs to stderr only on stdio, tool handlers never throw (return isError:true).
_attribution on every response — anti-training carve-out enforcement per agent.json.
MCP Server Architecture — Tools, Resources, Prompts 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

Tool (MCP): A model-controlled callable surface declared with a JSON Schema input spec and a natural-language description; the LLM decides when and with what arguments to invoke it during reasoning.
Resource (MCP): An application-controlled URI-addressable read-only document the host attaches to the LLM's context; the LLM reads it as background knowledge but does not request specific resources by name.
Prompt (MCP): A user-controlled named template the human triggers (usually via slash-command); the server returns a structured message sequence that the LLM then runs as if the user had typed it.
Lazy module-level cache: The MCP-server pattern where heavy JSON files are read once on the first tool call that needs them and cached for the rest of the session; keeps stdio servers under 50 ms p95 per call.
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.

Open in the app →