MCP explicado fácil: cómo conectar la inteligencia artificial con tus herramientas

Si ya usas agentes de inteligencia artificial y quieres que trabajen con tu correo, tu base de datos o tu repositorio, MCP es la pieza que falta. Este artículo explica qué es, cómo está montado por dentro y qué cambió en la versión del protocolo publicada el 28 de julio de 2026, que dejó obsoletas varias cosas que todavía se repiten en tutoriales viejos.

Qué problema resuelve MCP

Antes de MCP, conectar un modelo de lenguaje con una herramienta externa era trabajo artesanal. Si tenías cuatro aplicaciones de IA y seis fuentes de datos, acababas escribiendo veinticuatro integraciones distintas, cada una con su formato, su autenticación y sus errores. Ese es el problema N por M, y es la razón por la que la mayoría de proyectos de agentes se atascaban en la fontanería en lugar de avanzar.

El Model Context Protocol invierte la ecuación. Escribes un servidor MCP una sola vez y cualquier cliente compatible puede usarlo: Claude, ChatGPT, Visual Studio Code, Cursor y otros. La documentación oficial lo compara con un puerto USB-C, y la analogía funciona: el conector es siempre el mismo, lo que cambia es lo que enchufas.

Lo importante es entender el límite. MCP define cómo se intercambia el contexto, no cómo el modelo lo usa. No es un framework de agentes ni te dice cómo razonar. Es la capa de transporte y de contrato entre la aplicación de IA y el mundo exterior.

Las tres piezas: host, cliente y servidor

La arquitectura tiene tres participantes y confundirlos es el error de comprensión más común.

El host es la aplicación de IA: Claude Desktop, VS Code, Claude Code. El cliente es un objeto interno que el host crea por cada servidor al que se conecta, y mantiene esa conexión dedicada. El servidor es el programa que aporta el contexto, y puede correr en tu máquina o en la nube.

La consecuencia práctica: si conectas tres servidores a VS Code, VS Code instancia tres clientes. Un servidor local por stdio suele atender a un solo cliente; uno remoto por HTTP atiende a muchos a la vez. Esa diferencia condiciona cómo lo diseñas.

Qué puede exponer un servidor

El protocolo define tres primitivas de servidor. Cada una tiene sus métodos de descubrimiento y de uso.

Primitiva	Para qué sirve	Métodos	Quién decide usarla
Tools	Funciones ejecutables: consultar una API, escribir un archivo, lanzar una query	tools/list y tools/call	El modelo, durante la conversación
Resources	Datos de contexto: contenido de archivos, registros, esquemas	resources/list y resources/read	La aplicación o el usuario
Prompts	Plantillas reutilizables de interacción con ejemplos	prompts/list y prompts/get	El usuario, normalmente desde un menú
Elicitation	Primitiva de cliente: el servidor pide un dato o una confirmación al usuario	elicitation/create	El servidor, cuando le falta información

Un ejemplo concreto aclara el reparto. Un servidor que da acceso a una base de datos expondría una tool para lanzar consultas, un resource con el esquema de las tablas y un prompt con ejemplos de consultas bien escritas. Tres primitivas, tres funciones distintas, un solo servidor.

stdio o HTTP en streaming: cuál elegir

MCP soporta dos transportes y la elección no es de estilo, es de arquitectura.

Parámetro	stdio	Streamable HTTP
Dónde corre el servidor	En la misma máquina que el host	En cualquier sitio alcanzable por red
Canal	Entrada y salida estándar del proceso	POST HTTP, con Server-Sent Events opcional para streaming
Latencia	Mínima, sin sobrecarga de red	La de tu red y tu proveedor
Clientes simultáneos	Normalmente uno	Muchos
Autenticación	La del sistema operativo	Cabeceras HTTP estándar; la especificación recomienda OAuth
Depuración	Registra en stderr	Registra con OpenTelemetry o en tu stack habitual
Cuándo usarlo	Herramientas personales, acceso a archivos locales, prototipos	Servicios compartidos, equipos, integraciones de producto

Lo que cambió en la versión 2026-07-28

Aquí está el motivo por el que conviene desconfiar de los tutoriales de hace un año. La revisión del protocolo fechada el 28 de julio de 2026 introdujo cambios de fondo.

El protocolo pasó a ser sin estado. Cada petición lleva la versión del protocolo y las capacidades relevantes en su campo _meta, de modo que el servidor no deduce nada de peticiones anteriores. El antiguo apretón de manos de sesión desapareció como requisito.

El descubrimiento se hace ahora con una petición obligatoria, server/discover, que devuelve las versiones admitidas, las capacidades y la identidad del servidor. La respuesta trae además ttlMs y cacheScope, así que se puede cachear en lugar de repetirla en cada arranque.

Y dos primitivas de cliente quedaron obsoletas: sampling y logging. Si un tutorial te dice que uses sampling/createMessage para que el servidor pida una respuesta al modelo, está desactualizado; lo recomendado hoy es integrar directamente con la API del proveedor. Para el registro, escribe en stderr si usas stdio, o usa OpenTelemetry.

Así se ve una llamada a una herramienta con el formato actual:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "Santo Domingo", "units": "metric" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "mi-cliente", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

Tu primer servidor MCP en cinco pasos

1. Elige el SDK de tu lenguaje. Hay implementaciones oficiales para Python, TypeScript y otros; el SDK se encarga del JSON-RPC y del transporte, así que no escribes protocolo a mano.
2. Empieza por stdio. Es el transporte más simple de depurar y no necesitas desplegar nada. Pasa a HTTP solo cuando el servidor tenga que ser compartido.
3. Expón una sola tool al principio, con un inputSchema honesto. El esquema JSON es lo que el modelo lee para decidir cómo llamarte: si es vago, las llamadas saldrán mal.
4. Nombra las herramientas con prefijo de dominio. calculator_arithmetic se entiende mejor que calculate cuando el host federa diez servidores y todos tienen algo llamado "buscar".
5. Pruébalo con el MCP Inspector antes de conectarlo a tu cliente real. Separar "mi servidor está mal" de "mi cliente no lo carga" ahorra horas.

Errores típicos de principiante

1. Meter toda la lógica en tools y no usar resources. Si el modelo solo necesita leer algo, un resource es más barato que una llamada de herramienta.
2. Descripciones de herramienta escritas para humanos. El campo description lo consume el modelo: dile cuándo usarla y cuándo no, no solo qué hace.
3. Suponer que el cliente recibirá notificaciones automáticamente. Las notificaciones de cambio son opcionales: el cliente debe abrir un flujo con subscriptions/listen y pedir explícitamente los tipos que quiere.
4. Confiar solo en notificaciones para mantener la lista fresca. La especificación dice que son de mejor esfuerzo y que pueden perderse al reconectar, así que conviene refrescar también por tu cuenta.
5. Exponer un servidor remoto sin autenticación pensando que nadie lo encontrará. Un servidor MCP abierto es acceso directo a tus herramientas.

Veredicto crítico

MCP ganó la partida del estándar, y eso ya no está en discusión: lo soportan los clientes que importan y hay un catálogo grande de servidores de referencia. Para quien construye herramientas internas, escribir un servidor MCP es hoy la opción por defecto frente a una integración a medida.

Dicho eso, hay dos motivos reales para la cautela. El primero es que el protocolo se mueve rápido: en una sola revisión pasó a ser sin estado y dejó obsoletas dos primitivas. Si montas sobre MCP, planifica mantenimiento, no lo trates como una dependencia estable. El segundo es de seguridad. Un servidor MCP es, por definición, una superficie de ejecución conectada a un modelo que decide solo cuándo llamarte. Los permisos amplios y la ausencia de autenticación en servidores remotos son el fallo de diseño más repetido, no un descuido menor.

La recomendación práctica para empezar: un servidor, por stdio, con una herramienta y un alcance de permisos estrecho. Ampliar es fácil después. Reducir, cuando ya hay clientes conectados, no lo es.

Sigue leyendo

• Servidor MCP configurado pero no aparece en el cliente: cómo diagnosticarlo paso a paso
• Error 429 en la API de Gemini: cómo saber qué cuota agotaste
• Todas las guías prácticas de El Futuro 24/7

Fuentes

Los nombres de métodos, las primitivas, los transportes y los cambios de la revisión 2026-07-28 proceden de la documentación oficial del protocolo: introducción a MCP y visión general de la arquitectura. Las implementaciones de referencia y el Inspector están publicados en el repositorio del proyecto.