MCP, o Model Context Protocol, es el puente estándar entre un modelo de lenguaje y el mundo real. En lugar de encadenar prompts frágiles o atarte a funciones propietarias de un proveedor, MCP propone una vía única y coherente para exponer herramientas, datos y acciones con permisos, políticas y trazabilidad. El resultado es un agente que no solo “sabe”, sino que también “puede” actuar de manera segura y auditable sobre tus sistemas.
Qué es MCP y qué problema resuelve
Imagínate un enchufe universal para agentes de IA. MCP define ese enchufe: un formato común para descubrir qué herramientas existen, con qué parámetros se invocan y bajo qué condiciones está permitido usarlas. A diferencia de RAG —que enriquece el contexto del modelo con documentos y fragmentos de conocimiento— MCP se centra en la acción: leer un issue, abrir un ticket, consultar una API interna o actualizar una nota en un espacio corporativo. Son tecnologías complementarias; RAG aporta memoria curada, MCP aporta manos y reglas.
La otra comparación inevitable es con el function calling nativo de algunos LLMs. Es ágil y práctico, pero suele acoplar tu lógica a un proveedor concreto y deja la gobernanza en segundo plano. MCP deshace ese nudo: separa la definición de herramientas del modelo, añade consentimiento explícito y conserva un rastro claro de quién hizo qué, cuándo y con qué permisos. Si en tu organización importa la portabilidad, el cumplimiento y la reutilización de integraciones entre productos y modelos, MCP encaja de forma natural.
Arquitectura: Host, Cliente y Servidor sin tecnicismos
MCP organiza el sistema en tres papeles. El Host es la aplicación donde vive la experiencia del usuario (un IDE, una app de escritorio, un chat interno). El Cliente es la pieza que traduce las intenciones del modelo al lenguaje de MCP. Y el Servidor MCP es tu pasarela hacia herramientas reales: define qué capacidades ofreces, cómo se llaman, qué parámetros aceptan y qué límites deben respetar.
En la práctica, el flujo se siente así: el modelo propone “consultar la descripción de esta Pull Request”; el Host lo muestra y pide tu visto bueno; si aceptas, el Cliente invoca la herramienta “github.read_pr” en el Servidor MCP “repos”, y este devuelve una respuesta estructurada que el modelo puede entender. Todo queda registrado: qué herramienta, qué parámetros, con qué alcance. No hay magia, hay contratos bien definidos.
¿Cómo funciona el protocolo MCP?
El Servidor MCP anuncia sus herramientas y recursos; el Host las descubre y presenta esa información al modelo y al usuario. Cuando el modelo necesita actuar, sugiere una invocación con argumentos concretos.
El Host aplica políticas —por ejemplo, prohibir escrituras en producción o limitar el acceso a ciertos repos— y solicita consentimiento cuando corresponde. Aprobada la operación, el Servidor ejecuta la acción en el sistema de destino y devuelve un resultado estructurado. Este intercambio puede viajar por stdio en local (ideal para un arranque rápido), por WebSockets si quieres sesiones persistentes, o por SSE/HTTP si priorizas sencillez detrás de proxies. Lo importante es que el transporte no condiciona la semántica: la conversación MCP se mantiene estable.
Ventajas y límites
Lo primero que se nota es la interoperabilidad: un único servidor puede servir a varios hosts y modelos sin reescribir integraciones. Lo segundo es la gobernanza: MCP coloca permisos, consentimiento y auditoría como piezas de primera clase, de modo que puedes explicar —ante ti y ante terceros— por qué se tomó una acción. Además, al separar herramientas de modelos, reduces el acoplamiento y facilitas el mantenimiento: actualizas un conector una vez y lo heredan todos tus agentes.
¿Dónde están los costes? La adopción requiere definir contratos de herramientas con un mínimo de rigor, y eso es trabajo de diseño. También añades un salto en la cadena (Host ↔ Servidor), con el impacto de latencia que cabe esperar; se mitiga con transporte adecuado, batching y límites sensatos en tamaños de respuesta. Por último, los permisos no se improvisan: merece la pena diseñar scopes y roles bien pensados para evitar sorpresas más adelante.
Seguridad aplicada: PAT, RBAC y observabilidad
MCP brilla cuando lo combinas con controles de acceso simples de entender pero estrictos de ejecutar. Los Personal Access Tokens (PAT) acotan el alcance de cada herramienta: lectura frente a escritura, repos concretos, espacios delimitados. El RBAC (control de acceso por roles) permite que los usuarios del Host hereden permisos de manera predecible: un lector no podrá aprobar una publicación, un operador no tocará cuentas VIP sin la intervención adecuada. Todo esto se vuelve útil si, además, registras cada invocación con contexto suficiente: herramienta, parámetros, identidad, resultado y marcas de tiempo.
Así es posible auditar o reproducir escenarios, crear alertas por patrones peligrosos o rotar secretos con tranquilidad. La seguridad aquí no es un añadido, es parte del contrato.
MCP aporta orden donde antes había trucos puntuales. Te permite construir agentes que colaboran con tus sistemas respetando límites y dejando constancia. No es otro framework de moda: es una manera de formalizar cómo un modelo interactúa con el mundo, con el grado de control que una organización madura espera. Empieza con algo pequeño, exige permisos explícitos desde el primer día y deja que la interoperabilidad haga el resto.