Comprendiendo los agentes de IA: llamadas a herramientas, MCP y el bucle del agente
Cómo la llamada a herramientas, MCP y el bucle del agente se integran en la arquitectura real de los agentes de IA, partiendo del LLM mejorado y omitiendo los términos de moda.
Fuentes: Tool Calling vs MCP: How AI Agents Actually Use Tools
Cuando la gente comienza a explorar los agentes de IA, siempre aparecen los mismos pocos términos en todas partes:
Agentes. Herramientas. Llamadas a funciones. MCP. Contexto. Memoria.
A primera vista, parecen un montón de tecnologías no relacionadas.
Pero si se invierte tiempo suficiente en analizar cómo se construyen los sistemas agentes reales, especialmente examinando los artículos técnicos de Anthropic sobre agentes y MCP, comienza a surgir una arquitectura subyacente mucho más simple.
Este artículo explica esa arquitectura desde un enfoque práctico, orientado a desarrolladores.
¿Qué hace realmente que un sistema de IA sea un agente?
Una aplicación típica basada en LLM puede representarse de esta manera:
User
↓
LLM
↓
Response
Aquí, el modelo simplemente recibe entrada y genera salida.
Pero muchas tareas reales no pueden resolverse únicamente generando texto.
Tomemos esta solicitud como ejemplo:
“Revisa este repositorio de GitHub en busca de problemas abiertos, profundiza en el que sea más importante y haz un resumen de lo que aún necesita corrección.”
Para manejar algo así, el sistema debe:
- Comprender la solicitud.
- Decidir qué información necesita.
- Elegir una herramienta adecuada.
- Ejecutar la herramienta.
- Inspeccionar el resultado.
- Decidir qué hacer a continuación.
- Potencialmente llamar a otra herramienta.
- Generar la respuesta final.
Es exactamente aquí donde la noción de un sistema agente resulta útil.
Anthropic establece una distinción clara entre flujos de trabajo y agentes.
Un flujo de trabajo sigue una secuencia fija de pasos:
LLM → Step 1 → Step 2 → Step 3 → Answer
Un agente, por otro lado, decide por sí mismo qué acciones y herramientas utilizar:
┌──────────────┐
│ LLM │
└──────┬───────┘
│
choose action
↓
Tool
↓
Result
│
└──────────→ LLM
│
choose next action
El detalle clave no es solo que un LLM esté involucrado en alguna etapa del proceso.
Sino que el propio LLM tiene voz en la configuración del proceso.
Anthropic presenta a los agentes como sistemas en los cuales el LLM dirige activamente su propio flujo de trabajo y uso de herramientas, mientras que los flujos de trabajo dependen de una lógica de orquestación definida de antemano por el desarrollador.
El LLM ampliado
Una idea especialmente útil de los materiales de Anthropic es el concepto del LLM ampliado.
En lugar de imaginar un LLM simplemente como:
LLM → Text
puedes imaginarlo como:
┌─────────────┐
│ LLM │
└──────┬──────┘
│
┌────────────┼────────────┐
↓ ↓ ↓
Retrieval Tools Memory
Según esta perspectiva, el LLM adquiere la capacidad de ir más allá de sus propios parámetros entrenados e interactuar con información y capacidades externas.
Anthropic describe la recuperación de información, el acceso a herramientas y la memoria como formas de ampliación que convierten a un LLM simple en una pieza fundamental para construir sistemas agentes más capaces.
Esto es importante porque aclara que el modelo en sí no se transforma mágicamente en un sistema de software completo.
Es la aplicación que rodea al modelo la que proporciona esas capacidades adicionales.
¿Entonces qué es la llamada a herramientas?
Antes de adentrarnos en MCP, ayuda observar algo más básico.
Imagínese darle a un LLM acceso a una herramienta como:
get_weather(city)
Luego un usuario pregunta:
"¿Cuál es el clima en Colombo?"
En lugar de responder de inmediato, el modelo puede responder con una solicitud para llamar a la función:
{
"name": "get_weather",
"arguments": {
"city": "Colombo"
}
}
La aplicación que lo rodea es la que realmente ejecuta esta función.
Esa ejecución podría devolver algo como:
{
"temperature": 29,
"condition": "Partly cloudy"
}
Esta salida se vuelve a introducir en la ventana de contexto del modelo.
A partir de allí, el modelo puede generar una respuesta como:
"Actualmente hay 29°C y está parcialmente nublado en Colombo."
El detalle crucial aquí es:
El LLM solo decide si se debe llamar a una herramienta. La aplicación es la que realmente la ejecuta.
El modelo nunca establece una conexión directa con el servicio meteorológico en sí.
Llamar a herramientas no es MCP
Se podría decir que esta es la distinción más importante de toda esta área.
Llamar a herramientas y MCP abordan dos problemas diferentes.
Llamar a herramientas se refiere fundamentalmente al intercambio entre:
LLM
↓
Tool request
↓
Application
↓
Tool result
MCP, por el contrario, es un protocolo diseñado para estandarizar la forma en que las aplicaciones de IA se conectan a herramientas externas, fuentes de datos y contexto.
Anthropic lanzó MCP en noviembre de 2024 como un estándar abierto cuyo objetivo es conectar a los asistentes de IA con los sistemas donde se encuentran los datos y herramientas reales.
Según la propia documentación de Anthropic, MCP estandariza la forma en que las aplicaciones suministran contexto a los LLM, y la comparación que hacen es que funciona como un puerto USB-C para las aplicaciones de IA.
En resumen:
Tool Calling
↓
How an LLM requests an action
MCP
↓
How AI applications can standardize connections
to external tools and data
En otras palabras, estas dos ideas se complementan en lugar de competir entre sí.
Qué aporta realmente MCP
Imagínese una aplicación de IA que debe acceder a:
- GitHub
- PostgreSQL
- Google Drive
- Slack
- el sistema de archivos local
- APIs internas de la empresa
Sin algún protocolo compartido, cada una de estas conexiones podría necesitar su propio cableado personalizado. Podría terminar fácilmente con una configuración como esta:
AI Application
├── Custom GitHub integration
├── Custom Slack integration
├── Custom PostgreSQL integration
├── Custom filesystem integration
└── Custom internal API integration
MCP interviene al definir un protocolo estandarizado que se sitúa entre la aplicación de IA y los sistemas externos que brindan capacidades. Conceptualmente, se ve más así:
AI Application
│
MCP Client(s)
│
┌───────────────┼────────────────┐
↓ ↓ ↓
MCP Server MCP Server MCP Server
GitHub Database Files
│ │ │
↓ ↓ ↓
GitHub API PostgreSQL Filesystem
Con este arreglo, la aplicación de IA ya no necesita un conocimiento profundo e individual de cada sistema backend. En su lugar, los servidores MCP exponen sus capacidades a través de una capa de protocolo común.
La arquitectura MCP
MCP se basa en un modelo cliente-anfitrión-servidor. A nivel alto, se ve así:
┌─────────────────────────────────────┐
│ HOST │
│ │
│ AI Application │
│ │
│ ┌──────────────────────────┐ │
│ │ MCP Client │ │
│ └────────────┬─────────────┘ │
└─────────────────┼───────────────────┘
│
│ MCP
↓
┌──────────────────┐
│ MCP Server │
│ │
│ Tools │
│ Resources │
│ Prompts │
└────────┬─────────┘
│
↓
External System
Los roles clave en esta arquitectura se describen a continuación.
Anfitrión
El host es la aplicación de IA encargada de orquestar toda la interacción. Esto podría ser algo como:
- un asistente de programación por IA
- una aplicación de IA para escritorio
- una herramienta para desarrolladores
- una aplicación de agente personalizada
Cliente MCP
El cliente MCP se encuentra dentro del host y es responsable de mantener viva y funcional la conexión con un servidor MCP.
Servidor MCP
Un servidor MCP es simplemente un programa que expone capacidades a través del protocolo MCP. Puede exponer funcionalidades relacionadas con cosas como:
GitHub
Databases
Files
Cloud services
Internal systems
Development environments
Es importante destacar que el servidor MCP en sí no necesita ser un agente ni contener ningún tipo de razonamiento por IA. Su función es simplemente hacer que ciertas capacidades estén disponibles.
MCP tiene más que herramientas
Un punto que puede confundir fácilmente a las personas es asumir que MCP no es más que un “protocolo de llamada a herramientas”. En realidad, MCP define varias primitivas distintas además de las herramientas.
Herramientas
Se trata de acciones que un modelo puede invocar, como por ejemplo:
create_issue()
search_repository()
query_database()
send_message()
Recursos
Los recursos son fragmentos de información que una aplicación puede obtener y entregar al modelo como contexto, por ejemplo:
file://project/README.md
database://schema
Prompts
MCP también puede exponer plantillas de prompts reutilizables como una primitiva distinta.
La documentación de MCP de Anthropic establece una distinción clara entre quienes controlan cada uno de estos elementos: las herramientas son controladas por el modelo, los recursos por la aplicación y los prompts por el usuario. Este control en capas es lo que hace que MCP sea algo más que un simple mecanismo de llamada a funciones.
Un ejemplo completo
Tomemos una solicitud como esta:
“Muéstrame los problemas abiertos en este repositorio de GitHub.”
Una versión simplificada del flujo resultante podría verse así:
User
│
│ "Show me the open issues"
↓
AI Application
│
↓
LLM
│
│ decides a GitHub tool is needed
↓
Tool Call
│
↓
MCP Client
│
│ MCP
↓
GitHub MCP Server
│
↓
GitHub API
│
↓
Issue Data
│
↓
MCP Client
│
↓
LLM
│
↓
Final Answer
Fíjese en cuántas capas distintas están involucradas aquí. El modelo razona sobre qué información necesita. La aplicación se encarga de la orquestación y ejecución. MCP proporciona el canal estandarizado para comunicarse con la capacidad externa. El servicio externo en sí realiza el trabajo real. Estas son cuatro responsabilidades separadas, no un solo paso combinado.
¿Dónde encaja Docker?
A menudo verá servidores MCP empaquetados y distribuidos como contenedores Docker, por ejemplo:
AI Application
│
│ stdio
↓
Docker Container
│
↓
MCP Server
│
↓
External Service
Es importante aclarar que Docker en sí no es MCP. Docker es simplemente una forma práctica de empaquetar y ejecutar un servidor MCP. Ese mismo servidor podría funcionar igualmente bien como un proceso local ordinario o ser alojado de forma remota como servicio. El protocolo en sí es completamente independiente de la forma en que decida desplegarlo.
STDIO vs Streamable HTTP
MCP funciona a través de más de un mecanismo de transporte.
Cuando la integración es local, un cliente MCP puede iniciar un servidor MCP como su propio proceso y comunicarse con él a través de STDIO.
Conceptualmente:
AI Application
│
│ stdin/stdout
↓
MCP Server Process
En escenarios en los que el servidor se encuentra de forma remota, MCP depende en su lugar de Streamable HTTP.
AI Application
│
│ HTTP
↓
Remote MCP Server
Gracias a esto, MCP funciona sin problemas tanto si las herramientas se encuentran en la máquina de un desarrollador como si se ejecutan como servicio alojado en otro lugar.
MCP vs REST API
Otra distinción que vale la pena destacar es cómo se compara MCP con una API REST tradicional.
Una interacción con una API REST se ve así:
Application
│
│ HTTP request
↓
REST API
│
↓
Data
Una interacción con MCP se ve así:
AI Application
│
│ MCP
↓
MCP Server
│
↓
REST API / Database / Filesystem / Other system
Curiosamente, un servidor MCP puede llamar a APIs REST en el fondo sin problemas.
Por lo tanto, MCP no está ahí para reemplazar a REST.
Es mejor entenderlo como una capa amigable con la IA que se coloca sobre sistemas ya existentes.
Por qué MCP se volvió interesante
La magnitud del problema de integración se vuelve evidente cuando uno imagina varias aplicaciones de IA que cada una necesita comunicarse con varias herramientas externas.
Sin un protocolo compartido, uno termina con algo como esto:
AI App A ───── Custom ───── GitHub
AI App A ───── Custom ───── Slack
AI App A ───── Custom ───── Database
AI App B ───── Custom ───── GitHub
AI App B ───── Custom ───── Slack
AI App B ───── Custom ───── Database
Cada nueva combinación de aplicación y herramienta puede significar tener que escribir código de integración nuevo.
Un protocolo compartido transforma por completo esa situación:
MCP
│
┌────────────┼────────────┐
↓ ↓ ↓
GitHub Slack Database
MCP MCP MCP
Server Server Server
En esencia, esta es la razón por la que Anthropic lanzó MCP como un estándar abierto en lugar de tratarlo como algo creado únicamente para Claude.
Desde entonces, Anthropic ha ampliado MCP para que soporte servidores remotos e integrado directamente la conectividad de MCP en su API y productos.
Pero tener más herramientas no hace automáticamente que un agente sea mejor
Aquí es donde el trabajo de ingeniería posterior de Anthropic se vuelve realmente interesante.
Es fácil asumir:
Más herramientas = agente más capaz.
Esa suposición no se sostiene bien en la práctica.
La investigación de Anthropic sobre el diseño de herramientas demuestra que los agentes pueden incluso rendir peor cuando se les proporcionan demasiadas herramientas que se superponen o no están diseñadas cuidadosamente.
Una herramienta bien diseñada debe tener un único propósito claro y proporcionar información útil, evitando al mismo tiempo un exceso innecesario en la ventana de contexto del modelo.
Por ejemplo, en lugar de realizar tres llamadas separadas como:
list_users()
list_transactions()
list_notes()
puede ser más eficaz ofrecer al agente una capacidad combinada, como:
get_customer_context()
suponiendo que esto se ajusta mejor a lo que el agente realmente intenta lograr.
En otras palabras, la propia interfaz de la herramienta se convierte en parte del entorno en el que opera el agente.
Las herramientas son una interfaz para el agente
Esa observación lleva a una idea más amplia que merece destacarse:
Las herramientas deben diseñarse teniendo en cuenta al agente, y no simplemente reempaquetarse a partir de una API existente.
Una API convencional puede funcionar perfectamente bien cuando la llama un programa determinista.
No obstante, un agente impulsado por un LLM opera bajo un conjunto diferente de restricciones.
Tiene que lidiar con:
- una ventana de contexto limitada
- resultados probabilísticos
- errores ocasionales al elegir la herramienta adecuada
- errores ocasionales al generar parámetros correctos
- ambigüedad en lo que realmente se solicita
Por esta razón, la forma en que se describe una herramienta es realmente importante.
Considere lo vago que es esto:
search(id)
en contraste con lo mucho más claro que es esto:
search_github_issues(
repository,
query,
state
)
Para que el modelo utilice bien una herramienta, necesita saber:
- qué hace realmente la herramienta
- cuándo es la herramienta adecuada para usar
- qué representa cada parámetro de entrada
- qué forma tiene el resultado
- qué no puede hacer la herramienta
La guía de Anthropic sobre ingeniería de herramientas destaca la importancia de nombres precisos, descripciones claras, parámetros bien especificados, resultados útiles y una evaluación continua.
El contexto se está convirtiendo en una parte fundamental de la ingeniería de agentes
También recientemente, Anthropic ha enfatizado la idea de contexto justo a tiempo.
La forma ingenua de manejar el contexto es la siguiente:
Load everything
↓
Put everything into context
↓
Ask the LLM to reason
Ese enfoque enfrenta rápidamente problemas de escalabilidad.
Un patrón más sostenible es el siguiente:
Small amount of initial context
↓
Agent identifies what it needs
↓
Tool retrieves relevant information
↓
Relevant information enters context
↓
Agent continues
En lugar de cargar por adelantado todo lo que el modelo podría necesitar, el agente obtiene la información solo cuando determina que realmente es necesaria.
Anthropic ha presentado esto como un paso hacia el manejo de contexto “justo a tiempo” para los sistemas de agentes.
Esto está directamente relacionado con MCP.
MCP proporciona la vía estandarizada hacia capacidades externas, mientras que el agente mismo decide cuándo obtener algo y exactamente qué obtener.
El bucle del agente
Una vez que se combinan todas estas partes, la arquitectura general comienza a tener mucho más sentido.
Una versión simplificada del bucle del agente se ve así:
┌──────────────┐
│ User │
└──────┬───────┘
↓
┌──────────────┐
│ LLM │
└──────┬───────┘
↓
Need a tool?
/ \
No Yes
↓ ↓
Answer Tool Call
↓
Tool/MCP
↓
Tool Result
│
└─────────┐
↓
LLM
│
┌──────────┴──────────┐
↓ ↓
Continue Answer
Este bucle está en el centro de una gran parte de los sistemas agentes que se utilizan hoy en día.
Anthropic lo explica en términos sorprendentemente sencillos: un agente es esencialmente un LLM que llama a herramientas dentro de un bucle, donde la retroalimentación del entorno determina qué hará a continuación.
El sistema que rodea ese bucle puede volverse bastante complejo, pero el mecanismo básico sigue siendo tan simple.
¿Y qué hay de los frameworks?
Frameworks como LangGraph pueden hacer que la creación de estos sistemas sea más manejable al proporcionar una estructura dentro de la cual trabajar.
Aun así, hay una precaución importante que vale la pena tener en cuenta.
La recomendación de Anthropic es comprender lo que ocurre detrás del framework: las llamadas directas al LLM, las definiciones de las herramientas, la lógica de orquestación y las respuestas, en lugar de tratar el framework como una caja negra.
Un framework suele exponer algo similar a:
Agent
├── State
├── Nodes
├── Tools
├── Routing
└── Execution
Pero debajo de esa abstracción, la mecánica real sigue siendo:
LLM
↓
Messages
↓
Tool calls
↓
Tool execution
↓
Tool results
↓
LLM
Comprender ese flujo de nivel inferior hace que el propio framework sea mucho más fácil de analizar, ya que se puede ver qué está automatizando en lugar de limitarse a confiar en que funcione.
MCP no reemplaza a los frameworks de agentes
Es importante dejar claro que se trata de capas diferentes dentro de un sistema, y no de opciones competitivas.
Una pila simplificada podría verse así:
┌─────────────────────────────┐
│ User Interface │
├─────────────────────────────┤
│ Agent / Workflow │
├─────────────────────────────┤
│ LLM / Model API │
├─────────────────────────────┤
│ Tool Calling │
├─────────────────────────────┤
│ MCP │
├─────────────────────────────┤
│ External Tools / Systems │
└─────────────────────────────┘
Un marco de trabajo para agentes suele gestionar cosas como:
- estado
- flujo de ejecución
- enrutamiento
- bucles
- reintentos
- ejecución de herramientas
MCP, por otro lado, estandariza la forma en que te conectas a capacidades externas.
La llamada a herramientas proporciona al modelo un mecanismo para solicitar que se ejecute algo.
Ninguno de estos tres sustituye al otro.
Algunas concepciones erróneas comunes
“MCP es un modelo de IA.”
No es cierto.
MCP es un protocolo, nada más.
No tiene capacidad para generar texto ni razonar por sí mismo.
“MCP reemplaza a las llamadas a funciones.”
Tampoco es cierto.
Lo que realmente ocurre es que un servidor MCP puede exponer herramientas, y una aplicación de IA luego hace accesibles esas herramientas al modelo a través de su mecanismo existente para usar herramientas.
"El LLM llama directamente a GitHub."
Típicamente, no.
El modelo solo genera una solicitud para usar una herramienta.
Es la aplicación y la infraestructura de herramientas circundante las que realmente realizan la operación.
"Cada servidor MCP necesita Docker."
Incorrecto.
Docker es solo una de las formas posibles de desplegar un servidor.
MCP se ocupa de la comunicación y la exposición de capacidades, no de cómo se contenedoriza algo.
"Un servidor MCP es un agente de IA."
No necesariamente.
Un servidor MCP podría simplemente exponer operaciones simples y deterministas como:
search()
read()
create()
update()
delete()
"MCP solo es útil para GitHub."
Lejos de eso.
MCP fue creado como un protocolo de uso general para conectar aplicaciones de IA con datos y capacidades externas. El anuncio inicial de Anthropic ya señalaba integraciones con sistemas como GitHub, Slack, Google Drive, bases de datos y diversos entornos de desarrollo.
La lección más importante: la ingeniería de agentes no es solo ingeniería de prompts
Se podría decir que este es el cambio de perspectiva más significativo que surge al estudiar este material.
Crear sistemas agentes verdaderamente útiles no se trata solo de:
Write a clever prompt
↓
Use a powerful model
↓
Get a smart agent
Existen varios niveles de ingeniería distintos involucrados:
Model
↓
Tool Selection
↓
Tool Definitions
↓
Tool Execution
↓
Context Management
↓
State / Memory
↓
Control / Guardrails
↓
Evaluation
Los propios escritos técnicos de Anthropic tienden cada vez más hacia esta visión más amplia, a nivel de sistema, de lo que realmente se requiere para construir un agente.
Como ejemplo, su trabajo reciente en la evaluación de agentes se centra en analizar el comportamiento multietapa, el uso de herramientas, los cambios en el estado y la adaptación a lo largo del tiempo, en lugar de juzgar la calidad únicamente a partir del bloque final de texto generado.
Eso representa un enfoque significativamente diferente para el diseño de aplicaciones de IA.
La parte que me parece más interesante
La transición importante aquí no es realmente:
Chatbot → Agent
Es más exactamente:
LLM
↓
LLM + Tools
↓
LLM + Tools + External Context
↓
LLM + Tools + Context + Control Loop
↓
Agentic System
MCP se integra en esa progresión al proporcionar a las aplicaciones de IA una forma estandarizada para acceder a capacidades externas.
El modelo proporciona la inteligencia.
La aplicación proporciona el control.
Las herramientas proporcionan las acciones.
Los sistemas externos proporcionan información y capacidades del mundo real.
MCP ofrece la capa de conexión estandarizada que vincula a las aplicaciones de IA con esas capacidades.
Mi modelo mental actual
Después de estudiar el llamado a herramientas, MCP y los escritos más amplios de Anthropic sobre sistemas agentes, esta es la imagen arquitectónica más simple que muestra cómo encajan todas estas partes:
USER
│
↓
┌─────────────┐
│ LLM │
│ │
│ Reasoning │
│ Decision │
└──────┬──────┘
│
Tool request
│
↓
┌─────────────────┐
│ Agent Runtime │
│ │
│ State │
│ Control Flow │
│ Tool Execution │
└────────┬────────┘
│
↓
MCP / Tools
│
┌────────────┼────────────┐
↓ ↓ ↓
GitHub Database Files
│ │ │
└────────────┼────────────┘
↓
Tool Results
│
↓
LLM
│
↓
USER
El modelo, por sí solo, no constituye al agente completo.
Tampoco lo hace una sola herramienta.
Tampoco lo hace MCP.
Lo que realmente se obtiene como “el agente” surge del sistema que rodea al modelo, esa parte que le permite razonar, tomar acciones, observar lo que ocurre y seguir trabajando hacia un objetivo.
Conclusión final
Si se propone crear agentes de IA, hay cuatro conceptos que vale la pena dominar a fondo:
1. Llamado a herramientas
El modelo puede solicitar a la aplicación que ejecute una herramienta específica.
2. Bucles de agente
El sistema puede razonar repetidamente sobre una situación, actuar en consecuencia, observar el resultado y continuar desde allí.
3. MCP
Un protocolo estandarizado para conectar aplicaciones de IA con herramientas, recursos y contexto externos.
4. Ingeniería de herramientas
La calidad de sus herramientas, sus descripciones, sus parámetros, el contexto que devuelven y el grado en que se evalúan pueden influir de manera significativa en el rendimiento real de un agente.
Tal vez la lección más valiosa que se puede extraer de las prácticas de ingeniería de Anthropic sea esta:
No añada complejidad solo porque pueda hacerlo.
Comience con la arquitectura más simple capaz de resolver el problema que tiene ante sí. Introduzca flujos de trabajo, agentes adicionales, más herramientas, memoria, servidores MCP y otros componentes únicamente cuando ofrezcan un beneficio concreto.
Nunca fue el objetivo construir el agente más elaborado posible.
El objetivo es crear un sistema que cumpla la tarea de manera fiable.
Lecturas relacionadas
- Comprendiendo los agentes de IA: objetivos, herramientas, memoria y el bucle del agente — Una explicación sencilla para principiantes sobre cómo difieren los agentes de IA de los chatbots, que abarca sus componentes esenciales, el bucle de toma de decisiones, los niveles de autonomía y casos de uso en el mundo real.
- Un bucle de herramientas de LangChain diseñado a mano para comparar métricas bursátiles en tiempo real — Crea paso a paso un pequeño asistente de LangChain para comparar acciones y aprende el ciclo de crear, vincular, invocar y ejecutar que permite a un LLM solicitar datos en tiempo real en lugar de hacer conjeturas.