MCP lleva los agentes de IA a tus APIs, pero no decide qué pueden ver
Dar acceso a un agente a un sistema interno es la parte fácil; decidir qué campos ve y qué operaciones puede escribir es el problema, y ahí GraphQL lleva ventaja.
MCP (Model Context Protocol) resuelve la parte sencilla: exponer un sistema interno, por ejemplo una API de gestión de pedidos, para que un agente de IA lo alcance. Lo que no resuelve es qué ve ese agente cuando llega. Un servidor MCP que devuelve todo lo que le pasa su sistema de origen es un agujero de seguridad: datos personales identificables, detalles financieros y de fraude, notas operativas que nunca debieron salir de la red interna.
El parche evidente es filtrar la respuesta. Pero entonces finanzas necesita una vista distinta de los pedidos, soporte necesita las notas internas, otro equipo conecta el inventario, y acabas manteniendo decenas de herramientas solapadas. La aplicación tradicional ya sabe hacer esto: el backend comprueba los permisos del usuario, ejecuta la llamada a la API de arriba y devuelve solo la vista que corresponde. Con agentes que componen operaciones en tiempo de ejecución, ese control se vuelve urgente.
Un contrato por campo, no por herramienta
La salida que se propone es un contrato determinista a nivel de campo, independiente tanto de las APIs de origen como de los agentes que tiran de él. MCP define cómo el agente descubre y llama herramientas; el contrato define qué puede tocar. Son capas distintas y hacen falta las dos. GraphQL encaja porque nació justo para eso: que cada llamada pida exactamente los campos que necesita. Una consulta de estado de pedido puede pedir solo el estado y la fecha límite de envío, y la respuesta trae esos dos campos y nada más, aunque el sistema de origen devuelva el registro completo.
La gracia es que la regla vive en el campo, no en cada herramienta. Si un agente pide una puntuación interna de fraude o el número de seguridad social de un cliente, el servidor rechaza la petición o hace que esos campos sean inalcanzables. Se escribe una vez y aplica a cualquier operación que los solicite, sin que cada autor de herramientas tenga que acordarse de borrar la misma propiedad.
Las escrituras funcionan igual. Un mutation como requestInventoryTransfer expone una acción de negocio concreta: el runtime la autoriza y el servicio de debajo comprueba disponibilidad y aprobaciones antes de aceptarla. Sin ese permiso el agente no puede hacer su trabajo; con acceso sin restricciones, puede cambiar recuentos de stock, cancelar pedidos o emitir reembolsos.
Nada de esto obliga a reemplazar lo que ya corre en producción. Una capa GraphQL se pone delante de servicios que exponen REST, gRPC o SOAP. La API de pedidos sigue devolviendo su registro ancho a la capa de integración mientras el agente recibe únicamente los campos permitidos.
GraphQL lleva más de una década aplicando este modelo: Shopify, Netflix, Airbnb, Expedia Group y Walmart están entre las compañías que lo usan a diario. La novedad no es la técnica, sino quién llama. Ahora el cliente no es una aplicación escrita a mano, es un agente que decide en tiempo de ejecución qué operaciones encadenar. MCP pone los sistemas de negocio al alcance del agente; el contrato de campos determina si ese acceso es algo que la organización puede controlar. La pieza técnica existe y está probada. Lo que aún no está resuelto es cómo se integra ese contrato en cada servidor MCP que se despliegue.
