Tool use de agentes AI: MCP, CLI, Skills y ejecución de código

Viacheslav Dubrov

2026-03-24 · Actualizado 2026-08-01 · 25 min · Agentes de IA

Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

La Parte 1 trató los bucles de razonamiento y la Parte 2, la memoria. Este artículo añade la capa de acción: cómo un agente expone, selecciona y ejecuta herramientas. La memoria determina qué sabe el agente al comenzar un turno; esta capa determina qué puede hacer al respecto. La Parte 4 trata la comprobación que decide si una llamada con nombre llega a ejecutarse, y la Parte 6, el harness que ejecuta tanto la llamada como la comprobación. A lo largo de este artículo, harness significa el programa de control que compone cada prompt, envía las llamadas a herramientas que acepta y decide cuándo ha terminado la tarea: todo lo que rodea al modelo y que implementas como código convencional.

La situación de las herramientas cambió en 2025–2026. MCP, el Model Context Protocol, proporcionó a los proveedores una forma común de exponer servicios externos. Los agentes capaces de ejecutar código demostraron que, en ocasiones, un modelo puede componer un programa pequeño de forma más eficiente que emitir una larga secuencia de llamadas JSON. Anthropic informó de una reducción del 98,7 % en tokens para un flujo de trabajo de Google Drive a Salesforce, y el artículo de CodeAct informó de mejoras de hasta el 20 % en la configuración de sus benchmarks. Estos resultados describen sus tareas y harnesses, no una ventaja universal de la ejecución de código.

Comparo las llamadas a herramientas JSON, MCP, Skills, las herramientas CLI y la ejecución de código, en ese orden. Una sección posterior aplica principios de diseño de Agent-Computer Interface (ACI) al Market Analyst Agent, un pequeño agente de investigación basado en LangGraph que desarrollé para la Parte 1 y que obtiene datos de mercado y redacta un informe de analista.

Para consultar una decisión breve sobre interfaces, véase Interfaces de herramientas para agentes de IA.

En resumen: cinco patrones de interfaz útiles cubren la mayor parte del uso de herramientas por parte de los agentes. Las Skills contienen instrucciones, las herramientas CLI encajan en el desarrollo local, MCP conecta servicios compartidos y la ejecución de código compone trabajo de varios pasos dentro de un sandbox. Las llamadas a herramientas JSON siguen siendo la opción más sencilla para acciones pequeñas y atómicas. Independientemente del protocolo, la Agent-Computer Interface (ACI) debe dejar claras las acciones, mantener compacto el feedback y permitir recuperar los errores.

Cinco formas en que los agentes de IA usan herramientas

En la Parte 1, el bucle de razonamiento elegía el siguiente paso. La Parte 2 almacenaba el estado necesario para reanudarlo. El límite de herramientas se sitúa entre ambos: valida lo que propone el bucle, envía la llamada para su ejecución y devuelve el resultado al bucle. Estos cinco patrones ofrecen distintos compromisos entre coste en tokens, flexibilidad y control.

1. Llamadas a herramientas JSON: la opción de referencia

El patrón original: defines los esquemas de las herramientas como JSON, el LLM emite llamadas a funciones estructuradas y tu código las ejecuta. Es un enfoque conocido y funciona bien con conjuntos pequeños de herramientas.

# Traditional tool definition — each tool consumes ~550-1,400 tokens (Apideck benchmark)
tools = [
    {
        "name": "get_stock_price",
        "description": "Get the current stock price for a ticker symbol",
        "input_schema": {
            "type": "object",
            "properties": {
                "ticker": {"type": "string", "description": "Stock ticker (e.g., NVDA)"}
            },
            "required": ["ticker"]
        }
    }
]

Con entre 5 y 10 herramientas, la sobrecarga es aceptable. El problema aparece al escalar: cada definición de herramienta cuesta entre 550 y 1.400 tokens. Con 20 herramientas, consumes entre 11.000 y 28.000 tokens antes siquiera de que el agente empiece a razonar.

2. MCP para integraciones compartidas

MCP es el estándar en el que han convergido la mayoría de los proveedores. Un servidor MCP es un proceso que anuncia una lista de herramientas mediante un protocolo de comunicación definido: stdio para un proceso local y HTTP para uno remoto. Tu agente ejecuta un cliente MCP que se conecta, pregunta al servidor qué herramientas tiene y reenvía las llamadas del modelo, de modo que el mismo servidor funciona con cualquier cliente compatible con el protocolo. Anthropic donó el protocolo a la Linux Foundation en diciembre de 2025, bajo la Agentic AI Foundation, que cofundó con OpenAI y Block. Google, Microsoft y AWS respaldan la fundación como miembros platinum. OpenAI añadió compatibilidad con MCP en su Responses API. Según el anuncio de donación de Anthropic de diciembre de 2025, el ecosistema contaba con más de 10.000 servidores MCP públicos activos y más de 97 millones de descargas mensuales de los SDK, entre los SDK de Python y TypeScript.

MCP encaja en integraciones SaaS entre proveedores (Figma, Notion, Salesforce), servicios sin equivalentes de CLI y entornos que necesitan orquestación de OAuth. Su valor reside en ofrecer una capa compartida de descubrimiento y transporte. La gobernanza sigue dependiendo de los controles de autenticación, autorización, logging y despliegue del servidor.

La realidad en producción es más compleja de lo que sugieren las cifras principales.

La superficie de seguridad es el primer problema. El Vulnerable MCP Project registra 50 vulnerabilidades en servidores MCP, 13 de ellas con severidad Critical, aportadas por 32 investigadores de seguridad. Las clases de ataque abarcan prompt injection, fallos de validación de entradas, carencias de autenticación y vulnerabilidades de seguridad de red. El primer servidor MCP malicioso detectado en el mundo real apareció en septiembre de 2025: un paquete llamado postmark-mcp que enviaba en BCC todos los correos salientes a la dirección del atacante.

El tool poisoning es la clase de ataque que más me preocupa. Invariant Labs demostró que las herramientas MCP envenenadas pueden exfiltrar datos aunque nunca se invoquen. Basta con que el modelo lea los metadatos de la herramienta para activar el ataque. Los benchmarks de MCPTox, que probaron 20 agentes LLM contra 45 servidores MCP del mundo real, registraron tasas de éxito de los ataques de hasta el 72,8 %.

El overhead de tokens es el problema operativo. Un equipo que ejecutaba servidores MCP para GitHub, Slack y Sentry (unas 40 herramientas en total) descubrió que se inyectaban 55.000 tokens de definiciones de esquemas antes de que el usuario preguntara nada. Otro informó de que las definiciones de herramientas por sí solas consumían 143.000 de los 200.000 tokens disponibles (el 72 %).

El informe de Anthropic sobre Tool Search Tool midió una reducción del 85 % en el consumo total de contexto: de aproximadamente 77.000 tokens antes de empezar el trabajo a 8.700, con unos 72.000 tokens de definiciones de herramientas en la configuración tradicional. Carga únicamente las tres a cinco herramientas que necesita una solicitud, pero añade un paso de descubrimiento antes de la invocación; resulta menos útil para toolsets pequeños y compactos cuyas herramientas se utilizan con frecuencia en todas las sesiones.

3. Las skills aportan experiencia, no ejecución

Las agent skills son un formato abierto para empaquetar instrucciones y archivos auxiliares. Las herramientas proporcionan capacidades (lo que pueden hacer los agentes), mientras que las skills aportan experiencia (lo que los agentes saben sobre cómo llevar a cabo tareas complejas).

El formato SKILL.md define una skill como un archivo Markdown con frontmatter YAML. El estándar abierto solo exige name y description; el ejemplo siguiente también utiliza dos extensiones de Claude Code, argument-hint y user-invocable, además de su placeholder de argumento posicional $0:

---
name: deploy
description: Deploy the application to production
argument-hint: "[environment]"
user-invocable: true
---
Deploy the application to the $0 environment (default: staging).
Steps:
1. Run the test suite
2. Build the production bundle
3. Deploy using the deploy script
4. Verify the deployment health check

Las skills utilizan divulgación progresiva. Al inicio se cargan unos 100 tokens de metadatos; las instrucciones completas solo se cargan cuando la skill está activa. Compáralo con los aproximadamente 55.000 tokens que pueden consumir unas 40 herramientas MCP antes de empezar a razonar.

Usa skills para conocimiento de dominio, procedimientos de varios pasos y tareas recurrentes, como migraciones de bases de datos o integraciones de pagos. Encajan en tareas en las que el agente necesita instrucciones sobre cómo utilizar una capacidad ya existente.

4. Herramientas CLI y de shell

Las interfaces CLI pueden consumir mucho menos contexto cuando el modelo ya conoce el comando. Scalekit informó de una diferencia de 4-32x tokens entre sus rutas CLI y MCP en 75 ejecuciones. Ese estudio de caso mide sus herramientas y tareas; no sustituye una comparación con tus propias definiciones de herramientas y la salida de tus comandos.

Los comandos ampliamente documentados, como git, docker, kubectl, gh, curl y jq, suelen necesitar poco texto introductorio de esquema. Las CLI menos habituales o internas siguen necesitando ayuda detectable, ejemplos y una salida estable y legible por máquinas.

La guía de Ugo Enyioha, “Writing CLI Tools That AI Agents Actually Want to Use”, formalizó ocho reglas de diseño:

1. La salida estructurada es obligatoria — admite --json
2. Los códigos de salida forman parte del flujo de control — usa códigos distintos para cada tipo de error
3. Los comandos deben ser idempotentes
4. La CLI debe autodocumentarse --help con ejemplos realistas
5. Diseña pensando en la composabilidad — --quiet para valores sin formato, y admite stdin
6. Proporciona los flags --dry-run y --yes
7. Admite la introspección de versiones
8. Gestiona la autenticación mediante variables de entorno

La CLI no ofrece descubrimiento a nivel de protocolo. Las llamadas a herramientas mediante JSON pueden incluir esquemas tipados, mientras que MCP estandariza el descubrimiento de herramientas y, para transportes HTTP, un modelo de autorización. Ninguno de los dos proporciona gobernanza por sí solo: el host, el servidor o el harness debe aplicar las políticas y registrar las llamadas que necesite auditar. El patrón hacia el que veo converger a la mayoría de equipos es CLI para desarrollo y operaciones locales, y MCP para integraciones compartidas con servicios externos.

5. Ejecución de código para trabajo de varios pasos

Este es el cambio en las herramientas para agentes que considero más trascendental. En lugar de emitir JSON estructurado para invocar funciones predefinidas una a una, el agente escribe un script de Python o bash. El script llama a varias herramientas, procesa los resultados con bucles y condicionales, y devuelve únicamente el resumen final al contexto del modelo.

Anthropic introdujo Programmatic Tool Calling (PTC) como una de las tres funcionalidades beta de la API de Claude. Su base académica es el artículo de CodeAct (Wang et al., ICML 2024), que evaluó 17 LLM y descubrió que las acciones mediante código lograban tasas de éxito de hasta un 20 % superiores y requerían un 30 % menos de pasos que las alternativas basadas en JSON.

Tres casos prácticos de first-party muestran dónde puede ayudar este patrón: Vercel y Cloudflare, a continuación, y después el ejemplo de Anthropic sobre análisis de gastos. Considéralos evidencias aportadas por los proveedores y vuelve a ejecutar la comparación con tus propias tareas.

• Vercel reconstruyó d0, su agente de datos de lenguaje natural a SQL. Su antiguo ejemplo de código nombra 17 herramientas; el nuevo expone ExecuteCommand y ExecuteSQL. Vercel presenta el rediseño como una eliminación del 80 % de sus herramientas, pero esa afirmación es el titular de Vercel, no un porcentaje que se desprenda de las herramientas nombradas en los ejemplos. En cinco consultas representativas, Vercel informa de que el éxito de las tareas pasó de 4/5 a 5/5, el tiempo medio de ejecución se redujo 3,5 veces (de 274,8 s a 77,4 s) y el uso medio de tokens cayó un 37 % (de ~102k a ~61k). En sus palabras: «Los mejores agentes podrían ser los que tienen menos herramientas».

• Cloudflare desarrolló «Code Mode», que permite a los agentes escribir TypeScript para llamar a su API en lugar de definir esquemas de herramientas, reduciendo así la sobrecarga de contexto. Su razonamiento: «Los LLM tienen una enorme cantidad de TypeScript del mundo real en sus datos de entrenamiento, pero solo un pequeño conjunto de ejemplos artificiales de llamadas a herramientas».

Este es el patrón de la documentación de PTC de Anthropic. En la ilustración de Anthropic sobre el análisis secuencial de gastos, las llamadas tradicionales a herramientas requieren más de 20 pasadas de inferencia independientes, con los datos intermedios circulando por el contexto. Tras consultar al equipo, un host compatible con llamadas paralelas a herramientas puede agrupar las solicitudes de gastos independientes; la cifra de más de 20 no lo impide. Anthropic informa de que el código generado para responder a la misma pregunta reduce lo que llega al contexto desde 200 KB de filas de gastos sin procesar —más de 2.000 partidas— hasta 1 KB de resultados. Con la ejecución de código, el agente escribe un único script:

# Agent generates this code, executes in sandbox
import asyncio
import json

async def main() -> None:
    team = await get_team_members("engineering")
    levels = list(set(member["level"] for member in team))
    budgets = dict(zip(
        levels,
        await asyncio.gather(*(get_budget_by_level(level) for level in levels)),
    ))
    expenses = await asyncio.gather(
        *(get_expenses(member["id"], "Q3") for member in team)
    )
    over_budget = []
    for member, employee_expenses in zip(team, expenses):
        total = sum(expense["amount"] for expense in employee_expenses)
        limit = budgets[member["level"]]["travel_limit"]
        if total > limit:
            over_budget.append(
                {"name": member["name"], "spent": total, "limit": limit}
            )
    # Only this final summary returns to the LLM context
    print(json.dumps(over_budget))

asyncio.run(main())

El LLM solo ve el resumen JSON final, no las miles de partidas de gastos procesadas en el sandbox. El ahorro no es exclusivo de los informes de gastos: el artículo independiente de Anthropic sobre ejecución de código ofrece la cifra más contundente para este patrón: un flujo de trabajo de Google Drive a Salesforce que pasó de ~150.000 tokens a ~2.000, una reducción del 98,7 %.

La eficiencia en tokens es la ventaja más evidente. Los bucles y las condicionales salen gratis, y la ejecución de código puede gestionar los errores con handlers explícitos, en lugar de obligar al modelo a razonar sobre los fallos en lenguaje natural. Una ruta de ejecución de código puede mantener los datos intermedios sensibles fuera del contexto del modelo, pero eso no equivale a confidencialidad: el aislamiento, los controles de egress, las credenciales con permisos limitados y el logging requieren medidas de aplicación independientes.

Cuándo sigue teniendo sentido llamar a herramientas mediante JSON: operaciones atómicas individuales, entornos sin infraestructura de sandboxing, modelos pequeños con una generación de código deficiente o requisitos de auditoría que exijan registrar cada invocación individual de una herramienta.

Tabla comparativa de la invocación de herramientas en agentes de IA

«Meta-herramientas» en la fila del sobrecoste de tokens hace referencia a los pocos puntos de entrada genéricos que necesita un agente con ejecución de código —por ejemplo, ExecuteCommand y ExecuteSQL de Vercel— en lugar de un esquema por cada operación subyacente. Las filas de componibilidad y latencia se refieren a llamadas cuyos argumentos posteriores dependen de resultados anteriores en el harness o bucle analizado. La invocación de herramientas con JSON y MCP pueden emitir llamadas independientes a la vez, y un host puede ejecutarlas de forma concurrente; las llamadas dependientes normalmente necesitan otro turno del modelo para elegir la siguiente acción. PTC traslada el flujo de control dependiente y el filtrado del lado del código al script y después devuelve un resumen al modelo; también puede emitir llamadas independientes de forma concurrente. Las celdas de tokens y éxito de la tarea resumen los ejemplos citados, no un benchmark controlado único que abarque las cinco columnas.

La interfaz agente-ordenador (ACI) para herramientas de agentes de IA

El término «Agent-Computer Interface» (ACI) fue acuñado por John Yang, Carlos E. Jimenez y sus colaboradores de Princeton en su artículo sobre SWE-agent (NeurIPS 2024). La calidad de las interfaces para humanos cuenta con toda una disciplina dedicada a ella: la interacción persona-ordenador, o HCI. El artículo sostiene que los agentes basados en modelos de lenguaje merecen el mismo tratamiento: son «una nueva categoría de usuarios finales con sus propias necesidades y capacidades, y se beneficiarían de interfaces diseñadas específicamente para ellos».

Sus resultados de ablación ponen cifras a esta afirmación. Usando el mismo modelo base GPT-4 Turbo, la ablación de SWE-bench Lite del artículo alcanzó el 18,0 % con la ACI completa de SWE-agent en 300 tareas, frente al 7,3 % de la configuración basada únicamente en shell sin una demostración guiada y al 11,0 % con una. La comparación muestra que las condiciones de interfaz y demostración modificaron sustancialmente el rendimiento en esta configuración; no aísla el diseño de la interfaz de cualquier otra diferencia ni demuestra que el modelo no realizara trabajo alguno. Dentro de la misma ablación de interfaz, activar el linting elevó el resultado de la condición de edición del 15,0 % al 18,0 %; en el conjunto de prueba completo de SWE-bench, el 51,7 % de las ejecuciones de SWE-agent incluyeron al menos una edición que el linter rechazó antes de que pudiera propagarse.

Anthropic adoptó ACI como concepto fundamental en su guía «Building Effective Agents», donde lo presenta como uno de tres principios básicos: «Diseña cuidadosamente la interfaz agente-ordenador mediante una documentación y unas pruebas exhaustivas de las herramientas». Su recomendación práctica es: «Una regla general es pensar en cuánto esfuerzo se dedica a las interfaces persona-ordenador y planificar invertir exactamente el mismo esfuerzo en crear buenas interfaces agente-ordenador».

Cuatro principios de ACI en la práctica

1. Las acciones deben ser sencillas y fáciles de entender. El error más habitual es envolver los endpoints de una API uno a uno. En lugar de list_users, list_events y create_event, implementa schedule_event, que encuentra la disponibilidad y programa la cita en una sola llamada. En lugar de read_logs, implementa search_logs, que devuelve únicamente las líneas relevantes junto con su contexto.

2. Las acciones deben ser compactas y eficientes. Consolida las operaciones importantes en el menor número posible de acciones. En el Market Analyst Agent, combino la obtención de precios con métricas básicas en una única herramienta get_stock_snapshot, en lugar de exigir llamadas independientes para el precio, el volumen, la capitalización bursátil y el ratio PE.

3. El feedback del entorno debe ser informativo, pero conciso. Evita devolver HTML sin procesar o payloads completos de la API. Resuelve los ID crípticos y conviértelos en nombres semánticos. Las pruebas de Anthropic añadieron un enum response_format para que el agente pueda solicitar una respuesta concisa (aproximadamente 72 tokens) o detallada (aproximadamente 206 tokens), lo que supone una diferencia aproximada de 3× en el coste en tokens.

4. La validación debe mitigar la propagación de errores. La detección automática de errores ayuda a los agentes a reconocer y corregir fallos rápidamente. En SWE-agent, un editor de archivos personalizado con linting integrado rechaza automáticamente los errores de sintaxis: es el paso de validación que sustenta la cifra del 51,7 % anterior. Esto es validación de las entradas y salidas de una herramienta, no el filtrado de contenido que se aplica alrededor de una llamada al modelo y que realizan los productos de guardrails de la Parte 4; se usa la misma palabra para ambas cosas. Aplico el mismo principio en el Market Analyst Agent validando los argumentos de las herramientas con esquemas de Pydantic antes de ejecutarlas:

from pydantic import BaseModel, Field, field_validator

from market_analyst.utils import normalize_ticker

class StockQuery(BaseModel):
    """Validated input for stock queries.

    Pydantic catches malformed tickers before the API call,
    preventing error propagation through the reasoning loop.
    """
    ticker: str = Field(description="Stock ticker symbol (e.g., NVDA)")

    @field_validator("ticker")
    @classmethod
    def validate_ticker(cls, v: str) -> str:
        return normalize_ticker(v)

class StockHistoryQuery(StockQuery):
    """Validated input for price history queries."""

    period: str = Field(default="1mo", description="Time period: 1d, 5d, 1mo, 3mo, 6mo, 1y")

    @field_validator("period")
    @classmethod
    def validate_period(cls, v: str) -> str:
        valid = {"1d", "5d", "1mo", "3mo", "6mo", "1y"}
        if v not in valid:
            raise ValueError(f"Invalid period: {v}. Must be one of {valid}")
        return v

El normalizador compartido elimina espacios y convierte el valor a mayúsculas; después acepta los dígitos del ticker y sufijos separados por puntos o guiones, como BRK.B y BF-B; StockHistoryQuery, no StockQuery, es el propietario de period.

Patrones de diseño de herramientas para agentes de IA que funcionan

La guía de Anthropic “Writing effective tools for agents” define las herramientas como «un nuevo tipo de software que refleja un contrato entre sistemas deterministas y agentes no deterministas».

Trata las descripciones de las herramientas como prompt engineering

Las descripciones deberían tener al menos tres o cuatro frases e indicar cuándo usar la herramienta, qué parámetros son obligatorios u opcionales, el formato de salida y los casos límite. Anthropic informa de que la elección entre los nombres basados en prefijos y los basados en sufijos (asana_search frente a search_asana) tuvo «efectos no triviales» en sus propias evaluaciones del uso de herramientas. No indica qué esquema funciona mejor, así que prueba ambos en tu conjunto de herramientas en lugar de dar por hecho que los prefijos son superiores. Anthropic también introdujo las transcripciones de sus agentes de evaluación en Claude Code y dejó que reescribiera las herramientas. En conjuntos de pruebas reservados, ese ciclo obtuvo mejoras adicionales, «incluso por encima de lo que conseguimos con implementaciones de herramientas “expertas”»: tanto si las habían escrito a mano sus investigadores como si las había generado Claude.

# Bad: vague, no context for when to use
tools = [{
    "name": "search",
    "description": "Search for items",
}]

# Good: specific, with input examples and edge cases
tools = [{
    "name": "search_news",
    "description": (
        "Search for recent news articles about a specific stock or company. "
        "Use this tool when the user asks about recent events, earnings, "
        "announcements, or market-moving news for a specific ticker. "
        "Returns up to 10 articles sorted by relevance. "
        "For company competitors rather than news, use search_competitors instead."
    ),
    "input_schema": {
        "type": "object",
        "properties": {
            "query": {
                "type": "string",
                "description": "Search query. Examples: 'NVDA earnings Q3 2025', 'Tesla delivery numbers'"
            },
            "max_results": {
                "type": "integer",
                "description": "Max articles to return (1-10, default 5)",
                "default": 5
            }
        },
        "required": ["query"]
    }
}]

Las pruebas internas de Anthropic mostraron que añadir un campo input_examples aumentaba la precisión en la gestión de parámetros complejos del 72 % al 90 %.

Devuelve salidas de alta señal y legibles por máquinas

Evita los identificadores de bajo nivel (uuid, mime_type). Resuelve los ID crípticos en nombres semánticos. Estructura la respuesta para que el agente pueda razonar sobre ella sin tener que analizar boilerplate:

# Bad: raw API response dumped to agent
def get_stock_snapshot(ticker: str) -> dict:
    response = api.get(f"/v1/quotes/{ticker}")
    return response.json()  # 500+ tokens of nested JSON

# Good: high-signal summary the agent can immediately reason about
def get_stock_snapshot(ticker: str) -> dict:
    data = api.get(f"/v1/quotes/{ticker}").json()
    return {
        "ticker": ticker,
        "price": data["regularMarketPrice"],
        "change_pct": round(data["regularMarketChangePercent"], 2),
        "volume": data["regularMarketVolume"],
        "market_cap_b": round(data["marketCap"] / 1e9, 1),
        "pe_ratio": data.get("trailingPE"),
        "summary": f"{ticker} at ${data['regularMarketPrice']:.2f} "
                   f"({'up' if data['regularMarketChangePercent'] > 0 else 'down'} "
                   f"{abs(data['regularMarketChangePercent']):.1f}%)"
    }

Devuelve errores con los que el loop pueda actuar

La gestión de errores necesita cuatro mecanismos independientes, porque cada uno aborda una clase de fallo distinta:

1. Reintentos con exponential backoff para errores transitorios
2. Cadenas de fallback de modelos para caídas de proveedores
3. Enrutamiento según la clasificación del error: los errores transitorios se reintentan, los errores recuperables por el LLM se devuelven al agente con contexto y los errores que requieren intervención humana se escalan
4. Recuperación desde checkpoints para sobrevivir a crashes

“Writing effective tools for agents”, de Anthropic, aboga por errores claros en las herramientas y un diseño guiado por evaluaciones, pero no establece una cifra universal sobre cuánto recuperan estos cuatro mecanismos. Mide la tasa de recuperación, los reintentos y las escaladas en tu propio conjunto de tareas.

import httpx
from tenacity import retry, retry_if_exception, stop_after_attempt, wait_exponential

def is_transient_error(error: BaseException) -> bool:
    if isinstance(error, (httpx.TimeoutException, httpx.NetworkError)):
        return True
    if isinstance(error, httpx.HTTPStatusError):
        return error.response.status_code == 429 or 500 <= error.response.status_code < 600
    return False

@retry(
    retry=retry_if_exception(is_transient_error),
    stop=stop_after_attempt(3),
    wait=wait_exponential(multiplier=1, min=2, max=10),
    reraise=True,
)
def call_stock_api(ticker: str) -> dict:
    """Fetch stock data with automatic retry on transient failures.

    Mechanism 1 of the four above: exponential backoff for rate limits
    and network blips.
    If all retries fail, the error propagates to the agent with
    enough context to decide whether to try a different approach.
    """
    response = httpx.get(
        f"https://api.example.com/v1/quotes/{ticker}",
        timeout=10.0,
    )
    response.raise_for_status()
    return response.json()

Aplicación de los patrones al agente analista de mercados

El agente analista de mercados de la Parte 1 hace visible el efecto de la interfaz.

Consolidación de tools

Los módulos de tools originales definían get_stock_price, get_company_metrics, get_price_history, dos herramientas de búsqueda y execute_trade. Para realizar un análisis básico, el agente tenía que elegir tanto la llamada del precio como la de las métricas; la capitalización bursátil y el P/E eran campos de get_company_metrics, no tools independientes. El código fuente anterior a la consolidación muestra aquella interfaz.

He remodelado la interfaz de datos de mercado en 5 tools de alto nivel, siguiendo el principio ACI de acciones compactas y eficientes. La lista de tools de ReAct del repositorio incluye además otras cuatro: un cargador de skills, dos wrappers de CLI y un evaluador restringido de Python en el mismo proceso (una allowlist de AST, no un sandbox; la Parte 4 lo aborda), que cubren tres de las cinco modalidades anteriores. MCP aparece como sidecar, no como una tool de esta lista:

Esto reúne el precio y la valoración en una única definición orientada a la tarea y añade los estados financieros como una acción explícita. La mejora en la selección de tools es una hipótesis que debe comprobarse con solicitudes y trazas representativas.

Salidas estructuradas para los resultados de las tools

Las tools de acciones y noticias devuelven respuestas validadas por Pydantic. Los wrappers de CLI y de ejecución de código devuelven str, por lo que los modelos siguientes describen los resultados estructurados de las tools, no todos los wrappers del repositorio:

from pydantic import BaseModel

class StockSnapshot(BaseModel):
    """Structured tool response — the agent never sees raw API noise."""
    ticker: str
    price: float
    change_pct: float
    volume: int
    market_cap_b: float
    pe_ratio: float | None
    summary: str  # Human-readable one-liner for direct use in reports

class NewsItem(BaseModel):
    """One news item pre-processed for agent consumption."""
    headline: str
    source: str
    date: str
    relevance_score: float  # Pre-ranked so the agent doesn't waste tokens sorting
    key_points: list[str]  # Extracted by the tool, not the agent

class NewsSearchResult(BaseModel):
    query: str
    results: list[NewsItem]
    summary: str

El campo summary proporciona al agente una cadena lista para usar que puede incorporarse directamente a un informe. NewsItem.key_points las extrae la tool, no el agente, lo que ahorra tokens de inferencia que, de otro modo, se emplearían en analizar los cuerpos de los artículos.

Compromisos y consideraciones

Además de las salvedades específicas de cada patrón anterior, varios aspectos transversales influyen en la elección:

• El coste operativo varía según la dimensión. La ejecución de código ahorra tokens, pero añade latencia por el arranque en frío del sandbox. MCP ahorra tiempo de desarrollo en integraciones SaaS, pero añade la sobrecarga de desplegar servidores. CLI es gratuito para empezar, pero resulta más difícil de gobernar a escala. Optimiza según tu cuello de botella real, ya sea el coste de tokens, la latencia o la complejidad operativa.

• Las habilidades del equipo importan. La ejecución de código presupone que tus agentes (y los modelos que los respaldan) pueden generar Python o TypeScript fiable. CLI presupone familiaridad con las convenciones de Unix. MCP requiere comprender los protocolos de transporte y los flujos de OAuth. Adapta la modalidad a los puntos fuertes de tu equipo.

• La consolidación de herramientas puede llevarse demasiado lejos. Si una herramienta acumula modos y argumentos no relacionados, el agente se enfrenta a un problema de selección diferente dentro del esquema. Utiliza evaluaciones de selección de herramientas y de éxito de las tareas para encontrar la superficie adecuada para tu carga de trabajo.

• Las skills se basan en prompts, no están impuestas. Una skill contiene instrucciones que el agente debería seguir, no guardrails que deba seguir. Un bundle de skills puede incluir archivos arbitrarios y scripts ejecutables, así que confía solo en su origen, revisa el bundle y haz que el host imponga los permisos para cada recurso que pueda leer, modificar o ejecutar. En workflows críticos, combina las skills con validación determinista.

• Los requisitos de auditoría condicionan la elección. Las llamadas estructuradas a MCP y JSON son eventos cómodos de registrar, pero ninguno de los dos protocolos crea de serie un audit trail completo. El host, el servidor o el harness deben registrar las invocaciones y los resultados, y después aplicar la autorización, las políticas, la retención y la revisión. La ejecución de código necesita la misma instrumentación alrededor del sandbox; su script y su salida, por sí solos, no constituyen un registro de cumplimiento.

Tres direcciones para las herramientas de agentes de IA a escala

La primera es usar tool RAG para escalar. En las tareas de benchmark y la prueba de estrés de MCP de RAG-MCP, su precisión de referencia en la selección de herramientas era del 13,62 %; la recuperación la elevó al 43,13 %, una mejora de 3,2 veces, al tiempo que redujo los tokens del prompt en más de un 50 %. El resultado es evidencia para esa configuración de evaluación, no una tasa universal de selección ingenua a medida que crecen los toolsets.

La segunda consiste en que los propios agentes creen sus herramientas. El framework LATM («LLMs As Tool Makers») estableció un paradigma en dos fases en el que un LLM potente crea funciones reutilizables en Python y un LLM ligero las utiliza. En el benchmark de 15 tareas de ToolMaker, basado en papers con repositorios de código públicos proporcionados como URLs de GitHub y descripciones breves de las tareas, implementó correctamente el 80 % de las tareas. Ambos enfoques apuntan más allá del uso de herramientas: hacia la creación de herramientas y, después, hacia la gestión de una biblioteca de herramientas generadas.

La tercera es el stack de doble protocolo A2A + MCP. Google transfirió A2A a la Linux Foundation en junio de 2025. La documentación del protocolo A2A separa sus responsabilidades: MCP conecta un agente con herramientas y recursos, mientras que A2A permite que agentes independientes se descubran entre sí, negocien interacciones, gestionen tareas compartidas y deleguen trabajo.

Puntos clave

1. Elige la interfaz según la acción: llamadas JSON para operaciones pequeñas y tipadas, MCP para servicios compartidos, Skills para procedimientos, CLI para comandos consolidados y código en sandbox para composición local.
2. Mantén las condiciones del benchmark asociadas al resultado. CodeAct, Anthropic, Vercel, Cloudflare, Apideck y Scalekit midieron modelos, tareas, herramientas y harnesses diferentes.
3. La calidad de la ACI se mantiene aunque cambie el protocolo. Las acciones claras, el feedback conciso, la validación y los errores útiles ayudan en todas las modalidades.
4. Consolida herramientas solapadas solo cuando las evaluaciones demuestren que una superficie más pequeña mejora la selección o el éxito de las tareas.
5. La seguridad debe estar a la altura de la capacidad de ejecución. Las interfaces de shell y código necesitan sandboxing; MCP necesita una identidad con permisos limitados y políticas para los servidores; Skills siguen siendo instrucciones, no mecanismos de enforcement.

La siguiente capa es la policy

La Parte 4, AI Agent Security, sitúa una comprobación de policy entre una llamada a una herramienta propuesta y su ejecución. Es el mismo límite de herramientas descrito arriba, visto desde el lado que dice que no. La Parte 5 introduce después la herramienta y su sandbox en un runtime recuperable, y la Parte 6 añade un segundo contrato que el modelo nunca ve: una categoría de efectos, una regla de reintento y un resultado estructurado que un acceptance check puede leer sin analizar prosa.

Referencias

Papers

• Executable Code Actions Elicit Better LLM Agents (CodeAct) — Wang et al., ICML 2024 — Las acciones basadas en código alcanzan hasta un 20 % más de éxito en las tareas que JSON
• SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering — Yang, Jimenez et al., NeurIPS 2024 — Principios de diseño de ACI y evaluación en SWE-bench (18,0 % para SWE-agent frente a 7,3 % con solo shell y sin una demostración, en la ablación de 300 tareas de SWE-bench Lite del paper; las condiciones de interfaz y demostración difieren)
• RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection — Sus tareas de benchmark y su stress test de MCP mejoraron la precisión de selección del 13,62 % al 43,13 %
• LLMs As Tool Makers (LATM) — Cai et al., 2023 — Paradigma en dos fases para la creación de herramientas para agentes
• ToolMaker: LLM Agents Making Agent Tools — Wolflein et al., ACL 2025 — 80 % en su benchmark de 15 tareas sobre papers con repositorios de código públicos
• MCPTox: A Comprehensive MCP Toxicity Benchmark — Tasa de éxito de los ataques del 72,8 % en 20 agentes LLM y 45 servidores MCP

Ingeniería de Anthropic

• Advanced Tool Use / Programmatic Tool Calling — Tool Search (un 85 % menos de consumo total de contexto, de ~77K a ~8,7K), PTC y ejemplos de uso de herramientas
• Code Execution with MCP — Reducción del 98,7 % en tokens (de 150K a 2K tokens) mediante la orquestación de herramientas basada en código
• Writing Effective Tools for Agents — Ingeniería de descripciones de herramientas; los ejemplos de entrada mejoran la precisión; el enum response_format (72 frente a 206 tokens)
• Building Effective Agents — La ACI como principio de diseño fundamental

Especificaciones del protocolo

• Google Cloud dona A2A a la Linux Foundation — anuncio del 23 de junio de 2025 sobre la transferencia del protocolo, el SDK y las herramientas
• A2A y MCP: comparación detallada — documentación del protocolo A2A sobre las responsabilidades complementarias entre agentes y entre agentes y herramientas

Casos prácticos del sector

• Vercel: hemos eliminado el 80 % de las herramientas de nuestro agente — el ejemplo anterior menciona 17 herramientas; el nuevo expone ExecuteCommand y ExecuteSQL; Vercel presenta el rediseño como una eliminación del 80 %; éxito de 4/5 a 5/5 en cinco consultas representativas, 3,5 veces más rápido y con un 37 % menos de tokens
• Cloudflare: Code Mode — llamadas a API controladas por TypeScript que sustituyen a los esquemas de herramientas
• Apideck: el servidor MCP se come la ventana de contexto — entre 550 y 1.400 tokens por herramienta, 55.000 tokens para unas 40 herramientas MCP, 143.000 de 200.000 tokens de contexto consumidos
• Scalekit: benchmark de tokens de MCP frente a CLI — entre 4 y 32 veces más sobrecarga de tokens para MCP que para CLI en 75 ejecuciones de benchmark

Seguridad

• Proyecto MCP vulnerable — 50 vulnerabilidades registradas, 13 críticas, identificadas por 32 investigadores
• AuthZed: cronología de las brechas de seguridad de MCP — 9 incidentes importantes de seguridad de MCP (abril-octubre de 2025)
• Invariant Labs: ataques de tool poisoning en MCP — envenenamiento de herramientas, rug pulls y escalada entre orígenes
• Pivot Point Security: análisis de seguridad de MCP — un 43 % de inyección de comandos y un 43 % de fallos de autenticación OAuth

Diseño de CLI

• Cómo escribir herramientas CLI que los agentes de IA realmente quieran usar — Ugo Enyioha — ocho reglas de diseño para CLI adaptadas a agentes

Proyecto de demostración

• Agente analista de mercados — implementación completa con consolidación de herramientas y patrones ACI

El código completo del agente analista de mercados, incluidos los diseños de herramientas descritos en esta publicación, está disponible en GitHub.