MCP (Model Context Protocol): the standard for connecting AI to external systems

Цели урока

• Understand MCP architecture: client-server model, transport, capabilities
• Create an MCP server with tools and resources from scratch in Node.js
• Learn to define tools with JSON Schema and handle calls
• Implement resources: static, templated, with change subscriptions
• Master production patterns: remote deployment, security, server composition

MCP is USB-C for AI. Before it, every integration was written by hand: Claude + GitHub, Claude + Notion, Claude + DB. After - one protocol, any client. Anthropic open-sourced it in November 2024 - and within 3 months, 1000+ servers appeared. Claude Desktop, Cursor, VS Code, Windsurf - all added support. It's the fastest-growing standard in AI infrastructure ever.

• Claude Desktop + MCP servers: one command - search Jira, check GitHub PRs, post to Slack. No tab-switching
• Cursor uses MCP to connect to companies' internal APIs - an AI assistant with real-time access to production data
• Anthropic published reference MCP servers for PostgreSQL, Google Drive, Puppeteer, Brave Search - ready to use
• Companies build internal MCP servers: AI gets access to internal systems through a single protocol instead of dozens of custom integrations

How MCP came to be

**November 2024**: Anthropic releases MCP as open source - MIT license, open specification. **December 2024**: Claude Desktop adds native support, first 100 community servers appear. **January 2025**: Cursor, Windsurf, VS Code Copilot add MCP support. **February 2025**: 1000+ open-source servers on GitHub. **March 2025**: major companies announce production deployments of internal MCP servers. In 4 months, MCP became the de-facto standard for AI tool integration - faster than any other protocol in the history of developer tools.

Предварительные знания

• Tool Calling / Function Calling: LLMs Controlling External Systems

MCP: a standard protocol for AI integrations

Before November 2024, the world of AI integrations looked like the Tower of Babel. ChatGPT had plugins - one format. LangChain had tools - another. Every startup had its own homebrew schema. N clients x M systems = N x M integrations to write, maintain, and debug from scratch with every update.

**Model Context Protocol (MCP)** is an open standard from Anthropic that broke this logic. One server implements the protocol - and it automatically works with Claude Desktop, Cursor, VS Code, any custom agent. N + M instead of N x M. This is USB-C for AI: one connector, any device.

Under the hood - **JSON-RPC 2.0** over a transport layer. Every message looks like `{"jsonrpc": "2.0", "method": "tools/call", "params": {...}, "id": 1}`. Not a new format - familiar RPC. This matters: Anthropic didn't reinvent the wheel, they took a battle-tested standard and added discovery, versioning, and a security model on top.

Within 3 months of the MCP release, 1000+ open-source servers appeared: for GitHub, Jira, PostgreSQL, Slack, Notion, file systems. Claude Desktop, Cursor, Windsurf, VS Code - all added support. It's the fastest-growing standard in AI infrastructure.

Creating an MCP Server from scratch

An MCP server is a regular Node.js program. No magic: `@modelcontextprotocol/sdk` handles transport and JSON-RPC, the developer only registers capabilities. The entire server code is declarations: what it can do, how to call it, what it returns.

The MCP server lifecycle is a handshake protocol. The client starts the process (stdio) or connects via HTTP. An `initialize` exchange happens - capabilities are shared. Then `tools/list` - the client discovers what the server can do. After that - `tools/call` whenever the AI decides it's needed. All of this is automatic; the developer only registers handlers.

• **Launch** - the client starts the server process (stdio) or connects via HTTP
• **Initialize** - handshake: client and server exchange capabilities
• **List** - client requests tools/list, resources/list, prompts/list
• **Use** - client calls tools/call, resources/read when the AI decides it's needed
• **Shutdown** - client disconnects, server shuts down

**stdio transport is for local servers.** The process is started by the client, communication goes through stdin/stdout. Ideal for development and personal tools. For production and remote access - HTTP+SSE transport.

MCP Tools: defining and handling calls

**Tools** are the main capability of an MCP server. These are functions the AI calls to perform actions: API requests, database writes, command execution. Each tool is defined by a name, description, and JSON Schema of parameters.

Key insight: tool and parameter descriptions are a prompt for the model. Claude decides which tool to call by analyzing exactly this text. A poor description means the model calls the wrong thing, at the wrong time, with the wrong parameters. This isn't a technical problem - it's prompt engineering at the API level.

**Tools perform actions - they have side effects.** Creating tasks, sending emails, writing to DB - these are irreversible operations. In an agentic loop, Claude decides on its own when to call tools. An MCP server with a `delete-database` tool and no confirmation isn't a hypothetical risk - it's a real production scenario. Destructive operations require human-in-the-loop.

MCP Resources: data for AI context

**Resources** are read-only data that an MCP server provides to the client for context. The fundamental difference from tools: resources don't perform actions, they're only read. Files, configurations, database records, documentation - all of these are resources.

The Tools/Resources split isn't just architectural cleanliness - it's a security model. Resources are safe to load into context before a response: they don't change state. Tools are potentially dangerous - they have side effects. Clients like Claude Desktop and Cursor show users different UX patterns for reading vs acting.

**Resource templates** (`tasks://{taskId}`) are a powerful pattern. The AI can request `tasks://PROJ-123` - a specific task, and the template automatically extracts the taskId and loads the data. No need to create a separate resource for each item.

MCP in production: deployment, security, server composition

stdio is for local development. In production, a different class of problems emerges: how to deploy remote servers via HTTP+SSE, how to authenticate clients, how to prevent the AI from calling `delete-database` at 3am without confirmation.

• **Authentication** - Bearer token in HTTP headers. Each client has its own token with limited permissions
• **Tool-level authorization** - not all users can call all tools. Admin tools are for administrators only
• **Input validation** - Zod schemas validate tool parameters before execution. SQL injection through tool parameters is a real threat
• **Rate limiting** - limit tool calls per user. The AI can call a tool 100 times in a loop
• **Audit log** - log every tool call: who, what, when, result. Mandatory for compliance

**AI can call a tool unexpectedly.** In an agentic loop, the model decides which tools to call on its own. An MCP server with a `delete-database` tool and no confirmation is a ticking time bomb. Destructive operations require human-in-the-loop.

MCP is just another way to do tool calling

MCP is a standardized protocol with discovery, versioning, and a security model. Regular tool calling works within a single LLM API request. MCP is inter-process communication with a persistent connection

OpenAI function calling and Anthropic tool use operate at the level of a single inference request: define schema, model decides to call, the host executes, result returns. MCP is a layer above: a separate server process with a lifecycle, dynamic capability discovery via `tools/list`, versioning, authentication, audit trail. Cursor doesn't just know what a tool can do - it knows its version and can select a compatible server. These are different levels of abstraction.

Summary

• MCP is a standard protocol (JSON-RPC 2.0) for connecting AI to external systems: N + M instead of N x M integrations
• An MCP Server exposes 3 capabilities: Tools (actions with side effects), Resources (read-only data), Prompts (templates)
• Tool and parameter descriptions are a prompt for the AI - precision here determines whether the model picks the right tool
• Resources are read-only data: static URIs or templates (tasks://{taskId}) for dynamic loading
• Production: HTTP+SSE transport, Bearer auth, rate limiting, audit log, human-in-the-loop for destructive operations

Вопросы для размышления

• Which internal systems in a current or past project could be connected to AI via MCP? What would that change about the team's daily workflow?
• How does an MCP server differ from a regular REST API from a security standpoint - what threats are specific to AI-driven calls?
• Under what conditions is it worth building a custom MCP server vs using an existing one from the open-source registry?

What's Next

MCP is a protocol. Now it's time to look at how AI coding assistants (Copilot, Cursor, Claude Code) use MCP and similar patterns for IDE and codebase integration.

• AI Coding Assistants from the Inside — Cursor and Claude Code use MCP to connect to developer tools
• Autonomous Agents — MCP servers as tools for autonomous agents - Devin, SWE-Agent connect to systems via MCP

Связанные уроки

• aie-16-tool-calling — MCP standardizes the tool-calling interface
• aie-46-ai-coding-assistants — Coding assistants consume MCP servers
• aie-44-ai-backend-node — Backend implements an MCP server
• aie-17-agent-fundamentals — Agents gain tools through MCP
• net-54-rpc — Standardized client-server capability calls
• sd-10-microservices