MCP (Model Context Protocol)

1. Concept Overview & Systemic Problem

Before the introduction of the MCP protocol, the ecosystem of agent tools suffered from the classic $N \times M$ incompatibility problem:

1. Fragmentation of Adapters: If you have 5 AI clients (Cursor, Claude Desktop, Continue, internal CLI agent, web interface) and 10 data sources (PostgreSQL, GitHub, Slack, Sentry, local file system), engineers had to create and maintain 50 separate integration connectors.
2. Leakage of Sensitive Keys: Client applications required passing direct API tokens into their context, increasing the attack surface.
3. Lack of Unified Resource Typing: There was no standard for how a model should receive passive data (documents for reading) separately from active actions with side effects (mutations in the database).

Model Context Protocol (MCP) addresses this issue analogously to the Language Server Protocol (LSP) in the IDE world: it is the "USB-C for artificial intelligence," unifying interaction between AI clients and backend tools through an open JSON-RPC 2.0 protocol.

2. Architectural Taxonomy & Mental Model

The MCP protocol is based on a clear client-server distribution and operates with three main primitives:

• 1. Tools (Active Tools with Side Effects): Executable functions that the model can invoke to change the state of the external world (executing an SQL query, triggering a build, sending a comment on GitHub). They are described through a strict JSON Schema.
• 2. Resources (Passive Data Sources for Reading): URI-addressable data without side effects, passed into the model context as documents (file contents, server logs, table schemas, documentation).
• 3. Prompts (Interaction Templates): Pre-parameterized prompts and contextual chains that the server offers to the client (e.g., a ready-made instruction for vulnerability auditing or migration generation).
• 4. Transport Layer:
  • stdio: running the server as a child process on the same machine. It does not require network ports and has zero latency overhead.
  • SSE (Server-Sent Events): operating over HTTP/HTTPS, allowing connection to remote corporate microservices and cloud agents.

3. Technical Pipeline & Internal Mechanics

The session lifecycle under the MCP protocol goes through 4 stages:

1. Handshake & Capabilities Negotiation: The client sends an initialize request, declaring its capabilities (e.g., support for notifications or root folders). The server responds with a list of its capabilities (Tools, Resources, Prompts) and the protocol version.
2. Dynamic Discovery: The client requests manifests via tools/list or resources/list. The received descriptions of functions and parameters are automatically translated into Function Calling format for the target LLM.
3. Execution & Context Invocation: When the model generates a function call, the client transmits it in a tools/call request to the corresponding MCP server with validated JSON parameters.
4. Result Streaming & State Notification: The server executes the action locally, using its own secure configurations (without passing passwords to the client), and returns the result in the format of text, images, or embedded resources.

4. Production Engineering Scenarios

01. Secure Access to Production Database

An MCP server for PostgreSQL runs inside a closed VPC perimeter. It exposes only the execute_read_only_query tool to Cursor or Claude Code. The agent can analyze the schema and optimize slow queries without direct access to the database password and without deletion rights.

02. Unified Local Developer Toolkit

An MCP server written once for interacting with corporate GitLab, internal Jira, and Datadog metrics service connects simultaneously to the CLI terminal (Claude Code), graphical editor (Cursor), and automated GitHub Actions.

03. Browser Automation with Puppeteer/Playwright

The MCP server controls a headless browser, providing the client with navigate_to, click_element, take_screenshot tools. The agent autonomously tests interfaces and validates design without needing to connect heavy third-party plugins.

5. Pitfalls, Common Mistakes & Security

• Context Bloat: Connecting 15 MCP servers with hundreds of detailed JSON schemas can consume 30,000+ tokens before the user types the first word. Use dynamic filtering or lazy loading of tools (Dynamic Tool Selection).
• Risk of Arbitrary Code Execution: The local MCP server runs with full permissions of your OS account. Running unverified servers via npx -y without checking the source code can lead to theft of local SSH keys.
• Protocol Contract Violation through Logging: Using standard console.log() or print() within server code corrupts the stdout channel in stdio transport. Write diagnostics exclusively to stderr.