Concept card

MCP Server Architecture — Tools, Resources, Prompts

As of 2026-10-06

Edited by Cédric Mary, 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?

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.
SAP's own published MCP servers (BTP administration, Integration Suite Gateway) follow this same three-surface discipline; it is the right mental model for a consultant designing a custom MCP server in front of Datasphere, S/4HANA OData or a BDC data product.
The MCP specification moved to revision 2026-07-28, adding a client-side elicitation capability and an extensions framework (Tasks, Skills over MCP, MCP Apps) not accounted for in this architecture's original three-primitive framing — check which revision a given server targets.

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.
Elicitation: A client-side capability added in the MCP 2026-07-28 revision letting a tool handler ask the end user for missing or ambiguous information mid-call, through the client, instead of failing the call and asking the calling agent to re-prompt and retry.
Data Access Control-scoped tool: A tool whose input schema and server-side validation enforce the same row/column security rules (Data Access Controls in SAP Datasphere, or authorization objects in S/4HANA) that would apply to the calling user in any other SAP interface — the correct place to enforce SAP authorization for an MCP-exposed action.

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 →