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:

• Immutable from the model’s perspective
• Typed and structured
• Discoverable via MCP
• Owned by the system

This prevents a common anti pattern where models hallucinate state or attempt to infer missing data.

Example Resource Definition

COPY
{
  "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

If the model should not be able to change it, it belongs in a resource.

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 are how MCP enables safe interaction with real systems.

Why Tools Matter

Without tools, models either:

• Describe actions without executing them, or
• Are given excessive permissions through custom glue code

MCP tools formalize this boundary.

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:

• State changes are involved
• 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

Hardcoded prompts create long term maintenance issues:

• No version control
• No reuse
• No consistency across models

MCP treats prompts like configuration, not code comments.

Example Prompt Definition

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 model reads resources to understand context
2. The model follows prompts to reason correctly
3. The model invokes tools when action is required

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:

• Putting mutable data into resources
• 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 the next article, we will build a real MCP server in Python, step by step, and show how these concepts translate into working code.

Once you understand the primitives, implementation becomes straightforward.