MCP explicado a fondo: qué es, cómo funciona y cómo construir tu propio servidor

Cuando un modelo de lenguaje necesita leer un archivo, consultar una base de datos o llamar a una API, alguien tiene que construir el puente entre “el modelo entiende lenguaje natural” y “el sistema real expone datos y funciones”. Durante 2023 y 2024 ese puente se construía a mano, una integración por cada combinación de modelo y herramienta. MCP nació para acabar con esa combinatoria.

Model Context Protocol (MCP) es un estándar abierto, publicado por Anthropic a finales de 2024, que define un protocolo común para que las aplicaciones de IA se conecten con fuentes de datos y herramientas externas. En vez de escribir un conector distinto para cada asistente y cada servicio, escribes un servidor MCP una vez y cualquier cliente compatible —Claude Code, Cursor, Gemini CLI, VS Code, y decenas de agentes más— puede usarlo.

La analogía que mejor funciona es la del propio equipo de MCP: es como USB-C para aplicaciones de IA. Antes de USB-C, cada dispositivo tenía su conector propietario. MCP busca lo mismo para el “puerto” por el que un modelo accede al mundo exterior.

Por qué importa: el problema de M×N

Sin un protocolo común, conectar M asistentes con N herramientas requiere M×N integraciones distintas: cada combinación cliente-herramienta es un adaptador ad hoc, con su propio formato de autenticación, su propio esquema de errores y su propio ciclo de mantenimiento. En cuanto una herramienta cambia su API, hay que tocar todos los adaptadores que dependen de ella.

MCP convierte ese problema en uno de M+N: cada herramienta implementa un servidor MCP una vez, cada cliente implementa soporte MCP una vez, y cualquier combinación funciona sin trabajo adicional. Es el mismo principio que llevó a estandarizar LSP (Language Server Protocol) para que un editor no tuviera que implementar soporte específico para cada lenguaje de programación.

El ecosistema ha crecido rápido: a cierre del segundo trimestre de 2026 existían del orden de 9.400 servidores MCP publicados entre los principales registros, con cerca de 1.300 considerados listos para producción. Anthropic y OpenAI, además, han donado MCP y el formato AGENTS.md a la recién creada Agentic AI Foundation, bajo el paraguas de la Linux Foundation, lo que refuerza su papel como estándar neutral y no ligado a un único proveedor.

Arquitectura: clientes, servidores y hosts

MCP define tres roles:

• Host: la aplicación con la que interactúa la persona usuaria (Claude Code, un IDE, una app de escritorio). El host puede gestionar múltiples clientes.
• Cliente MCP: vive dentro del host y mantiene una conexión 1:1 con un servidor MCP concreto, traduciendo entre el modelo y el protocolo.
• Servidor MCP: un proceso (local o remoto) que expone capacidades concretas: herramientas, datos o prompts predefinidos.

graph LR
H[Host: Claude Code / IDE] --> C1[Cliente MCP]
H --> C2[Cliente MCP]
C1 <-->|JSON-RPC 2.0| S1[Servidor MCP: GitHub]
C2 <-->|JSON-RPC 2.0| S2[Servidor MCP: Postgres]
S1 --> API1[(API de GitHub)]
S2 --> DB[(Base de datos)]

Toda la comunicación entre cliente y servidor usa JSON-RPC 2.0 como formato de mensajes, con tres tipos de transporte soportados por la especificación:

• stdio: el servidor se ejecuta como subproceso local y se comunica por entrada/salida estándar. Es el transporte más simple y el habitual para herramientas que corren en la máquina del desarrollador (acceso a archivos, git, bases de datos locales).
• Streamable HTTP: el servidor expone un endpoint HTTP y usa Server-Sent Events para el streaming de respuestas. Es el transporte pensado para servidores remotos multi-usuario.
• stdio con procesos sandboxed o HTTP tras un gateway de autenticación, en despliegues empresariales que necesitan aislar la ejecución o centralizar el control de acceso.

Las tres primitivas: tools, resources y prompts

Un servidor MCP puede exponer tres tipos de capacidades, y no está obligado a implementar las tres:

Tools (herramientas): funciones que el modelo puede invocar de forma activa, con un nombre, una descripción y un esquema de parámetros en JSON Schema. Son el equivalente MCP al function calling de las APIs de LLM, pero estandarizado y descubrible: el cliente pregunta al servidor qué herramientas ofrece (tools/list) y las expone al modelo automáticamente.

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { z } from 'zod';

const server = new McpServer({ name: 'demo-db', version: '1.0.0' });

server.tool(
  'buscar_pedido',
  'Busca un pedido por su número de referencia',
  { referencia: z.string().describe('Número de pedido, ej. PED-2026-001') },
  async ({ referencia }) => {
    const pedido = await db.pedidos.findUnique({ where: { referencia } });
    if (!pedido) {
      return { content: [{ type: 'text', text: 'No se encontró ningún pedido con esa referencia.' }] };
    }
    return { content: [{ type: 'text', text: JSON.stringify(pedido, null, 2) }] };
  }
);

Resources (recursos): datos que el servidor pone a disposición del cliente —el contenido de un archivo, una fila de base de datos, una página de documentación— identificados por una URI. A diferencia de las tools, los resources normalmente los decide cargar el host o la persona usuaria, no el modelo por iniciativa propia, lo que los hace más predecibles en cuanto a coste y control de acceso.

Prompts: plantillas de prompt reutilizables y parametrizables que el servidor expone para flujos de trabajo concretos (por ejemplo, “revisar este pull request siguiendo nuestra guía de estilo”). El cliente las presenta a la persona usuaria como acciones explícitas, no como algo que el modelo decide invocar solo.

Construir un servidor MCP mínimo

El SDK oficial de TypeScript reduce la mayor parte del trabajo a describir las herramientas; el transporte y el framing JSON-RPC los gestiona el propio SDK.

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';

const server = new McpServer({ name: 'clima-server', version: '1.0.0' });

server.tool(
  'obtener_clima',
  'Devuelve la temperatura actual de una ciudad',
  { ciudad: z.string() },
  async ({ ciudad }) => {
    const res = await fetch(`https://api.ejemplo.com/clima?city=${encodeURIComponent(ciudad)}`);
    const data = await res.json();
    return { content: [{ type: 'text', text: `${ciudad}: ${data.temp}°C` }] };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

Para probarlo desde Claude Code, basta con registrarlo en la configuración de servidores MCP del proyecto o del usuario, apuntando al comando que arranca el proceso (node clima-server.js, por ejemplo). El cliente hace el handshake inicial, pide la lista de herramientas disponibles y a partir de ahí el modelo puede invocarlas cuando lo considere útil para responder a la persona usuaria.

Un patrón habitual en servidores reales es separar la lógica de negocio del wrapper MCP: la función obtener_clima de arriba debería ser una llamada fina a un servicio que ya existe y que se testea de forma independiente, no lógica nueva escrita solo para el agente.

Seguridad: la superficie de ataque que MCP introduce

Exponer herramientas a un modelo que actúa de forma semiautónoma cambia el perfil de riesgo de una integración. Los puntos que conviene tener resueltos antes de llevar un servidor MCP a producción:

El informe State of Agentic AI Security de 2026 sitúa la inyección de prompts —directa e indirecta— como el riesgo mejor documentado en despliegues agentic reales, y las herramientas conectadas vía protocolos como MCP son precisamente el vector por el que ese contenido no confiable llega al modelo. No es una razón para evitar MCP, pero sí para diseñar cada servidor asumiendo que cualquier dato que devuelva puede contener texto adversarial.

Cuándo tiene sentido usar MCP (y cuándo no)

MCP encaja bien cuando quieres que varios clientes de IA reutilicen la misma integración, cuando construyes una herramienta interna que distintos equipos conectarán a distintos asistentes, o cuando publicas un conector para que terceros lo usen desde cualquier host compatible.

Tiene menos sentido si estás construyendo una única aplicación con un único modelo y un único flujo: ahí, una llamada a función directa contra la API del proveedor del modelo (function calling clásico) es más simple y con menos piezas en marcha. MCP añade un proceso servidor, un transporte y un ciclo de vida de conexión que se justifican cuando esa infraestructura se va a reutilizar, no cuando es un one-off.

Alternativas y cómo se relaciona con RAG

MCP no compite con RAG (retrieval-augmented generation): son complementarios. RAG resuelve cómo recuperar información relevante de una base de conocimiento y metérsela al modelo en el contexto; MCP resuelve cómo un agente descubre y ejecuta acciones sobre sistemas externos de forma estandarizada. Un servidor MCP puede perfectamente exponer una tool de búsqueda semántica que internamente hace RAG contra una base de datos vectorial.

Tampoco sustituye al function calling nativo de las APIs de LLM: lo usa por debajo. MCP es la capa de estandarización sobre ese mecanismo, no un reemplazo.

Conclusión práctica

Si mantienes una herramienta o fuente de datos que varios agentes de IA van a necesitar, construir un servidor MCP hoy es más barato que mantener N integraciones ad hoc, y el ecosistema de clientes que ya lo soportan —Claude Code, Cursor, Gemini CLI, VS Code y otros— hace que el retorno sea inmediato. Empieza exponiendo una única tool bien definida, con un esquema de entrada estricto y sin efectos secundarios sorpresa; el resto del protocolo (recursos, prompts, transportes remotos) puedes incorporarlo cuando el caso de uso lo pida de verdad.