Un equipo técnico diseñó y desplegó una interfaz que permite a un cliente de lenguaje grande (LLM) formular consultas estructuradas sobre una base de datos B2B con más de un millón de perfiles de empresas, incorporando controles específicos para impedir que el LLM sirva como puente inseguro hacia datos de producción. La solución sitúa un servidor MCP (Model Context Protocol) en AWS como frontera de seguridad entre el LLM y el backend, y usa GraphQL expuesto por AWS AppSync como límite del servicio subyacente. El servidor MCP está implementado en Go y aprovecha la biblioteca mcp-go junto con una capa de herramientas enfocadas en búsqueda, búsqueda asistida por IA y operaciones sobre colecciones.
En la arquitectura, AppSync ofrece el esquema y las operaciones GraphQL que representan la lógica del dominio, mientras que el servidor MCP actúa como traductor y guardián: recibe llamadas de herramienta desde el LLM, normaliza y valida argumentos y, solo entonces, invoca consultas o mutaciones controladas contra AppSync. La capa de herramientas dedicada encapsula funciones concretas — por ejemplo, listar empresas por país, obtener detalles de empresa o gestionar colecciones— y expone contratos estrechos que limitan el alcance de cada operación. Ese límite deliberado reduce la probabilidad de que una petición malformada o una conclusión del LLM provoque accesos fuera de intención.
Una decisión clave del equipo fue tratar la capa MCP como una interfaz de primera clase con sus propios contratos, supuestos de seguridad, estrategia de pruebas y controles operativos, en lugar de considerarla un simple envoltorio conveniente sobre la API existente. En la práctica, esto implicó separar explícitamente operaciones de lectura y escritura a nivel de herramienta y aplicar una política por defecto que deniega mutaciones. Esa separación y la negación por defecto no solo reducen la exposición a cambios involuntarios, sino que acotan el perímetro del experimento y facilitan el tránsito seguro desde prototipos hacia entornos de producción supervisados.
El flujo end-to-end especificado comienza cuando el cliente LLM realiza una llamada de herramienta sobre el transporte MCP stdio con una carga JSON, por ejemplo: {"query": "SaaS companies in Germany", "country": "DE", "limit": 20}. El servidor mcp-go recibe la llamada y la despacha al manejador registrado bajo el nombre de la herramienta correspondiente; ese manejador valida y normaliza los argumentos antes de contactar al backend. En la fase de ejecución GraphQL, cada herramienta construye un mapa de variables y realiza la invocación mediante client.Execute(ctx, query, variables, &result) contra AppSync. El cliente GraphQL centraliza la gestión de autenticación — soportando OpenID Connect bearer token, API key o AWS SigV4— y abstrae el manejo de errores HTTP como 401, 404 y 429 para que la lógica superior procese fallos de forma consistente.
La respuesta de AppSync se deserializa primero en tipos internos de la capa GraphQL (por ejemplo, gqlCompanyModelV2 o gqlCollection) y a continuación se transforma en formas planas y apropiadas para consumo por modelos de IA (CompanySummary, CompanyDetail, Collect). Mantener formas de respuesta estrechas y bien definidas facilitó la validación independiente del cliente LLM y evitó que ambigüedades del prompt se filtraran hacia el backend. Esa claridad de contrato también simplificó los chequeos de seguridad y las reglas de autorización, al limitar los campos y estructuras que cada herramienta puede devolver.
En el plano de pruebas y operación, capturar las variables GraphQL reales enviadas por cada herramienta aumentó considerablemente el valor de los tests simulados: permitió detectar errores de normalización — por ejemplo, resolución incorrecta de códigos de país— y la ausencia de capping de límites antes de que las peticiones alcanzaran AppSync. Sin embargo, no todos los fallos pudieron preverse con pruebas unitarias aisladas: un incidente de producción crítico relacionado con la operación create_collection no fue detectado por tests locales y apareció como un error de puntero nulo en una función Lambda. Como respuesta, el equipo mantuvo la validación contra sistemas reales — mediante la herramienta de inspección MCP Inspector — como una puerta de liberación obligatoria para captar fallos que solo se manifiestan en integración completa.
Por qué importa: la experiencia demuestra que al conectar un LLM a datos empresariales a gran escala, la arquitectura y los límites de las herramientas importan tanto o más que el protocolo o el transporte escogido. Diseñar el MCP como una interfaz con contratos explícitos, limitar el poder de cada herramienta, separar roles de lectura y escritura y exigir validación en sistemas reales reduce riesgos operativos, mejora la auditabilidad y facilita la observabilidad en entornos que manejan más de un millón de perfiles empresariales.
Fuentes
Respuestas (0)
Aún no hay respuestas en este tema.
