Importância do Tool Routing e Intent Lock no Servidor MCP

O Model Context Protocol (MCP) permite que um modelo de linguagem invoque ferramentas em sistemas externos através de uma interface padronizada. Na prática, o elemento determinante não é o protocolo em si, mas sim a conceção das ferramentas no servidor: os nomes das ferramentas, os esquemas de parâmetros e as 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 utilizador pesquisa num determinado domínio, o modelo invoca uma ferramenta pertencente a outro domínio devido a semelhanças no nome ou nos parâmetros. Este fenómeno designa-se por intent drift. Por exemplo, o pedido de um utilizador que procura autocarros interurbanos pode ser direcionado para uma ferramenta de aluguer de viaturas devido à semelhança do conjunto de parâmetros. Trata-se de uma situação que decorre mais da ambiguidade na conceção da interface do que propriamente de um erro do modelo.

O que é o intent lock? Consiste em manter o domínio ativo da sessão do lado do servidor e verificar a correspondência com esse domínio a cada chamada de ferramenta. Se um utilizador se encontrar no domínio de autocarros, qualquer chamada direcionada para a ferramenta de aluguer de viaturas é rejeitada e é devolvido um erro inequívoco ao modelo: o domínio não coincide, invoque primeiro a ferramenta de mudança de domínio. Deste modo, a alteração de intenção deixa de ser implícita e passa a ser uma etapa explícita.

A segunda linha de defesa é o esquema. Adicionar informação obrigatória de domínio a cada objeto de pedido e resposta assegura que o modelo declara novamente, em cada invocação, o contexto em que está a operar. Sempre que a declaração entrar em conflito com o estado da sessão, o servidor interrompe a operação. Desta forma, a validação é transferida para o servidor, em vez de depender de uma regra do lado do cliente.

O terceiro ponto reside na disciplina de nomenclatura. A utilização de nomes com prefixos de domínio, tais como bus_search, flight_search e car_rental_search, em vez de designações genéricas como arama_yap, ara ou sorgula, amplia a diferenciação entre ferramentas semelhantes. Os textos descritivos devem apresentar a mesma clareza; explicitar o que uma ferramenta não faz é tão valioso como descrever o que ela faz.

Os campos de data e hora constituem outra fonte de erros frequente. Uma ferramenta que aceite datas em texto livre leva o modelo a produzir formatos localizados. Exigir o padrão ISO-8601 e solicitar explicitamente o fuso horário simplifica tanto a validação como as mensagens de erro. Da mesma forma, a indicação clara de unidades em campos numéricos (número de pessoas, número de noites, moeda) reduz a ambiguidade.

No que respeita à segurança, os fluxos de autenticação por OTP ou mecanismos equivalentes são adequados para ferramentas que iniciam transações. Contudo, a validação deve ser vinculativa ao nível da transação e não da ferramenta: chamadas para reservas, pagamentos ou cancelamentos não devem ser aceites sem um identificador de sessão verificado. Conceder autorizações com base na confiança no texto gerado pelo modelo constitui uma vulnerabilidade de segurança independente do protocolo.

As mensagens de erro funcionam como a superfície de aprendizagem do modelo. Em vez de uma resposta genérica 400, devolver erros estruturados que especifiquem qual o campo em falta e o formato esperado aumenta significativamente a probabilidade de o modelo gerar a chamada correta na tentativa seguinte. Da mesma forma, os limites de taxa e as políticas de repetição devem ser documentados, uma vez que o modelo apenas consegue compreender a necessidade de espera através do texto do erro.

Lista de verificação essencial para um tool routing seguro: nomenclatura de ferramentas baseada em domínios, intent lock ao nível da sessão, informação obrigatória de domínio no esquema, validação do lado do servidor, ferramenta explícita de mudança de domínio, formato de data ISO-8601, controlo de autorização ao nível da transação, mensagens de erro estruturadas e documentação de limites e tentativas.

O ponto comum entre estes aspetos é tornar o comportamento incorreto impossível do lado do servidor, em vez de apenas esperar que o modelo atue corretamente. Ao conceber um servidor MCP, a questão fundamental a colocar é: qual é a chamada incorreta mais plausível que o modelo pode gerar e em que camada é que o sistema a bloqueia?