Basics: Context Engineering with MCP

Basics · Topic 01

What is Context Engineering?

The discipline isn't about writing better prompts. It's about designing the entire information environment an AI operates in — what it knows, from where, when, and in what form.

💡 The Analogy

A new employee's first day performance depends entirely on what you've told them before they walk in the door — their role, the customer context, the company rules, the tools at their desk.

You wouldn't hand them a generic instruction sheet and hope for the best. You'd engineer their context: briefing document, system access, a mentor's notes, live dashboards. Context Engineering does the same for AI — systematically, programmatically, at scale.

✍️

Prompt Engineering

What to Say

Crafting the right question or instruction in a single conversation turn. Reactive, manual, rewritten every time. Breaks at scale when AI needs live, dynamic data.

🧠

Context Engineering

What It Knows

Designing the full information architecture — tools available, data accessible, memory maintained, instructions enforced. Proactive, programmatic, consistent across every session.

⚡

Why It Matters

Reliability at Scale

Demos work on good prompts. Production systems work on engineered context. The difference between a clever chatbot and an enterprise AI agent is how context is architected.

🎯

The Core Insight

Context Engineering = controlling what the model knows (data in), how it acts (tools available), and what it remembers (memory & state). MCP provides the infrastructure to do all three programmatically.

Scenario	Prompt Only	Context Engineered
Customer query arrives	Write prompt with account details manually	MCP Resource auto-fetches live account data
AI needs to check GitHub	Paste PR content into prompt by hand	MCP Tool calls GitHub API in real-time
Team needs consistent instructions	Each person rewrites the system prompt differently	Versioned MCP Prompt template — one source of truth
Context goes stale	User has to paste updated docs every session	MCP Resource subscription pushes live updates

Basics · Topic 02

MCP: The Context Delivery Protocol

The Model Context Protocol (MCP) is an open standard published by Anthropic in November 2024. It defines a universal, vendor-neutral way for AI models to interact with tools, data sources, and instruction templates — programmatically and securely.

💡 The Analogy

Just as USB-C unified device connectivity — one standard port, countless compatible devices — MCP unifies how AI connects to the world. Build one MCP server for GitHub, and any MCP-compatible AI (Claude, GPT-4, Gemini) can use it.

No more bespoke integrations. No more fragile glue code. One protocol, infinite interoperability.

📋

Wire Format

JSON-RPC 2.0

All MCP messages are JSON-RPC 2.0 requests and responses. Each message has an id, method, and params. Lightweight, human-readable, language-agnostic.

🌐

Open Standard

Vendor-Neutral

MCP is not a proprietary Anthropic feature. Any LLM can implement MCP. OpenAI, Google DeepMind, and hundreds of open-source projects have adopted it — it's the HTTP of AI integration.

🔒

Security First

Permission-Scoped

AI only accesses what the server explicitly exposes. Capabilities are declared up-front during handshake. OAuth 2.0 support means enterprise-grade access control from day one.

        JSON-RPC 2.0
        MCP tool call — the actual wire message
      
// Every MCP message follows this shape
{
  "jsonrpc": "2.0",
  "id": "req-001",           // Unique request ID for correlation
  "method": "tools/call",   // MCP method: tools/call, resources/read, etc.
  "params": {
    "name": "search_github_issues",
    "arguments": {
      "repo": "anthropics/mcp",
      "state": "open",
      "label": "bug"
    }
  }
}

Basics · Topic 03

The Three-Tier MCP Architecture

Every MCP ecosystem has three layers. Understanding which layer does what is the single most important mental model in context engineering with MCP.

🖥️

HOST APPLICATION

Claude Desktop, VS Code, your custom app — what the user interacts with

MCP Protocol (JSON-RPC 2.0)

🔌

MCP CLIENT

Embedded inside the host — manages server connections, routes messages, handles auth

Stdio · HTTP+SSE · Streamable HTTP

⚙️

MCP SERVER

Your code — exposes Tools, Resources, and Prompts to the AI

Native APIs / SDKs

🗄️

THE WORLD

Databases, file systems, APIs, services — the live data your AI context needs

🏠

Layer 1

Host Application

The user-facing application that contains an AI model. It owns the conversation, decides what to show users, and delegates context retrieval to its embedded MCP Client. You interact with the Host; the Host talks to MCP.

🔌

Layer 2

MCP Client

Lives inside the Host. Manages the lifecycle of MCP server connections, routes tool/resource/prompt requests to the right server, handles protocol negotiation, and aggregates results back to the Host.

⚙️

Layer 3

MCP Server

Your code. A lightweight process that declares its capabilities (which Tools, Resources, and Prompts it offers) and executes requests from the Client. This is where Context Engineering work happens.

💡 The Restaurant Analogy

The Host is the dining room — where guests (users) experience everything. The Client is the waiter — takes orders and routes them. The Server is the kitchen — executes the actual work. You build the kitchen.

Basics · Topic 04

Context Window Mechanics

Every LLM has a finite token budget — the "context window." Context Engineering is fundamentally about being strategic with what earns a spot inside it. Overflow means lost context, hallucination, and degraded performance.

Context Window Token Budget — Visualized

System

Retrieved Context (MCP Resources)

Tool Results

History

⚠ Overflow

System Instructions (~2k tokens)

Retrieved Context — MCP Resources (~12k tokens)

Tool Call Results (~6k tokens)

Conversation History (~8k tokens)

Overflow — dropped or truncated

The CE Principle: Never stuff the full context window statically. Use MCP Resources to retrieve only what's relevant to the current task — dynamically, on demand — so the window is always used efficiently.

📥

Strategy 1

Retrieval on Demand

Use MCP Resources to fetch only the documents, records, or data chunks relevant to the current query. Don't pre-load everything — let the AI ask for what it needs via Tools and Resources.

✂️

Strategy 2

Summarize, Don't Inject

Long documents should be summarized server-side before being returned as Resource content. Send the AI the insight, not the raw 50-page PDF. Context density beats context volume.

🗂️

Strategy 3

Hierarchical Retrieval

Index your data at multiple granularities. The AI first retrieves a high-level summary (cheap), then drills into specific sections (targeted) — saving tokens and improving answer accuracy.

Basics · Topic 05

The Three MCP Context Primitives

MCP exposes exactly three types of context primitives. Together they cover everything an AI needs: the ability to act, the ability to read, and consistent instructions. Learn these deeply — they're the entire vocabulary of the protocol.

🔧

Tools

AI's Hands

Callable functions the AI invokes when it needs to do something. Search the web, run SQL, send an email, file a GitHub issue. Tools are actions with JSON Schema inputs — the AI decides when to call them; your server decides what happens.

📂

Resources

AI's Eyes

Read-only structured data the AI can access via URI-based addressing. Files, database records, API responses, live metrics. Resources are how you serve context to the AI — dynamically and on demand, not pre-stuffed in prompts.

💬

Prompts

AI's Playbook

Server-side prompt templates with dynamic arguments. Version your instructions, share them across teams, enforce consistent AI behavior organization-wide. Prompts as a first-class artifact — no more prompt drift.

🧩

Mental Model: Tools Act, Resources Inform, Prompts Guide

If the AI needs to do something → Tool. If it needs to know something → Resource. If it needs consistent instructions → Prompt. These three primitives compose into any context engineering architecture you need.

Basics · Topic 06

Stdio Transport: Local Context First

Before deploying remote MCP servers, start local. The Stdio transport runs your MCP server as a child process — your host app launches it and communicates via stdin/stdout pipes. No networking, no auth overhead, just clean bidirectional messaging.

🚀

Benefit 1

Zero Setup Friction

No ports, no TLS certificates, no OAuth configuration. Claude Desktop spawns your server binary directly. Ship your first working context system in minutes, not hours.

🔒

Benefit 2

Process Isolation

Each MCP server runs in its own process. A crash in your server doesn't crash the host. Permissions are inherited from the user's shell — natural sandboxing out of the box.

🔄

Benefit 3

Fast Iteration

Change your server code → restart the host connection → immediately test the new context behavior. The tight feedback loop makes Stdio the perfect development transport.

        JSON5 · Claude Desktop Config
        ~/Library/Application Support/Claude/claude_desktop_config.json
      
// Wire your MCP server to Claude Desktop via Stdio
{
  "mcpServers": {
    "my-context-server": {
      "command": "node",
      "args": ["/absolute/path/to/server/dist/index.js"],
      "env": {
        "NODE_ENV": "production"
      }
    }
  }
}

Basics · Topic 07

Your First MCP Server

Theory is finished. Here's the complete, working TypeScript MCP server that registers a context-aware Tool — your entry point into Context Engineering with MCP. Every concept from this page shows up here in code.

        TypeScript
        src/index.ts — Complete Basics MCP Server
      
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

// ─── 1. Create the MCP Server (the "kitchen") ───────────────────────────────
const server = new McpServer({
  name: "my-context-server",
  version: "1.0.0",
});

// ─── 2. Register a Tool (AI's "hands") ──────────────────────────────────────
server.tool(
  "get_project_status",
  "Fetch the current status of a project from our internal tracker",
  {
    project_id: z.string().describe("The unique project identifier"),
  },
  async ({ project_id }) => {
    // Your real logic here — DB query, API call, file read, etc.
    const status = await fetchProjectStatus(project_id);
    return {
      content: [{ type: "text", text: JSON.stringify(status, null, 2) }],
    };
  }
);

// ─── 3. Register a Resource (AI's "eyes") ───────────────────────────────────
server.resource(
  "team-guidelines",
  "context://team/engineering-guidelines",
  async (uri) => ({
    contents: [{
      uri: uri.href,
      mimeType: "text/markdown",
      text: await readGuidelinesDoc(),   // returns your doc content
    }],
  })
);

// ─── 4. Register a Prompt (AI's "playbook") ─────────────────────────────────
server.prompt(
  "code-review",
  "Standard engineering code review checklist prompt",
  [{ name: "pr_url", description: "The GitHub PR URL to review" }],
  ({ pr_url }) => ({
    messages: [{
      role: "user",
      content: { type: "text", text: `Review the PR at ${pr_url}.
Check: correctness, performance, security, test coverage.
Use our engineering guidelines resource for standards.` },
    }],
  })
);

// ─── 5. Connect via Stdio transport and start listening ─────────────────────
const transport = new StdioServerTransport();
await server.connect(transport);

console.error("Context Engineering MCP Server running via stdio ✓");

✅

What This Server Does

In ~50 lines, you've given an AI Tools it can call (get project status), Resources it can read (team guidelines doc), and a Prompt template it can invoke (code review checklist). This is a complete, functional context engineering system. Ship it, connect it to Claude Desktop, and watch context come to life.

        Shell
        Getting started in 3 commands
      
# 1. Install the MCP SDK and Zod
npm install @modelcontextprotocol/sdk zod

# 2. Compile TypeScript
npx tsc

# 3. Add to Claude Desktop config and restart — you're live
# (See Topic 06 above for the config JSON)

Context Engineering
with MCP: The Foundations

What is Context Engineering?

What to Say

What It Knows

Reliability at Scale

The Core Insight

MCP: The Context Delivery Protocol

JSON-RPC 2.0

Vendor-Neutral

Permission-Scoped

The Three-Tier MCP Architecture

Host Application

MCP Client

MCP Server

Context Window Mechanics

Retrieval on Demand

Summarize, Don't Inject

Hierarchical Retrieval

The Three MCP Context Primitives

Mental Model: Tools Act, Resources Inform, Prompts Guide

Stdio Transport: Local Context First

Zero Setup Friction

Process Isolation

Fast Iteration

Your First MCP Server

What This Server Does

🌱 Basics Complete

Context Engineeringwith MCP: The Foundations

What is Context Engineering?

What to Say

What It Knows

Reliability at Scale

The Core Insight

MCP: The Context Delivery Protocol

JSON-RPC 2.0

Vendor-Neutral

Permission-Scoped

The Three-Tier MCP Architecture

Host Application

MCP Client

MCP Server

Context Window Mechanics

Retrieval on Demand

Summarize, Don't Inject

Hierarchical Retrieval

The Three MCP Context Primitives

Mental Model: Tools Act, Resources Inform, Prompts Guide

Stdio Transport: Local Context First

Zero Setup Friction

Process Isolation

Fast Iteration

Your First MCP Server

What This Server Does

🌱 Basics Complete

Context Engineering
with MCP: The Foundations