Las herramientas de agentes de programación con IA se eligen principalmente a partir del nombre de la herramienta, la descripción en lenguaje natural, el esquema de entrada, el contexto disponible, los permisos y las instrucciones del agente. En la práctica, la mejor herramienta es la que el modelo puede identificar, invocar de forma segura y encajar en su plan actual. La calidad de la documentación importa. También importan las colisiones, los filtros y si la herramienta está expuesta siquiera.
Lo que realmente significa la “elección de herramienta” para un agente de programación
La intención de búsqueda aquí es informativa: quieres saber cómo un agente como Claude Code, OpenAI’s Agents SDK, Codex, Cursor, GitHub Copilot o Gemini decide a qué capacidad llamar cuando edita un repositorio. La respuesta es menos mística de lo que parece. El modelo lee un menú.
Ese menú suele contener nombres de herramientas, descripciones, esquemas de parámetros y, a veces, ejemplos o metadatos del servidor. El benchmark MetaTool de 2023 planteó el problema de forma precisa: un LLM debe decidir si usar una herramienta en absoluto y, después, qué herramienta usar. Ese segundo paso es donde muchos flujos de trabajo de programación fallan silenciosamente.
Para los equipos de software, las herramientas de agentes de programación con IA se están convirtiendo en un nuevo tipo de superficie de API orientada a desarrolladores. No son solo funciones. Son prompts con identificadores, contratos y modos de fallo. Si tu agente no puede entender el identificador, puede que nunca llegue al contrato.
La guía de 2025 de OpenAI para crear agentes señala un punto práctico que sigue vigente en 2026: las herramientas estandarizadas, bien documentadas, probadas y reutilizables mejoran la capacidad de descubrimiento, la gestión de versiones y reducen las definiciones redundantes. Sinceramente, eso suena aburrido hasta que tu agente llama a la función de despliegue equivocada porque dos herramientas parecen casi idénticas.
Las señales que leen los agentes antes de llamar a una herramienta
La mayor parte de la evidencia apunta a un pequeño conjunto de señales de alto valor. Los nombres de las herramientas le indican al modelo la categoría general. Las descripciones le indican cuándo es útil la herramienta. Los esquemas de entrada le indican qué argumentos son válidos. Los prompts del sistema y las instrucciones del repositorio le indican qué prefiere el equipo.
Múltiples fuentes de 2026 identifican los nombres, las descripciones y los esquemas de entrada o parámetros como señales principales para la elección de herramientas. Una encuesta de 2026 en Preprints.org sobre agentes LLM eficientes en el uso de herramientas también dice que filtrar las herramientas relevantes para la tarea puede mejorar una selección eficiente y precisa. Eso coincide con lo que se ve en agentes de programación reales: unas pocas herramientas relevantes suelen superar a una enorme bolsa variada.
Hay un paralelismo útil con inteligencia de repositorios para programación con AI. El modelo necesita conocer la forma de la base de código antes de editarla. También necesita conocer la forma del conjunto de herramientas antes de actuar.
Una afirmación merece cautela. La gente suele asumir que el HTML semántico, la popularidad en GitHub, los metadatos del paquete o la familiaridad derivada del entrenamiento del modelo hacen que un agente elija directamente una herramienta. Pueden ayudar indirectamente mediante la documentación y los ejemplos, pero la evidencia directa y fiable de que esos factores afecten a las herramientas de agentes de programación con IA es escasa en la investigación proporcionada para 2026.
MCP cambió el descubrimiento de herramientas, pero no la parte difícil
El Model Context Protocol, o MCP, ofrece a los agentes una forma estandarizada de descubrir herramientas externas. En la especificación de MCP del 2026-07-28, el descubrimiento de herramientas se formaliza mediante tools/list. Un servidor expone sus herramientas disponibles; el cliente puede listarlas, mostrárselas al modelo e invocar la seleccionada.
La denominación es más sutil de lo que parece al principio. La unicidad del nombre de las herramientas de MCP se limita a un solo servidor, no a todo el entorno del agente. Si un cliente agrega herramientas de varios servidores, la especificación del 2026-07-28 dice que debe desambiguar las colisiones, por ejemplo prefijando identificadores del servidor.
Claude Code hace exactamente eso en su patrón de nombres de MCP. En la documentación de 2026, una herramienta de servidor de GitHub llamada list_issues se convierte en mcp__github__list_issues. Es feo, pero útil. El prefijo indica al modelo y al entorno de ejecución qué servidor es el propietario de la acción.
El SDK de Agents de OpenAI tiene su propia ruta MCP. En 2026, el SDK de Python admite herramientas MCP alojadas, donde la API de Responses enumera e invoca herramientas de servidor remoto sin una devolución de llamada adicional al proceso local de Python. El mismo SDK admite filtros, incluido el filtrado dinámico por ejecución, para que los desarrolladores expongan solo las funciones que necesita un agente.
Los permisos también importan. Las herramientas MCP de Claude Code requieren permiso explícito antes de usarse en 2026; el modelo puede ver una herramienta, pero no puede invocarla sin aprobación. Es una función de seguridad, pero también es una restricción de selección. Disponible no siempre significa invocable.
Sobrecarga de herramientas: el silencioso coste de la fiabilidad
Más herramientas parecen implicar más capacidad. A menudo implican más ambigüedad. Un estudio de arXiv de 2026 sobre 177,000 herramientas MCP informa de que el desarrollo de software representa 67% de las herramientas de agentes y 90% de las descargas de servidores MCP. El centro de gravedad es claramente la programación.
El mismo estudio informa de que las herramientas de “acción” aumentaron de 27% a 65% del uso total a lo largo del periodo de 16 meses analizado. Ese cambio importa porque las herramientas de acción pueden modificar archivos, crear incidencias, ejecutar comandos o acceder a APIs. Una mala selección ya no devuelve una respuesta deficiente; puede cambiar el espacio de trabajo.
Aquí tienes una forma concreta de entender la carga. Si un agente está expuesto a 12 herramientas, tiene 66 distinciones por pares que debe mantener mentalmente separadas. Con 30 herramientas, eso sube a 435. Con 85 herramientas, son 3,570. El modelo no está realizando literalmente un torneo por pares cada vez, pero la superficie de ambigüedad crece rápido.
Publicaciones anecdóticas de profesionales en Reddit en 2026 afirmaban que la fiabilidad mejoró tras reducir un servidor MCP de 85 herramientas a 9, y que la precisión empeoraba al superar aproximadamente las 20 herramientas. Tómalas como informes de campo, no como ciencia. Aun así, la dirección coincide con la orientación formal: filtra de forma agresiva.
Aquí es donde razonamiento adaptativo en sistemas de IA se vuelve relevante. Dedicar más razonamiento a un registro de herramientas sobredimensionado tiene un coste. Si el filtrado puede eliminar opciones irrelevantes antes de que el modelo razone, ahorras latencia, dinero y errores.
| Pruebas o plataforma | Año | Lo que dice sobre la elección de herramientas | Implicaciones prácticas |
|---|---|---|---|
| guía de creación de agentes de OpenAI | 2025 | Las herramientas estandarizadas, documentadas, probadas y reutilizables mejoran la facilidad de descubrimiento y la gestión de versiones. | Trata las definiciones de herramientas como APIs de producción. |
| especificación MCP | 2026-07-28 | Las herramientas se descubren mediante tools/list; los nombres son únicos solo dentro de un servidor. |
Añade un prefijo o desambigua de otro modo los nombres de herramientas agregadas. |
| Documentación de Claude Code MCP | 2026 | Las herramientas MCP requieren permiso explícito antes de usarse, y los nombres siguen mcp__server__tool. |
Tanto el permiso como el nombre afectan a lo que se llama. |
| SDK de OpenAI Agents | 2026 | Los filtros de herramientas MCP pueden exponer solo las funciones necesarias, incluido el filtrado dinámico por ejecución. | Reduce el menú antes de que el modelo elija. |
| Estudio de arXiv sobre 177,000 herramientas MCP | 2026 | El desarrollo de software representa 67% de las herramientas de agentes y 90% de las descargas de servidores MCP. | La programación es el principal campo de pruebas para la selección de herramientas MCP. |
Cómo hacer que las herramientas de agentes de programación con IA sean más fáciles de elegir
Una buena definición de herramienta es aburrida del mismo modo que una buena señal de aeropuerto es aburrida. Dice exactamente lo que hace, cuándo usarla y cuándo no usarla. Los nombres ingeniosos perjudican. Los verbos vagos perjudican aún más.
Cuando diseñes herramientas de agentes de programación con IA, escribe primero para el modelo y después para el responsable humano de mantenimiento. El artículo MetaTool de 2023 incluso recomienda reescribir las descripciones de las herramientas para el LLM final. Estoy de acuerdo con eso: la documentación orientada al agente es ahora su propio género.
- Usa nombres específicos: prefiere
create_github_issueen lugar decreate, yrun_pytest_for_packageen lugar detest. - Indica las condiciones previas: di cuándo el repositorio debe estar limpio, cuándo se requieren credenciales o cuándo la herramienta no debe ejecutarse.
- Define estrictamente las entradas: La compatibilidad con JSON Schema 2020-12 en la versión candidata de MCP del 2026-07-28 hace que la precisión del esquema sea aún más valiosa.
- Describe las salidas: indica al agente si recibe un diff, una ruta de archivo, un ID de incidencia, un registro de comandos o un resultado estructurado.
- Expón menos herramientas por tarea: usa filtros de MCP, servidores específicos por rol o filtrado dinámico por ejecución en lugar de un único registro plano.
- Versiona el comportamiento visible: si
deploy_previewcambia la semántica, no ocultes ese cambio tras la misma descripción.
Un problema del que casi nadie habla lo suficiente: un fallo de registro puede hacerse pasar por estupidez del modelo. La documentación del SDK de MCP Go en 2026 dice que las herramientas que no superan la validación en el momento del registro se descartan silenciosamente de tools/list. Si el agente nunca elige tu herramienta, primero confirma que realmente se está mostrando en la lista.
La seguridad forma parte de la misma conversación. Que un agente elija una herramienta también significa que está eligiendo un límite de confianza. Si vas a permitir que un agente clone repositorios, ejecute comandos de shell o llame a servicios de terceros, lee las advertencias sobre repositorios Git maliciosos que pueden secuestrar agentes de programación antes de tratar la elección de herramientas como un simple problema de UX.
La configuración vive en el repositorio, no solo en el agente
Un estudio de 2026 sobre la configuración de herramientas de programación de IA agéntica abarca Claude Code, GitHub Copilot, Cursor, Gemini y Codex, e identifica los artefactos Markdown y JSON a nivel de repositorio como mecanismos de configuración. Esos archivos pueden indicarle a un agente cómo compilar, probar, revisar y dar preferencia a determinados flujos de trabajo.
Los datos de uso de Codex añaden otro matiz. Un estudio de arXiv de 2026 informa de que más del 10% de los usuarios gestionan tres o más agentes de Codex simultáneos en algunas semanas, mientras que el 26.6% utiliza skills para instrucciones compartidas de flujo de trabajo. Una vez que ejecutas varios agentes, una configuración de herramientas coherente deja de ser un detalle pulido. Se convierte en coordinación.
El SDK de Agents JS de OpenAI describe las herramientas en sentido amplio: capacidades para obtener datos, llamar a API, ejecutar código o usar un ordenador. Su herramienta experimental Codex enruta las llamadas de herramientas del modelo al SDK de Codex para que un agente pueda ejecutar de forma autónoma tareas de shell con ámbito de espacio de trabajo, edición de archivos y herramientas MCP. Potente. También fácil de configurar mal.
Las pistas de transporte importan en el momento de la configuración. La documentación de Claude Code dice que un comando como npx ... implica stdio, mientras que una URL implica HTTP o SSE. Si el transporte es incorrecto, el razonamiento de selección del modelo es irrelevante porque el entorno de ejecución no puede llegar al servidor.
Para los equipos que incorporan agentes en flujos de trabajo regulados, esto se conecta con normas de gobernanza de IA que las empresas deben seguir y el complicado auge de gestión de identidades no humanas. Las llamadas a herramientas necesitan identidad, autorización, registros y revocación. Una descripción bonita de la herramienta no salvará un modelo de permisos débil.
Qué miden los benchmarks y qué se les escapa
Los benchmarks se están poniendo al día. Se informa de que MCPToolBench++ en 2026 cubre el descubrimiento, la selección y la invocación de herramientas MCP, incluida la «precisión en la selección de herramientas». Se informa de que MCP-Bench evalúa la validez del nombre, el cumplimiento del esquema de entrada, el éxito en tiempo de ejecución, la selección de herramientas y la eficiencia de la planificación.
Esas métricas son útiles porque los fallos por elegir la herramienta equivocada tienen un aspecto distinto. A veces el agente inventa un nombre. A veces elige una herramienta válida pero inadecuada. A veces elige correctamente y envía argumentos mal formados. A veces el plan es sólido, pero la herramienta falla.
La investigación más reciente se está adentrando en ámbitos más allá de la automatización ordinaria de la web y de repositorios. Un artículo de arXiv del 2026-08-25 sobre automatización del diseño de hardware mediante llamadas a herramientas MCP evaluó siete modelos de código abierto y varió el nivel de detalle de la descripción de las herramientas, el alcance del contexto, los prompts del sistema y la arquitectura de agente único frente a la de múltiples agentes. Esa es la dirección correcta porque la elección de herramientas es contextual, no solo léxica.
Aun así, los benchmarks pueden pasar por alto los molestos casos de producción: descripciones obsoletas, wrappers duplicados, endpoints medio obsoletos, solicitudes de permisos que los usuarios aceptan sin pensar y servidores que descartan silenciosamente herramientas no válidas. Con este nivel de complejidad, el registro más simple que haga el trabajo suele ser el mejor.
Preguntas frecuentes
¿Qué son las herramientas de agente de programación con IA?
Las herramientas de agentes de programación con IA son capacidades invocables que permiten a un agente inspeccionar archivos, editar código, ejecutar pruebas, consultar APIs, usar servidores MCP o ejecutar comandos con alcance limitado al espacio de trabajo. El modelo las selecciona a partir de metadatos como nombres, descripciones, esquemas e instrucciones.
¿Cómo sabe un agente de IA qué herramienta MCP utilizar?
Con MCP, el cliente puede descubrir herramientas mediante tools/list, y luego presentar al modelo sus nombres, descripciones y esquemas. El agente elige en función del contexto de la tarea, los metadatos de la herramienta, las instrucciones del sistema y de si tiene permiso para llamar a la herramienta.
¿Más herramientas hacen que un agente de programación sea mejor?
No automáticamente. Más herramientas pueden aumentar la ambigüedad, especialmente cuando los nombres y las descripciones se solapan. Filtrar el registro para mostrar las herramientas relevantes para la tarea suele ser más seguro que exponer todas las funciones.
¿Por qué mi agente ignora una herramienta que existe?
Comprueba si la herramienta aparece realmente en la lista, si ha superado la validación del esquema, si se ha concedido el permiso y si su descripción coincide claramente con la tarea. En algunos SDK, es posible que las herramientas no válidas no aparezcan en la lista detectada.
¿Deben redactarse las descripciones de las herramientas para personas o para modelos?
Ambos, pero prioriza la claridad del modelo. Usa verbos directos, condiciones previas explícitas, resultados esperados y esquemas ajustados para que el agente pueda distinguir la herramienta de opciones similares.
ES 
EN 
FR