MCP para chatbots de website: conectar ferramentas com OAuth e aprovações

O MCP torna os chatbots de website mais capazes de agir — mas apenas com limites claros

O MCP para chatbots de IA não é uma ficha mágica que confia subitamente qualquer sistema a um chatbot de website. Pelo contrário, o Model Context Protocol descreve uma interface comum através da qual um modelo pode descobrir e chamar ferramentas: por exemplo, uma pesquisa numa base de conhecimento, uma consulta de tickets, uma lógica de agendamento ou uma verificação interna com dados de produtos. Isso é especialmente atraente para chatbots de website, porque muitos diálogos não terminam com uma simples resposta. Os visitantes perguntam pelo estado da entrega, preços, canais de contacto, formulários, disponibilidade ou próximos passos. Sem ferramentas, o bot limita-se a explicar. Com ferramentas, pode — de forma controlada e rastreável — procurar dados relevantes ou iniciar ações preparadas.

A questão decisiva não é, portanto: um chatbot pode usar ferramentas? A questão é: que ferramentas pode ele ver em que contexto, chamar com que token, executar com que aprovação humana e explicar mais tarde com que registo de logs? A especificação final do MCP de 28 de julho de 2026 reforça precisamente estas questões operacionais. Ela torna o núcleo stateless, exige metadados relevantes por pedido e especifica como a autorização HTTP remota, o OAuth, os scopes e a vinculação de audience do token se articulam.

O que a especificação 2026-07-28 muda para as equipas de websites

A alteração arquitetónica mais importante é o stateless core. Um servidor MCP não pode presumir que pedidos anteriores na mesma ligação já estabeleceram contexto, capacidades do cliente ou uma sessão. Tudo o que é necessário para o processamento deve estar no pedido atual. Para infraestruturas de websites distribuídas, isto é prático: os pedidos podem cair em diferentes instâncias atrás de load balancers, edge gateways ou plataformas de workers. Para as implementações, porém, significa também: nada de suposições ocultas sobre sessões de transporte, nada de permissões silenciosas de uma ligação anterior e nada de usar a conversação de chat como limite de segurança.

Cada pedido necessita dos metadados _meta exigidos. Isto inclui, em particular, a versão do protocolo e as capacidades do cliente; as informações do cliente são úteis para exibição, logging e depuração, mas não servem como prova de segurança. Se um website servir múltiplas instâncias de bots, idiomas ou áreas de clientes, esta camada de metadados deve ser validada e registada em log de forma consciente. Ela não substitui a autorização de negócio, mas garante que o servidor consiga classificar os pedidos corretamente.

As listas de ferramentas são dinâmicas, mas não arbitrárias

O tools/list na especificação atual é paginado e passível de ser guardado em cache. As respostas podem conter indicações de cache como ttlMs e cacheScope. Ao mesmo tempo, a ordem deve permanecer determinística, desde que o conjunto de ferramentas subjacente não mude. Isto é mais do que cosmética de desempenho: quando os catálogos de ferramentas estão ordenados de forma estável, os clientes podem guardá-los em cache de forma mais fiável e os contextos dos modelos permanecem mais estáveis.

A nuance na autorização é importante. O conjunto de ferramentas pode variar por pedido com base na autorização apresentada, por exemplo porque um token apenas permite direitos de leitura sobre dados de suporte, mas não permite direitos de escrita num CRM. No entanto, não pode flutuar aleatoriamente como um efeito secundário de pedidos anteriores na mesma ligação. Para chatbots de website, isto resulta num padrão claro: o catálogo de ferramentas visível surge da função, scope, tenant, idioma, contexto e risco do pedido atual.

As descrições das ferramentas não são uma base de confiança

As ferramentas MCP descrevem o seu nome, as suas entradas e, opcionalmente, saídas e anotações. Estes metadados ajudam o modelo e a interface do utilizador a compreender a função. Contudo, não são uma âncora de segurança. A especificação afirma claramente que os clientes devem tratar as anotações das ferramentas como não confiáveis, a menos que venham de servidores de confiança. Uma ferramenta que se descreve como sendo apenas de leitura ainda assim deve ser construída no lado do servidor para garantir que não executa efeitos secundários de escrita.

Isto aplica-se também a resultados estruturados. Um outputSchema ajuda a validar respostas e não apenas a enviar texto livre para o modelo. Apesar disso, os servidores têm de verificar entradas, controlar o acesso, aplicar rate limits e higienizar saídas. Um chatbot de website não deve incorporar resultados de ferramentas sem filtragem nas respostas visíveis, especialmente quando estão envolvidas APIs externas, dados de clientes ou conteúdos próximos do HTML.

OAuth: O servidor MCP é um recurso protegido

No MCP por HTTP remoto, a divisão de funções é crucial. Um servidor MCP protegido atua como um OAuth Resource Server. O cliente MCP atua em nome de um Resource Owner, ou seja, tipicamente um utilizador ou uma organização. O Authorization Server interage com o utilizador, se necessário, e emite Access Tokens. O servidor MCP deve disponibilizar os seus Protected Resource Metadata para que os clientes possam descobrir o Authorization Server adequado. O Authorization Server disponibiliza pelo menos um dos métodos de descoberta, OAuth Authorization Server Metadata ou OpenID Connect Discovery; o cliente MCP deve suportar ambos.

Para as equipas de produto, isto significa: o chatbot não deve gerir palavras-passe, chaves de API ou tokens de terceiros por si próprio se estiver previsto um fluxo OAuth. Deve guiar o utilizador para uma aprovação clara, usar depois um Access Token com finalidade específica e limitar visivelmente as ferramentas permitidas com ele. Para o registo do cliente, são preferidos os Client ID Metadata Documents; o Dynamic Client Registration é mantido apenas por motivos de compatibilidade com versões anteriores e está descontinuado (deprecated). Especialmente em integrações como calendário, CRM, helpdesk, armazenamento de documentos ou sistemas de e-commerce, esta separação é importante porque a mesma conversa altera frequentemente entre perguntas públicas e ações dependentes de conta.

Os tokens têm de estar vinculados ao recurso de destino

A especificação de autorização atual exige Resource Indicators de acordo com o RFC 8707. O cliente deve definir o parâmetro resource nos pedidos de autorização e de token, indicando assim o URI canónico do servidor MCP a que o token se destina. O servidor MCP deve verificar se o Access Token foi emitido exatamente para o seu recurso. Os tokens não podem ser transmitidos via query string, devendo pertencer ao Authorization Header.

Esta vinculação de audience previne um atalho perigoso: um token destinado ao Serviço A não pode ser aceite ou repassado ao Serviço B. Os chatbots de website precisam, portanto, de um limite de token limpo por servidor MCP e por ambiente. Preview, Staging e Production não devem usar a mesma audience se representarem recursos diferentes. Da mesma forma, um agregador que combine vários servidores MCP diante de um modelo não deve misturar tokens.

Os scopes são um contrato de UX e de segurança

Os scopes devem começar pequenos. A especificação recomenda a utilização de indicações de scope a partir de desafios WWW-Authenticate e, em caso de falta de permissões, a permissão de um fluxo de step-up. Na prática, isto significa: um visitante pode inicialmente trabalhar com ferramentas de leitura. Apenas quando uma ação necessita de mais direitos, como criar um ticket, escrever um ficheiro ou preparar uma encomenda, o sistema solicita especificamente a aprovação adicional.

Um bom design de consentimento não menciona apenas o nome da integração, mas também o impacto: que dados são lidos? Que ação está a ser preparada? Algo será guardado externamente, enviado ou alterado permanentemente? Para operações sensíveis, o utilizador deve ver uma confirmação real e poder recusá-la. Isto não é aconselhamento jurídico individual, mas sim uma regra de design técnico: as aprovações têm de ser compreensíveis para humanos, aplicáveis para servidores e rastreáveis para auditorias.

Uma arquitetura robusta para chatbots de website com MCP

Uma arquitetura sólida separa o modelo, a fachada de ferramentas (tool facade) e os sistemas de destino. O chatbot do website não fala diretamente com todos os fornecedores terceiros, mas sim com um cliente MCP ou gateway que controla a versão do protocolo, as capacidades do cliente, o estado de autenticação, os rate limits e a observabilidade. Por trás estão servidores MCP para integrações individuais ou áreas funcionais. Cada servidor declara apenas as ferramentas permitidas para o pedido atual e valida cada chamada novamente.

A fachada de ferramentas deve usar nomes estáveis, esquemas de entrada restritos e esquemas de saída claros. Os nomes das ferramentas têm de ser suficientemente inequívocos, especialmente quando vários servidores oferecem funções semelhantes como search, create ou lookup. Na agregação, um namespace ou prefixo ajuda. Os parâmetros devem ser concebidos de modo a que o modelo não precise de inventar dados brutos secretos. Se um processo se estender por vários pedidos, o servidor deve retornar um handle explícito e de curta duração, reautorizando-o a cada chamada subsequente.

Um segundo bloco de construção é a interface do utilizador. Os visitantes devem ver quando uma ferramenta é chamada, que entradas são enviadas e quando é necessária uma aprovação. Para acessos puramente de leitura, um estado transparente é muitas vezes suficiente. Para ações de escrita, pagas, externas ou com dados pessoais, é necessária uma confirmação mais consciente. A especificação deixa em aberto os padrões de interface, mas exige claramente que as aplicações permitam o controlo humano sobre as chamadas de ferramentas.

Checklist de lançamento para MCP em chatbots de IA

1. Criar um inventário de ferramentas: que sistemas devem ser ligados, que ferramentas são apenas de leitura, quais alteram dados e quais precisam de confirmação humana?
2. Definir scopes: dividir permissões por ações, não por equipas internas. Uma ferramenta para consulta de estado precisa de scopes diferentes de uma ferramenta para criar, alterar ou enviar.
3. Verificar a descoberta de OAuth: testar Protected Resource Metadata, Authorization Server Metadata, registo do cliente e URIs de redirecionamento por ambiente.
4. Forçar a vinculação de audience: aceitar tokens apenas para o URI canónico do servidor MCP, nunca repassá-los para recursos errados e nunca colocá-los em URLs.
5. Tornar o tools/list determinístico: testar conjuntamente ordenação estável, paginação, indicações de cache e filtros de autorização.
6. Manter os esquemas restritos: validar entradas, usar saídas estruturadas e desativar por predefinição o carregamento automático de rede de destinos $ref externos; opcionalmente apenas com allowlist, timeout, limite de tamanho e logging.
7. Construir aprovações na UI: tornar visíveis o nome da ferramenta, finalidade, entradas, sistema de destino, upgrade de scope e opção de rejeição.
8. Consolidar a observabilidade: registar num log a ID do pedido, nome da ferramenta, scope, decisão, erros, latência e tipo de resultado, sem guardar desnecessariamente conteúdos sensíveis.
9. Treinar cenários de erro: tratar 401, 403, tokens expirados, scopes em falta, handles desconhecidos, timeouts e aprovações rejeitadas como estados normais do produto.
10. Começar pequeno: colocar primeiro em produção uma ou duas ferramentas de leitura de baixo risco, adicionando depois gradualmente step-up, ações de escrita e outras integrações.

Erros típicos na implementação

O erro mais comum é um primeiro token demasiado amplo. Se um chatbot de website receber direitos abrangentes de escrita logo após o primeiro login, qualquer decisão do modelo torna-se mais arriscada. O ideal é um scope inicial mínimo com step-up direcionado. O segundo erro é um catálogo de ferramentas composto por nomes de sistemas internos em vez de intenções do utilizador. Um modelo funciona de forma mais fiável com ações claras e estritamente descritas do que com endpoints genéricos de uso geral.

O terceiro erro é a falta de separação entre a confiança no modelo e a confiança no servidor. O modelo pode propor uma ação, mas é o servidor que decide se as entradas são válidas, se o token é adequado e se existe uma aprovação. O quarto erro é a falta de rastreabilidade. Se mais tarde não for claro qual ferramenta, com qual scope, leu ou alterou quais dados, não será possível operar o suporte nem a segurança de forma adequada.

Aprofundamentos adicionais

Este artigo aborda a camada de integração MCP: stateless core, tools/list e HTTP-OAuth. Os artigos seguintes aprofundam a segurança genérica de ferramentas e a operação: para o modelo de permissões, veja KI-Chatbots: Tools sicher mit Rechten und Bestätigungen nutzen. Para chamadas de ferramentas concretas, vale a pena ler KI-Chatbot-Tool-Aufrufe sicher gestalten. Se pretende que os resultados das ferramentas permaneçam legíveis por máquinas, consulte Strukturierte KI-Chatbot-Ausgaben validieren. Para operações e resolução de problemas, KI-Chatbot-Observability für Traces, Retrieval und Tools é a continuação técnica.

Fontes oficiais

A base técnica é a especificação final do MCP 2026-07-28: a página sobre MCP Tools, a MCP Authorization, o artigo oficial The 2026-07-28 Specification e o Base Protocol Overview.

Conclusão

O MCP para chatbots de IA torna-se valioso quando as equipas de websites o encaram não como uma caixa de ferramentas aberta, mas como uma camada de integração controlada. A especificação 2026-07-28 adapta-se bem à infraestrutura web moderna: pedidos stateless, listas passíveis de cache, cabeçalhos HTTP encaminháveis e autorização explícita por recurso. Ao mesmo tempo, torna a responsabilidade mais clara. As ofertas de ferramentas têm de corresponder ao token atual, operações sensíveis precisam de controlo humano e cada chamada deve ser validada no lado do servidor.

O início pragmático é pequeno: uma ferramenta de leitura, um scope restrito, um texto de consentimento claro, descoberta determinística de ferramentas e bons logs. Depois disso, podem ser ligadas mais ferramentas sem que o chatbot se transforme numa caixa preta. Dessa forma, em vez de um agente não controlado, o chatbot do website torna-se um assistente rastreável, autorizado a usar exatamente os sistemas aprovados para o utilizador e tarefa atuais.