You are building a server for an internal reporting database. It needs to let an assistant run parameterised queries, read the current table schema, and offer a ready-made walkthrough for the monthly close. How should those three needs be exposed?

The principle — Choosing the primitive is choosing who will reach for the thing, and that decision is made once, at design time.

Why the key is correct — The three blocks map onto the three needs almost by definition. Tools: Executable functions that AI applications can invoke to perform actions (e.g., file operations, API calls, database queries) — that is the parameterised query. Resources: Data sources that provide contextual information to AI applications (e.g., file contents, database records, API responses) — that is the schema, and each resource has a unique URI (e.g., file:///path/to/document.md) and declares its MIME type for appropriate content handling. Prompts: Reusable templates that help structure interactions with language models (e.g., system prompts, few-shot examples) — that is the monthly close.

Why the others are wrong — Everything-as-a-tool works but discards the distinction that makes schema retrieval cheap. Leaving the walkthrough to the host misplaces a server primitive. And nothing obliges a server to pick one kind of capability.

Remember this — One server, three kinds of offering, chosen by who will use each.

Sources — MCP first-party documentation.