2026-03-24 · Atualizado 2026-07-14

[!NOTE] Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.

AI Agente Tool Use em 2026: MCP, CLI, Habilidades e Execução de Código

Parte 3 da série Engenharia da pilha Agentic

Parte 1 laços de raciocínio cobertos, e Parte 2 Memória coberta. Este artigo introduz a camada de ação: como um agente expõe, seleciona e executa ferramentas.

A evolução das ferramentas mudou entre 2025 e 2026. O MCP proporcionou aos fornecedores um protocolo comum para serviços externos, ao mesmo tempo que os agentes capazes de executar código demonstraram que, em certos casos, um modelo consegue compor um pequeno programa de forma mais eficiente do que realizar uma sequência longa de chamadas JSON. A Anthropic relatou uma redução de 98,7% nos tokens num fluxo de trabalho de análise de despesas, enquanto o artigo científico do CodeAct apresentou ganhos de até 20% na sua configuração benchmark. Esses resultados referem-se às tarefas e aos mecanismos utilizados por eles, e não a uma vantagem universal para a execução de código.

Comparo a chamada da ferramenta JSON, MCP, Skills, ferramentas CLI e a execução de código nessa ordem. A secção final aplica os princípios de design da Interface Agente-Computador (ACI) a Agente de Análise de Mercado.

TL;DR: Cinco padrões de interface úteis abrangem a maioria dos agentes tool use. As skills transmitem instruções, as ferramentas CLI são adequadas para desenvolvimento local, o MCP liga serviços partilhados, e a execução de código compõe tarefas multifásicas dentro de um sandbox. A utilização de ferramentas JSON permanece a opção mais simples para ações atómicas pequenas. Independentemente do protocolo, a Interface Agente-Computador (ACI) deve garantir que as ações sejam claras, o feedback seja conciso e os erros possam ser recuperados.

Cinco formas como os agentes AI utilizam ferramentas

In Parte 1, O reasoning loop selecionou o passo seguinte. Parte 2 Armazena o estado necessário para retomá-lo. A fronteira da ferramenta transforma essa decisão numa ação e devolve uma observação ao ciclo. Estes cinco padrões implicam diferentes compromissos em termos de custo de tokens, flexibilidade e aplicação estrita das regras.

1. Chamada da ferramenta JSON: a linha de base

O padrão original consiste em definir tool schemas como JSON, de modo que o LLM emita chamadas de função estruturadas, sendo que o seu código as executa posteriormente. Este método é amplamente compreendido e funciona perfeitamente para conjuntos de ferramentas pequenos.

# 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 a 10 ferramentas, isto é aceitável. O problema está na escala: cada definição de ferramenta tem um custo elevado. 550–1.400 tokens. Com 20 ferramentas, já se gastam entre 15 e 25 mil tokens antes mesmo de o agente começar a raciocinar.

2. MCP para integrações partilhadas

O Model Context Protocol é o padrão no qual a maioria dos fornecedores concordou. A Anthropic doou-o à Linux Foundation através da Fundação AAIF ( Agentic AI ), em dezembro de 2025, em parceria com a OpenAI e a Block, contando com o apoio da Google, Microsoft e AWS na qualidade de membros platinados. A OpenAI adicionou suporte para MCP nas suas respostas API. Atualmente, existem mais de 10.000 servidores MCP ativos e mais de 97 milhões de downloads mensais de SDK.

MCP é adequado para integrações SaaS entre diferentes fornecedores (Figma, Notion, Salesforce), serviços que não dispõem de equivalentes via CLI, e ambientes que exigem orquestração OAuth. A sua principal vantagem reside num camada comum de descoberta e transporte de dados. A governança continua a depender dos mecanismos de autenticação, autorização, registo de atividades e controlos de deploy do servidor.

A realidade na produção é mais complexa do que indicam os números divulgados nos títulos das notícias.

A superfície de segurança é o primeiro problema. O Projeto vulnerável MCP Monitoriza 50 vulnerabilidades em servidores MCP, das quais 13 foram classificadas como Críticas, identificadas por 32 investigadores de segurança. As categorias de ataque abrangem prompt injection, falhas na validação de entrada, lacunas na autenticação e falhas de segurança de rede. O primeiro servidor MCP malicioso no mundo real foi publicado em setembro de 2025: um pacote chamado postmark-mcp que enviava cópias ocultas para o endereço de um atacante em cada e-mail enviado, afetando cerca de 300–500 organizações antes de ser detetado.

A envenenamento de ferramentas é a classe de ataque que mais me preocupa. A Invariant Labs demonstrou Essas ferramentas contaminadas com MCP conseguem extrair dados mesmo quando nunca são invocadas. Basta o modelo ler os metadados da ferramenta para desencadear o ataque. MCPTox benchmarks Ao testar 20 LLM agentes contra 45 servidores do mundo real MCP, verificou‑se que as taxas de sucesso dos ataques atingiam 72,8%.

O overhead de tokens representa o problema operacional principal. Uma equipa que gere servidores MCP para o GitHub, Slack e Sentry (~40 ferramentas no total) constatou 55.000 tokens de definições de esquema injetadas antes de o utilizador fazer qualquer pergunta. Outro problema reportado 143.000 de 200.000 tokens disponíveis (72%) Consumido exclusivamente pelas definições das ferramentas.

A Anthropic comunicou uma redução de 85% nos esquemas associados à sua Ferramenta de Pesquisa de Ferramentas, bem como uma redução de 96% ao carregar de três a cinco ferramentas relevantes para as tarefas avaliadas. O carregamento seletivo permite manter a superfície de protocolo, eliminando simultaneamente os esquemas que a solicitação atual não necessita.

3. Experiência no conjunto de competências, não na execução

No final de 2025, ocorreu a padronização das habilidades de agente como um formato aberto (lançado em outubro de 2025 e publicado como padrão aberto em dezembro de 2025). Esta distinção é importante: as ferramentas fornecem capacidades (o que os agentes conseguem fazer), enquanto as habilidades conferem conhecimento especializado (o que os agentes sabem para realizar tarefas complexas).

O padrão SKILL.md define uma competência como um ficheiro Markdown com frontmatter em 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

As competências utilizam divulgação progressiva. Cerca de 100 tokens de metadados são carregados na inicialização; as instruções completas só são carregadas quando a competência está ativa. Em contraste, cerca de 40 MCP ferramentas podem consumir cerca de 55.000 tokens Antes mesmo de o processo de raciocínio começar, já em março de 2026, o Claude Code, o OpenAI Codex CLI, o Cursor, o GitHub Copilot, o Gemini CLI, o Goose, o Windsurf e o Roo Code tinham adotado este formato. Victor Dibia descreve esta mudança em direção a ações de agente orientadas por código.

Utilize essas competências para conhecimento de domínio, procedimentos em vários passos e tarefas recorrentes, como migrações de bases de dados ou integrações de pagamento. Elas são adequadas para tarefas em que o agente necessita de instruções sobre como utilizar uma capacidade já existente.

4. Ferramentas CLI e de shell

As interfaces CLI podem ser muito mais económicas no contexto em que o modelo já conhece o comando. A Scalekit relatou um 4-32x diferença de tokens entre as suas rotas CLI e MCP ao longo de 75 execuções. Esse estudo de caso avalia as suas ferramentas e tarefas; ele não substitui uma comparação feita com os seus próprios manifestos e resultados das operações de comando.

Comandos amplamente documentados, como git, docker, kubectl, gh, curl, e jq Geralmente, necessitam de pouco texto introdutório no esquema. Os CLI menos comuns ou internos continuam a exigir ajuda acessível, exemplos e resultados estáveis e legíveis por máquinas.

Guia de Ugo Enyioha “Desenvolver ferramentas CLI que os AI Agentes realmente querem utilizar” Codificaram oito regras de projeto:

1. Structured output é obrigatório — suporte --json
2. Códigos de saída constituem fluxo de controle — utilize códigos distintos para diferentes tipos de erro.
3. Os comandos devem ser idempotentes.
4. Autodocumentação. --help com exemplos realistas
5. Projeto para composabilidade — --quiet para valores simples, suporte a stdin
6. Fornecer --dry-run e --yes flags
7. Suporte à introspecção da versão
8. Tratamento da autenticação por meio de variáveis de ambiente

Os compromissos são reais. A CLI carece da segurança de tipo oferecida por MCP, bem como da orquestração integrada de OAuth, da descoberta de ferramentas e do registo de auditoria. O padrão que observo na maioria das equipas é utilizar a CLI como padrão para desenvolvimento e operações locais, e MCP para a integração com serviços externos e a governação empresarial.

5. Execução de código para tarefas multifaseadas

Esta é a alteração nas ferramentas de agente que considero mais significativa. Em vez de o LLM emitir JSON estruturado para invocar funções predefinidas uma a uma, o agente escreve um script completo em Python ou bash que chama vários instrumentos, processa os resultados através de laços e condicionais, e devolve apenas resumos finais para o contexto do modelo.

A Anthropic formalizou isto com Chamada de Ferramentas Programáticas (PTC), Atualmente, o GA está integrado no Claude API. A base académica é a Artigo CodeAct (Wang et al., ICML 2024), que realizou testes em 17 LLMs e constatou que as ações de código alcançaram taxas de sucesso nas tarefas até 20% mais elevadas e exigiram 30% menos passos em comparação com as alternativas baseadas em JSON.

Três estudos de caso de primeira mão demonstram em que cenários este padrão pode ser útil. Trate-os como evidências fornecidas pelos fabricantes e realize novamente a comparação nas suas próprias tarefas.

• Vercel reconstruiu o seu agente d0 de texto para SQL ao remover 80% das suas ferramentas (de 15 para 2): ExecuteCommand e ExecuteSQL). A taxa de sucesso das tarefas aumentou de 80% para 100%, o tempo de execução diminuiu 3,5 vezes e o consumo de tokens caiu 40%. A forma como eles expressam isso é: “Os melhores agentes podem ser aqueles que dispõem dos menores números de ferramentas.”

• A Cloudflare desenvolveu o “Code Mode”. Permitir que os agentes escrevam em TypeScript para chamar o API em vez de definirem o tool schemas, o que reduz a sobrecarga de contexto. A sua justificação é a seguinte: “LLMs dispõem de uma quantidade enorme de código em TypeScript do mundo real no seu conjunto de treino, mas apenas um pequeno conjunto de exemplos artificiais de tool calls.”

Aqui está o padrão de Documentação PTC da Anthropic. As ferramentas tradicionais utilizadas para a análise de despesas exigem mais de 20 passagens de inferência separadas, uma para cada membro da equipa, sendo que todos os dados intermediários são processados através do contexto. Um fluxo de trabalho que consumia cerca de 150.000 tokens com chamadas diretas à ferramenta foi reimplementado para apenas cerca de 2.000 tokens, o que representa uma redução de 98,7%. Com a 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 visualiza apenas o resumo final JSON, e não as milhares de linhas de despesa processadas no sandbox. Eficiência de tokens, composabilidade nativa (laços e condicionais disponíveis sem custo adicional) e tratamento eficaz de erros reais.try/except Em vez de um raciocínio em linguagem natural sobre erros, bem como a privacidade (dados sensíveis permanecem em sandbox), todos estes aspetos melhoram simultaneamente.

Quando ainda faz sentido utilizar a ferramenta JSON: operações atómicas únicas, ambientes sem infraestrutura de sandboxing, modelos mais pequenos com capacidades limitadas de geração de código, ou requisitos de auditoria que exigem o registo de cada chamada individual à ferramenta.

AI Tabela de comparação entre ferramentas de chamada de agente

A composabilidade, neste contexto, refere‑se à facilidade com que várias operações podem ser encadeadas num fluxo de trabalho mais amplo. Um valor baixo indica que cada tool call geralmente exige uma nova ida e volta ao modelo; um valor alto significa que a interface consegue transmitir os resultados intermediários através de pipelines, variáveis ou etapas procedimentais. As células de token e de sucesso da tarefa resumem os exemplos citados, e não um único benchmark controlado em todas as cinco colunas.

A Interface Agente-Computador (ACI) para ferramentas de agente AI

O termo “Agent-Computer Interface” (ACI) foi cunhado por John Yang, Carlos E. Jimenez e colegas de Princeton nos seus Artigo sobre SWE-agent (NeurIPS 2024). A ideia é simples: da mesma forma que os seres humanos se beneficiam de interfaces bem projetadas (HCI), os agentes baseados em LM representam “uma nova categoria de utilizadores finais com necessidades e capacidades próprias, que também se beneficiariam de interfaces desenvolvidas especificamente para eles.”

O resultados de ablação Fiz uma cópia de segurança disso. O SWE-agent, com o seu ACI completo, alcançou 18,0% no SWE-bench Lite, contra 7,3% quando se utilizava apenas um shell Linux padrão — o que representa uma melhoria de 10,7 pontos percentuais apenas graças ao design da interface. A funcionalidade de proteção por linting, por si só, foi responsável por mais 3 pontos percentuais: 51,7% das edições feitas pelo agente apresentaram pelo menos um erro detetado pelo linter antes que ele pudesse ser propagado.

Anthropic adotou o ACI como conceito fundamental nas suas “Desenvolvimento de Agentes Eficazes” guia, listando-o como um dos três princípios fundamentais: “Elabore com cuidado a sua interface agente-computador através de documentação e testes exaustivos das ferramentas.” A orientação prática é a seguinte: “Uma regra prática consiste em considerar o esforço necessário para desenvolver interfaces humano-computador e planejar investir uma quantidade semelhante de esforço na criação de boas interfaces agente-computador.”

Quatro princípios ACI na prática

1. As ações devem ser simples e fáceis de compreender. O erro mais comum consiste em associar os endpoints API de forma um-a-um. Em vez disso, list_users, list_events, create_event, implementar schedule_event que determina a disponibilidade e agenda as tarefas numa única chamada. Em vez de read_logs, implementar search_logs que devolve apenas as linhas relevantes juntamente com o contexto.

2. As ações devem ser compactas e eficientes. Consolide as operações importantes em o menor número possível de ações. Em Agente de Análise de Mercado, Eu combino a recolha de preços com métricas básicas num único get_stock_snapshot uma ferramenta que permite obter essas informações de forma integrada, em vez de ser necessário realizar chamadas separadas para saber o preço, o volume, o valor de mercado e o rácio PE.

3. O feedback do ambiente deve ser informativo, mas conciso. Evite retornar HTML bruto ou pacotes completos API. Converta IDs enigmáticos em nomes semânticos. Os testes da Anthropic mostrou que a adição de um response_format A enum que permite aos agentes solicitar respostas concisas (~72 tokens) ou detalhadas (~206 tokens), com uma diferença de custo em tokens de 3 vezes, melhorou significativamente o desempenho em cenários reais.

4. As regras de segurança devem atenuar a propagação de erros. A deteção automática de erros ajuda os agentes a identificar e corrigir falhas de forma rápida. Em SWE-agente, um editor de ficheiros personalizado com linting integrado rejeita automaticamente erros de sintaxe, detetando 51,7% dos erros de edição do agente antes que estes possam agravar-se. Aplico o mesmo princípio no Market Analyst Agent, validando os argumentos das 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

AI padrões de projeto de ferramentas de agente que são eficazes

da Anthropic “Desenvolver ferramentas eficazes para agentes” Os frameworks de orientação descrevem tais ferramentas como “um novo tipo de software que reflete um contrato entre sistemas determinísticos e agentes não determinísticos”. Seguem-se os padrões que se consolidaram a partir da experiência em produção.

Trate as descrições de ferramentas como prompt engineering

As descrições devem ser extensas. É necessário garantir que o número total de sentenças seja igual ou superior a três a quatro, assegurando assim uma estrutura textual suficientemente extensa e bem delimitada. Este requisito é fundamental para cumprir os padrões de qualidade esperados em documentos técnicos destinados a engenheiros de IA em Portugal. A formatação deve manter a coerência sintática e a clareza conceitual ao longo de todo o texto., abordando quando utilizar a ferramenta, parâmetros obrigatórios versus opcionais, formato de saída e casos limite. Nomeação com prefixosasana_search, jira_search) exerce “efeitos não triviais” na precisão da seleção de ferramentas. Nos experimentos da Anthropic, as descrições de ferramentas otimizadas para o Claude superaram as redigidas por especialistas humanos nas avaliações 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"]
    }
}]

Testes internos mostrou que os exemplos de entrada (input_examples Este campo melhorou substancialmente a precisão no tratamento de parâmetros complexos.

Devolver uma saída de alto sinal, legível por máquinas

Evite identificadores de baixo nível (uuid, mime_type). Resolva IDs enigmáticos em nomes semânticos. Estruture a resposta de forma a que o agente possa raciocinar sobre ela sem ter de analisar texto genérico:

# 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 erros nos quais o loop pode intervir

Utilize quatro mecanismos distintos, uma vez que cada um lida com categorias diferentes de falhas:

1. Tentativa de repetição com retrocesso exponencial para erros transitórios
2. Cadeias de fallback de modelo em caso de interrupções do fornecedor
3. Roteamento por classificação de erros — tentativas de repetição para erros transitórios, LLMerros recuperáveis devolvidos ao agente com contexto, erros que exigem intervenção humana são escalonados
4. Recuperação Checkpointpara garantir a continuidade após falhas abruptas

O guia da Anthropic citado apoia a identificação clara de erros nas ferramentas e um design destas baseado em avaliações. Não estabelece uma taxa universal de redução de falhas; portanto, deve medir a taxa de recuperação, as tentativas de repetição e os processos de escalonamento na sua própria suite de tarefas.

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

Aplicação dos padrões ao Agente de Análise de Mercado

O Agente de Análise de Mercado de Parte 1 torna visível o efeito da interface.

Consolidação de ferramentas

O artigo da Parte 1 apresenta a superfície simplificada com 5 ferramentas após esta refatoração. Antes dessa otimização, o design original contava com mais de 10 ferramentas: get_stock_price, get_company_metrics, get_market_cap, get_pe_ratio, get_volume, e assim por diante. Cada um deles era uma camada externa simples que envolvia um endpoint API. O agente tinha de determinar qual combinação chamar para cada pedido.

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

Isto reduziu significativamente o overhead do tool schema e tornou a seleção de ferramentas pelo agente mais fiável, uma vez que existem menos opções ambíguas a considerar.

Structured outputs para tool results

Cada ferramenta no Agent Market Analyst devolve uma resposta validada por Pydantic. Isto aplica o princípio dos limites de segurança ACI na fronteira entre a ferramenta e o sistema:

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 summary O campo é o que tem maior importância. Ele fornece ao agente uma string pronta para uso que pode ser inserida diretamente num relatório, sem necessidade de processamento adicional. key_points em NewsResult São extraídos do lado do servidor, o que permite que o agente não gaste tokens de inferência na análise do conteúdo dos artigos.

Compromissos e considerações

Para além das ressalvas específicas por modalidade mencionadas anteriormente, existem algumas preocupações transversais que influenciam a escolha:

• O custo operacional varia consoante a dimensão. A execução de código permite poupar tokens, mas aumenta o tempo de latência de inicialização sandbox. O MCP acelera o tempo de desenvolvimento para integrações SaaS, contudo gera custos adicionais relacionados com a implementação dos servidores. A interface CLI tem um custo inicial nulo, mas é mais difícil de gerir em larga escala. Otimize as suas soluções tendo em conta o verdadeiro gargalo, quer se trate de custos de tokens, de latência ou de complexidade operacional.

• As competências da equipa são fundamentais. A execução de código pressupõe que os seus agentes (e os modelos por trás deles) sejam capazes de gerar código em Python ou TypeScript fiável. A interface CLI exige conhecimento das convenções do Unix. O MCP requer compreensão dos protocolos de transporte e dos fluxos OAuth. Adeque a modalidade às competências da sua equipa.

• A consolidação de ferramentas pode ir longe demais. Se uma ferramenta acumular modos e argumentos não relacionados, o agente depara-se com um problema diferente de seleção dentro do esquema. Utilize avaliações de seleção de ferramentas e de sucesso da tarefa para encontrar a solução mais adequada para a sua carga de trabalho.

• As competências são baseadas em prompt, e não são impositivas. Uma competência representa instruções que o agente deve seguir, e não regras rígidas que ele tem de seguir. Em fluxos de trabalho críticos, deve-se combinar competências com validação determinística.

• Os requisitos de auditoria influenciam a escolha a ser feita. Se for necessário um registo completo de cada chamada à ferramenta e do seu resultado, as ferramentas MCP e JSON fornecem, por padrão, registos de auditoria estruturados. A execução de código gera um script e o seu respetivo output, o que é útil, mas é mais difícil de decompor em ações individuais para fins de elaboração de relatórios de conformidade.

Seleção de ferramentas em escala maior

Três direções merecem ser monitorizadas.

O primeiro é a ferramenta RAG para escalonamento. À medida que os conjuntos de ferramentas passam a contar com centenas ou milhares de elementos, a precisão na seleção ingênua de ferramentas diminui para 13,62%. O artigo científico sobre RAG-MCP Verificou‑se que a aplicação da geração reforçada por recuperação à seleção de ferramentas — ou seja, indexando as descrições das ferramentas numa base de dados vetorial e recuperando apenas as ferramentas relevantes para cada consulta — alcança uma precisão de 43,13%, o que representa uma melhoria de 3,2 vezes, ao mesmo tempo que reduz os tokens prompt em cerca de 50%.

O segundo caso refere‑se a agentes que criam as suas próprias ferramentas. O LATM framework “LLMs Como criadores de ferramentas”, estabeleceu um paradigma em duas fases no qual um LLM poderoso gera funções em Python reutilizáveis, sendo que um LLM mais leve as utiliza. ToolMaker (ACL 2025) transforma de forma autónoma repositórios do GitHub em ferramentas compatíveis com LLM, atingindo uma taxa de sucesso de 80%. A fronteira da área está a deslocar-se de tool use para a criação de ferramentas e, posteriormente, para a gestão de bibliotecas de ferramentas.

O terceiro elemento é a pilha de protocolo duplo A2A + MCP. O Protocolo Agent2Agent da Google (A2A)) resolve o problema que MCP não consegue tratar: a comunicação entre agentes. O MCP é responsável pela integração entre agentes e ferramentas, enquanto o A2A lida com a descoberta, negociação e delegação de tarefas entre agentes. A fórmula combinada é: construir com o seu framework, equipar com MCP e comunicar através de A2A.

Principais conclusões

1. Escolha a interface conforme a ação desejada: JSON para operações de pequeno porte e tipadas, MCP para serviços partilhados, Skills para procedimentos, CLI para comandos estabelecidos, e código em ambiente isolado para composição local.
2. Mantenha as condições benchmark associadas ao resultado. Ferramentas como CodeAct, Anthropic, Vercel, Cloudflare, Apideck e Scalekit avaliaram modelos, tarefas, ferramentas e plataformas diferentes.
3. A qualidade do ACI permanece estável mesmo após alterações de protocolo. Ações claras, feedback conciso, validação eficaz e mensagens de erro úteis são essenciais em todas as modalidades.
4. Consolide apenas as ferramentas que se sobrepõem quando as avaliações demonstrarem que uma abordagem mais simplificada melhora a seleção ou o sucesso da tarefa.
5. A segurança acompanha o poder de execução. As interfaces de shell e de código exigem ambiente isolado; MCP necessita de identidade delimitada e políticas de servidor; já as Skills continuam a funcionar como instruções, em vez de mecanismos de fiscalização.

A próxima camada é a política

Parte 4, AI Segurança de Agentes em 2026, É realizada uma verificação de política entre a proposta de tool call e a sua execução. A Parte 5, por sua vez, insere a ferramenta e o seu sandbox dentro de um runtime recuperável. A Parte 6 regressa à interface a partir do lado de harness: explicando como os rastreios, avaliadores, regras de tentativa múltipla e verificações de aceitação transformam o feedback da ferramenta num ciclo contínuo de melhoria mensurável.

Referências

Artigos Científicos

• Ações de Código Executável Geram Agentes LLM Melhores (CodeAct) — Wang et al., ICML 2024 — As ações baseadas em código alcançam um nível de sucesso nas tarefas 20% superior ao de JSON SWE-agent: As interfaces agente-computador permitem a engenharia de software automatizada — Yang, Jimenez et al., NeurIPS 2024 — Princípios de projeto ACI e avaliação com SWE-bench (18,0% contra 7,3%, diferença de 10,7 pp em relação ao design da interface)
• RAG-MCP: Atenuar o aumento de tamanho decorrente de Prompt na seleção de ferramentas LLM — Ferramenta RAG que aumenta a precisão de seleção de 13,62% para 43,13% LLMs Como Criadores de Ferramentas (LATM) — Cai et al., 2023 — Paradigma de duas fases para a criação de ferramentas de agente ToolMaker: LLM Agentes que criam ferramentas para outros agentes — Wolflein et al., ACL 2025 — Taxa de sucesso de 80% na transformação de repositórios em ferramentas
• MCPTox: Uma avaliação abrangente da MCP toxicidade Benchmark — Taxa de sucesso dos ataques de 72,8% em 20 agentes LLM e 45 servidores MCP

Engenharia Anthropic

• Chamadas avançadas de ferramentas Tool Use / de forma programática — Pesquisa de ferramentas (redução de esquema de 85%), PTC e exemplos de tool use Execução de código com MCP — Redução de 98,7% nos tokens (de 150K para 2K tokens) graças à orquestração de ferramentas baseada em código
• Escrever Ferramentas Eficazes para Agentes — Engenharia da descrição da ferramenta; exemplos de entrada que melhoram a precisão; enum response_format (72 contra 206 tokens) Construção de Agentes Eficazes — O ACI como princípio fundamental de projeto

Estudos de caso da indústria

• Vercel: Removemos 80% das ferramentas do nosso agente — De 15 para 2 ferramentas, de 80% a 100% de sucesso, 3,5 vezes mais rápido, 40% menos tokens Cloudflare: Modo Código — Chamadas impulsionadas por TypeScript API que substituem tool schemas
• Apideck: MCP Servidor a consumir a sua janela de contexto — 550–1.400 tokens/ferramenta, 55 mil tokens para aproximadamente 40 MCP ferramentas, consumo de contexto de 143 mil a 200 mil tokens Scalekit: MCP versus token da CLI Benchmark — Custo adicional de 4-32x em tokens para MCP em comparação com a CLI, observado em 75 execuções de benchmark

Segurança

• Projeto vulnerável MCP — 50 vulnerabilidades rastreadas, 13 de nível Crítico, enviadas por 32 investigadores Autenticado: Cronologia das violações de MCP — 9 incidentes de segurança graves MCP (abril-outubro de 2025)
• Invariant Labs: Ataques de Envenenamento de Ferramentas MCP — Envenenamento de ferramentas, retiradas abruptas de recursos e escalada entre origens diferentes Segurança de Ponto de Pivote: Análise de Segurança MCP — 43% de injeção de comandos, 43% de falhas na autenticação OAuth

Design da CLI

• Escrever ferramentas CLI que os AI Agentes realmente querem utilizar — Ugo Enyioha — Oito regras de design para CLIs amigáveis a agentes

Projeto de demonstração

• Agente de Análise de Mercado — Implementação completa com consolidação de ferramentas e padrões ACI

O código completo do Agente Analista de Mercado, incluindo os designs das ferramentas descritos neste artigo, encontra-se em GitHub._

Série: Engenharia da pilha Agentic

• Parte 1: AI Laços de Raciocínio de Agente em 2026 — ReAct, ReWOO e Plan-and-Execute Parte 2: AI Arquitetura de Memória de Agente em 2026 — checkpoints, armazenamentos vetoriais e memória de documentos
• Parte 3: AI Agentes Tool Use em 2026 (este artigo) Parte 4: AI Segurança de Agentes em 2026 — restrições de segurança, permissões, sandboxes, HITL e delimitação de escopo de MCP
• Parte 5: Agente AI de Execução Prolongada Runtime em 2026 — sessões, sandboxes, checkpoints, mecanismos de aproveitamento e formatos de implementação
• Parte 6: Harness Engineering para Agentes AI (a chegar em breve) — verificações de aceitação, rastreios, tentativas repetidas, transferências de responsabilidade e o ciclo associado ao modelo