Dentro del protocolo de contexto modelo (MCP): arquitectura, motivación y uso interno

Introducción

Las aplicaciones impulsadas por LLM han creado una necesidad apremiante de modelos para acceder a datos actualizados y específicos del dominio de diversas fuentes. MCP aborda este problema proporcionando un protocolo unificado que estandariza la forma en que las aplicaciones pueden exponer datos y capacidades de forma dinámica a cualquier aplicación impulsada por LLM.

Descripción general de MCP

En esencia, MCP sigue una arquitectura cliente-servidor basada en JSON-RPC en la que una aplicación host puede conectarse a varios servidores:

• Anfitriones MCP son aplicaciones impulsadas por LLM como Claude Desktop, IDEs o herramientas de inteligencia artificial que desean acceder a los datos a través de MCP.
• Clientes MCP implementar el protocolo MCP del lado del cliente en diferentes lenguajes de programación. Son el puente a través del cual los hosts MCP se conectan con los servidores MCP.
• Servidores MCP exponer datos y capacidades específicos a través del protocolo MCP. Puede proporcionar tres tipos principales de capacidades:
  • Recursos son datos que los servidores MCP ponen a disposición de las aplicaciones para que los lean. Pueden incluir el contenido de los archivos, las respuestas de la API, etc. Los recursos están controlados por la aplicación; las aplicaciones deciden cómo incluirlos en el flujo de usuarios.
  • Herramientas son las capacidades y los datos expuestos por los servidores MCP. Por ejemplo, un servidor MCP de Kubernetes puede ofrecer herramientas para obtener todos los pods y eliminar un pod. Las herramientas están controladas por modelos. Los LLM deciden llamarlos en función del contexto dado.
  • Indicaciones son interacciones de usuario o flujos de trabajo configurables expuestos por el servidor MCP. Están controlados por el usuario. Las aplicaciones LLM deciden cómo exponerlas para que el usuario pueda seleccionar la solicitud adecuada.

Transportes

Los transportes definen la forma en que un cliente y un servidor MCP se comunican entre sí.

ESTUDIO

En esta configuración, el cliente MCP del host MCP es responsable de hacer funcionar el servidor MCP en la misma máquina. La comunicación entre el cliente MCP y el servidor MCP se realiza mediante STDIN y STDOUT. Aquí, un servidor MCP solo se comunica con un único cliente MCP.

Una configuración típica tiene este aspecto:

Ejemplo: Puedes ejecutar el servidor MCP de GitHub de forma local con Docker y un token de acceso personal (PAT)

GitHub - github/github-mcp-server: servidor MCP oficial de GitHub

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

Autorización

Por lo general, la autorización se puede realizar de dos maneras:

1. Los usuarios pueden usar variables de entorno para pasar su token al proceso del servidor MCP. Este es el método más utilizado.
2. El servidor MCP puede implementar el flujo de dispositivos OAuth2. Sin embargo, la especificación oficial de MCP no describe nada.

Limitaciones

• El dispositivo del usuario, que ejecuta la aplicación impulsada por LLM, debe instalar Docker o Node/Python. Si bien esto no es un problema para un desarrollador, reduce drásticamente la cantidad de personas que pueden usar el servidor MCP.
• Dado que el servidor MCP está presente y ejecutándose en el dispositivo del usuario, las actualizaciones se vuelven engorrosas y la rápida iteración se ve afectada.
• Las aplicaciones web que se ejecutan en el navegador no pueden usar esto.
• Sin el flujo de dispositivos OAuth2, los usuarios deben configurar sus tokens para cada servidor MCP. Los tokens no suelen almacenarse de forma segura en el dispositivo y la rotación es engorrosa.

Dadas las limitaciones, el transporte STDIO no es adecuado para crear servidores MCP personalizados sobre el servicio y la fuente de datos de una empresa o suscripciones SaaS como GitHub o Slack. Sin embargo, será útil para los casos de uso de herramientas para desarrolladores en los IDE.

HTTP transmisible

El HTTP transmisible permite a los servidores MCP gestionar varios clientes MCP que se conectan y se comunican mediante el protocolo HTTP. Esto elimina muchas de las limitaciones del transporte de STDIO. Principalmente:

1. Ya no necesitamos alojar el servidor MCP en el dispositivo del usuario; se puede alojar en cualquier lugar.
2. Las nuevas capacidades agregadas al servidor MCP están disponibles al instante para todos los usuarios.
3. Las aplicaciones web que se ejecutan en el navegador pueden usar esto.

Autorización

La autorización de este transporte se está desarrollando activamente. La última especificación publicada el 26 de marzo de 2025 menciona:

1. La implementación de MCP Auth debe seguir OAuth 2.1.
2. La implementación de MCP Auth debe seguir el registro dinámico de clientes.

Un flujo de autenticación típico tendría un aspecto similar al siguiente:

En el flujo anterior, el servidor MCP que emite los tokens actúa como un recurso y un servidor de autorización. Esto no es práctico para los servidores MCP de Slack, GitHub, etc., donde el proveedor ya implementa su servidor de autorización OAuth2. Los servicios alojados internamente de una empresa detrás de los servidores de autorización proporcionados por un IdP presentan el mismo problema (por ejemplo, la instalación de ArgoCD detrás de un servidor de autorización proporcionado por Okta).

La especificación permite delegar esto en un servidor de autorización de terceros, pero el servidor MCP debe emitir su token y administrar la relación con el token de terceros. Esto anula todos los beneficios de un servidor de autorización de terceros, ya que el servidor MCP necesita implementar una administración segura de los tokens y las rutas OAuth2.

Limitación

• Los servidores MCP con autenticación requieren una infraestructura como una base de datos para almacenar y administrar de forma segura el ciclo de vida de sus tokens. De hecho, cada servidor MCP se convertiría en su propio servidor de autorización, que es redundante e imposible de mantener en una empresa. La comunidad está trabajando activamente para modificar la especificación de autorización para mejorarla.
• Los proveedores como Atlassian, Sentry, Slack, Github, etc., no admiten el registro dinámico de clientes (DCR) ni siquiera admiten el cliente público OAuth2. Construir servidores MCP sobre la base de estos proveedores resulta más difícil para la comunidad y supone más trabajo para el proveedor. Atlassian publicó recientemente su propio servidor MCP, pero su implementación de DCR solo permite host local y unos pocos URI de redireccionamiento seleccionados, como Claude, etc.

El enfoque de TrueFoundry

En TrueFoundry, queremos que nuestros colegas puedan conectar activamente sus cuentas de Atlassian, Sentry, Slack, GitHub, etc. a LLM como contexto adicional. También queremos asegurarnos de que todos los empleados solo puedan acceder a los recursos o tomar medidas sobre los recursos a través de los LLM para los que estén autorizados. MCP + OAuth2 parece la manera perfecta de exponer esto.

• Queremos centrarnos en escribir servidores MCP de buena calidad para exponer los datos y las capacidades de manera más eficiente a los LLM. Queremos hacerlo de forma segura, respetando los límites de RBAC definidos por el proveedor.
• No queremos mantener servidores de autorización adicionales para diferentes servidores MCP. Queremos reutilizar las capacidades de OAuth2 de los proveedores.
• Por lo general, los proveedores solo admiten clientes confidenciales de OAuth2. El DCR y el cliente público ni siquiera son una opción.
• La especificación de autorización de MCP aún está cambiando activamente y se está trabajando en ella. No podemos esperar a que se estabilice para trabajar en ello.

Teniendo en cuenta lo anterior, se nos ocurrió la siguiente arquitectura.

Aquí hay algunos componentes.

Servidores MCP

Creamos servidores HTTP MCP para proveedores como Slack, Sentry, Atlasian, Github, etc., siguiendo el transporte HTTP Streamable.

Estos servidores MCP actúan como proxy entre la LLM y las API HTTP del proveedor. Tenga en cuenta que esta no es una traducción 1:1. Las API HTTP de estos proveedores tienen una gran cantidad de contenido innecesario que puede hacer fracasar fácilmente el LLM y llenar la ventana de contexto. Por ejemplo, una herramienta de módulos de listas de un servidor MCP de Kubernetes tendrá mucho contenido duplicado, ya que la especificación del módulo se repite en varios módulos. Campos grandes, como Campos gestionados, no será necesario para la mayoría de las solicitudes de los usuarios. Otros proveedores de SaaS tendrán entidades principales anidadas, campos que no son funcionales, como la URL del avatar, etc. Es aquí donde queremos dedicar la mayor parte de nuestro tiempo de desarrollo. Con el tiempo, necesitaremos un sistema en MCP que pueda ayudar a los LLM a descubrir el modelo de datos de un sistema y, a continuación, a consultar de forma dinámica campos de recursos específicos.

Estos servidores MCP esperan un encabezado de autorización HTTP y lo transmiten directamente a la API HTTP del proveedor.

Registro de servidores MCP en TrueFoundry

Tras implementar los servidores MCP, creamos aplicaciones OAuth2 o clientes confidenciales para cada proveedor. Este es el aspecto que tiene Slack.

Arriba, también puedes observar que el URI de redireccionamiento del autorizador está configurado. Por lo general, tiene un aspecto parecido a https://base-url/mcp-integrations/oauth2/callback.

Luego integramos el servidor MCP junto con la URL.

Podemos usar los alcances para hacer que toda esta integración sea de solo lectura, si queremos o damos permiso para tipos de recursos específicos. Incluso si el servidor MCP tiene herramientas para «escribir» cualquier recurso y el usuario tiene acceso de «escritura», los LLM no podrán obtener el mismo privilegio.

Selección del servidor MCP en la puerta de enlace TrueFoundry y autorización

Una vez integrado, podemos seleccionar el servidor MCP en Gateway Playground.

Si el usuario no está autorizado, utilizamos la información del cliente de OAuth2 en la integración y guiamos al usuario a través del flujo de código de autorización de OAuth2. Al final del proceso, TrueFoundry guarda de forma segura los tokens de acceso y actualización (si se admiten y están habilitados).

Podemos eliminar nuestras credenciales de TrueFoundry o incluso revocarlas directamente del proveedor.

¡Empieza a usarlo!

Una vez autorizado, puede usar el contexto de los servidores MCP directamente en nuestro Playground.

Tenga en cuenta que no pasamos ninguna credencial de OAuth2 a la interfaz. La interfaz llama a una API:

curl -X POST "https://base-url/api/llm/agent/responses" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai-main/gpt-4o-mini",
    "messages": [
      {
        "role": "user",
        "content": "what are the issues in my app"
      }
    ],
    "tools": [
      {
        "type": "mcp-server",
        "integration_fqn": "truefoundry:custom:devtest-mcp-servers:mcp-server:sentry",
        "tools": ["list_projects", "list_issues"]
      },
      {
        "type": "mcp-server",
        "integration_fqn": "truefoundry:custom:devtest-mcp-servers:mcp-server:slack"
      }
    ]
  }'

‍

LLM Gateway implementa el bucle «agentic» y envía los mensajes iniciales y las descripciones de las herramientas del servidor MCP al LLM. El usuario también puede filtrar las herramientas expuestas al LLM. Según la respuesta del LLM, LLM Gateway puede comunicarse con los servidores MCP y transmitir las credenciales de las personas que llaman. Actualizamos automáticamente las credenciales de corta duración. Las actualizaciones se envían a la interfaz mediante SSE.

Conclusión

Este flujo de MCP + OAuth2 permitió a nuestros colegas incorporar de forma segura datos de proveedores como Slack, GitHub, Sentry, etc., en su flujo de trabajo centrado en LLM.

Un par de casos de uso,

• Los LLM pueden acceder a Sentry a través de MCP para obtener detalles de los errores y correlacionarlos con los cambios de código relacionados desde GitHub para una depuración más rápida.
• Los LLM crean, actualizan y consultan tickets de Jira a través de MCP, lo que agiliza los flujos de trabajo de los desarrolladores.
• Los LLM pueden acceder a las conversaciones de Slack a través de MCP para analizar y resumir los largos hilos de debate, lo que ayuda a los equipos a entender rápidamente las decisiones y las acciones sin tener que leer los registros de chat completos.