MCP's Three Primitives Explained: How Tools, Resources, and Prompts Each Play a Role

A Design Challenge That Often Gets Overlooked

When an AI application connects to external systems through an MCP (Model Context Protocol) server, developers frequently run into a question that sounds simple but is easy to get wrong: should a given feature be implemented as a Tool, a Resource, or a Prompt?

Take a typical scenario — a database query, a database schema, and an analysis guide all sharing the same MCP server to connect an AI application to an external data system. At first glance, all three seem "database-related," but within MCP's architecture, they serve fundamentally different roles.

There's one guiding principle that ties it all together: Tools perform actions, Resources provide readable context, and Prompts are reusable message templates. Clearly categorizing each feature as "doing something," "providing context," or "offering reusable guidance" naturally keeps responsibilities from bleeding into one another.

MCP (Model Context Protocol) is an open protocol introduced by Anthropic in late 2024, designed to give AI applications a standardized way to connect large language models with external data sources, tools, and services. Before MCP, every AI application typically needed a custom integration layer for each external system, resulting in enormous amounts of duplicated effort. MCP addresses this through a unified client-server architecture: MCP servers expose capabilities (tools, resources, prompts), while MCP clients (usually embedded in AI applications or agent frameworks) invoke them. Because the protocol bundles all three capability types into a single server, it's easy for developers to conflate their use cases — understanding how they divide responsibilities is a prerequisite for designing MCP servers correctly.

Tools: The Executors That Trigger Real Logic

A database query should be implemented as a Tool. The reason: its parameters trigger database logic — even if that logic only reads records rather than writing or modifying them.

This is a common point of confusion. Many developers assume that "read-only" operations should be classified as resources. But MCP's classification criteria isn't about reading versus writing — it's about whether input parameters trigger some piece of logic to execute. A query needs to accept conditions, assemble or execute a statement, and return results. That entire process constitutes "doing something," which makes it a tool.

In other words, the key question for determining whether something is a Tool is: does invoking it produce behavior? Whenever there's a parameter-driven action — regardless of whether the outcome is a read or a write — it falls within the domain of tools.

Resources: Context You Can Fetch Without Running Anything

A database schema, on the other hand, is a textbook Resource. It's context that an application can access directly via an address, with no query needing to run in order to retrieve it.

The essence of a Resource is "statically readable content." A schema describes the structure of the data — it doesn't perform any computation, it doesn't accept parameters, and any application that knows its address can simply read it and use it as background knowledge. This kind of context helps the AI understand how data is organized, enabling it to construct more accurate queries downstream.

The boundary between Resources and Tools is therefore clear: if a piece of content only needs to be "read" without triggering any logic execution, it should be a resource.

Prompts: Reusable Message Templates

An analysis guide belongs in the Prompt category. It's a reusable message template that provides "repeatable guidance."

A Prompt neither executes actions nor sits passively as raw context data. Instead, it's a structured, repeatedly invocable piece of instructional text — one that tells the model how to conduct an analysis or what framework to use when organizing its thinking. Packaging common analytical approaches as Prompts makes them reusable across different scenarios and eliminates the need to rewrite instructions from scratch each time.

This is precisely where Prompts deliver value: distilling experiential know-how into templates that teams and applications can share, ensuring consistent guidance logic across the board.

In the MCP protocol, a Prompt isn't simply a string constant — it's a structured sequence of messages that can carry parameters and be dynamically rendered by the server. Clients can discover all Prompts exposed by a server via the prompts/list endpoint, then retrieve a fully rendered message list by calling prompts/get with the appropriate parameters. This means a single analysis guide template can accept different parameters for different business contexts (e.g., "analyze by quarter" vs. "analyze by region"), generating tailored instructional text without hardcoding multiple instruction sets on the client side. This design gives Prompts both "template reuse" and "dynamic customization" — making them especially valuable in team collaboration or multi-agent scenarios.

One Rule to Define All Three

Distilling this classification logic into a single statement:

• Tool = does something; parameters trigger logic execution (e.g., a database query)
• Resource = provides context; readable via address, no execution required (e.g., a schema)
• Prompt = reusable guidance; structured message template (e.g., an analysis guide)

When designing an MCP server, faced with any given feature, simply ask: is it doing something, providing context, or offering reusable guidance? Apply this three-way classification and each component's responsibilities stay clearly in their own lane — improving both the maintainability and the overall clarity of the system.

For developers building Agentic AI systems, understanding the division of labor among Tools, Resources, and Prompts isn't just a conceptual exercise — it's the foundation for keeping your architecture clean when integrating AI applications with external systems.