MCP: El Protocolo que Convierte a los LLMs en Agentes que Realmente Hacen Cosas

Pedirle a un LLM que lea un archivo de tu ordenador, consulte tu calendario o ejecute una consulta SQL ha sido, hasta ahora, un ejercicio de ingeniería de prompts y scripts ad-hoc. Cada integración requería su propia API, su propio formato de respuesta y su propia gestión de errores. MCP (Model Context Protocol), publicado por Anthropic como estándar abierto, cambia esto: define un protocolo común para que los modelos de lenguaje se comuniquen con herramientas externas, transformando al LLM de generador de texto pasivo en agente que interactúa con sistemas reales.

El problema: los LLMs están aislados de tus sistemas

Un modelo de lenguaje, por muy capaz que sea, vive en un vacío. No sabe qué hora es, no puede acceder a tu base de datos, no puede leer un archivo de tu servidor, no puede consultar el estado de una API interna. Cuando le pides algo que requiere datos externos, solo puede inventarlos o decirte que no puede ayudarte. Las soluciones existentes —function calling de OpenAI, plugins de ChatGPT, extensiones de VS Code— son propietarias, acopladas a plataformas concretas y no interoperables. Si construyes una herramienta para que Claude use tu CRM, no puedes reutilizarla con GPT-4 sin reescribirla.

MCP resuelve esto definiendo un protocolo de comunicación bidireccional y agnóstico de modelo. No importa si usas Claude, GPT-4, Gemini o un LLM local: si habla MCP, puede conectarse a cualquier herramienta que también hable MCP.

Qué es exactamente MCP

MCP es un protocolo JSON-RPC sobre transportes estándar (stdio para procesos locales, HTTP/SSE para servidores remotos). Define tres tipos de capacidades que un servidor MCP puede exponer: tools (funciones que el LLM puede invocar), resources (datos de solo lectura que el LLM puede consultar) y prompts (plantillas de interacción predefinidas). Cada servidor MCP describe automáticamente qué ofrece mediante un esquema JSON que el cliente puede inspeccionar antes de usarlo.

La arquitectura es deliberadamente simple: un cliente MCP (la aplicación que aloja el LLM) se conecta a uno o varios servidores MCP (cada uno expone herramientas de un dominio concreto). El cliente descubre las capacidades disponibles, el LLM decide cuáles necesita para responder, y el cliente ejecuta las llamadas correspondientes. El resultado vuelve al modelo como contexto adicional.

Un ejemplo concreto: consultar una base de datos

Imagina que tienes una base de datos PostgreSQL con datos de ventas y quieres preguntarle a un asistente: '¿Cuáles fueron los cinco productos más vendidos el mes pasado?'. Sin MCP, el modelo no puede hacer nada. Con MCP, el flujo es:

• El cliente se conecta al servidor MCP-postgres que expones en tu red. Este servidor describe sus capacidades: una herramienta llamada 'query' que acepta una sentencia SQL y devuelve resultados tabulares.
• El usuario hace la pregunta. El LLM analiza la petición y decide que necesita la herramienta 'query' con una sentencia SQL apropiada.
• El cliente ejecuta la llamada al servidor MCP-postgres. El servidor valida la consulta (buena práctica: solo SELECT, sin DROP ni DELETE), la ejecuta y devuelve los resultados.
• El LLM recibe los datos y genera una respuesta en lenguaje natural: 'Los cinco productos más vendidos en abril fueron...'

El modelo nunca tuvo acceso directo a la base de datos. El servidor MCP actuó como puente controlado, y el esquema declarado permitió al LLM entender qué podía hacer y cómo pedirlo.

El ecosistema de servidores MCP

Desde su publicación, la comunidad ha desarrollado servidores MCP para prácticamente todo. Estos son los más útiles para un entorno de trabajo o homelab:

• Filesystem: Permite al LLM leer, listar y buscar archivos en directorios concretos. Útil para que un asistente revise logs, analice configuraciones o navegue proyectos.
• GitHub: Crea issues, busca repositorios, lee pull requests y comenta código directamente desde el chat con el LLM.
• Brave Search: Añade búsqueda web en tiempo real al modelo, superando el corte de conocimiento de su fecha de entrenamiento.
• PostgreSQL / SQLite: Consulta bases de datos con SQL controlado. Algunos servidores permiten incluso análisis exploratorio con prompts automáticos.
• Puppeteer: Navegación web automatizada: screenshot, extracción de datos, interacción con formularios. El LLM puede 'ver' páginas web.
• Slack / Discord: Envía mensajes, lee canales, resume conversaciones. Convierte al LLM en un participante de tus chats de equipo.

La lista crece cada semana. La ventaja es que todos comparten el mismo contrato: si tu aplicación habla MCP, gana acceso instantáneo a todo el ecosistema sin código adicional.

Seguridad: no es 'acceso total'

Una objeción legítima: si el LLM puede ejecutar SQL, leer archivos y navegar por la web, ¿no es eso peligroso? MCP incorpora principios de seguridad desde el diseño. Primero, el servidor MCP opera con los permisos del proceso que lo ejecuta: si lo corres como usuario restringido, solo accede a lo que ese usuario puede ver. Segundo, cada servidor declara explícitamente qué herramientas ofrece, y el cliente decide cuáles exponer al LLM. Tercero, la mayoría de servidores de bases de datos incluyen validación de consultas (whitelist de comandos, bloqueo de DROP/DELETE) y requieren confirmación humana para operaciones destructivas.

La seguridad no es inherente al protocolo, sino a la implementación de cada servidor. Un servidor filesystem mal configurado puede exponer /etc/passwd. Un servidor postgres sin validación puede ejecutar TRUNCATE. La responsabilidad recae en quién despliega y configura cada servidor. MCP da la estructura; tú pones las barreras.

Dónde encaja MCP en tu arquitectura

MCP no reemplaza las APIs que ya tienes. Las complementa. Si tienes una aplicación con un backend REST, MCP es una capa de traducción que permite a un LLM usar ese backend sin entender OpenAPI ni JSON Schema. Si tienes un homelab con Home Assistant, Grafana, y una base de datos de logs, MCP permite a un asistente consultar los tres sistemas desde una única conversación.

En mi propio setup, tengo servidores MCP para: filesystem (acceso a notas y proyectos), Brave Search (búsqueda web), y un servidor custom que expone métricas de Ollama. Desde la misma conversación con el modelo, puedo pedirle que resuma un archivo de mi disco, busque información actualizada sobre un tema, y me diga cuántos tokens por segundo está sirviendo mi instancia local. Cada uno corre como proceso independiente, aislado, y el modelo solo ve lo que cada servidor decide exponer.

Implementación básica: tu primer servidor MCP

Crear un servidor MCP es sorprendentemente sencillo. El SDK oficial de Anthropic está disponible para Python, TypeScript y otros lenguajes. Un servidor mínimo expone una única herramienta:

La estructura es: importas el SDK, defines las herramientas con su esquema de entrada, implementas la función que ejecuta la lógica, y arrancas el servidor. El SDK se encarga del JSON-RPC, el descubrimiento de capacidades y el manejo de errores. El servidor puede correr como proceso local (stdio) o como servicio HTTP remoto.

Limitaciones y dónde no encaja

MCP no es una bala de plata. Tiene límites que es importante conocer antes de adoptarlo:

• Latencia acumulada: Cada llamada a herramienta requiere una ronda de comunicación cliente-servidor. Si un flujo necesita cinco herramientas secuenciales, el tiempo de respuesta se multiplica. No es adecuado para operaciones que requieren microsegundos.
• Dependencia del razonamiento del LLM: El modelo debe decidir correctamente qué herramienta usar y con qué parámetros. Modelos pequeños (7B-8B) a veces se confunden con el esquema de herramientas o inventan parámetros. Modelos de 30B+ parámetros funcionan más fiablemente.
• Estado no persistente: MCP no define mecanismos de memoria entre sesiones. Cada conversación empieza de cero. Si necesitas que el modelo recuerde contexto entre interacciones, debes implementarlo tú.
• Transporte síncrono: Aunque el protocolo permite notificaciones, la mayoría de implementaciones actuales son request-response. Operaciones asíncronas largas (como entrenar un modelo) no encajan bien en el modelo MCP estándar.

Conclusión

MCP es el tipo de estándar que la comunidad de IA necesitaba: abierto, agnóstico de modelo, y lo suficientemente simple para implementar en una tarde. No convierte a un LLM en AGI, pero elimina la fricción entre 'el modelo sabe hacer cosas' y 'el modelo puede realmente hacer cosas con tus sistemas'.

Si tienes un homelab con varios servicios, o una aplicación que quieres dotar de capacidades agenticas, MCP es el punto de partida más sensato. Empieza con un servidor simple —filesystem o búsqueda web— y ve añadiendo complejidad a medida que el modelo demuestre que usa las herramientas correctamente. Como todo en este campo, la iteración gana a la planificación excesiva.

*Este artículo es parte de ByteStream, análisis técnico sobre IA, desarrollo y self-hosting.*