The Three Core Capabilities of MCP: Tools, Resources, and Prompts Explained

MCP (Model Context Protocol) is becoming the standard bridge connecting AI models with the outside world. What makes this protocol important is that it redefines how AI acquires information, follows instructions, and executes operations through three concise primitives — resources, prompts, and tools. Understanding how these three divide responsibilities and work together is the key to grasping MCP's design philosophy.

Resources: Read-Only Data That Injects Context into the Model

Resources are the most fundamental primitive in MCP, and are essentially read-only data. Their role is straightforward: they feed documents, files, or other information sources directly into the model's context window. You can think of resources as the model's "reference library" — when a user needs AI to answer questions based on a certain document, or needs the model to analyze specific data, resources provide a standardized channel for injecting data.

This read-only nature brings two benefits. The first is security: resources produce no side effects on the system, and read operations are inherently controllable. The second is determinism: what the model receives is the raw data itself, with no uncertainty introduced by execution logic. For scenarios that require precise citation — such as code review or document Q&A — the resources primitive is the most reliable source of context.

The context window is the key background for understanding the value of resources. A large language model can only "see" a limited length of text per inference, and this capacity is called the context window. Window sizes vary from thousands to hundreds of thousands of tokens across models, and the more content is filled into the window, the higher the inference cost and the more easily attention is diluted. Therefore, how to efficiently and accurately place external information into this window is one of the core problems of AI application engineering. The resources primitive is precisely the standardized answer to this problem: it specifies in what format and through what interface data is retrieved and injected into context, avoiding the chaotic practice of each application assembling prompts and manually concatenating documents on its own. Understanding the finiteness of the context window also makes it clear why "read-only, deterministic" resources are more reliable than having the model fetch data itself.

Prompts: Reusable Instruction Templates

Prompts are defined in MCP as reusable templates that provide predefined instructions. This design solves a practical problem: many AI interaction scenarios require repeatedly using the same instruction structure, such as "please output in JSON format" or "please analyze the code according to the following steps." If you had to type these in manually each time, it would be both inefficient and error-prone.

By standardizing prompts as an MCP primitive, developers can encapsulate commonly used instructions as templates for the model to invoke when needed. This is not merely a matter of convenience — it transforms prompt engineering from ad-hoc manual work into a manageable, versionable asset. Teams can maintain a validated prompt library, ensuring consistent instruction quality across different sessions.

Tools: Executable Functions Triggered Autonomously by the Model

Tools are the most powerful primitive in MCP, and the part that best embodies the concept of "AI agents." Unlike the read-only nature of resources, tools are executable functions that the model can autonomously trigger to perform active external operations. Querying databases, calling APIs, writing files — all these actions that change external state are accomplished through tools.

"Autonomous triggering" is the keyword here. The model is no longer merely responding passively; it can decide on its own which tool to call and when, based on task needs. This grants AI tremendous operational capability, but it also raises the most critical question: how do we ensure the safety of these active operations?

Function calling is the underlying mechanism that makes the tools primitive work. The model itself does not execute code; what it does is output a structured piece of data (usually JSON) declaring "I want to call a function named X with parameters Y." The host program parses this declaration, actually executes the function, and then passes the result back to the model to continue reasoning. MCP's tools primitive is essentially a unified encapsulation of this mechanism: it uses a standard schema to describe each tool's name, purpose, and parameters, enabling different models and different clients to discover and call tools in a consistent way. This also explains why permission gates can be placed at the tool layer — because it is always the host program that executes actions, and it naturally has the opportunity to intercept and request user confirmation before turning the model's "call intent" into a real operation.

Human-in-the-Loop: The Permission Gate for Tool Execution

MCP's answer to this is very clear: tool execution strictly requires explicit human-in-the-loop permission. The system prompts the user to approve the operation before any code runs.

This design choice deserves careful thought. It means that while MCP grants the model capabilities, it keeps ultimate control firmly in human hands. The model can propose executing a tool, but it must be confirmed by the user before it can actually run. For write operations, external API calls, or any action with side effects, this gate is the last line of defense against accidental harm.

From an architectural perspective, this combination of "open capabilities + tightened permissions" is pragmatic. It acknowledges the limitations of current AI systems in terms of autonomy, and also addresses enterprises' legitimate security concerns. The three primitives each play their role: resources handle "reading," prompts handle "teaching," tools handle "doing," and the human-in-the-loop mechanism ensures the "doing" step is always controllable.

Human-in-the-loop (HITL) originates from a classic concept in automation and human-computer interaction, referring to retaining human confirmation or intervention steps in a system's decision-making process. In AI agent scenarios, it is usually divided into several levels: pre-operation approval (model proposes, human approves), in-operation supervision (can be interrupted at any time), and post-operation auditing (recording complete call logs). MCP chooses the strictest pre-approval model, meaning any tool call must obtain explicit permission before execution. This choice is in line with the "principle of least privilege" — the system grants only the minimum capability necessary to complete the task, and each exercise of that capability requires reauthorization. For irreversible operations such as writing files, sending requests, or touching databases, pre-approval can effectively prevent actual harm caused by model hallucination or prompt injection.

The Collaborative Logic of the Three Primitives

Looking at these three primitives together, MCP's design approach becomes clear. Resources provide the model with a factual foundation, prompts provide the model with behavioral norms, and tools provide the model with a means of action. Once the three are standardized, AI gains immense operational capability, but real control remains safely in the hands of human users.

For developers building AI applications, understanding this layering helps make better architectural decisions: what information should be injected through resources, what instructions should be solidified as prompt templates, and what actions must go through the tools channel with approval workflows configured. The value of MCP lies not in how powerful any single primitive is, but in how it uses a unified set of conventions to break down the interaction between AI and external systems into controllable, auditable, and authorizable modules.

One-line Summary

MCP standardizes AI-external interaction with three primitives — resources, prompts, and tools — and safeguards execution authority with human-in-the-loop.

Paragraph Summary

The article explains the three core primitives of MCP (Model Context Protocol) and how they divide responsibilities. Resources are read-only data that deterministically and without side effects inject documents and other information into the model's context; prompts are reusable instruction templates that transform prompt engineering from manual work into a versionable, manageable asset; tools are executable functions that the model can autonomously trigger to perform active operations such as querying databases, calling APIs, and writing files. Among the three, tools are the most powerful and also the most dangerous, so MCP mandates explicit human-in-the-loop permission before tool execution, keeping ultimate control in human hands. The article argues that this layered design of "open capabilities + tightened permissions" makes AI-external interaction controllable, auditable, and authorizable, providing developers with a clear basis for architectural decisions.