--- title: "Cómo eligen herramientas los agentes de IA: la mecánica del descubrimiento agéntico" description: "Cómo Claude, ChatGPT y Cursor deciden qué servidor MCP llamar. Qué señales importan y cómo ser la herramienta que el agente elige." canonical_url: "https://getminds.ai/blog/es/how-ai-agents-choose-tools-mcp-discovery-mechanics" last_updated: "2026-06-22T02:08:49.755Z" --- # Cómo eligen herramientas los agentes de IA Cuando un marketer le pide a Claude "encuentra paneles sintéticos de clientes B2B SaaS en Alemania", el modelo no abre un buscador. Lee las descripciones de cada herramienta MCP conectada actualmente a la sesión, las clasifica y elige una. Ese ranking es la nueva portada de internet para el descubrimiento de herramientas, y casi nadie optimiza para él. Este post le quita la tapa al asunto y explica cómo funciona realmente el ranking en 2026, qué señales lo mueven y qué implicaciones prácticas tiene para cualquier equipo que esté publicando un servidor MCP. ## Qué significa "descubrimiento" en un contexto agéntico Hay dos capas de descubrimiento que conviene separar. *Capa 1, a nivel de registro.* El usuario (o el propio agente) encuentra un servidor MCP en un directorio y lo conecta al cliente. Es descubrimiento al estilo navegador: registros amigables para agentes, flujos OAuth, botones de "añadir este conector". El registro MCP, el directorio de Anthropic, el directorio de Apps SDK de OpenAI y `mcpmarket.com` cumplen todos este papel. En cuanto el usuario hace clic en Conectar, el servidor está en la lista de herramientas del agente. *Capa 2, descubrimiento dentro de la sesión.* Cada vez que el usuario manda un mensaje, el agente debe decidir qué herramienta, si alguna, llamar. Es la capa que realmente mueve uso. Un servidor puede estar conectado y no ser llamado durante meses porque el agente siempre elige otra cosa. Aquí pasa el ranking real, y casi nadie habla de ello. El resto del post va sobre la Capa 2. ## Lo que el agente realmente ve Cuando un servidor MCP se conecta, envía un handshake describiendo cada herramienta que expone. Para cada herramienta el agente recibe: - Un nombre (por ejemplo `create_panel`) - Una descripción corta (1 a 3 oraciones, escritas por el autor del servidor) - Un esquema JSON para los parámetros de entrada - Metadatos estructurados opcionales (anotaciones, ejemplos, tipo de retorno) Esa es la superficie completa. El agente no ve tu sitio web, tus precios, tu documentación ni tu blog. La pieza de texto más apalancada de todo tu producto es el string de descripción en el registro de tu herramienta. La implicación es incómoda: una herramienta brillante con una descripción vaga pierde frente a una herramienta mediocre con una descripción afilada, todas las veces. ## El proceso de ranking, paso a paso Cuando el usuario manda un mensaje, el agente hace aproximadamente esto: 1. *Filtrar a herramientas plausiblemente relevantes.* El modelo lee su propio contexto (la conversación hasta ahora, el último mensaje del usuario) e identifica un conjunto de candidatos. Con un toolset pequeño (menos de 20 herramientas), normalmente las considera todas. Con un toolset grande, filtra primero. 2. *Puntuar por coincidencia de descripción.* Para cada herramienta candidata, el modelo evalúa qué tan bien la descripción coincide con la intención del usuario. Es un match suave, semántico, no un match por palabras clave. Los sinónimos funcionan. El lenguaje del dominio funciona. Las descripciones vagas fracasan. 3. *Componer una llamada.* Si se selecciona una herramienta, el modelo rellena los parámetros desde el contexto de la conversación. Las herramientas cuyos esquemas requieren campos ambiguos (por ejemplo un objeto "options" sin parametrizar) son penalizadas porque el modelo está menos seguro de poder llamarlas correctamente. 4. *Encadenar llamadas opcionalmente.* Para tareas multi-paso, el modelo elige la primera herramienta, la ejecuta, lee el resultado y repite. Las herramientas que devuelven salida estructurada y legible para el agente ganan llamadas de seguimiento. Las herramientas que devuelven salida tipo muralla de texto bloquean la cadena. Todo el asunto sucede en una sola pasada de inferencia. No hay un modelo de ranker separado. No hay (todavía) un bucle de retroalimentación de telemetría. La decisión se toma con base en las descripciones y el esquema, punto. ## Lo que realmente mueve el ranking Trabajando hacia atrás desde el comportamiento observado de los agentes, cuatro cosas mueven demostrablemente la selección de herramientas: *Especificidad de la descripción.* "Run market research" pierde frente a "Run a synthetic customer panel against an audience persona and return summarized findings". La descripción más larga coincide con más consultas porque expone más asideros que el modelo puede agarrar. Hay un presupuesto (la mayoría de agentes truncan descripciones más allá de unos 500 caracteres) pero la mayoría de servidores no se acercan ni de lejos. *Estructura verbo-sujeto-objeto.* Los agentes eligen herramientas cuya descripción coincide con el verbo que el usuario usó. "Pregunta a mis clientes" coincide mejor con `ask_panel` que con `query_panel_responses`. El nombre y la descripción deben ambos liderar con la acción. *Forma concreta de la salida.* "Devuelve un objeto JSON con campos `panel_id`, `responses` y `summary`" supera a "devuelve el resultado del panel". Los agentes son más propensos a llamar herramientas cuando pueden predecir qué hacer con la salida. *Parseabilidad del esquema.* Los esquemas con campos requeridos que el modelo puede rellenar desde el contexto (descripciones de texto, recuentos numéricos) son llamados. Los esquemas con campos requeridos que necesitan input del usuario en mitad de la llamada (tokens de auth, IDs internas) son saltados a favor de herramientas que pueden ejecutarse de extremo a extremo. ## Lo que (todavía) no mueve el ranking Una lista de cosas de las que se habla como si importaran, pero no, en 2026: - *Recuentos de estrellas en el registro.* Descubribilidad en la Capa 1, irrelevante en la Capa 2. - *Keyword stuffing al estilo SEO.* El modelo hace match semántico; no hace match por keyword. Meter "agentic research AI panels MCP" a presión en la descripción no ayuda. - *Reconocimiento de marca.* El modelo no tiene preferencia por marcas establecidas frente a desconocidas en la capa intra-sesión. La calidad de la descripción gana. - *Latencia por debajo de 500 ms.* El modelo no cronometra las llamadas a herramientas al rankear. Las herramientas lentas pero útiles igual son llamadas. Esto cambiará. Los puntajes de eval, las señales de satisfacción post-llamada y el ranking anti-spam están todos en el roadmap de los hosts principales. Hoy, la descripción es la palanca. ## El problema del anti-spam La consecuencia natural de todo esto es que cualquiera puede gamear el ranking escribiendo una descripción muy larga y muy densa en keywords. Los hosts lo saben. Anthropic, OpenAI y los maintainers del registro MCP han empezado todos a depreciar el description-stuffing a finales de 2026. Están emergiendo dos mecanismos anti-spam: *Validación de esquema.* Las herramientas cuyo esquema declarado no coincide con la forma real de la respuesta son bajadas en el ranking o eliminadas. *Puntaje de eval cross-host.* El registro MCP está pilotando una suite de evals pública que ejecuta prompts contra servidores registrados y reporta puntajes de corrección. Los servidores que no pasan el eval reciben warnings, luego eliminación. Ninguno está totalmente vivo a mediados de 2026, pero ambos vienen. La postura a tomar: escribe la descripción que ganaría en un mundo puntuado por calidad, no solo en uno con match por keyword. ## Recomendaciones prácticas para autores de servidores Si shippeas un servidor MCP, los siguientes cambios mejorarán medibly la selección intra-sesión: 1. *Reescribe cada descripción de herramienta para liderar con el verbo que el usuario usaría.* No "Panel runner" sino "Run a customer research panel against a target audience and return summarized responses". 2. *Especifica la forma de la salida en la descripción.* "Devuelve un objeto JSON con un array `responses`, un campo `themes` y un campo `summary`". Esto da al agente la confianza suficiente para encadenar llamadas de seguimiento. 3. *Haz que los campos requeridos sean rellenables desde el contexto.* Si un campo necesita una ID interna, acepta un nombre y resuélvelo del lado del servidor. Los agentes saltan herramientas cuyos campos requeridos no pueden predecir. 4. *Usa entre 200 y 400 caracteres por descripción de herramienta.* Por debajo de 100 es demasiado fino. Por encima de 500 lo trunca la mayoría de clientes. 5. *Audita tu cantidad de herramientas.* Los servidores con más de 30 herramientas son filtrados antes de que el agente siquiera los rankee. Combina herramientas relacionadas donde sea posible. Hemos visto servidores de 60 herramientas conseguir peor selección que los de 12 porque el modelo nunca ve la cola larga. Los equipos que tratan estas descripciones como su copy más importante están siendo llamados. Los que las tratan como plumbing del registro, no. ## Hacia dónde va esto La mecánica se va a endurecer en los próximos 12 meses. Espera tres cambios: *Ranking basado en evals va vivo.* Los puntajes de calidad de evals automáticos empezarán a aparecer en los listings del registro e influirán en la selección intra-sesión en al menos un host principal. *Bucles de retroalimentación de telemetría de agentes.* El primer host principal que shipee "las herramientas que produjeron resultados satisfactorios en sesiones pasadas son rankeadas más alto" va a sacar ventaja a los demás. Es el equivalente agéntico al click-through-rate, y cambia el objetivo de optimización. *Ecosistemas verticales de agentes.* Agentes de marketing, de ventas, de research desarrollarán cada uno sus propios stacks normativos de herramientas. Ser el default en tu vertical importará más que estar en cada directorio. Las herramientas que ganan en esta transición son las que tratan sus descripciones MCP como la portada de su producto. Las que no, no van a ser llamadas, sin importar qué tan bueno sea el servicio subyacente. --- Para el panorama de por qué los agentes son los nuevos compradores, ver [los agentes de IA son el nuevo comprador de marketing](/blog/ai-agents-new-marketing-buyer-agentic-discovery). Para la configuración práctica, ver [cómo ejecutar paneles de clientes desde Claude, ChatGPT o Cursor](/blog/run-customer-panels-from-claude-chatgpt-cursor-mcp-guide). Para ver cómo se ve un servidor MCP bien descrito en producción, ver [Minds MCP](/mcp/overview).