MCP Core Concepts Explained – Resources, Tools, and Prompts

In the previous article, we established a key idea: models do not manage context, systems do. This article goes one level deeper and explains how MCP structures that responsibility through three core primitives: resources, tools, and prompts.

Understanding these components clearly is essential. Most MCP design mistakes happen when teams blur the boundaries between them.

MCP Architecture at a Glance

At a conceptual level, MCP introduces a clean separation of concerns:

• Systems expose context and capabilities
• Models reason over provided context
• MCP defines the contract between the two

Instead of embedding everything into a prompt, MCP makes context explicit, discoverable, and governed.

Resources: Structured Read Only Context

What Is a Resource?

A resource is a read only piece of contextual information that the model can consume.

Resources answer a single question:

Examples include:

• User profile data
• Application configuration
• Feature flags
• Database query results
• CI or deployment metadata

Resources are not actions. They do not change state.

Key Characteristics of Resources

Resources are:

• Readable through a URI, even when the underlying data changes
• Typed and structured
• Discoverable via MCP
• Owned by the system

The host chooses which resource content to include in the model context. The resource specification describes this application-driven interface.

Example Resource Definition

COPY
{
  "uri": "profile://current-user",
  "name": "user_profile",
  "description": "Basic user account information",
  "mimeType": "application/json"
}

The important detail here is not the format, but the intent: the system decides what exists and what is exposed.

When to Use a Resource

Use a resource when:

• Data is factual
• Data should not be modified by the model
• Multiple models may need the same context
• Auditing and versioning matter

A URI-based read fits a resource. An argument-based lookup can instead fit a read-only tool; the next article demonstrates this with get_stock(sku).

Tools: Controlled Actions

What Is a Tool?

A tool represents an action the model is allowed to request.

Tools answer the question:

Examples:

• Create a ticket
• Trigger a deployment
• Send an email
• Write data to a system
• Call an internal API

Tools expose operations through a defined interface. The application, server, and downstream service must implement validation and authorization; the protocol does not make an operation safe by itself.

Why Tools Matter

MCP tools formalize discovery and invocation through a shared protocol. An application can also implement direct tool bindings without MCP. In either design, execution happens in application or service code.

Example Tool Definition

COPY
{
  "name": "create_incident",
  "description": "Create a production incident ticket",
  "inputSchema": {
    "type": "object",
    "properties": {
      "severity": { "type": "string" },
      "summary": { "type": "string" }
    },
    "required": ["severity", "summary"]
  }
}

This ensures:

• Clear input contracts
• Validation before execution
• Auditable execution paths

When to Use a Tool

Use a tool when:

• A lookup, search, calculation, or state change needs explicit arguments
• External systems are affected
• Permissions matter
• Execution must be logged or approved

If something changes the world, it is a tool.

Prompts: Reusable Instructions

What Is a Prompt in MCP?

In MCP, prompts are first class entities, not inline text blobs.

Prompts answer the question:

Examples:

• System role definitions
• Task instructions
• Output formatting rules
• Domain constraints

Why Prompts Should Be Externalized

Prompts stored in code can be version-controlled and reused. MCP adds a standard way for clients to discover and retrieve templates with arguments. The host decides how to use the returned messages; a server prompt does not override the host's policy. See the prompt specification.

Conceptual Prompt Content

The following illustrates a template, not the wire format of a prompt listing response:

COPY
{
  "name": "support_agent_prompt",
  "description": "Guidelines for handling customer support tickets",
  "content": "You are a professional support agent. Be concise, factual, and polite."
}

This allows:

• Central updates
• Environment specific prompts
• Safer experimentation

How Resources, Tools, and Prompts Work Together

A well designed MCP interaction looks like this:

1. The host reads relevant resources and selects context.
2. A user or application retrieves a prompt template when useful.
3. The host routes requested tool calls to the server and returns results to the model.

Each component has a clear responsibility.

This separation:

• Reduces hallucinations
• Improves predictability
• Simplifies debugging

Stateless Models, Stateful Systems

One of MCP’s most important design principles is acknowledging reality:

• Models are stateless
• Systems are stateful

MCP bridges this gap without pretending models understand system state. State always lives outside the model.

Common Beginner Mistakes

Some frequent issues seen in early MCP implementations:

• Assuming readable resources never change or that all tools perform writes
• Encoding business logic inside prompts
• Exposing too many tools
• Allowing tools to return unstructured responses
• Treating MCP as just another function calling layer

Avoiding these mistakes early saves significant rework later.

Conclusion

Resources, tools, and prompts are simple concepts individually, but powerful when combined correctly.

MCP succeeds not because it is complex, but because it enforces discipline:

• Data is data
• Actions are actions
• Instructions are instructions

In part 3, building your first MCP server, we implement these primitives as inventory://catalog, a read-only get_stock tool, and a stock_question prompt. A local client verifies each capability without an LLM. That gives us a concrete example to carry into part 4, client responsibilities.

Once you understand the primitives, implementation becomes straightforward.