Ir para o conteúdo

Tradução automática

Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Utilização de Ferramentas por Agentes de IA em 2026: MCP, CLI, Skills e Execução de Código

Parte 3 da série Engineering the Agentic Stack

A Parte 1 abordou os ciclos de raciocínio, a Parte 2 abordou a memória. Este artigo é sobre utilização de ferramentas por agentes de IA: como os agentes interagem com o mundo e porque o desenho das ferramentas importa mais do que a maioria das equipas percebe.

A história das ferramentas mudou em 2025–2026. O MCP tornou-se o standard de facto para serviços externos, mas as equipas de produção continuam a deparar-se com as suas lacunas de segurança e overhead de tokens. A outra abordagem que está a ganhar adoção são agentes que escrevem e executam código em vez de chamarem ferramentas definidas em JSON. A Anthropic mediu uma redução de 98,7% em tokens num workflow representativo, e o artigo CodeAct reporta taxas de sucesso em tarefas 20% mais altas.

Este artigo compara JSON tool calling, MCP, Skills, ferramentas CLI e execução de código, e depois mapeia-os para os princípios de desenho Agent-Computer Interface (ACI) que aplico no Market Analyst Agent.

Resumo: Existem cinco modalidades de ferramentas para agentes de IA, cada uma com o seu ponto ideal. A stack prática de 2026: Skills para especialização, CLI por omissão, MCP para serviços externos, execução de código para orquestração multi-step. Os princípios de desenho ACI do SWE-agent aplicam-se a todas elas.

Cinco formas de os agentes de IA usarem ferramentas

Na Parte 1, mostrei como os ciclos de raciocínio dos agentes de IA decidem como pensar. As modalidades de ferramentas decidem como agir. Existem agora cinco abordagens distintas, cada uma com trade-offs diferentes em custo de tokens, flexibilidade e segurança.

Panorama das Modalidades de Ferramentas

1. JSON Tool Calling — A Base

O padrão original: define esquemas de ferramentas em JSON, o LLM emite chamadas de função estruturadas, o teu código executa-as. É bem compreendido e funciona bem para conjuntos pequenos de ferramentas.

# 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"]
        }
    }
]

Com 5-10 ferramentas, isto funciona bem. O problema é a escala: cada definição de ferramenta custa 550-1.400 tokens. Com 20 ferramentas, estás a gastar 15-25K tokens antes de o agente sequer começar a raciocinar.

2. MCP — O Standard Universal (Com Reservas)

O Model Context Protocol é o standard para o qual a maioria dos vendors convergiu. A Anthropic doou-o à Linux Foundation sob a Agentic AI Foundation (AAIF) em dezembro de 2025, cofundada com a OpenAI e a Block, e apoiada pela Google, Microsoft e AWS como membros platinum. A OpenAI adicionou suporte para MCP na sua Responses API. Existem agora mais de 10.000 servidores MCP ativos e mais de 97M de downloads mensais do SDK.

Onde o MCP ganha: integração SaaS cross-vendor (Figma, Notion, Salesforce), governance empresarial com audit trails, serviços sem equivalentes CLI, e ambientes que precisam de orquestração OAuth. Para estes casos de uso, o MCP é a escolha clara.

A realidade em produção é mais confusa do que os números de destaque sugerem.

A superfície de segurança é o primeiro problema. O Vulnerable MCP Project acompanha 50 vulnerabilidades em servidores MCP, 13 classificadas como Critical, contribuídas por 32 investigadores de segurança. As classes de ataque abrangem prompt injection, falhas de validação de input, lacunas de autenticação e falhas de segurança de rede. O primeiro servidor MCP malicioso no mundo real apareceu em setembro de 2025: um pacote chamado postmark-mcp que colocava em BCC todos os emails enviados para um endereço de um atacante, afetando um número estimado de 300–500 organizações antes de ser descoberto.

Tool poisoning é a classe de ataque que mais me preocupa. A Invariant Labs demonstrou que ferramentas MCP envenenadas podem exfiltrar dados mesmo quando nunca são invocadas. Basta o modelo ler os metadados da ferramenta para desencadear o ataque. Os benchmarks MCPTox, que testaram 20 agentes LLM contra 45 servidores MCP do mundo real, encontraram taxas de sucesso de ataque tão altas como 72,8%.

O overhead de tokens é o problema operacional. Uma equipa a correr servidores MCP para GitHub, Slack e Sentry (~40 ferramentas no total) encontrou 55.000 tokens de definições de esquema injetadas antes de um utilizador perguntar qualquer coisa. Outra reportou 143.000 de 200.000 tokens disponíveis (72%) consumidos apenas por definições de ferramentas.

Comparação de Overhead de Tokens

As mitigations funcionam, mas confirmam o problema subjacente. A Tool Search Tool da Anthropic reduz o overhead de esquemas em 85%. O carregamento dinâmico de ferramentas (3-5 ferramentas relevantes por tarefa) atinge uma redução de 96%. Estes são workarounds para um protocolo que não foi desenhado a pensar em orçamentos de tokens.

3. Skills (SKILL.md) — Especialização, Não Execução

O final de 2025 trouxe a normalização de agent skills como formato aberto (lançado em outubro de 2025, publicado como standard aberto em dezembro de 2025). A distinção importa: as ferramentas fornecem capacidades (o que os agentes podem fazer), e as skills fornecem especialização (o que os agentes sabem sobre como realizar tarefas complexas).

O standard SKILL.md define uma skill como um ficheiro markdown com YAML frontmatter:

---
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

As skills usam progressive disclosure: apenas os metadados (~100 tokens para o YAML frontmatter) são carregados no arranque, e as instruções completas são carregadas quando a skill é ativada. Compare-se isso com o MCP, onde ~40 ferramentas em serviços típicos consomem ~55.000 tokens antes de qualquer raciocínio começar. A adoção cross-platform em março de 2026 inclui Claude Code, OpenAI Codex CLI, Cursor, GitHub Copilot, Gemini CLI, Goose, Windsurf e Roo Code, uma tendência que Victor Dibia explorou na sua análise da mudança das ferramentas de volta para ações de agentes orientadas por código.

Quando as skills ganham: transferência de especialização de domínio, procedimentos complexos multi-step, workflows recorrentes como migrações de bases de dados ou integrações de pagamentos, e qualquer tarefa em que o agente precise de saber como e não apenas o quê.

4. CLI/Bash — O Renascimento Unix

O terminal Unix acabou por ser a interface de agente mais eficiente em tokens. A matemática é unilateral: um manifesto de ferramenta CLI custa cerca de 100 tokens, enquanto os esquemas equivalentes de um servidor MCP consomem mais de 50.000 tokens. Esta é uma diferença de 4-32x medida pela Scalekit em 75 execuções de benchmark (32x para tarefas como identificar a linguagem de um repositório e consultar a licença).

Os modelos são falantes nativos de CLI. Os seus dados de treino incluem milhares de milhões de interações de terminal vindas do Stack Overflow, repositórios GitHub e documentação. Compreendem nativamente git, docker, kubectl, gh, curl e jq sem quaisquer definições de esquema.

O guia de Ugo Enyioha \"Writing CLI Tools That AI Agents Actually Want to Use\" codificou oito regras de desenho:

  1. Structured output is mandatory — suportar --json
  2. Exit codes are control flow — usar códigos distintos para diferentes tipos de erro
  3. Commands should be idempotent
  4. Self-documenting --help com exemplos realistas
  5. Design for composability — --quiet para valores simples, suporte para stdin
  6. Provide --dry-run e flags --yes
  7. Support version introspection
  8. Handle auth via environment variables

Os trade-offs são reais. A CLI não tem a type safety do MCP, a orquestração OAuth integrada, a descoberta de ferramentas e o audit trail. O padrão que vejo a maioria das equipas adotar: CLI por omissão para desenvolvimento e operações locais, MCP para integração com serviços externos e governance empresarial.

5. Execução de Código — A Grande Mudança

Esta é a mudança em tooling de agentes que considero mais consequente. Em vez de o LLM emitir JSON estruturado para invocar funções predefinidas uma de cada vez, o agente escreve um script completo em Python ou bash que chama várias ferramentas, processa resultados com loops e condicionais, e devolve apenas resumos finais ao contexto do modelo.

A Anthropic formalizou isto com Programmatic Tool Calling (PTC), agora GA na Claude API. A base académica é o artigo CodeAct (Wang et al., ICML 2024), que testou 17 LLMs e concluiu que ações baseadas em código atingiram até 20% mais sucesso em tarefas e 30% menos passos do que alternativas JSON.

Fluxo de Execução de Código

A evidência em produção:

  • A Vercel reconstruiu o seu agente d0 text-to-SQL removendo 80% das suas ferramentas (de 15 para 2: ExecuteCommand e ExecuteSQL). O sucesso nas tarefas saltou de 80% para 100%, o tempo de execução caiu 3,5x e o uso de tokens desceu 40%. Nas palavras deles: \"The best agents might be the ones with the fewest tools.\"

  • A Cloudflare desenvolveu o \"Code Mode,\" permitindo aos agentes escrever TypeScript para chamar a sua API em vez de definir esquemas de ferramentas, o que reduz o overhead de contexto. A sua justificação: \"LLMs have an enormous amount of real-world TypeScript in their training set, but only a small set of contrived examples of tool calls.\"

Aqui está o padrão da documentação de PTC da Anthropic. O tool calling tradicional para análise de despesas requer mais de 20 passes de inferência separados, um por membro da equipa, com todos os dados intermédios a passarem pelo contexto. Um workflow que consumia ~150.000 tokens com tool calling direto foi reimplementado para ~2.000 tokens, uma redução de 98,7%. Com execução de código, o agente escreve um ú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))

O LLM vê apenas o resumo JSON final, não as milhares de linhas de despesas processadas no sandbox. Eficiência de tokens, composabilidade nativa (loops e condicionais vêm gratuitamente), tratamento real de erros (try/except em vez de raciocínio em linguagem natural sobre erros), e privacidade (dados sensíveis ficam no sandbox) melhoram todos ao mesmo tempo.

Quando o JSON tool calling continua a fazer sentido: operações atómicas únicas, ambientes sem infraestrutura de sandboxing, modelos menores com fraca geração de código, ou requisitos de auditoria que precisem de cada invocação individual de ferramenta registada.

Tabela comparativa de tool calling para agentes de IA

Dimension JSON Tool Calling MCP Skills (SKILL.md) CLI/Bash Code Execution (PTC)
Best for Ações simples e únicas SaaS cross-vendor Especialização de domínio Workflows de dev, ops locais Orquestração multi-step
Token overhead Médio (esquemas por pedido) Muito alto (550-1.400/tool) Muito baixo (~100 tokens) Quase zero Baixo (2 meta-tools)
Task success rate Baseline Semelhante à baseline N/A (camada de especialização) Mais alta para tarefas nativas de CLI +20% vs baseline
Composability Baixa (sequencial) Baixa (sequencial) Alta (conhecimento procedural) Alta (pipes, chaining) Muito alta (código nativo)
Security surface Moderada Alta (50+ CVEs) Baixa (baseada em prompts) Alta (acesso shell) Alta (requer sandboxing)
Setup complexity Baixa Média (deploy de servidor) Muito baixa (markdown) Muito baixa (CLIs existentes) Média (infra de sandbox)
Latency per action 1 inferência/chamada 1 inferência + transporte 0 (injeção no contexto) 1 inferência/chamada 1 passagem para N chamadas
Debugging Bom (I/O estruturado) Moderado (camada de transporte) Bom (markdown legível) Excelente (visível) Bom (código legível)

Composability aqui significa quão facilmente várias operações se encadeiam num workflow maior. Baixa significa que cada chamada de ferramenta exige um round-trip separado ao LLM; alta significa que a modalidade suporta nativamente o encadeamento de resultados (pipes Unix, variáveis de código, passos procedurais).

A Agent-Computer Interface (ACI) para ferramentas de agentes de IA

O termo \"Agent-Computer Interface\" (ACI) foi cunhado por John Yang, Carlos E. Jimenez e colegas de Princeton no seu artigo SWE-agent (NeurIPS 2024). A ideia é simples: tal como os humanos beneficiam de interfaces bem desenhadas (HCI), os agentes LM são \"a new category of end users with their own needs and abilities, and would benefit from specially-built interfaces.\"

Os resultados de ablation comprovaram-no. O SWE-agent com a sua ACI completa atingiu 18,0% no SWE-bench Lite versus 7,3% com apenas uma shell Linux standard, uma melhoria de 10,7 pontos percentuais apenas por desenho de interface. O guardrail de linting, por si só, representou 3 pontos percentuais: 51,7% das edições do agente tinham pelo menos um erro apanhado pelo linter antes de se propagar.

Princípios de Desenho ACI

A Anthropic adotou a ACI como conceito fundamental no seu guia \"Building Effective Agents\", listando-o como um de três princípios centrais: \"Carefully craft your agent-computer interface through thorough tool documentation and testing.\" A sua orientação prática: \"One rule of thumb is to think about how much effort goes into human-computer interfaces, and plan to invest just as much effort in creating good agent-computer interfaces.\"

Os Quatro Princípios na Prática

1. As ações devem ser simples e fáceis de compreender. O erro mais comum é encapsular endpoints de API um-para-um. Em vez de list_users, list_events, create_event, implementa schedule_event que encontra disponibilidade e agenda numa só chamada. Em vez de read_logs, implementa search_logs que devolve apenas as linhas relevantes com contexto.

2. As ações devem ser compactas e eficientes. Consolida operações importantes no menor número possível de ações. No Market Analyst Agent, combino a obtenção de preços com métricas básicas numa única ferramenta get_stock_snapshot em vez de exigir chamadas separadas para preço, volume, market cap e PE ratio.

3. O feedback do ambiente deve ser informativo mas conciso. Evita devolver HTML bruto ou payloads completos de API. Resolve IDs crípticos para nomes semânticos. Os testes da Anthropic mostraram que adicionar um enum response_format permitindo aos agentes pedir respostas concisas (~72 tokens) ou detalhadas (~206 tokens) — uma diferença de custo de 3x em tokens — melhorou visivelmente o desempenho no mundo real.

4. Os guardrails devem mitigar a propagação de erros. A deteção automática de erros ajuda os agentes a reconhecer e corrigir rapidamente falhas. No SWE-agent, um editor de ficheiros personalizado com linting integrado rejeita automaticamente erros de sintaxe, apanhando 51,7% dos erros de edição do agente antes de se acumularem. Aplico o mesmo princípio no Market Analyst Agent validando argumentos de ferramentas com esquemas Pydantic antes da execução:

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

Padrões de desenho de ferramentas para agentes de IA que funcionam

O guia da Anthropic \"Writing effective tools for agents\" enquadra as ferramentas como \"a new kind of software reflecting a contract between deterministic systems and non-deterministic agents.\" Eis os padrões que se consolidaram com a experiência em produção.

Tratar Descrições de Ferramentas como Prompt Engineering

As descrições devem ter no mínimo 3-4+ frases, cobrindo quando usar a ferramenta, parâmetros obrigatórios versus opcionais, formato de output e edge cases. Namespacing com prefixos (asana_search, jira_search) tem \"non-trivial effects\" na precisão da seleção de ferramentas. Nas experiências da Anthropic, descrições de ferramentas otimizadas para Claude superaram as escritas por humanos especialistas nos benchmarks de avaliação.

# 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"]
    }
}]

Testes internos mostraram que exemplos de input (campo input_examples) melhoraram substancialmente a precisão no tratamento de parâmetros complexos.

Devolver Output de Alto Sinal e Legível por Máquina

Evita identificadores de baixo nível (uuid, mime_type). Resolve IDs crípticos para nomes semânticos. Estrutura a resposta para que o agente consiga raciocinar sobre ela sem ter de fazer parsing de boilerplate:

# 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}%)"
    }

Desenhar o Tratamento de Erros para Resiliência

O padrão que se manteve em produção é de quatro camadas de tolerância a falhas:

  1. Retry com exponential backoff para erros transitórios
  2. Cadeias de fallback de modelos para indisponibilidade de providers
  3. Routing por classificação de erros — erros transitórios fazem retry, erros recuperáveis por LLM regressam ao agente com contexto, erros que exigem intervenção humana são escalados
  4. Recuperação por checkpoint para sobreviver a crashes

As equipas reportam quedas de falhas irrecuperáveis de 23% para menos de 2% com esta abordagem de quatro camadas, tal como documentado nos padrões de resiliência de ferramentas da Anthropic.

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()

Aplicar Estes Padrões: o Market Analyst Agent

Deixa-me mostrar como estes princípios se combinam no Market Analyst Agent da Parte 1.

Consolidação de Ferramentas

O artigo da Parte 1 mostra a superfície simplificada de 5 ferramentas após esta refatoração. Antes dessa limpeza, o desenho original tinha mais de 10 ferramentas: get_stock_price, get_company_metrics, get_market_cap, get_pe_ratio, get_volume, entre outras. Cada uma era um wrapper fino sobre um endpoint de API. O agente tinha de raciocinar sobre que combinação chamar para cada pedido.

Consolidei-as em 5 ferramentas de alto nível, seguindo o princípio ACI de ações compactas e eficientes:

Before (10+ tools) After (5 tools) Why
get_stock_price + get_company_metrics + get_pe_ratio get_stock_snapshot Uma única chamada devolve tudo o que é necessário para análise básica
get_price_history + get_volume_history get_price_history Combinado com período e indicadores configuráveis
search_news + search_press_releases search_news Pesquisa unificada com filtragem por fonte
search_competitors + get_sector_data search_competitors Devolve concorrentes com métricas relativas
get_financials + get_balance_sheet + get_cash_flow get_financials Unificado com parâmetro statement_type

Isto reduziu substancialmente o overhead do esquema de ferramentas e tornou a seleção de ferramentas do agente mais fiável, porque há menos escolhas ambíguas a fazer.

Outputs Estruturados para Resultados de Ferramentas

Todas as ferramentas do Market Analyst Agent devolvem uma resposta validada por Pydantic. Isto aplica o princípio ACI dos guardrails no boundary da ferramenta:

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

O campo summary é o que mais importa. Dá ao agente uma string pronta a usar que pode ir diretamente para um relatório sem processamento adicional. As key_points em NewsResult são extraídas do lado do servidor, poupando ao agente tokens de inferência gastos a fazer parsing dos corpos dos artigos.

Trade-offs e Considerações

Para além das reservas específicas de cada modalidade acima, há algumas preocupações transversais que moldam a escolha:

  • O custo operacional varia por dimensão. A execução de código poupa tokens mas acrescenta latência de cold-start do sandbox. O MCP poupa tempo de desenvolvimento para integrações SaaS mas acrescenta overhead de deploy do servidor. A CLI é gratuita para começar mas mais difícil de governar à escala. Otimiza para o teu verdadeiro bottleneck, seja custo de tokens, latência ou complexidade operacional.

  • As competências da equipa importam. A execução de código assume que os teus agentes (e os modelos por detrás deles) conseguem gerar Python ou TypeScript fiável. A CLI assume familiaridade com convenções Unix. O MCP exige compreensão de protocolos de transporte e fluxos OAuth. Ajusta a modalidade aos pontos fortes da tua equipa.

  • A consolidação de ferramentas pode ir longe demais. Se juntares tudo numa mega-ferramenta, o espaço de parâmetros torna-se demasiado complexo para o agente navegar. O ponto ideal é 5-10 ferramentas bem delimitadas para a maioria dos sistemas de agentes.

  • As skills são baseadas em prompts, não impostas. Uma skill são instruções que o agente deve seguir, não guardrails que tem de seguir. Para workflows críticos, combina skills com validação determinística.

  • Os requisitos de auditoria moldam a escolha. Se precisas de um registo completo de cada invocação de ferramenta e do seu resultado, MCP e JSON tool calling fornecem audit trails estruturados de origem. A execução de código produz um script e o seu output, o que é útil mas mais difícil de decompor em ações individuais para reporting de compliance.

Para Onde Vai a Ergonomia das Ferramentas

Há três direções que vale a pena acompanhar.

A primeira é tool RAG para escalar. À medida que os conjuntos de ferramentas crescem para centenas ou milhares, a precisão ingênua de seleção de ferramentas degrada-se para 13,62%. O artigo RAG-MCP mostrou que aplicar retrieval-augmented generation à seleção de ferramentas (indexando descrições de ferramentas numa base de dados vetorial e recuperando apenas ferramentas relevantes por query) atinge 43,13% de precisão, uma melhoria de 3,2x, ao mesmo tempo que corta ~50% dos tokens no prompt.

A segunda é agentes a criarem as suas próprias ferramentas. O framework LATM (\"LLMs As Tool Makers\") estabeleceu um paradigma de duas fases em que um LLM poderoso cria funções Python reutilizáveis e um LLM leve as usa. O ToolMaker (ACL 2025) transforma autonomamente repositórios GitHub em ferramentas compatíveis com LLM com uma taxa de sucesso de 80%. A fronteira está a mover-se da utilização de ferramentas para a criação de ferramentas, e depois para a gestão de bibliotecas de ferramentas.

A terceira é a stack de protocolo duplo A2A + MCP. O Agent2Agent Protocol (A2A) da Google resolve o que o MCP não consegue: comunicação agente-a-agente. O MCP trata da integração agente-ferramenta; o A2A trata da descoberta, negociação e delegação de tarefas entre agentes. A fórmula combinada: construir com o teu framework, equipar com MCP, comunicar com A2A.

Principais Conclusões

  1. A utilização de ferramentas tem cinco modalidades distintas, cada uma com um ponto ideal claro. Não uses MCP por defeito para tudo; ajusta a modalidade à tarefa.

  2. A execução de código a substituir JSON tool calling é a maior mudança no tooling de agentes. O PTC da Anthropic, a redução de ferramentas da Vercel e o Code Mode da Cloudflare convergem todos na mesma ideia: deixar os agentes escrever código em vez de chamarem esquemas.

  3. O overhead de tokens é o bottleneck operacional. Mais de 55K tokens para ~40 ferramentas MCP versus ~100 tokens para manifestos CLI não é uma diferença marginal. É a diferença entre um agente ter 65% versus 95% do seu contexto para raciocinar.

  4. Os princípios de desenho ACI importam mais do que o protocolo. O SWE-agent mostrou que o desenho da interface por si só representou 10,7 pontos percentuais em benchmarks. Ações simples, feedback conciso e guardrails integrados aplicam-se independentemente de usares MCP, CLI ou execução de código.

  5. Consolida ferramentas de forma agressiva. Cinco ferramentas bem desenhadas superam vinte granulares. Cada ferramenta é uma escolha que estás a forçar o modelo a fazer, por isso reduz o espaço de decisão.

  6. Trata as descrições das ferramentas como prompt engineering. Exemplos de input melhoram substancialmente a precisão. Descrições otimizadas para Claude superam as escritas por humanos especialistas. Investe o mesmo esforço em UX de ferramentas que investes em UX humana.

  7. A stack prática de 2026 é Skills + CLI + MCP + Code Execution, em camadas por caso de uso. Skills para especialização, CLI para ops locais, MCP para serviços externos, execução de código para orquestração multi-step.

O Que Vem a Seguir

Na Parte 4, Segurança de Agentes de IA em 2026, cubro a camada de políticas à volta dos agentes: como prevenir ações destrutivas, chamadas de ferramentas alucinadas e fugas de dados sensíveis através das respostas das ferramentas.

Referências

Papers

Engenharia Anthropic

Casos de Estudo da Indústria

Segurança

Desenho CLI

Projeto Demo

  • Market Analyst Agent — Implementação completa com consolidação de ferramentas e padrões ACI

O código completo do Market Analyst Agent, incluindo os desenhos de ferramentas descritos neste artigo, está no GitHub.

Série: Engineering the Agentic Stack