Cuando un agente de IA tiene 1,000 herramientas MCP: selección, contexto y habilidades
Conectar agentes a muchos servidores MCP genera una explosión de herramientas, un contexto sobrecargado y selecciones inadecuadas. Por qué el descubrimiento, las habilidades y las pasarelas pueden ser más importantes que el acceso directo.
Más herramientas para un agente de IA suenan como una ventaja clara, al menos hasta que su número llega a 1,000. En ese punto, la pregunta cambia: deja de ser “¿puede el agente hacer esto?” y se convierte en “¿puede el agente encontrar la herramienta adecuada y usarla correctamente?”. Ahí es donde MCP se vuelve interesante.
MCP facilita la exposición de herramientas
Una gran ventaja del Protocolo de Contexto de Modelo es que las capacidades llegan a los agentes a través de una única interfaz común. Un producto SaaS podría publicar create_customer, get_customer, update_customer, create_invoice, refund_payment y search_orders. Otro servidor MCP podría gestionar GitHub, otro Slack y otro aún una base de datos interna. Cada uno funciona bien por separado. Los problemas surgen cuando un agente se conecta a muchos servidores y su número aumenta rápidamente. Diez herramientas no son nada, cien ya comienzan a ser un problema, y mil representan un tipo diferente de dificultad.
La explosión de herramientas
Imagínese en la posición del agente con 1,000 herramientas a su disposición. Tendría que averiguar qué función cumple cada una, cuáles están relacionadas, cuáles utilizar, qué parámetros requieren, cuáles deben ejecutarse primero y si varias realizan la misma tarea. Técnicamente el agente puede acceder a todo, pero el acceso no equivale a usabilidad. Más herramientas significan más capacidades y también más opciones, y más opciones pueden dificultar la selección.
Se completa el contexto
Cada herramienta necesita una descripción. Para una herramienta, eso podría ser un nombre:
create_invoice
Y una breve definición:
Creates an invoice for a customer.Parameters:
- customer_id
- amount
- currency
- due_date
Multiplíquelo por 1,000. Incluso las descripciones cortas suman una gran cantidad de contexto, por lo que se gastan tokens solo para indicarle al modelo qué podría hacer, y la mayoría de esas herramientas no tienen nada que ver con la tarea en cuestión. Si un usuario pregunta por el estado de un pedido, no hay razón para que el agente analice 500 herramientas de facturación, GitHub, CRM e implementación.
Elegir la herramienta adecuada es la verdadera dificultad
Supongamos que el agente ve estas:
get_customer
get_customer_details
lookup_customer
search_customer
find_customer
Todos suenan igual. ¿A cuál debería llamar? Ahora imagina eso aplicado a cientos de herramientas. El modelo puede utilizar las herramientas perfectamente bien. Lo difícil es elegir una entre un enorme conjunto de ellas. Es como lanzarle a un desarrollador 10,000 funciones y desearle suerte. Es posible, pero no agradable.
Más herramientas, más errores
La selección a menudo no es binaria, ya que varias herramientas podrían funcionar:
search_orders
get_order
list_orders
find_order_by_customer
Un agente puede elegir una herramienta válida y usarla de manera ineficiente, llamar a varias cuando solo se necesita una, o llamarlas en el orden incorrecto. Toda la cadena comienza con la disponibilidad de las herramientas, pasa por su selección, luego por su secuenciación y finalmente por su ejecución. MCP ayuda principalmente en el primer eslabón. El resto depende del agente y de la arquitectura que lo rodea.
¿Deberían los agentes tener menos herramientas?
No necesariamente. El objetivo no es limitar lo que puede hacer un agente, sino evitar forzarlo a comprender todo al mismo tiempo. Una persona que soluciona un problema de pago no abre todas las herramientas internas ni lee la documentación; solo utiliza las relacionadas con los pagos. Los agentes podrían funcionar de la misma manera. El patrón de cargar todo primero y luego elegir podría ser reemplazado por uno de descubrir, seleccionar, cargar y ejecutar, lo cual representa un diseño más interesante.
Dónde encajan las habilidades
Las habilidades están directamente relacionadas. Una habilidad puede proporcionar el contexto necesario para un tipo específico de tarea. Por ejemplo, una habilidad relacionada con la facturación de clientes podría indicarle al agente que localice al cliente, verifique la suscripción, revise las facturas pendientes, decida cuál es la acción de facturación adecuada, solicite aprobación cuando sea necesario y, a continuación, utilice la herramienta correspondiente.
El agente ya no tiene que considerar cada herramienta del sistema; recibe un conjunto más reducido y relevante para la tarea. En lugar de esto:
Agent
↓
1,000 tools
El flujo podría ser este:
Agent
↓
Relevant Skill
↓
Relevant tools
↓
MCP
↓
API / System
Las habilidades no reemplazan a MCP, ya que abordan problemas diferentes. MCP conecta al agente con las capacidades, y las habilidades pueden enseñarle cómo utilizarlas. La idea de utilizar habilidades en lugar de MCP sigue siendo experimental y en evolución, por lo que es mejor considerarla como una dirección emergente en lugar de una arquitectura establecida.
Los gateways también pueden ser importantes
Otra dirección es el gateway MCP. En lugar de conectar directamente a un agente con docenas de servidores MCP, un gateway se interponga entre ellos:
Agent
↓
MCP Gateway
↓
MCP Servers
↓
APIs / Systems
Un gateway podría encargarse potencialmente de la autenticación, el enrutamiento, el control de acceso, la observabilidad, el descubrimiento de herramientas y la gestión de muchos servidores. Eso se vuelve aún más valioso a medida que las implementaciones MCP crecen en tamaño.
El verdadero problema es la irrelevancia
La preocupación no radica en 1,000 herramientas en sí. Se trata de 1,000 herramientas irrelevantes. Si una tarea realmente necesita mil herramientas, que así sea. Pero si solo necesita doce y el agente tiene que procesar mil para encontrarlas, eso representa una complejidad innecesaria. El principio es: los agentes no necesitan acceso a todo, solo a lo que es importante en ese momento.
Eso probablemente se convertirá en una preocupación central en la arquitectura MCP a medida que los agentes se conecten a más sistemas. MCP resolvió la primera pregunta: cómo dar a los agentes acceso estandarizado a las herramientas. La siguiente es cómo gestionar todas esas herramientas de manera inteligente, y eso parece considerablemente más difícil. Hacer que los agentes tengan herramientas ya es sencillo; lo que queda por hacer es proporcionarles las herramientas adecuadas en el momento oportuno.