Introducción

El Model Context Protocol, o MCP, es un protocolo abierto para conectar aplicaciones de IA con fuentes externas de contexto y capacidades ejecutables. Una aplicación puede utilizar MCP para acceder a archivos, consultar un servicio, invocar lógica de negocio o reutilizar una plantilla de prompt mediante un modelo de interacción coherente. La idea fundamental es la separación: la aplicación orquesta la conversación, mientras que un servidor MCP expone una interfaz controlada para acceder a datos o ejecutar acciones.

Esta separación es importante porque las aplicaciones de IA suelen necesitar muchas integraciones. Sin un protocolo compartido, cada aplicación debe definir su propio formato de conectores, mecanismo de descubrimiento, flujo de autenticación y esquema de herramientas para cada servicio. MCP proporciona a los hosts y servidores un contrato común, lo que reduce el código específico de cada integración y facilita la inspección de las capacidades. Por sí solo, no hace que un modelo de lenguaje sea preciso, no sustituye a un sistema de autorización ni garantiza que una operación externa sea segura.

Un modelo mental útil es el de un puente controlado. El modelo propone que una capacidad puede ser útil, el host decide si la solicitud está permitida, un cliente MCP envía una solicitud del protocolo y el servidor ejecuta o rechaza la operación. A continuación, el resultado vuelve a través del cliente hasta el host, que decide cómo presentárselo al modelo y al usuario.

Arquitectura principal

Un host MCP es la aplicación de IA completa con la que interactúa el usuario. Un asistente de escritorio, un entorno de programación o un servicio de agentes personalizado pueden actuar como host. El host controla el flujo de la conversación y normalmente decide qué servidores están configurados, qué permisos se aplican, cómo se incorporan los resultados de las herramientas al contexto del modelo y si el usuario debe aprobar una operación.

Un cliente MCP es el componente del protocolo gestionado por el host. En una arquitectura habitual, el host crea una conexión de cliente por cada servidor MCP. El cliente gestiona la comunicación del protocolo, la inicialización, la negociación de capacidades, la correlación de solicitudes, las notificaciones y los detalles específicos del transporte. El cliente no es el modelo de lenguaje ni la implementación del servidor; es la capa de conexión entre el host y un servidor.

Un servidor MCP es un programa que expone capacidades mediante MCP. Puede ejecutarse localmente como un subproceso o de forma remota detrás de un transporte de red, según el despliegue y la compatibilidad del cliente. Un servidor puede leer de una fuente de datos autorizada, invocar un servicio externo o implementar lógica de dominio. Debe exponer una interfaz limitada y comprensible, y aplicar su propia validación en lugar de asumir que el host o el modelo han comprobado cada entrada.

Por lo general, el modelo no abre conexiones de red sin procesar con los servidores. En su lugar, el host pone a disposición las capacidades descubiertas mediante MCP e incorpora los resultados relevantes a la interacción con el modelo. Este límite mejora el control y la observabilidad, ya que el host puede registrar las solicitudes, exigir confirmación, aplicar políticas y gestionar los fallos antes de que se produzca una acción externa.

Flujo del protocolo

Una sesión de MCP comienza con la inicialización. El cliente y el servidor identifican la información del protocolo e intercambian capacidades que describen qué funciones admite cada parte. El cliente debe completar este paso del ciclo de vida antes de utilizar las funciones normales del servidor. Además, el cliente debe contemplar la posibilidad de que un servidor no admita una capacidad opcional, en lugar de asumir que todos los servidores implementan todas las funciones.

Después de la inicialización, el cliente puede descubrir las funciones del servidor. Las herramientas describen operaciones que pueden invocarse con entradas estructuradas, como buscar en un sistema de seguimiento de incidencias o crear un evento de calendario. Los recursos representan datos que pueden leerse como contexto, como un documento o el resultado de una consulta a una base de datos. Los prompts representan estructuras de mensajes o flujos de trabajo reutilizables que un servidor puede proporcionar al host. Estas categorías tienen propósitos distintos y no deben tratarse como etiquetas intercambiables.

Un flujo típico de una herramienta consta de varias etapas. El host pone a disposición del modelo la definición de una herramienta, el modelo propone una llamada con argumentos y el host evalúa las políticas y el consentimiento del usuario. Si se aprueba, el cliente envía la solicitud al servidor. El servidor valida los argumentos, realiza la operación si está permitida y devuelve un resultado o un error. A continuación, el host decide si el resultado debe mostrarse al usuario, devolverse al modelo o ambas cosas.

Los mensajes de MCP utilizan un protocolo estructurado basado en conceptos de JSON-RPC, por lo que las solicitudes, los resultados, los errores y las notificaciones tienen funciones definidas. El transporte exacto es independiente del significado del mensaje. Las integraciones locales suelen utilizar una conexión basada en procesos, como la entrada y salida estándar, mientras que las integraciones remotas pueden utilizar un transporte basado en HTTP compatible con la implementación. Un transporte lleva mensajes; no decide si una acción está autorizada.

Escenario práctico de integración

Consideremos un asistente interno de soporte conectado a dos servidores. Un servidor de tickets ofrece una herramienta para buscar tickets y otra para añadir una nota interna. Un servidor de documentación ofrece recursos que contienen páginas de resolución de problemas aprobadas. El host se conecta a ambos servidores mediante clientes de MCP independientes y descubre sus capacidades durante el arranque.

Cuando un ingeniero de soporte pregunta por la causa probable de un error conocido, el host puede permitir que el modelo utilice la herramienta de búsqueda de tickets y los recursos de documentación. El resultado de la búsqueda puede identificar incidencias relacionadas, mientras que el recurso de documentación proporciona contexto técnico aprobado. El host puede presentar ambos resultados al modelo junto con la información de origen, lo que permite al modelo redactar una respuesta fundamentada en los datos disponibles.

Si el ingeniero pide al asistente que añada una nota a un ticket, el flujo cambia porque la operación tiene un efecto externo. El host debe mostrar el ticket de destino y la nota propuesta, verificar que el usuario tiene permiso y solicitar confirmación cuando corresponda. El servidor debe seguir validando el identificador del ticket, la longitud de la nota y el contexto de autorización. La aprobación de una capa no elimina la responsabilidad de validación de las demás.

Las pruebas más útiles abarcan el límite completo, no solo la respuesta final. Hay que verificar que la inicialización se complete correctamente, que las capacidades no compatibles se gestionen de forma adecuada, que los argumentos malformados produzcan un error controlado, que una operación denegada no modifique el estado externo y que un tiempo de espera agotado del servidor no haga que el host muestre un mensaje de éxito inventado. Estas pruebas hacen explícito el comportamiento de la integración y facilitan su diagnóstico.

Modos de fallo habituales

Un error frecuente consiste en confundir MCP con un framework de agentes autónomos. MCP define la comunicación y la exposición de capacidades; no prescribe un algoritmo de planificación, un proveedor de modelos, un sistema de memoria ni una interfaz de usuario concretos. Un agente puede usar MCP, pero el ciclo del agente sigue siendo una decisión de diseño de la aplicación. Otro error consiste en tratar cada funcionalidad del servidor como una herramienta, lo que puede fomentar acciones innecesarias cuando sería más apropiado utilizar recursos de solo lectura.

Los fallos de seguridad suelen deberse a un exceso de confianza. Las descripciones de las herramientas son metadatos útiles, pero no constituyen una frontera de seguridad completa. Valide las entradas en el servidor, restrinja el acceso a archivos y redes, proteja las credenciales y aplique la autorización en el límite de cada operación. Evite exponer una herramienta general de ejecución de comandos cuando una operación pequeña y específica del dominio pueda satisfacer el caso de uso.

Los fallos operativos suelen estar relacionados con la gestión del ciclo de vida y del transporte. Un cliente puede intentar realizar solicitudes antes de la inicialización, asumir que existe una capacidad, perder una conexión sin borrar el estado o tratar un tiempo de espera agotado como un resultado exitoso. Registre la identidad del servidor, el tipo de solicitud, la información de correlación, la duración y los detalles de error sanitizados. No registre tokens, contraseñas ni contenido confidencial del usuario simplemente para facilitar la depuración.

Otro fallo consiste en permitir que los resultados de las herramientas entren en el contexto del modelo sin comprobar su origen o relevancia. El contenido externo puede incluir instrucciones engañosas o datos cuya repetición no sea segura. El host debe mantener límites claros entre las instrucciones, los datos recuperados y las acciones aprobadas por el usuario, mientras que la aplicación define cómo se gestiona el contenido no confiable.

Resumen

MCP proporciona una forma estándar para que las aplicaciones de IA conecten los modelos con contexto y capacidades externas. El host se encarga de la experiencia de la aplicación y de las decisiones de política, el cliente gestiona una conexión de protocolo y el servidor expone datos u operaciones validados. Mantener estas responsabilidades separadas facilita el análisis y las pruebas de las integraciones.

El flujo de trabajo principal comprende la inicialización, la negociación de capacidades, el descubrimiento, la invocación o recuperación controlada y la gestión de resultados. Las herramientas son adecuadas para operaciones invocables, los recursos para datos contextuales y los prompts para plantillas de interacción reutilizables. El protocolo puede transportar mensajes mediante distintos transportes, pero la elección del transporte no sustituye la autenticación, la autorización, la validación ni la observabilidad.

Al diseñar una integración con MCP, comience por la interfaz de servidor útil más pequeña. Defina qué expone el servidor, identifique qué operaciones tienen efectos secundarios, decida dónde se requiere el consentimiento y especifique el comportamiento ante fallos antes de conectar el modelo. Una aplicación fiable trata la salida del modelo como una propuesta, aplica la política en el host y el servidor, y verifica los resultados externos antes de informar de un éxito.