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

AI Agente Tool Use en 2026: MCP, CLI, Habilidades y Ejecución de Código

Parte 3 de la serie de ingeniería de la pila Agentic

Parte 1 bucles de razonamiento cubiertos, y Parte 2 Memoria cubierta. Este artículo introduce la capa de acciones: cómo un agente expone, selecciona y ejecuta herramientas.

La evolución de las herramientas experimentó un cambio significativo entre 2025 y 2026. MCP proporcionó a los proveedores un protocolo común para los servicios externos, mientras que los agentes capaces de ejecutar código demostraron que, en ocasiones, un modelo puede compilar un programa pequeño de forma más eficiente que realizar una larga secuencia de llamadas a JSON. Anthropic informó de una reducción del 98,7 % en los tokens en un flujo de trabajo de análisis de gastos, y el artículo de CodeAct señaló ganancias de hasta el 20 % en su configuración benchmark. Dichos resultados se refieren específicamente a sus tareas y arquitecturas, y no representan una ventaja universal para la ejecución de código.

Comparo, en ese orden, las llamadas a la herramienta JSON, MCP, Skills, las herramientas de línea de comandos y la ejecución de código. La sección final aplica los principios de diseño de la Interfaz Agente-Computadora (ACI) a Agente Analista de Mercado.

TL;DR: Cinco patrones de interfaz útiles abarcan la mayoría de los casos de uso de los agentes tool use. Las habilidades sirven para transportar instrucciones, las herramientas de línea de comandos son ideales para el desarrollo local, MCP permite conectar servicios compartidos, y la ejecución de código permite componer tareas multietapas dentro de un sandbox. La opción más sencilla para realizar acciones atómicas pequeñas sigue siendo el uso de herramientas JSON. Independientemente del protocolo utilizado, la Interfaz Agente-Computadora (ACI) debe garantizar que las acciones sean claras, los comentarios de retroalimentación sean concisos y sea posible recuperarse de los errores.


Cinco formas en las que los agentes AI utilizan herramientas

In Parte 1, El reasoning loop seleccionó el siguiente paso. Parte 2

Cinco modalidades de herramientas para agentes AI y sus compensaciones técnicas

1. Llamada de la herramienta JSON: el punto de referencia

El patrón original consiste en definir tool schemas como JSON; a continuación, LLM emite llamadas a funciones estructuradas que su código ejecuta posteriormente. Este enfoque está ampliamente reconocido y funciona sin problemas en conjuntos de herramientas pequeños.

# 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 5-10 herramientas, está bien. El problema es la escala: cada definición de herramienta tiene un costo 550-1,400 tokens. Con 20 herramientas, ya se gastan entre 15 y 25 mil tokens antes de que el agente siquiera comience a razonar.

2. MCP para integraciones compartidas

El Model Context Protocol constituye el estándar al que se han alineado la mayoría de los proveedores. En diciembre de 2025, Anthropic lo donó a la Linux Foundation a través de la Fundación AAIF ( Agentic AI ), en colaboración con OpenAI y Block, contando con el respaldo de Google, Microsoft y AWS como miembros de nivel platino. OpenAI incorporó soporte para MCP dentro de sus Respuestas API. Actualmente existen más de 10.000 servidores MCP activos y más de 97 millones de descargas mensuales de SDK.

MCP es adecuado para la integración de SaaS entre diferentes proveedores (Figma, Notion, Salesforce), para servicios que no disponen de equivalentes a través de la CLI, y en entornos que requieren orquestación mediante OAuth. Su principal ventaja radica en ofrecer una capa común de descubrimiento y transporte de datos. No obstante, la gobernanza sigue estando sujeta a los mecanismos de autenticación, autorización, registro de actividades y control de despliegue del servidor.

La realidad en producción es mucho más complicada de lo que indican las cifras publicadas en los titulares.

La superficie de seguridad es el primer problema. El Proyecto vulnerable MCP Detección de 50 vulnerabilidades en servidores MCP, 13 de ellas clasificadas como Críticas, reportadas por 32 investigadores de seguridad. Las categorías de ataque incluyen prompt injection, fallos en la validación de entradas, deficiencias en el proceso de autenticación y brechas de seguridad en la red. El primer servidor MCP malicioso en entornos reales Apareció en septiembre de 2025.: un paquete llamado postmark-mcp Que enviaba copias ocultas de cada correo electrónico enviado a la dirección del atacante, afectando a un estimado de 300–500 organizaciones antes de que se detectara el problema.

El envenenamiento de herramientas es el tipo de ataque que más me preocupa. Invariant Labs mostró Esos herramientajes contaminados con MCP pueden extraer datos incluso cuando nunca se invocan. Basta con que el modelo lea los metadatos de dicha herramienta para desencadenar el ataque. MCPTox benchmarks Durante las pruebas realizadas con 20 agentes LLM contra 45 servidores MCP del mundo real, se observó que las tasas de éxito en los ataques alcanzaban hasta el 72,8%.

El sobrecoste por tokens representa el problema operativo principal. Un equipo que gestiona servidores MCP para GitHub, Slack y Sentry (~40 herramientas en total) descubrió 55,000 tokens de las definiciones de esquema inyectadas antes de que el usuario solicite algo. Otra queja reportó 143,000 de 200,000 tokens disponibles (72%) consumidos únicamente por las definiciones de herramientas.

Comparación del sobrecoste por tokens

3. Expertise en el conjunto de habilidades, no en la ejecución

A finales de 2025 se produjo la estandarización de las habilidades de agente como formato abierto (lanzado en octubre de 2025 y publicado como estándar abierto en diciembre de 2025). Diferenciar estos conceptos es clave: las herramientas ofrecen capacidades (lo que pueden hacer los agentes), mientras que las habilidades aportan conocimiento especializado (lo que saben los agentes sobre cómo llevar a cabo tareas complejas).

El estándar SKILL.md define una habilidad como un archivo Markdown que contiene frontmatter en formato YAML:

---
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 habilidades emplean divulgación progresiva. Al iniciar, se cargan unos 100 tokens de metadatos; las instrucciones completas solo se cargan cuando la habilidad está activa. En contraste, alrededor de 40 MCP herramientas pueden consumir Aproximadamente 55.000 tokens. Antes de que comience el proceso de razonamiento. Para marzo de 2026, Claude Code, OpenAI Codex CLI, Cursor, GitHub Copilot, Gemini CLI, Goose, Windsurf y Roo Code ya habrán adoptado este formato. Victor Dibia describe este cambio hacia acciones de agente impulsadas por código.

Aprovecha estas habilidades para el conocimiento del dominio, los procedimientos de múltiples pasos y las tareas recurrentes como las migraciones de bases de datos o las integraciones de pago. Son ideales para aquellas 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 resultar mucho más económicas en este contexto cuando el modelo ya conoce la orden. Scalekit informó un 4-32 veces la diferencia de tokens entre sus rutas de CLI y MCP a lo largo de 75 ejecuciones. Dicho estudio de caso evalúa sus herramientas y tareas; no sustituye una comparación basada en sus propios manifiestos y resultados de las órdenes.

Comandos ampliamente documentados como git, docker, kubectl, gh, curl, y jq Con frecuencia, estos esquemas requieren poca información introductoria. Los CLI menos comunes o de uso interno siguen necesitando ayuda accesible, ejemplos y una salida legible por máquina de forma estable.

La guía de Ugo Enyioha “Cómo desarrollar herramientas de línea de comandos que los AI Agentes realmente quieran utilizar” Se han codificado ocho reglas de diseño:

  1. Structured output es obligatorio — se requiere su soporte. --json
  2. Los códigos de salida constituyen el flujo de control: se deben utilizar códigos distintos para los diferentes tipos de errores.
  3. Las instrucciones deben ser idempotentes.
  4. Autodocumentación. --help con ejemplos realistas
  5. Diseño orientado a la componibilidad--quiet Para valores simples, soporte para stdin
  6. Proporcionar --dry-run y --yes flags
  7. Soporte para la introspección de versiones
  8. Gestión de la autenticación mediante variables de entorno

Los compromisos son reales. La CLI carece de la seguridad tipológica de MCP, de la orquestación OAuth integrada, de la capacidad de descubrimiento de herramientas y de un registro de auditoría. El patrón al que suelen recurrir la mayoría de los equipos es utilizar la CLI como opción predeterminada para el desarrollo y las operaciones locales, y MCP para la integración con servicios externos y la gobernanza empresarial.

5. Ejecución de código para tareas multietapa

Este es el cambio en las herramientas de agente que considero más significativo. En lugar de que LLM emita JSON estructurado para invocar funciones predefinidas una por una, el agente escribe un script completo en Python o Bash que llama a múltiples herramientas, procesa los resultados mediante bucles y condicionales, y devuelve únicamente resúmenes finales al contexto del modelo.

Anthropic formalizó esto mediante Llamada a herramientas programáticas (PTC), Ahora, GA en Claude API. La base académica es la Artículo CodeAct (Wang et al., ICML 2024), que realizaron pruebas en 17 LLMs y descubrieron que las acciones de código lograron tasas de éxito en las tareas un 20 % más altas, así como un 30 % menos de pasos en comparación con las alternativas basadas en JSON.

Flujo de ejecución de código

Tres estudios de caso de primera mano ilustran en qué situaciones este patrón puede resultar útil. Considérelos como evidencia proporcionada por el proveedor y realice nuevamente la comparación con sus propias tareas.

Aquí está el patrón de La documentación de PTC de Anthropic. Las herramientas tradicionales utilizadas para el análisis de gastos requieren más de 20 pasos de inferencia independientes, uno por cada miembro del equipo, y todos los datos intermedios deben transmitirse a través del contexto. Un flujo de trabajo que consumía aproximadamente 150,000 tokens al utilizar llamadas directas a herramientas fue reimplementado para solo unos 2,000 tokens, lo que supone una reducción del 98,7 %. Gracias a la ejecución de código, el agente escribe un único script:

# Agent generates this code, executes in sandbox
import json
members = get_team_members("engineering")
over_budget = []
for m in members:
    expenses = get_expenses(m["id"], "Q3")
    total = sum(e["amount"] for e in expenses)
    if total > 5000:
        custom = get_custom_budget(m["id"])
        limit = custom["limit"] if custom else 5000
        if total > limit:
            over_budget.append({"name": m["name"], "spent": total, "limit": limit})
# Only this final summary returns to the LLM context
print(json.dumps(over_budget))

El LLM solo muestra el resumen final JSON, y no los miles de elementos de gasto procesados en el sandbox. Eficiencia en el uso de tokens, composibilidad nativa (bucles y estructuras condicionales sin coste adicional), manejo real de errores (try/except En lugar del razonamiento en lenguaje natural sobre errores, así como la privacidad —ya que los datos sensibles permanecen dentro de sandbox—, todo mejora al mismo tiempo.

Cuando sigue teniendo sentido utilizar la herramienta JSON: operaciones atómicas individuales, entornos que no cuentan con infraestructura de aislamiento, modelos más pequeños con una capacidad limitada de generación de código, o requisitos de auditoría que exigen que se registre cada llamada individual a la herramienta.


AI Tabla de comparación entre herramientas de llamada desde agentes

DimensiónJSON Llamada a herramientasMCPHabilidades (SKILL.md)Ejecución de código (PTC)
Mejor paraAcciones simples y únicasSaaS multi-proveedorExperiencia en el dominio específicoFlujos de trabajo de desarrollo, operaciones localesOrquestación multietapa
Coste adicional por tokensMedio (esquemas por solicitud)Muy alto (550-1,400/herramienta)Muy bajo (~100 tokens)Casi ceroBajo (2 herramientas meta)
Evidencia de tareaLínea de base en los estudios citadosDepende del servidor y de la tarea.N/A (capa de expertise)Medir tareas nativas de la CLICodeAct reporta un aumento de hasta el +20%.
ComposibilidadBajo (secuencial)Bajo (secuencial)Alto (conocimiento procedimental)Alto (conductos, encadenamiento)Muy alto (código nativo)
Superficie de seguridadModerarAlto (50+ CVEs)Bajo (prompt-basado)Alto (acceso al shell)Alto (requiere entorno aislado)
Complejidad de configuraciónMediano (despliegue en servidor)Muy bajo (markdown)Muy bajo (CLIs existentes)Medio (sandbox infra)
Latencia por acción1 inferencia/llamada1 inferencia + transporte0 (inyección de contexto)1 inferencia/llamada1 paso para N llamadas
DepuraciónBuena (E/S estructurada)Moderación (capa de transporte)Excelente (visible)Código bueno (legible)

La composibilidad se refiere aquí a la facilidad con la que varias operaciones pueden encadenarse para formar un flujo de trabajo más amplio. Un valor bajo implica que cada tool call suele requerir un viaje adicional al modelo; en cambio, un valor alto indica que la interfaz permite transmitir los resultados intermedios mediante tuberías, variables o pasos procedimentales. Las celdas de token y de éxito de tarea resumen los ejemplos mencionados, y no representan a un único benchmark controlado en las cinco columnas.


La interfaz agente-computadora (ICA) para las herramientas de agente AI

El término “Agent-Computer Interface” (ACI) fue acuñado por John Yang, Carlos E. Jiménez y sus colegas en Princeton en su Artículo sobre SWE-agent (NeurIPS 2024). La idea es sencilla: al igual que los seres humanos se benefician de interfaces bien diseñadas (HCI), los agentes basados en modelos de lenguaje constituyen “una nueva categoría de usuarios finales con sus propias necesidades y capacidades, que también se beneficiarían de interfaces desarrolladas específicamente para ellos”.

El resultados de ablación Realicé una copia de seguridad de estos resultados. El SWE-agent, con su implementación completa de ACI, logró un rendimiento del 18,0% en SWE-bench Lite, frente al 7,3% que se obtuvo únicamente con una shell estándar de Linux; esto supone una mejora de 10,7 puntos porcentuales solo gracias al diseño de la interfaz. Por su parte, la función de control de errores de linting aportó 3 puntos porcentuales adicionales: el 51,7% de las ediciones realizadas por el agente presentaban al menos un error detectado por el linter antes de que pudiera propagarse.

Principios de diseño de ACI

Anthropic adoptó el ACI como concepto fundamental en su “Desarrollo de agentes eficaces” Guía, presentándolo como uno de los tres principios fundamentales: «Diseñe cuidadosamente su interfaz agente-computadora mediante una documentación y pruebas exhaustivas de las herramientas». Su recomendación práctica: «Una regla práctica es considerar la cantidad de esfuerzo que se invierte en las interfaces humano-computadora, y planificar invertir la misma cantidad de esfuerzo en crear buenas interfaces agente-computadora».

Cuatro principios de ACI en la práctica

1. Las acciones deben ser simples y fáciles de comprender. El error más frecuente es envolver los endpoints API de forma uno a uno. En lugar de list_users, list_events, create_event, implementar schedule_event que determina la disponibilidad y programa las tareas en una sola llamada. En lugar de read_logs, implementar search_logs que devuelve únicamente las líneas relevantes junto con su contexto.

2. Las acciones deben ser compactas y eficientes. Consolide las operaciones importantes en el menor número posible de acciones. En el Agente Analista de Mercado, Integro la obtención de precios con métricas básicas en una única get_stock_snapshot una herramienta que permite obtener dichos datos en una sola operación, en lugar de requerir llamadas separadas para el precio, el volumen, la capitalización de mercado y la relación P/E.

3. La retroalimentación del entorno debe ser informativa pero concisa. Evite devolver HTML sin procesar o cargas completas de API. Sustituya los identificadores crípticos por nombres semánticos. Las pruebas de Anthropic demostró que al añadir un response_format La enumeración que permite a los agentes solicitar respuestas concisas (~72 tokens) o detalladas (~206 tokens), con una diferencia de costo en tokens de 3 veces, mejoró de forma notable el rendimiento en entornos reales.

4. Las medidas de contención deben mitigar la propagación de errores. La detección automática de errores permite a los agentes reconocer y corregir los fallos de forma rápida. En SWE-agente, Un editor de archivos personalizado con linting integrado rechaza automáticamente los errores sintácticos, detectando el 51,7 % de los errores en las ediciones realizadas por los agentes antes de que puedan agravarse. Aplico el mismo principio en el Market Analyst Agent al validar los argumentos de las herramientas mediante esquemas Pydantic antes de su ejecución:

from pydantic import BaseModel, Field, field_validator

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)")
    period: str = Field(default="1mo", description="Time period: 1d, 5d, 1mo, 3mo, 1y")

    @field_validator("ticker")
    @classmethod
    def validate_ticker(cls, v: str) -> str:
        v = v.upper().strip()
        if not v.isalpha() or len(v) > 5:
            raise ValueError(f"Invalid ticker format: {v}")
        return v

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

AI Patrones de diseño de herramientas para agentes que son eficaces

Anthropic’s “Desarrollo de herramientas eficaces para agentes” Estas herramientas de guía se presentan como “un nuevo tipo de software que materializa un contrato entre sistemas deterministas y agentes no deterministas”. A continuación se detallan los patrones que han surgido a partir de la experiencia en entornos de producción.

Trate las descripciones de herramientas como prompt engineering

Las descripciones deben ser extensas. El proceso de entrenamiento de estos modelos requiere una cantidad significativa de recursos computacionales y tiempo de ejecución. Además, la selección adecuada de los parámetros de optimización es crucial para garantizar un aprendizaje eficiente y evitar el sobreajuste del modelo., Tratando cuándo utilizar la herramienta, los parámetros obligatorios frente a los opcionales, el formato de salida y los casos límite. Nomenclatura con prefijosasana_search, jira_searchEsto tiene «efectos no triviales» en la precisión de la selección de herramientas. En los experimentos de Anthropic, las descripciones de herramientas optimizadas para Claude superaron a las redactadas por expertos humanos en las pruebas de evaluación benchmarks.

# 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": "stock_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 broad market news (not ticker-specific), use market_overview 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"]
    }
}]

Pruebas internas se demostró que los ejemplos de entrada (input_examples Este parámetro) mejoró de forma sustancial la precisión en el manejo de parámetros complejos.

Devolver una salida de alto nivel de señal y legible por máquinas

Evite los identificadores de bajo nivel.uuid, mime_type). Resolver los ID enigmáticos en nombres semánticos. Estructurar la respuesta de modo que el agente pueda razonar sobre ella sin tener que analizar texto genérico innecesario:

# Bad: raw API response dumped to agent
def get_stock_price(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_price(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}%)"
    }

Devolver los errores en los que puede actuar el bucle

Utilice cuatro mecanismos independientes, ya que cada uno está diseñado para gestionar distintas categorías de fallos:

  1. Reintentar con retroceso exponencial ante errores transitorios.
  2. Cadenas de fallback de modelo en caso de interrupciones del proveedor.
  3. Enrutamiento por clasificación de errores: los errores transitorios se vuelven a intentar, los errores LLM recuperables se devuelven al agente junto con el contexto correspondiente, y los errores que requieren intervención humana se escalan.
  4. Recuperación Checkpoint para garantizar la continuidad tras caídas del sistema.

La guía de Anthropic mencionada aboga por la detección clara de errores en las herramientas y por un diseño basado en la evaluación. No establece una tasa universal de reducción de fallos; por lo tanto, debe medir usted mismo la tasa de recuperación, el número de intentos repetidos y los procedimientos de escalado en su propio conjunto de tareas.

from tenacity import retry, stop_after_attempt, wait_exponential

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

    Layer 1: Exponential backoff handles 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 Market Analyst

El Agente Analista de Mercado desde Parte 1 Hace visible el efecto de la interfaz.

Consolidación de herramientas

El artículo de la Parte 1 muestra la superficie simplificada con 5 herramientas tras esta refactorización. Antes de dicha limpieza, el diseño original contaba con más de 10 herramientas: get_stock_price, get_company_metrics, get_market_cap, get_pe_ratio, get_volume, y así sucesivamente. Cada uno de ellos era un envoltorio sencillo alrededor de un endpoint API. El agente tenía que razonar sobre qué combinación llamar para cada solicitud.

Consolidé todo esto en 5 herramientas de alto nivel, siguiendo el principio ACI de acciones compactas y eficientes:

¿Por qué?
get_stock_price + get_company_metrics + get_pe_ratioget_stock_snapshotUna sola llamada devuelve todo lo necesario para el análisis básico.
get_price_history + get_volume_historyget_price_historyEn combinación con un período y indicadores configurables.
search_news + search_press_releasessearch_newsBúsqueda unificada con filtrado de fuentes
search_competitors + get_sector_datasearch_competitorsDevuelve a los competidores junto con las métricas relativas.
get_financials + get_balance_sheet + get_cash_flowget_financialsUnificado con el parámetro statement_type

Esto redujo de forma significativa la sobrecarga generada por tool schema y aumentó la fiabilidad en la selección de herramientas por parte del agente, ya que disminuyeron las opciones ambiguas que era necesario tomar.

Structured outputs para tool results

Cada herramienta del agente Market Analyst devuelve una respuesta validada mediante Pydantic. De este modo, se aplica el principio de límites de seguridad de ACI en la interfaz con dichas herramientas:

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 NewsResult(BaseModel):
    """Each news item is 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

El summary El campo es el que tiene más importancia. Proporciona al agente una cadena lista para usar que puede incorporarse directamente en un informe sin necesidad de procesamiento adicional. key_points en NewsResult Se extraen del lado del servidor, lo que evita que el agente gaste tokens de inferencia al analizar el contenido de los artículos.


Compromisos y consideraciones

Más allá de las consideraciones específicas por modalidad mencionadas anteriormente, existen algunos problemas transversales que influyen en la elección:


Selección de herramientas a escala amplia

Tres direcciones merecen ser monitoreadas.

El primero es la herramienta RAG para el escalado. A medida que los conjuntos de herramientas pasan a contar con cientos o miles de elementos, la precisión en la selección de herramientas de forma intuitiva se degrada hasta el 13,62 %. El artículo sobre RAG-MCP Se demostró que la aplicación de la generación reforzada por recuperación en la selección de herramientas —es decir, indexando las descripciones de dichas herramientas en una base de datos vectorial y recuperando únicamente las herramientas relevantes para cada consulta— permite alcanzar una precisión del 43,13 %, lo que supone una mejora de 3,2 veces, al tiempo que se reducen los tokens prompt en aproximadamente un 50 %.

El segundo caso corresponde a los agentes que crean sus propias herramientas. El LATM framework (“@@LLMs@@ Como creadores de herramientas”) establecieron un paradigma en dos fases en el que un LLM potente genera funciones reutilizables en Python, y un LLM ligero las utiliza. ToolMaker (ACL 2025) transforma de forma autónoma los repositorios de GitHub en herramientas compatibles con LLM, logrando una tasa de éxito del 80 %. La frontera actual se está desplazando desde tool use hacia la creación de herramientas, y posteriormente hacia la gestión de bibliotecas de herramientas.

El tercero es la pila de protocolos duales A2A + MCP. El Protocolo Agent2Agent de Google (A2A) aborda aquello que MCP no puede hacer: la comunicación entre agentes. MCP se encarga de la integración entre agentes y herramientas; por su parte, A2A gestiona el descubrimiento, la negociación y la delegación de tareas entre agentes. La fórmula combinada es: construir con tu framework, equiparse con MCP y comunicarse mediante A2A.


Conclusiones principales

  1. Elija la interfaz según la acción: JSON para operaciones de tipo estructurado, MCP para servicios compartidos, Skills para procedimientos, CLI para comandos estandarizados, y código en entorno aislado para la composición local.
  2. Mantenga las condiciones benchmark asociadas al resultado. Plataformas como CodeAct, Anthropic, Vercel, Cloudflare, Apideck y Scalekit han evaluado distintos modelos, tareas, herramientas y frameworks.
  3. La calidad de ACI se mantiene estable incluso ante cambios en los protocolos. Acciones claras, retroalimentación concisa, mecanismos de validación y mensajes de error útiles son esenciales en todas las modalidades.
  4. Consolide solo las herramientas que se superponen cuando las evaluaciones demuestren que una interfaz más simplificada mejora la selección o el éxito de la tarea.
  5. La seguridad evoluciona junto con la capacidad de ejecución. Las interfaces de shell y código requieren entornos aislados; MCP necesita identidades y políticas de servidor bien delimitadas; Skills siguen funcionando como instrucciones en lugar de mecanismos de control estricto.

La siguiente capa corresponde a la política

Parte 4, AI Seguridad de agentes en 2026, Se realiza una comprobación de política entre la propuesta de tool call y su ejecución. A continuación, la Parte 5 coloca la herramienta y su sandbox dentro de un runtime recuperable. Por último, la Parte 6 vuelve a la interfaz desde el lado de harness: explicando cómo los rastreos, los evaluadores, las reglas de reintentos y las comprobaciones de aceptación convierten los comentarios de la herramienta en un ciclo de mejora medible.


Referencias

Artículos científicos

Ingeniería de Anthropic

Estudios de caso del sector

Seguridad

Diseño de CLI

Proyecto de demostración


El código completo del agente Market Analyst, incluidos los diseños de herramientas descritos en esta publicación, se encuentra en GitHub._

Serie: Ingeniería de la pila Agentic