Dás ferramentas reais a um servidor MCP descrevendo endpoints HTTP que já tens — o URL, os parâmetros, onde vão as credenciais — e anexando-os ao servidor. No SuperCognit, qualquer ferramenta HTTP que construas para um agente torna-se uma ferramenta MCP invocável no momento em que publicas: sem SDK, sem código de protocolo, sem um deployment separado. Se o teu CRM e o teu calendário têm APIs — e têm —, podem ser ferramentas.

O conhecimento responde; as ferramentas agem

Uma base de conhecimento torna um assistente bom em perguntas: qual é a política de reembolsos, o que inclui o escalão premium. As ferramentas tornam-no útil na parte a seguir à pergunta — consultar a conta deste cliente, verificar a disponibilidade de quinta-feira, registar o pedido. A maioria dos fluxos de trabalho reais precisa das duas metades, e a maioria dos servidores MCP só entrega a primeira, porque a segunda exigia, historicamente, escrever e alojar um servidor.

A conclusão pouco glamorosa das ferramentas HTTP é que a segunda metade, em grande parte, já existe. O teu CRM tem uma API. O teu calendário tem uma API. O serviço interno que alguém construiu em 2019 tem uma API, sem documentação mas funcional. Uma ferramenta é um invólucro descrito à volta de um endpoint de um desses sistemas.

A descrição é a interface

O modelo nunca vê o teu código. Vê o nome da ferramenta, a descrição e os parâmetros, e decide quando chamar a ferramenta, e com quê, apenas a partir disso. 'Procura um cliente pelo endereço de email; devolve o plano, a data de renovação e os tickets abertos' será chamada corretamente. 'Integração com o CRM' será chamada mal, ou constantemente, ou as duas coisas. Escrever descrições de ferramentas é o mais próximo que este fluxo de trabalho tem de programação — e faz-se em prosa.

01

Escolhe um endpoint por ferramenta

Uma ferramenta deve fazer um trabalho. Procurar um contacto por email. Listar as vagas livres de uma dada semana. Criar um rascunho de fatura. Ferramentas específicas são chamadas corretamente; uma ferramenta faz-tudo obriga o modelo a adivinhar qual dos seus feitios tinhas em mente.

02

Descreve-a para um leitor que não vê o código

Diz o que a ferramenta faz, o que significa cada parâmetro e o que vem de volta. Indica os formatos e as unidades. Se um parâmetro é um endereço de email, di-lo — a descrição é a única documentação que o modelo recebe.

03

Anexa, publica, pronto

Anexa a ferramenta à construção e publica. Fica exposta como uma ferramenta MCP com um esquema tipado que qualquer cliente entende — e o agente de chat da mesma construção também a pode chamar. As credenciais ficam do lado do servidor, na configuração da ferramenta; nunca viajam até ao cliente.

04

Testa onde a tua equipa vive

Liga o servidor no Claude ou em qualquer cliente MCP, pergunta algo que exija a ferramenta e observa a chamada. Uma descrição vaga revela-se em três perguntas. Corrige a prosa, não o endpoint.

Regras de design que te poupam mais tarde

  • Privilégio mínimo: se a ferramenta só lê, põe por trás dela uma chave de API só de leitura. Uma ferramenta não pode exceder a credencial que transporta.
  • Devolve o que é preciso, não o registo inteiro — uma consulta de cliente não precisa de enviar todos os campos que o teu CRM guarda.
  • Mantém as escritas pequenas e deliberadas: uma ferramenta que cria uma reserva no calendário é mais segura do que uma que também pode apagar eventos.
  • Prefere várias ferramentas específicas a uma engenhosa; o modelo compõe-nas melhor do que descodifica flags.

O que não expor

Um teste útil: davas esta capacidade a um recém-contratado no primeiro dia, sem supervisão? O acesso ao servidor passa pelo OAuth 2.1 com identidade por utilizador, e cada espaço de trabalho está isolado, por isso o raio de impacto é contido — mas o mecanismo de segurança mais barato é, à partida, não anexar o endpoint perigoso. Apagar, exportar em massa e tudo o que for irreversível pode esperar até as ferramentas só de leitura terem provado o seu valor.

Começa com duas ferramentas só de leitura: uma consulta ao CRM e a disponibilidade do calendário. Esse par transforma um servidor de conhecimento em algo que responde a 'podemos reunir na quinta, e este cliente está no plano premium?' numa única troca — e fica pronto numa tarde.