Skip to main content

Model Context Protocol (MCP)

In the previous session, we explored how to extend an agent's reasoning via Skills (on-demand procedural memory). However, a language model on its own has no access to the real world: it cannot query your Supabase database, interact with remote GitHub repositories, or control a web browser to test a live screen.

To bridge this disconnect between LLMs and real-world data sources, the industry adopted a critical open standard: the Model Context Protocol (MCP).

1. What is MCP?​

The Model Context Protocol (MCP) is an open, bidirectional protocol developed by Anthropic that standardizes how AI applications (Hosts) securely connect with external tools, data sources, and services (Servers).

Prior to MCP, if a tool wanted to connect an agent to a PostgreSQL database, a GitHub repository, and the local file system, it had to implement proprietary connectors for each one. With MCP, any service that implements the specification becomes universally and instantly accessible to any compatible client (agy, Claude Desktop, Cursor, VS Code).

Comparison: Traditional API vs Skill vs MCP Server

2. The Conceptual Triad: API vs. Skill vs. MCP​

Developers frequently confuse these three concepts in the agentic ecosystem. Understanding their distinctions is essential for designing modern software architectures:

FeatureTraditional API (REST / GraphQL)Agent SkillMCP Server (Model Context Protocol)
What is it?Programming interface for communication between systems.Module containing procedural memory, heuristics, and reasoning rules.Client-server protocol exposing executable tools and real-time resources.
Target AudienceHuman developers and traditional compiled code.The language model (injected into its context window).The intelligent agent and its tool-calling runtime.
Self-DiscoveryNone. Requires a human to read Swagger/OpenAPI docs and write client code.Via YAML frontmatter metadata or explicit command (/skill).Fully dynamic. The server exposes its tools (tools/list) with live JSON Schema definitions.
Real-World AnalogyA fixed-voltage wall outlet.The workshop repair manual with step-by-step assembly instructions.The mechanical toolbox attached to an operator's robotic arm.

3. Why Can't an LLM Directly Consume a REST API?​

You might wonder: "If we already have REST APIs with endpoints like /api/v1/contacts, why do we need MCP?".

Traditional REST APIs pose three significant challenges when interacting with language models:

  1. Lack of semantic introspection: An HTTP API returns a status code (such as 400 Bad Request or 404 Not Found) without explaining to the agent what parameters were expected or what alternative options exist to resolve the error.
  2. Unnecessary token overhead: Injecting an entire Swagger specification (OpenAPI) containing hundreds of endpoints into the LLM prompt exhausts the context window before work even begins.
  3. Runtime security and permissions: A traditional REST API grants global access through a static API token. MCP implements a consent protocol where the user can authorize individual tool calls (Human-in-the-Loop).

4. MCP Architecture: Host, Client, and Server​

The MCP specification operates on a three-tier architecture:

  1. MCP Host: The main application where the user interacts with the AI (for instance, the developer CLI or your code editor).
  2. MCP Client: The module inside the host that manages active connections, transmits model requests, and receives execution results.
  3. MCP Server: A lightweight, standalone process exposing three primitive capability types:
    • Tools: Executable functions with side effects (e.g., create_table, git_commit, send_slack_message).
    • Resources: Contextual read-only data (e.g., database schemas, log files, technical documentation).
    • Prompts: Preconfigured prompt templates guiding the model through server-specific tasks.

Transport Channels​

MCP communicates using JSON-RPC 2.0 messages across two transport mechanisms:

  • stdio (Standard Input/Output): The host launches the MCP server as a local child process on the same machine (ideal for CLI tools, emulators, and local file operations).
  • SSE (Server-Sent Events over HTTP): The MCP server runs on a remote cloud host (ideal for shared services such as Supabase, enterprise Jira, or Docker clusters).

5. Practical Examples of MCP Servers in Engineering​

Below are the most widely used MCP servers in contemporary software projects:

Allows the agent to inspect real database schemas before writing queries or Dart data models:

tools/list (Postgres MCP Server Response)
{
  "tools": [
    {
      "name": "describe_table",
      "description": "Returns columns, data types, and foreign keys for a PostgreSQL table.",
      "inputSchema": {
        "type": "object",
        "properties": {
          "table_name": { "type": "string" }
        },
        "required": ["table_name"]
      }
    }
  ]
}
  • Engineering benefit: The agent calls describe_table(table_name: "contacts") and generates the immutable Dart model with exact field names and types directly from the database without hallucinating.

6. Configuring an MCP Server in Your Environment​

To enable an MCP server in your developer CLI (agy), define a JSON configuration file in your workspace or global directory:

mcp_servers.json
{
  "mcpServers": {
    "supabase-db": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://postgres:pass@db.supabase.co:5432/postgres"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxx"
      }
    }
  }
}

Upon launching the session, the agent automatically detects these servers through the MCP handshake, listing newly available tools to assist in building and auditing your application.

Self-Assessment Quiz​

Cargando cuestionario...