Importância do Tool Routing e Intent Lock em Servidores MCP

O Model Context Protocol (MCP) permite que um modelo de linguagem acione ferramentas em sistemas externos por meio de uma interface padronizada. Na prática, o fator determinante não é o protocolo em si, mas o design das ferramentas no lado do servidor: nomes de ferramentas, esquemas de parâmetros e mensagens de erro moldam diretamente o comportamento do modelo.

Ao testar um servidor MCP multidomínio (multi-domain), surge um problema típico: enquanto o usuário realiza uma busca em determinado domínio, o modelo aciona uma ferramenta de outro domínio devido a semelhanças de nomes ou parâmetros. Isso é conhecido como intent drift. Por exemplo, a solicitação de um usuário que pesquisa passagens rodoviárias pode ser direcionada a uma ferramenta de locação de veículos porque o conjunto de parâmetros é semelhante. Isso decorre mais da ambiguidade no design da interface do que de uma falha do modelo.

O que é intent lock? Trata-se da manutenção do domínio ativo da sessão no lado do servidor e da verificação de compatibilidade com esse domínio a cada chamada de ferramenta. Quando o usuário está no domínio rodoviário, uma chamada direcionada à ferramenta de aluguel de carros é rejeitada, retornando um erro explícito ao modelo: o domínio não coincide, execute primeiro a ferramenta de troca de domínio. Dessa forma, a mudança de intenção deixa de ser implícita e se torna uma etapa explícita.

A segunda linha de defesa é o esquema. Adicionar uma informação obrigatória de domínio a cada objeto de solicitação e resposta garante que o modelo declare novamente o contexto em que está operando a cada chamada. Caso haja divergência entre o domínio declarado e o estado da sessão, o servidor interrompe o processo. Isso transfere a validação para o servidor em vez de depender de regras no lado do cliente.

O terceiro ponto é a disciplina de nomenclatura. Em vez de utilizar termos genéricos como buscar, pesquisar ou consultar, o uso de nomes com prefixos de domínio como bus_search, flight_search e car_rental_search amplia a distinção entre ferramentas semelhantes. Os textos descritivos devem ter a mesma clareza; detalhar o que uma ferramenta não faz é tão valioso quanto explicar o que ela faz.

Os campos de data e hora representam outra fonte frequente de erros. Uma ferramenta que aceita datas em texto livre faz com que o modelo gere formatos regionalizados. Tornar o padrão ISO-8601 obrigatório e exigir explicitamente o fuso horário simplifica tanto a validação quanto as mensagens de erro. Da mesma forma, declarar unidades em campos numéricos (número de pessoas, quantidade de diárias, moeda) reduz incertezas.

Do ponto de vista da segurança, fluxos de autenticação como OTP ou mecanismos similares são fundamentais para ferramentas transacionais. No entanto, a validação deve ser mandatória no nível da transação, e não da ferramenta: chamadas para reservas, pagamentos ou cancelamentos não devem ser aceitas sem uma identificação de sessão autenticada. Conceder autorização confiando apenas no texto gerado pelo modelo é uma vulnerabilidade de segurança independente do protocolo.

As mensagens de erro funcionam como a superfície de aprendizado do modelo. Em vez de uma resposta 400 genérica, retornar erros estruturados que indiquem qual campo está ausente e o formato esperado aumenta significativamente a probabilidade de o modelo gerar a chamada correta na próxima tentativa. Da mesma forma, limites de taxa (rate limits) e políticas de nova tentativa devem ser documentados; o modelo só conseguirá identificar a necessidade de espera por meio do texto de erro.

Um breve checklist para um roteamento seguro de ferramentas (tool routing): nomenclatura de ferramentas baseada em domínio, intent lock em nível de sessão, informação de domínio obrigatória no esquema, validação no servidor, ferramenta explícita de troca de domínio, formato de data ISO-8601, controle de autorização em nível de transação, mensagens de erro estruturadas e documentação de limites e tentativas.

O ponto em comum entre esses itens é inviabilizar o comportamento incorreto diretamente no servidor, em vez de apenas esperar que o modelo aja corretamente. Ao projetar um servidor MCP, a pergunta essencial é: qual é a chamada incorreta mais plausível que o modelo pode gerar e em qual camada o sistema a bloqueia?