Con todo cambiando tan rápido, este es el mejor momento para empezar a construir con MCP y agentes de IA en AWS

La idea surgió de una necesidad bastante cotidiana. Como parte de la comunidad, constantemente hablamos sobre servicios, arquitecturas, permisos, configuraciones y problemas que aparecen cuando estamos aprendiendo. Quería explorar una forma de automatizar algunas respuestas a preguntas frecuentes de los miembros del club y, al mismo tiempo, permitir que un asistente consultara información real de AWS.

Por ejemplo, imaginaba preguntarle algo tan sencillo como: ¿Qué buckets tengo creados en Amazon S3?, y recibir una respuesta basada en los recursos de mi cuenta, sin tener que entrar a la consola cada vez.

Fue entonces cuando empecé a explorar MCP y los agentes de IA. Y aquí apareció mi primera confusión: ¿qué diferencia había entre utilizar MCP y conectarme directamente a una API?

Al principio, ambas cosas me parecían bastante similares. Después de todo, si una API permite consultar información y ejecutar acciones, ¿para qué necesitaba otro protocolo?

Esa pregunta terminó siendo una de las partes más interesantes de mi aprendizaje.

Imaginemos que estamos en una cafetería y queremos pedir algo. Normalmente no entramos a la cocina, buscamos los ingredientes y preparamos nuestra bebida. Hablamos con alguien que entiende nuestro pedido, sabe qué opciones existen y se encarga de comunicarlo a la cocina.

Ahora imaginemos que esa cafetería tiene diferentes áreas: bebidas, alimentos y postres. No necesitamos conocer cómo funciona cada una. Simplemente pedimos lo que queremos y alguien coordina nuestra solicitud.

Para mí, esa fue una manera sencilla de empezar a entender MCP.

El asistente de inteligencia artificial sería quien interpreta lo que estoy pidiendo. Los servidores MCP serían como los puntos de atención especializados que ofrecen determinadas capacidades: consultar archivos, buscar información o interactuar con servicios externos.

Y AWS sería uno de esos sistemas con los que queremos trabajar.

La comparación no es perfecta, pero ayuda a entender algo importante: el asistente no necesita conocer todos los detalles internos de cada sistema para descubrir qué herramientas tiene disponibles y utilizarlas.

Aquí sí vale la pena introducir el término técnico.

MCP significa Model Context Protocol, un protocolo abierto que estandariza cómo las aplicaciones de inteligencia artificial pueden conectarse con herramientas y fuentes de información externas.

Un servidor MCP puede exponer herramientas, recursos y otras capacidades. Una aplicación compatible puede descubrirlas y, cuando corresponda, utilizarlas para atender una solicitud.

GitHub

+1

 

Entonces, ¿qué pasa con las API tradicionales?

Las API siguen siendo fundamentales. De hecho, un servidor MCP puede utilizarlas internamente. La diferencia es que MCP proporciona una interfaz estandarizada para que las aplicaciones de IA descubran e invoquen herramientas sin tener que desarrollar una integración completamente distinta para cada una.

Eso fue lo que finalmente me permitió comprender por qué MCP no era simplemente otra API.

Quise aterrizar todo esto en un ejemplo que pudiera entender y explicar fácilmente a otros miembros de la comunidad.

El escenario era sencillo: utilizar un servidor MCP que permitiera consultar los buckets de Amazon S3 desde un asistente de IA.

La conversación que quería conseguir era algo así:

Yo: ¿Qué buckets tengo disponibles en mi cuenta de AWS?

Asistente: Voy a consultar los buckets de Amazon S3 a los que tienes acceso.

A continuación, el asistente debería utilizar una herramienta proporcionada por el servidor MCP, consultar AWS y devolver la información correspondiente.

En lugar de inventar una respuesta o basarse únicamente en lo que el modelo había aprendido durante su entrenamiento, estaría consultando información directamente desde el servicio.

Para entenderlo mejor, dividí mentalmente el proceso en cuatro componentes: el usuario que formula la pregunta, el asistente que interpreta la solicitud, el servidor MCP que expone la herramienta y AWS, que proporciona los datos mediante sus API.
Mientras estudiaba este escenario, encontré algo útil en la documentación de AWS: para utilizar la operación ListBuckets, la identidad que realiza la consulta necesita el permiso s3:ListAllMyBuckets.
Un detalle aparentemente pequeño, pero que nos lleva directamente a otro de los problemas que encontré.

Cuando los permisos IAM complican las cosas

En paralelo a mi exploración de agentes de IA, también estuve trabajando con AWS DevOps Agent.

Y aquí quiero hacer una distinción: AWS DevOps Agent y un servidor MCP personalizado no son el mismo componente ni necesariamente utilizan los mismos mecanismos de integración.

Durante mi experiencia con AWS DevOps Agent me encontré con varios inconvenientes relacionados con permisos de IAM. Entre los errores que tuve que revisar estaban acciones como iam:CreateRole, iam:PassRole y aidevops:CreateOneTimeLoginSession.

En mi exploración también apareció un problema de permisos al intentar conectar el servidor MCP. Todavía tengo pendiente recuperar el mensaje exacto de ese error, así que no sería correcto afirmar que alguno de los errores anteriores fue necesariamente la causa de esa conexión fallida.

Lo interesante es que ambas experiencias me obligaron a prestar más atención a una pregunta que a veces pasamos por alto: ¿con qué identidad está trabajando realmente nuestro asistente y qué puede hacer esa identidad?

Cuando estamos desarrollando una aplicación tradicional, normalmente tenemos bastante claro dónde configurar las credenciales y qué servicio se está invocando. Sin embargo, cuando introducimos asistentes, herramientas externas y diferentes componentes, es fácil perder de vista en qué punto ocurre la autorización.

Mi experiencia con AWS DevOps Agent me hizo revisar con más cuidado ese asunto.

Por ejemplo, en AWS DevOps Agent los permisos para acceder a las funciones del agente son distintos de los permisos que necesita el propio agente para investigar recursos de AWS. Además, los Agent Spaces delimitan qué cuentas, recursos e integraciones están disponibles para cada entorno.

AWS DevOps Agent

+1

 

Eso me ayudó a comprender que conseguir acceso a una interfaz no significa automáticamente tener autorización para consultar cualquier recurso.

Y también me recordó algo que considero esencial al desarrollar soluciones con agentes: no debemos otorgar permisos excesivos únicamente para conseguir que una prueba funcione.

Uno de los aspectos que más me hizo pensar fue descubrir que el problema no siempre está en el modelo de inteligencia artificial.

Podemos tener un asistente capaz de interpretar perfectamente nuestra pregunta, una herramienta correctamente definida y una integración que parece tener sentido desde el punto de vista técnico. Sin embargo, si la identidad utilizada no tiene los permisos necesarios, la operación puede fallar.

En mi caso, la confusión inicial entre MCP y las API tradicionales también hizo más difícil comprender dónde debía buscar el problema.

Estaba intentando aprender varias cosas al mismo tiempo: cómo interactúa un asistente con herramientas externas, qué función cumple un servidor MCP y cómo intervienen los permisos de AWS.

Mirando esa experiencia, ahora entiendo que habría sido mejor separar cada parte y comprobarla individualmente.

Primero, verificar que el servidor MCP pudiera iniciar correctamente. Después, comprobar que el cliente fuera capaz de descubrir sus herramientas. Finalmente, validar que la identidad utilizada por el servidor tuviera los permisos necesarios para ejecutar las operaciones en AWS.

Estos son pasos que tomaría para depurar la integración; no quiero presentarlos como una secuencia de pruebas completadas porque todavía no tengo todos los registros técnicos para respaldarla.

Lo que sí puedo afirmar es que trabajar con AWS DevOps Agent, revisar errores de IAM y estudiar la integración con MCP cambió mi manera de abordar este tipo de soluciones.

Antes estaba concentrado principalmente en conseguir que el asistente respondiera. Ahora me interesa mucho más entender qué ocurre detrás de cada respuesta.

La idea original de automatizar respuestas a preguntas frecuentes sigue pareciéndome un buen punto de partida.

Pienso, por ejemplo, en un miembro nuevo del club que quiera comprender qué diferencia hay entre Amazon EC2 y AWS Lambda. Un asistente podría ayudarle a consultar información técnica preparada para la comunidad.

Pero también imagino escenarios más prácticos, como consultar recursos en un entorno de laboratorio o identificar qué herramientas están disponibles para realizar determinada tarea.

Por supuesto, no todas esas funcionalidades necesitan MCP. Para responder preguntas frecuentes basadas en documentación, podríamos utilizar otras arquitecturas. MCP adquiere especial relevancia cuando queremos conectar el asistente con herramientas que pueda descubrir y utilizar de manera estandarizada.

También tendría mucho cuidado con la seguridad. No es lo mismo ofrecer información general sobre servicios de AWS que permitir consultas a recursos reales de una cuenta.

Empezaría por herramientas de solo lectura, entornos controlados, permisos mínimos y resultados fáciles de verificar.

Me parece una buena forma de aprender sin convertir una demostración sencilla en una arquitectura innecesariamente compleja.

Si algo me han enseñado estas experiencias es que construir con agentes de IA implica mucho más que escribir un buen prompt.

También significa comprender integraciones, permisos, límites de acceso y las responsabilidades de cada componente.

MCP me ayudó a entender una forma de conectar asistentes con herramientas externas. AWS DevOps Agent, por su parte, me permitió enfrentar problemas reales relacionados con permisos y acceso a capacidades dentro de AWS.

Son experiencias diferentes, pero ambas apuntan hacia algo que cada vez considero más importante: aprender a construir sistemas que no solamente respondan, sino cuyas acciones podamos comprender, verificar y controlar.

Todavía tengo cosas pendientes por probar y documentar, especialmente la implementación completa del servidor MCP para Amazon S3. Prefiero compartir esa limitación antes que presentar una demostración como terminada.

Como AWS Community Builder, creo que compartir las dudas, los errores y las pruebas incompletas también puede ser útil. Muchas veces otra persona está intentando resolver exactamente el mismo problema.

Y ahora me gustaría dejarle una pregunta a la comunidad:

¿Ustedes por dónde empezarían al construir un agente de IA conectado a AWS: por desarrollar las herramientas con MCP, por diseñar los permisos de IAM o por resolver primero un caso de uso pequeño que realmente necesite automatización?