Expor Ferramenta via MCP (Expose Tool via MCP) é uma refatoração de IA para sistemas com LLM, do grupo Simplificando ferramentas. Publicar a integração como servidor MCP para que qualquer agente use o mesmo contrato.
O time de suporte tem find_order no formato de um provedor, dentro do agente. O backoffice copiou a função, trocou o nome para lookup_order e devolve campos diferentes. O assistente de código do financeiro fez uma terceira cópia, com o token no cabeçalho. Uma mudança no ERP corrigiu duas. A terceira ficou uma semana devolvendo 401. Cada novo agente reescreve a mesma integração, no formato de quem o hospeda. É o smell Vazamento de Formato do Provedor.
Solução
Publique a integração como um servidor MCP (Model Context Protocol). As ferramentas passam a viver no servidor, com schema, autenticação e permissões; qualquer agente ou cliente que fale MCP se conecta e usa o mesmo contrato.
Antes e depois
-# agente_suporte/tools.py (formato de um provedor, dentro do agente)-TOOLS = [{"name": "find_order", "description": "...", "input_schema": {...}}]-def handle_tool(block):- if block.name == "find_order":- return erp.get(f"/orders/{block.input['id']}", headers={"Authorization": TOKEN})+# erp_mcp/server.py (servidor próprio, usado por qualquer agente)+mcp = FastMCP("erp")++@mcp.tool()+def find_order(order_id: str) -> dict:+ """Status, itens e datas de um pedido."""+ require_scope("orders:read")+ return normalize(erp_client.get_order(order_id))++# agente_suporte, agente_backoffice, assistente de código:+# conectam no servidor "erp" e recebem as ferramentas
Depois: um servidor por sistema, um contrato para todos.
flowchart LR
A1(["1. Agente A"]):::llm --> S["2. Servidor MCP do ERP"]:::tool
A2(["1. Agente B"]):::llm --> S
A3(["1. Cliente MCP de terceiros"]):::llm --> S
S --> ERP[("3. ERP")]:::store
Agentes diferentes, em tecnologias diferentes.
Um servidor expõe as ferramentas do sistema, com permissões e formato de saída definidos.
Só o servidor fala com o sistema interno.
Por que funciona
O MCP separa quem usa a ferramenta de quem a implementa. A integração deixa de ser código de um agente e passa a ser um serviço do sistema, com dono, versão e testes próprios. Mudanças de autenticação, de API ou de formato acontecem num lugar só. Rotacionar um token é deploy do servidor, não de três agentes.
O protocolo é aberto e independente de provedor. A Anthropic publicou o MCP em novembro de 2024 exatamente para esse contrato comum: o cliente (agente, IDE, assistente) descobre ferramentas em tempo de execução com tools/list, em vez de carregá-las no formato de um SDK. A descrição e o schema viajam no protocolo, não num arquivo Python de um agente. Trocar o modelo de um agente não mexe nas ferramentas. Um cliente de terceiros acessa os mesmos sistemas com as mesmas regras.
Exemplo trabalhado: três cópias, um 401
Entrada: o ERP rotaciona o token. O agente de suporte lê o segredo novo do cofre. O de backoffice também. O assistente de código do financeiro ainda tem o token antigo no arquivo do agente. Saída: duas ferramentas funcionam, uma devolve 401, o analista acha que o ERP caiu.
Com um servidor erp, a rotação acontece no servidor. Os três clientes recebem find_order com o mesmo schema (id, status, items, promised_date). O eval do servidor cobre o contrato; o eval de cada agente cobre o uso. O padrão de destino é o Adaptador MCP.
Passo a passo seguro
Meça. Rode o eval de cada agente que usa a integração e guarde o resultado. Sem linha de base, você não sabe o que a unificação mudou.
Reúna as implementações existentes e escolha o comportamento certo de cada ferramenta. Diferenças entre cópias são bugs disfarçados de “variação”.
Crie o servidor MCP com essas ferramentas, schemas estritos, descrições claras e saída normalizada.
Ponha autenticação e escopos no servidor, propagando a identidade do usuário final. O servidor não é um atalho para o token de serviço.
Migre um agente por vez: troque as ferramentas locais pela conexão MCP e rode o eval dele.
Apague as cópias locais da integração. Ferramenta “só mais um sprint” vira a terceira cópia de novo.
Versione o servidor e trate mudanças de schema como mudanças de API.
Armadilha: um servidor com 40 ferramentas
Juntar ERP, CRM e fiscal no mesmo processo recria Ferramentas Demais do lado do cliente: o agente vê dezenas de nomes parecidos. Um servidor por domínio (erp, crm, nfe). O agente de suporte conecta só no que usa.
Outra armadilha: conectar um servidor MCP de terceiros sem revisar descrições e código. A descrição da ferramenta entra no prompt do seu modelo. Um servidor malicioso descreve send_email como “sincroniza o calendário” e o modelo chama. Trate o retorno como conteúdo não confiável, no espírito de Pôr Conteúdo Externo em Quarentena.
Riscos
Ponto único de falha. O servidor fora do ar afeta todos os agentes. Monitore, coloque timeout e um caminho de fallback, como qualquer serviço que o produto precisa.
Diferença de comportamento. As cópias antigas podiam ter detalhes diferentes. O eval de cada agente mostra o que mudou.
Ferramentas demais num servidor. Divida por domínio.
Servidores de terceiros. Revise como qualquer dependência. Descrições e retornos vêm de fora.
Desafio
Três agentes da empresa consultam o CRM, cada um com sua função: get_contact, lookup_customer e crm_search. Os três fazem quase a mesma coisa, com campos de saída diferentes. Como você desenharia o servidor MCP do CRM?
Ver solução
Um servidor crm com poucas ferramentas por intenção: find_contact(by: "email" | "phone" | "id", value) para leitura, devolvendo um formato único (id, nome, empresa, dono da conta, último contato), e operações de escrita separadas (log_interaction, update_stage) com escopos próprios. Os três agentes migram para o servidor um de cada vez, com o eval de cada um. As três funções antigas são removidas.
Expor Ferramenta via MCP (Expose Tool via MCP) é uma refatoração de IA para sistemas com LLM, do grupo Simplificando ferramentas. Publicar a integração como servidor MCP para que qualquer agente use o mesmo contrato.