TL;DR: Model Context Protocol (MCP) es el protocolo abierto estándar introducido por Anthropic que resuelve el problema de integración $N \times M$ entre modelos de lenguaje y sistemas de datos. En lugar de escribir conectores personalizados para cada modelo e interfaz, MCP proporciona una arquitectura Client-Server unificada con tres primitivas básicas: Resources (lectura de datos), Prompts (plantillas reutilizables) y Tools (ejecución de acciones).
El problema $N \times M$ de la integración en Inteligencia Artificial
Antes de la llegada de MCP, la integración de modelos de lenguaje con fuentes de datos externas (bases de datos, repositorios Git, APIs de terceros, sistemas de archivos) presentaba un desafío estructural masivo:
Si tenías $N$ aplicaciones de IA (como Claude, Cursor o aplicaciones personalizadas) y $M$ fuentes de datos (PostgreSQL, GitHub, Slack, Jira, Notion), necesitabas desarrollar e implementar $N \times M$ integraciones individuales.
SIN MCP:
[Claude Desktop] ─── (Código a medida) ───> [PostgreSQL]
[Cursor IDE] ─── (Código a medida) ───> [PostgreSQL]
[Claude Desktop] ─── (Código a medida) ───> [GitHub API]
[Cursor IDE] ─── (Código a medida) ───> [GitHub API]
CON MCP:
[Claude Desktop] ──┐
[Cursor IDE] ──┼──> [ Protocolo MCP ] ──┬──> [MCP Server PostgreSQL]
[Claude Code] ──┘ └──> [MCP Server GitHub]
MCP elimina esta complejidad. Al definir una especificación abierta basada en JSON-RPC 2.0, cualquier aplicación cliente compatible con MCP puede conectarse inmediatamente a cualquier servidor MCP existente.
Arquitectura de MCP: Host, Client y Server
El diseño de MCP sigue una arquitectura de capas bien delimitada:
- MCP Host: La aplicación principal donde interactúa el usuario (por ejemplo, Claude, Cursor o Claude Code).
- MCP Client: El componente interno dentro del Host que mantiene la conexión 1:1 con un servidor MCP, gestiona la negociación de capacidades y envía las solicitudes JSON-RPC.
- MCP Server: Un proceso independiente (local o remoto) que expone recursos, plantillas y herramientas mediante la especificación MCP.
┌─────────────────────────────────────────────────────────┐
│ MCP HOST │
│ ┌─────────────────┐ ┌─────────────────────┐ │
│ │ UI / Chat │ ◄───────► │ LLM Engine │ │
│ └────────┬────────┘ └──────────┬──────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ MCP CLIENT │ │
│ └────────────────────────┬──────────────────────────┘ │
└───────────────────────────┼─────────────────────────────┘
│ (JSON-RPC 2.0 via stdio/SSE)
▼
┌─────────────────────────────────────────────────────────┐
│ MCP SERVER │
│ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │
│ │ Resources │ │ Prompts │ │ Tools │ │
│ └──────────────┘ └──────────────┘ └───────────┘ │
└─────────────────────────────────────────────────────────┘
Mecanismos de Transporte
MCP soporta dos canales de comunicación estándar:
- stdio (Standard I/O): El Host lanza el servidor MCP como un subproceso local y se comunica a través de
stdinystdout. Ideal para utilidades locales, acceso a archivos y ejecución en máquinas de desarrollo. El tiempo de latencia es <1ms. - SSE (Server-Sent Events) sobre HTTP: Utilizado para servidores MCP remotos. El cliente recibe eventos en tiempo real desde el servidor vía SSE y envía comandos mediante peticiones POST HTTP.
Las Tres Primitivas Fundamentales de MCP
MCP estructura la interacción entre el LLM y el entorno en tres primitivas bien definidas:
1. Resources (Recursos de Lectura)
Los recursos permiten al servidor exponer datos pasivos al modelo (archivos, logs, registros de base de datos, métricas). Los recursos son leídos por el cliente y adjuntados al contexto del modelo.
- Identificados por URI únicas (ej:
postgres://database/users/schemaofile:///var/logs/app.log). - Soporta contenido textual o binario codificado en Base64.
- Soporta suscripciones en tiempo real (
resources/subscribe): cuando el archivo o registro cambia, el servidor notifica al cliente para actualizar el contexto.
2. Prompts (Plantillas Contextuales)
Permiten a los servidores expone patrones de prompts parametrizados que ayudan a los usuarios a realizar tareas complejas sobre las herramientas del servidor.
- Ejemplo: Un servidor de GitHub puede exponer un prompt
review-pull-requestque acepta el parámetropr_idy estructura automáticamente las instrucciones para el LLM.
3. Tools (Funciones Ejecutables)
Las herramientas son funciones con efectos secundarios o capacidad de computación activa que el LLM puede decidir invocar.
- Cada herramienta define un nombre, una descripción detallada y un esquema de parámetros formateado en JSON Schema.
- Cuando el modelo genera un call de herramienta, el cliente solicita aprobación al usuario (si es necesario) y ejecuta la función en el servidor MCP, devolviendo el resultado al contexto del modelo.
Guía Paso a Paso: Creando un Servidor MCP en TypeScript
A continuación se muestra una implementación práctica de un servidor MCP local usando el SDK oficial @modelcontextprotocol/sdk en Node.js/TypeScript. Este servidor expone una herramienta para consultar el esquema de una base de datos SQLite y ejecutar consultas SQL de solo lectura.
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
CallToolRequestSchema,
ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";
import Database from "better-sqlite3";
const db = new Database("app.db", { readonly: true });
// Inicializar el servidor MCP
const server = new Server(
{
name: "sqlite-readonly-mcp",
version: "1.0.0",
},
{
capabilities: {
tools: {},
},
}
);
// Listar herramientas disponibles
server.setRequestHandler(ListToolsRequestSchema, async () => {
return {
tools: [
{
name: "execute_readonly_query",
description: "Ejecuta una consulta SQL SELECT de solo lectura en la base de datos SQLite local.",
inputSchema: {
type: "object",
properties: {
sql: {
type: "string",
description: "La consulta SQL SELECT a ejecutar.",
},
},
required: ["sql"],
},
},
],
};
});
// Manejar la ejecución de la herramienta
server.setRequestHandler(CallToolRequestSchema, async (request) => {
if (request.params.name !== "execute_readonly_query") {
throw new Error(`Herramienta no encontrada: ${request.params.name}`);
}
const sql = String(request.params.arguments?.sql);
// Validación básica de seguridad
if (!sql.trim().toUpperCase().startsWith("SELECT")) {
return {
content: [
{
type: "text",
text: "ERROR: Solo se permiten consultas de tipo SELECT por razones de seguridad.",
},
],
isError: true,
};
}
try {
const stmt = db.prepare(sql);
const rows = stmt.all();
return {
content: [
{
type: "text",
text: JSON.stringify(rows, null, 2),
},
],
};
} catch (error: any) {
return {
content: [
{
type: "text",
text: `Error en la ejecución SQL: ${error.message}`,
},
],
isError: true,
};
}
});
// Arrancar el servidor sobre stdio
async function main() {
const transport = new StdioServerTransport();
await server.connect(transport);
console.error("Servidor SQLite MCP ejecutándose en stdio");
}
main().catch(console.error);
Configuración en el Cliente MCP (ej. Claude Desktop o Cursor)
Para registrar este servidor en Cursor o Claude Desktop, se añade la siguiente configuración en el archivo claude_desktop_config.json:
{
"mcpServers": {
"sqlite-local": {
"command": "node",
"args": ["/path/to/build/index.js"],
"env": {
"NODE_ENV": "production"
}
}
}
}
Modelo de Seguridad y Buenas Prácticas
MCP ha sido diseñado teniendo en cuenta los vectores de ataque más comunes en agentes de IA (como el Prompt Injection indirecto y la ejecución arbitraria de código):
- Aislamiento de Entorno: Los servidores
stdioheredan los permisos del proceso hijo, impidiendo accesos no autorizados a la red a menos que el servidor esté explícitamente programado para ello. - Consentimiento Humano Explícito (Human-in-the-loop): El protocolo exige que el cliente implemente mecanismos de autorización por confirmación del usuario para cualquier invocación de
Tools. - Principio de Mínimo Privilegio: Exponer servidores dedicados para funciones específicas (por ejemplo, separar el servidor de lectura de logs del servidor de despliegue en producción) en lugar de un servidor monolítico con acceso total.
Comparativa: MCP vs Custom Tool Calling vs REST APIs
| Característica | MCP (Model Context Protocol) | Tool Calling Tradicional (OpenAI/Anthropic APIs) | REST APIs Tradicionales |
|---|---|---|---|
| Arquitectura | Client-Server Abierto (JSON-RPC 2.0) | Integración acoplada en código del cliente | Cliente-Servidor Web |
| Reutilización | Alta (un servidor sirve a cualquier IDE/Chat) | Nula (código duplicado en cada app) | Alta entre servicios web |
| Soporte de Recursos | Nativo (recursos con suscripción push) | Manual (inyectado como texto en prompt) | Requiere polling o Webhooks |
| Gestión de Contexto | Estandarizada por el Host | Manual por el desarrollador | No aplica |
| Modo de Ejecución | Local (stdio) o Remoto (SSE) | Remoto (ejecutado por backend propio) | Remoto |
El Ecosistema MCP en 2026
El estándar MCP se ha consolidado como la columna vertebral del desarrollo de software asistido por IA. Actualmente cuenta con soporte nativo en:
- Entornos de Desarrollo: Cursor, Claude Code, VS Code (vía extensiones agénticas), Windsurf.
- Aplicaciones de Escritorio: Claude Desktop, Ollama Desktop.
- Servidores MCP Oficiales y de la Comunidad: Conectores validados para PostgreSQL, MySQL, GitHub, GitLab, Brave Search, Puppeteer, Docker, Slack, Google Drive y Sentry.
El Model Context Protocol no solo simplifica la conexión entre los LLMs y los sistemas de información corporativos, sino que sienta las bases para redes de agentes autónomos interoperables.