Qué es MCP: protocolo, actores y por qué importa para agentes conectados
Construye el modelo mental correcto de MCP desde el inicio: qué problema resuelve, cómo se reparten host, cliente y servidor, y por qué este protocolo cambia la forma de conectar IA con herramientas reales.
Model Context Protocol, o MCP, no es una app concreta ni un framework cerrado. Es un protocolo abierto para que una aplicación con IA pueda conectarse de forma estructurada con herramientas, datos y servicios externos.
La idea clave es sencilla: un modelo de lenguaje por sí solo razona sobre texto, pero no sabe consultar tu base de datos, leer un repositorio local o lanzar una acción en otra plataforma si nadie le da una interfaz clara para hacerlo.
Antes de MCP, muchas integraciones se resolvían con conexiones ad hoc: cada cliente hablaba con cada herramienta a su manera. Eso multiplica esfuerzo, inconsistencias y mantenimiento.
MCP propone una capa común para que hosts, clientes y servidores negocien capacidades, descubran herramientas y se comuniquen con un contrato estable.
- Un LLM sin conexión a contexto fiable se queda corto muy rápido en trabajo real.
- Un asistente puede redactar, resumir o sugerir pasos a partir de su conocimiento general, pero eso no basta cuando necesitas consultar datos actuales, operar sobre un sistema o recuperar información privada de un entorno controlado.
- Ahí aparece el cuello de botella clásico: cada producto de IA necesita su propia integración con cada fuente de datos o herramienta. Ese patrón M x N hace que el ecosistema crezca con demasiada fricción.
- MCP reduce ese problema definiendo una forma común de describir capacidades, descubrir primitivas y ejecutar acciones sin depender de una integración inventada desde cero para cada pareja de cliente y servidor.
- Confundir estos roles es uno de los errores más frecuentes al empezar con MCP.
Problema y aislamiento
Un LLM sin conexión a contexto fiable se queda corto muy rápido en trabajo real.
Un asistente puede redactar, resumir o sugerir pasos a partir de su conocimiento general, pero eso no basta cuando necesitas consultar datos actuales, operar sobre un sistema o recuperar información privada de un entorno controlado.
Ahí aparece el cuello de botella clásico: cada producto de IA necesita su propia integración con cada fuente de datos o herramienta. Ese patrón M x N hace que el ecosistema crezca con demasiada fricción.
MCP reduce ese problema definiendo una forma común de describir capacidades, descubrir primitivas y ejecutar acciones sin depender de una integración inventada desde cero para cada pareja de cliente y servidor.
Roles del sistema
Confundir estos roles es uno de los errores más frecuentes al empezar con MCP.
El host es la aplicación de IA que coordina la experiencia general. Puede ser un editor, un asistente de escritorio o un entorno compatible que quiera conectarse a uno o varios servidores MCP.
El cliente MCP vive dentro del host y mantiene la conexión con un servidor concreto. Su trabajo es hablar el protocolo, negociar capacidades y transportar mensajes entre ambos lados.
El servidor MCP es el programa que expone contexto o acciones: por ejemplo acceso a archivos, una API, documentación o una operación sobre una base de datos.
- Host: la aplicación que orquesta la experiencia de IA.
- Cliente: el conector que mantiene la sesión con un servidor MCP.
- Servidor: el proceso que ofrece datos, herramientas o prompts al cliente.
- Una misma aplicación host puede gestionar varios clientes y varios servidores a la vez.
Primitivas base
La decisión de diseño importante no es solo qué conectar, sino cómo representarlo.
Separar bien estas tres primitivas evita servidores confusos. No todo debe resolverse como tool, igual que no todo dato debe serializarse como recurso estático.
En las siguientes lecciones entraremos en este criterio con más detalle, porque de él depende que un servidor sea usable, mantenible y fácil de descubrir para el cliente.
Transporte
El protocolo de datos puede ser el mismo, pero el canal cambia según el despliegue.
Cuando un servidor MCP corre localmente en la misma máquina, el transporte habitual es `stdio`. Es rápido, directo y muy útil para desarrollo, pruebas o acceso controlado a recursos locales.
Cuando el servidor vive de forma remota, el protocolo puede usar `Streamable HTTP`, con `POST` y streaming opcional mediante Server-Sent Events. Esto permite escenarios multiusuario y autenticación estándar.
La decisión no es estética. Marca latencia, despliegue, seguridad operativa y el tipo de recursos a los que el servidor puede acceder.
Caso guiado
Imagina un host compatible con MCP conectado a un servidor de sistema de archivos local. El modelo ya no responde solo con conocimiento general: puede listar recursos disponibles, leer un archivo permitido y usar esa información como contexto real de trabajo.
Ese salto no convierte mágicamente al modelo en fiable. Lo que hace es cambiar la calidad del entorno: ahora trabaja con una puerta de entrada explícita, con permisos delimitados y con primitivas descubribles.
Esto conecta de forma natural con el resto de rutas del repositorio. Si vienes del curso de <a href="/curso/vibe-coding/leccion/vibe-coding-agentes-editores-builders-fundamentos" target="_self" rel="noopener">vibe coding</a>, aquí ves la capa de infraestructura que hace posible que un agente deje de estar aislado. Si vienes de <a href="/curso/terminal/leccion/terminal-introduccion-terminales-entornos-basico" target="_self" rel="noopener">terminal</a>, reconocerás por qué `stdio` y los procesos locales importan tanto en este tipo de integración.
