What Is the Model Context Protocol (MCP)? A Complete Guide to AI Tool Standards

The Model Context Protocol (MCP) is a JSON-RPC 2.0-based specification that standardizes how large language models (LLMs) discover and invoke tools, resources, and prompts, eliminating the need for custom integrations across different AI providers.

The Model Context Protocol (MCP) has emerged as the de-facto standard for connecting AI assistants to external systems. According to the rohitg00/ai-engineering-from-scratch curriculum, MCP replaces the fragmented pre-2025 landscape where each LLM provider required unique tool schemas, forcing developers to rewrite integrations repeatedly. This protocol enables a single server implementation to serve Anthropic, OpenAI, Google, and other compatible hosts through a unified interface.

What Is the Model Context Protocol (MCP)?

MCP is a JSON-RPC 2.0-based specification that defines a standardized way for AI hosts to interact with external capabilities. Before MCP, developers maintained separate integrations for each provider's function-calling format. As implemented in phases/11-llm-engineering/14-model-context-protocol/docs/en.md, the protocol establishes a common language for exposing three primitive capabilities that servers can advertise to LLM clients.

The protocol operates through a handshake mechanism where the client (such as Claude Desktop, ChatGPT, or Cursor) sends an initialize request to advertise its capabilities. The server responds with its version and supported primitives, after which the client can discover available features via standardized endpoints like tools/list, resources/list, and prompts/list.

The Three Core MCP Primitives

MCP servers expose functionality through three distinct primitives, each serving a specific purpose in the AI workflow.

Tools

Tools represent callable functions that perform actions such as add, delete_user, or querying databases. Each tool is defined by a JSON Schema describing its input arguments, along with a name, description, and optional destructiveHint flag indicating potentially dangerous operations. When an LLM decides to use a tool, the client invokes it via the tools/call method.

Resources

Resources provide read-only data addressed by URI schemes (e.g., config://app, file://logs). Unlike tools, resources are passive data sources that the model can read via resources/read requests. Examples include configuration files, database rows, or API responses that provide context without executing side effects.

Prompts

Prompts are reusable templated strings that function as shortcuts for common tasks. A server might expose a code_review prompt that renders a formatted instruction asking the model to review code for correctness and style. Clients retrieve these via prompts/get when the user triggers specific workflows.

Transport Options and Architecture

The MCP specification supports multiple transport mechanisms to accommodate different deployment scenarios.

Transport Methods

• stdio: Ideal for local development and CLI tools, using standard input/output streams for JSON-RPC messages
• WebSocket: Suitable for real-time bidirectional communication between browser-based clients and servers
• Streamable HTTP: The production-grade default introduced in the 2025-06-18 spec revision, using stateless POST requests with optional Server-Sent Events for streaming

According to phases/11-llm-engineering/14-model-context-protocol/docs/en.md, Streamable HTTP is the recommended transport for remote deployments because it scales horizontally behind load balancers without maintaining persistent connections.

Capability Negotiation

During the initialize handshake, servers advertise which primitives they support (tools, resources, prompts, plus optional logging and roots). Hosts may request only a subset of capabilities, enabling fine-grained permission control where certain integrations expose only read-only resources while others enable full tool access.

Safety Mechanisms

MCP enforces three mandatory safety patterns as documented in the curriculum:

1. Allow-lists for file-system roots that restrict which directories servers can access
2. Human-in-the-loop confirmation for destructive tools marked with destructiveHint
3. Tool-poisoning defenses that treat resource content as untrusted input

MCP Implementation in ai-engineering-from-scratch

The rohitg00/ai-engineering-from-scratch repository provides comprehensive coverage of MCP across two major curriculum phases.

Lesson 14: Model Context Protocol Fundamentals

Located in phases/11-llm-engineering/14-model-context-protocol/, this lesson covers the theoretical foundations and basic implementation. The documentation at phases/11-llm-engineering/14-model-context-protocol/docs/en.md explains the handshake process, primitive definitions, and transport configurations. The accompanying reference code in phases/11-llm-engineering/14-model-context-protocol/code/main.py demonstrates both server implementation and in-process client usage.

Capstone Project 13: Production MCP Server

For advanced deployment scenarios, phases/19-capstone-projects/13-mcp-server-with-registry/ provides enterprise-grade patterns. The documentation at phases/19-capstone-projects/13-mcp-server-with-registry/docs/en.md covers OAuth 2.1 authentication, OPA policy enforcement, and registry management. The outcome artifact at phases/19-capstone-projects/13-mcp-server-with-registry/outputs/skill-mcp-server.md describes production deployment architectures.

Building Your First MCP Server

The following example from phases/11-llm-engineering/14-model-context-protocol/code/main.py shows a minimal MCP server using the FastMCP framework:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("demo-server")

@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two integers."""
    return a + b

@mcp.resource("config://app")
def app_config() -> str:
    """Return the app's current JSON config."""
    return '{"env":"prod","region":"us-east-1"}'

@mcp.prompt()
def code_review(language: str, code: str) -> str:
    """Review code for correctness and style."""
    return f"You are a senior {language} reviewer. Review:\n\n{code}"

if __name__ == "__main__":
    mcp.run(transport="stdio")

To interact with this server programmatically without external dependencies, you can use an in-process client:

client = MCPClient(server)                # server is the MCPServer instance above

init = client.request("initialize", {"protocolVersion": PROTOCOL_VERSION})
print(f"Connected to {init['serverInfo']['name']}")

tools = client.request("tools/list")["tools"]
print(f"Discovered tools: {[t['name'] for t in tools]}")

result = client.request("tools/call", {"name": "add", "arguments": {"a": 40, "b": 2}})
print("add(40,2) →", result["content"][0]["text"])

For remote deployment, switch to Streamable HTTP transport:

# In the server entrypoint

mcp.run(transport="streamable-http", host="0.0.0.0", port=8765)

# Host configuration (JSON file read by Claude Desktop / Claude Code)

{
  "mcpServers": {
    "demo": {
      "type": "http",
      "url": "https://tools.example.com/mcp"
    }
  }
}

Summary

• Model Context Protocol (MCP) is a JSON-RPC 2.0 specification that standardizes tool, resource, and prompt exposure across LLM providers
• Three primitives define the protocol: Tools (callable functions), Resources (read-only data), and Prompts (reusable templates)
• Transport flexibility allows local development via stdio and production deployment via Streamable HTTP
• Safety mechanisms include allow-lists, destructive hints, and content sanitization
• rohitg00/ai-engineering-from-scratch covers MCP in Lesson 14 (fundamentals) and Capstone Project 13 (production with OAuth and registry)

Frequently Asked Questions

What is the Model Context Protocol (MCP) used for?

MCP enables AI assistants to discover and interact with external tools and data sources through a standardized interface. It allows developers to build server integrations once and have them work across multiple LLM hosts including Claude Desktop, ChatGPT, Cursor, and other MCP-compatible clients without rewriting integration logic for each platform.

How does MCP differ from traditional function calling?

Traditional function calling requires custom JSON schemas for each LLM provider, forcing developers to maintain separate integrations for Anthropic, OpenAI, and Google. MCP replaces this fragmentation with a unified JSON-RPC 2.0 protocol where type hints automatically generate JSON Schema definitions, and the same server implementation serves all compatible hosts through capability negotiation.

What transport methods does MCP support?

MCP supports three transport mechanisms: stdio for local CLI-based development, WebSocket for real-time browser communication, and Streamable HTTP for production deployments. The 2025-06-18 spec revision made Streamable HTTP the default for remote servers because it enables stateless, horizontally scalable architectures behind standard load balancers.

Where can I learn to build production MCP servers?

The rohitg00/ai-engineering-from-scratch repository provides comprehensive MCP education through phases/11-llm-engineering/14-model-context-protocol/ for fundamentals and phases/19-capstone-projects/13-mcp-server-with-registry/ for production patterns. The capstone covers OAuth 2.1 authentication, OPA policy enforcement, and registry management for enterprise deployments.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}