Understanding Context Components

Learning Objectives

By the end of this lesson, you will be able to:

• Identify the three capabilities an MCP server can expose: Tools, Resources, and Prompts
• Explain the purpose of each capability and when a server would use it
• Read and write simple examples of each component
• Understand how an AI client discovers what a server offers before using it

Prerequisites

• Completed: Introduction to MCP
• Understanding of basic JSON structure
• Familiarity with basic AI prompting concepts

The Three Building Blocks of an MCP Server

Every MCP server, no matter what system it connects to, exposes its capabilities through the same three building blocks:

1. Tools 🔧 - Functions the AI agent can call to take action
2. Resources 📄 - Data the AI agent can read for context
3. Prompts 📝 - Reusable instruction templates the server provides

A single server can expose one, two, or all three. A GitHub server, for example, might offer tools to create issues, resources to read repository files, and a prompt template to summarize a pull request. Let's look at each one closely.

1. Tools 🔧

Purpose: Let the AI agent perform an action or fetch dynamic information by calling a function.

Think of a Tool as a button the AI is allowed to press. Each tool has a name, a description telling the AI what it does and when to use it, and an input schema defining what parameters it accepts. The agent decides, based on the conversation, when a tool is relevant, calls it with specific arguments, and gets a result back to reason over.

Basic Tool Structure

{
  "name": "search_slack",
  "description": "Search Slack messages by keyword and optional channel",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "channel": { "type": "string", "description": "optional" }
    },
    "required": ["query"]
  }
}

Agent uses it:

Agent: "Find mentions of 'budget' in Slack"
→ Calls: search_slack({ "query": "budget" })
→ Gets: [list of messages]
→ Responds to user with findings

Real-World Tool Examples

Example 1: Creating a GitHub issue

{
  "name": "create_issue",
  "description": "Open a new issue in a GitHub repository",
  "inputSchema": {
    "type": "object",
    "properties": {
      "repo": { "type": "string" },
      "title": { "type": "string" },
      "body": { "type": "string" }
    },
    "required": ["repo", "title"]
  }
}

Example 2: Querying a database

{
  "name": "query_customers",
  "description": "Query the customers table with an optional status filter",
  "inputSchema": {
    "type": "object",
    "properties": {
      "status": { "type": "string", "enum": ["active", "inactive", "trial"] },
      "limit": { "type": "number", "default": 10 }
    }
  }
}

Why Tools Matter

• Action, not just answers: Tools let an agent do something in the real world - send a message, file a ticket, update a record - instead of just describing what to do.
• Structured input: The input schema tells the agent exactly what arguments are valid, which cuts down on malformed requests.
• Reusable across clients: Any MCP client (Claude Desktop, a custom agent, another AI platform) can call the same tool the same way.

2. Resources 📄

Purpose: Give the AI agent read access to data it can pull into context - without that data being a callable action.

Think of a Resource as a labeled document on a shelf. Each resource has a URI (a unique address), a name, and a MIME type describing its format. The agent (or the person using it) can ask to read a resource, and the server returns its current contents.

Basic Resource Structure

{
  "uri": "slack://channels/general/messages",
  "name": "General channel messages",
  "mimeType": "application/json"
}

Real-World Resource Examples

Example 1: API documentation

{
  "uri": "docs://api-reference",
  "name": "API Reference",
  "mimeType": "text/markdown"
}

A client can read this resource to pull the current API docs directly into the conversation, so the agent answers questions with the real, up-to-date reference instead of guessing from training data.

Example 2: A file on disk

{
  "uri": "file:///Users/alex/projects/notes.md",
  "name": "notes.md",
  "mimeType": "text/markdown"
}

The filesystem MCP server exposes files this way, letting an agent read project notes, config files, or logs on request.

Tools vs. Resources: What's the Difference?

It's easy to mix these up at first, so here's the distinction that matters:

	Tools	Resources
What it does	Performs an action or computation	Returns readable data
Has side effects?	Often (send, create, update, delete)	No - reading a resource shouldn't change anything
Analogy	A button you press	A document you open
Example	search_slack(query)	slack://channels/general/messages

A good rule of thumb: if calling it changes something or requires parameters to compute a result, it's a Tool. If it just hands you data by address, it's a Resource.

3. Prompts 📝

Purpose: Give the AI (or the user) a pre-written, reusable instruction template for a common task, so nobody has to retype the same detailed instructions every time.

Think of a Prompt as a saved template with blanks to fill in. The server defines the template's name, description, and the arguments it accepts; the client fills in those arguments and hands the fully assembled instructions to the model.

Basic Prompt Structure

{
  "name": "analyze_thread",
  "description": "Analyze a Slack thread for action items",
  "arguments": [
    { "name": "thread_url", "description": "URL of the Slack thread", "required": true }
  ]
}

Real-World Prompt Examples

Example 1: Feedback analysis

{
  "name": "analyze_user_feedback",
  "description": "Analyze customer feedback for themes and sentiment",
  "arguments": [
    { "name": "feedback_source", "description": "Where the feedback came from", "required": true }
  ]
}

Selecting this prompt and filling in feedback_source hands the agent a consistent, well-tested set of instructions: read the feedback, identify themes, categorize it, score sentiment, and summarize - the same steps every time, without the user having to write them out.

Example 2: Code review

{
  "name": "review_pull_request",
  "description": "Review a pull request for security issues and best practices",
  "arguments": [
    { "name": "pr_url", "description": "URL of the pull request", "required": true }
  ]
}

Why Prompts Matter

• Consistency: Everyone using the server gets the same well-crafted instructions for a given task, instead of reinventing the wording each time.
• Discoverability: Prompts show up as selectable options in the client, so users don't need to know the "right" way to ask.
• Server-owned expertise: The team that built the server can encode their domain knowledge (e.g., "always check for SQL injection first") directly into the prompt template.

How a Client Discovers a Server's Capabilities

Before an AI client like Claude Desktop can use a server, it needs to know what that server offers. This happens through a simple discovery step when the connection is established, often called capability negotiation.

At a conceptual level, here's what happens:

1. Connect: The client opens a connection to the MCP server.
2. List capabilities: The client asks the server "what do you have?" - conceptually, this is a tools/list, resources/list, and prompts/list request for each capability type.
3. Server responds: The server returns the full list of tools (with their schemas), resources (with their URIs), and prompts (with their arguments) it currently supports.
4. Client makes them available: Claude Desktop now knows these tools exist and can decide, mid-conversation, when to call one, read a resource, or offer a prompt template.

You don't need to memorize the exact wire format to use MCP effectively - what matters is the mental model: a server advertises what it can do, and the client discovers that list before using any of it. This is also why adding a new tool to a server doesn't require any changes on the client side; the next time the client connects (or refreshes), the new tool simply shows up in the list.

How the Three Components Work Together

Let's see all three working together for a single server: a GitHub MCP server.

{
  "server": "github",
  "tools": [
    { "name": "create_issue", "description": "Open a new issue in a repository" },
    { "name": "search_code", "description": "Search code across repositories" }
  ],
  "resources": [
    { "uri": "github://repo/ai-maniacs/README.md", "name": "README", "mimeType": "text/markdown" }
  ],
  "prompts": [
    { "name": "summarize_pr", "description": "Summarize a pull request's changes and risk level" }
  ]
}

With this one server connected, an agent can:

• Act: Call create_issue to file a bug report
• Read: Pull in github://repo/ai-maniacs/README.md to understand the project before answering a question
• Follow a template: Use the summarize_pr prompt to generate a consistent PR summary every time

Hands-On Exercise: Design a Server's Capabilities

Scenario: You're designing an MCP server for a college study app. Think through what it should expose.

Your task: For each category below, write one realistic example in the same JSON shape used above.

1. A Tool the AI could call to do something (e.g., create a flashcard, schedule a study session)
2. A Resource the AI could read (e.g., a syllabus file, a set of lecture notes)
3. A Prompt the AI could offer as a reusable template (e.g., "quiz me on this chapter")

Try it yourself before checking the solution below.

Exercise Solution

{
  "tools": [
    {
      "name": "create_flashcard",
      "description": "Create a new flashcard for a study deck",
      "inputSchema": {
        "type": "object",
        "properties": {
          "deck": { "type": "string" },
          "front": { "type": "string" },
          "back": { "type": "string" }
        },
        "required": ["deck", "front", "back"]
      }
    }
  ],
  "resources": [
    {
      "uri": "study://courses/cognitive-psych/syllabus",
      "name": "Cognitive Psychology Syllabus",
      "mimeType": "text/markdown"
    }
  ],
  "prompts": [
    {
      "name": "quiz_me",
      "description": "Generate a short practice quiz on a chapter",
      "arguments": [
        { "name": "chapter", "description": "Chapter or topic to quiz on", "required": true }
      ]
    }
  ]
}

Knowledge Check

Test your understanding of MCP's core components:

1. Tools Question: What makes something a Tool rather than a Resource, even if both technically "return data"?
2. Resources Question: Why does a Resource use a URI instead of a function call with parameters?
3. Prompts Question: What problem do server-provided Prompts solve that a user typing their own instructions doesn't?
4. Discovery Question: Why does capability discovery (listing tools, resources, and prompts) happen before the client uses any of them?

What's Next?

Now that you understand the three building blocks of an MCP server, it's time to connect a real one and try it yourself. In the next lesson, we'll walk through installing and using an actual MCP server from Claude Desktop, step by step.

Ready to connect one? Let's set up your First MCP Server →

---

Quick Reference Card

Component	Purpose	Key Question
Tools 🔧	Actions the AI can take	"What can this server do for me?"
Resources 📄	Data the AI can read	"What can this server show me?"
Prompts 📝	Reusable instruction templates	"What common task has the server already scripted for me?"

Remember: A client discovers all three through capability negotiation before it ever uses them - the server always advertises what it offers first.