Desarrollo de servidores MCP: convierte a la IA con agentes en el "cliente cero" de tu API

Los equipos de ingeniería de Red Hat Trusted Profile Analyzer (TPA) y Trustify decidieron experimentar con elprotocolo de contexto de modelo (MCP). En este artículo, analizamos los desafíos que tuvimos que enfrentar a lo largo del proceso para ayudar con nuestra experiencia a otras personas que intenten lo mismo.

A modo de contexto, Red Hat Trusted Profile Analyzer (TPA) es un producto de Red Hat que permite gestionar la lista de elementos de software (SBOM). Almacena dichas listas y relaciona los paquetes en ellas con puntos vulnerables públicos conocidos. Se basa en el proyecto upstream Trustify.

En general, su arquitectura es bastante "tradicional":

• El frontend se desarrolla con elementos de React y PatternFly (trustify-ui).
• El backend se desarrolla con Rust, se conecta a una instancia de base de datos y almacena las SBOM en un almacenamiento compatible con S3.

Estos son los pasos generales que seguimos:

1. diseño de la integración del servidor MCP a TPA/Trustify;
2. definición de las descripciones de las herramientas del servidor MCP;
3. diseño de los parámetros de las herramientas del servidor MCP.

A continuación, analizaremos los aspectos que deben tenerse en cuenta en cada fase y, como resultado final, encontraremos el servidor MCP en GitHub. 

Diseño de la integración del servidor MCP con TPA/Trustify

Antes de detallar la integración entre el servidor MCP y Trustify, enfrentamos un dilema común en la vida de un ingeniero de software: ¿qué biblioteca usaré en este proyecto? ¿Debo comenzar desde cero y desarrollar todo por mi cuenta?

Como verdaderos partidarios del open source, analizamos el panorama actual de las bibliotecas de Rust (Trustify se desarrolla principalmente en Rust, por lo que una biblioteca de este lenguaje era nuestra preferencia) para implementar un servidor MCP.

La búsqueda no tomó mucho tiempo porque MCP proporciona algunas bibliotecas oficiales en su organización de GitHub. Entre ellas, había una desarrollada con Rust.

Esta biblioteca, además de incluir el código necesario para respaldar el desarrollo de un servidor MCP, también proporciona un excelente conjunto de ejemplos para comenzar.

De inmediato, fue evidente que, además de los detalles específicos de la biblioteca para ejecutar el servidor MCP y definir las herramientas disponibles con sus parámetros, teníamos que decidir cómo queríamos que el servidor MCP obtuviera acceso a los datos del backend.

Evaluamos dos opciones diferentes. El servidor MCP podría recuperar los datos de las siguientes maneras:

• conectándose directamente a la base de datos donde el backend de Trustify almacena los datos; o
• llamando a los endpoints de REST proporcionados por el backend de Trustify.

Como te puedes imaginar, ambas opciones presentan ventajas y desventajas, lo que generó un animado debate que resumiré aquí.

Ventajas de conectarse directamente a la base de datos:

1. Se puede acceder a los datos de manera eficaz.
2. Tienes la oportunidad de implementar un enfoque de conversión de texto a SQL.

Desventajas:

1. El servidor MCP debe estar en el mismo nivel de arquitectura que el backend.
2. Se tendría que duplicar el código para gestionar el acceso a los datos en comparación con el código en el backend.
3. Se tendría que gestionar el formato de los datos para definir los resultados de las llamadas de las herramientas de MCP.

Ventajas de llamar a los endpoints de REST:

1. Las llamadas cumplen la autenticación y la autorización que ya se aplican en las API de backend.
2. Los datos disponibles del servidor MCP serán totalmente coherentes con los que están disponibles en la interfaz de usuario, ya que surgen de la misma fuente de datos.
3. Los resultados JSON están disponibles de forma gratuita con solo enviar los resultados que devuelven las API de backend.

Desventajas:

1. El rendimiento es más lento porque se debe pasar por más niveles de arquitectura.

Al final, decidimos llamar a los endpoints de REST desde las herramientas del servidor MCP porque la desventaja de tener que ubicar el servidor MCP junto al backend y "lo suficientemente cerca" de la base de datos era un posible obstáculo, especialmente en el servidor MCP con el transporte stdio que se ejecuta de forma local en los hosts de los desarrolladores.

Convertir "de forma gratuita" el formato de todos los datos en respuestas JSON fue otra ventaja en esta fase inicial de desarrollo.

Definición de las descripciones de las herramientas del servidor MCP

Después de decidir que las herramientas del servidor MCP llamarían a las API de backend, teníamos que determinar la forma en que se describirían las diferentes herramientas. En la primera repetición, queríamos que cada herramienta de MCP llamara a un único endpoint de la API de backend.

Teniendo en cuenta que Trustify documenta los endpoints disponibles con el archivo openapi.yaml de OpenAPI, decidimos usar las descripciones y las definiciones de los endpoints de OpenAPI como las descripciones de las herramientas de MCP. De este modo, pudimos evaluar la documentación de esos endpoints para nuestros usuarios. Esto convirtió a nuestra inteligencia artificial con agentes en el "cliente cero" de nuestras propias API.

Todo esto se ha logrado con el enfoque de mejora continua. Si las descripciones de las API de Trustify son lo suficientemente buenas como para que las gestione un modelo de lenguaje de gran tamaño (LLM), nuestros usuarios también deberían ser capaces de comprender esa documentación.

Aplicar este enfoque nos permite mejorar cada endpoint y nos guía a nuestra próxima decisión de diseño.

Diseño de los parámetros de las herramientas del servidor MCP

A esta altura, nos enfrentamos al problema de los parámetros de entrada para invocar la herramienta y, para comprenderlo, tuvimos que retroceder un paso. El endpoint de Trustify para recuperar una lista de entidades acepta un parámetro de consulta q. Este parámetro permite que los usuarios especifiquen una consulta de acuerdo con la gramática que se define en las especificaciones de OpenAPI. 

Estas son las opciones que teníamos:

1. exponer directamente el parámetro q path del endpoint como el parámetro de entrada de la herramienta de MCP;
2. exponer los campos internos disponibles para crear el valor de consulta para el parámetro q como los parámetros de entrada de la herramienta de MCP.

Probamos ambos enfoques.

El primer enfoque requiere una descripción sólida y detallada del parámetro de consulta que, por el momento, la especificación de OpenAPI no proporciona. Creemos que una lista completa de campos que se puedan consultar debe ser una sección obligatoria de la documentación, no opcional. Sería útil que todos los usuarios tuviesen acceso a esta información.

El segundo enfoque simplifica el proceso para el agente de inteligencia artificial. Al enumerar explícitamente los parámetros de las consultas, como la gravedad del punto vulnerable, la fecha de publicación o la descripción, la información resultante es más útil para el modelo de lenguaje de gran tamaño. Esto elimina la necesidad de que el modelo interprete primero la gramática de una consulta, lo cual puede ser un paso complejo en el primer enfoque.

Otro aspecto que se debe considerar es que enumerar todos los parámetros disponibles de forma explícita en la herramienta de MCP requiere un trabajo constante para mantener la uniformidad con la implementación real del endpoint del backend. Además, exponer solo un subconjunto de los parámetros disponibles limita la versatilidad de la herramienta y no garantiza la reducción de la sobrecarga de mantenimiento.

Decidimos seguir adelante con el uso de un parámetro de consulta q para la herramienta de MCP. Además, mejoraremos su descripción en la definición de OpenAPI para que todos los usuarios puedan beneficiarse.

Reflexiones finales

Al diseñar un servidor MCP, adoptamos el siguiente enfoque:

• El servidor MCP aprovecha las API actuales.
• El servidor MCP aprovecha la documentación de OpenAPI actual.
• Las herramientas del servidor MCP muestran el mismo parámetro que espera el endpoint de la API remota.

Como mencionamos anteriormente, el resultado final está disponible en GitHub.