Transportes e perfis
Versões do protocolo MCP que o PEP aceita, transportes upstream, setup do protocolo e a lista de tools que o gateway responde.
O MCP tem várias versões em uso ao mesmo tempo, e elas não descrevem uma chamada do mesmo jeito. A versão 2026-07-28 repete o método e o nome da tool em headers HTTP (Mcp-Method, Mcp-Name). As versões de 2025 só usam o corpo. Um gateway que aceitasse as duas formas misturadas abriria espaço para uma mensagem com um nome no header e outro no corpo, em que o PEP autoriza uma tool e o server executa outra.
Por isso o PEP lê a versão declarada e escolhe um único decodificador, sem segunda tentativa:
| Perfil declarado | Como o PEP lê a mensagem |
|---|---|
2026-07-28 | Exige MCP-Protocol-Version, Mcp-Method e Mcp-Name consistentes com o corpo |
2025-03-26, 2025-06-18, 2025-11-25 | Lê do corpo; rejeita Mcp-Method e Mcp-Name |
| Sem header de versão | Assume 2025-03-26, desde que não haja metadados modernos |
| Não suportado ou misturado | Rejeita com 400 |
Do Xokepoint até o server
Do lado do server, o Xokepoint fala Streamable HTTP ou o HTTP+SSE original. O transporte é detectado quando o server é descoberto e fica gravado na revisão. stdio não é suportado, porque o server precisa estar na rede para o Xokepoint ficar no caminho.
O agente e o server negociam versões de forma independente. Um agente na versão nova pode chamar um server antigo, e o Xokepoint adapta a tool call entre os dois, sem fingir que o server antigo implementa recursos que só existem na versão nova.
Setup e a lista de tools
Antes de chamar tools, o client faz setup e descoberta: initialize e tools/list nas versões de 2025, server/discover e tools/list na de 2026. Todo server ativo aceita essas mensagens, sem nenhuma configuração, depois de autenticação e validação e sem ir ao PDP.
- Setup.
initializeeserver/discovervão ao server, mas o Xokepoint responde como gateway. Ele anuncia sótools, a única família que atende, então um client que segue o protocolo não chama mais nada. Ele remove asinstructionsdo server, que um harness colocaria no contexto do modelo sem revisão, e identifica o server pelo nome do registry, no lugar do nome e da versão do upstream. - Lista de tools. O Xokepoint responde o
tools/listsozinho, e a requisição nunca chega ao server. A lista tem só as tools que o agente pode chamar: cada tool revisada e ativa em que a delegação do sujeito e a capability do agente passam no OpenFGA, restrita pelosauthorization_detailsdo token. Cada tool vem com a definição que o administrador revisou, nunca o texto atual do server. A lista é uma página só, não é registrada no Investigate e, na versão 2026, é marcada como privada e sem cache.
Uma tool na lista não é permissão para executá-la. O tools/call sempre passa pelo PDP, em qualquer versão, com condições e recursos. A escolha também usa o método JSON-RPC validado, nunca só um header.
O que o Xokepoint não atende do MCP, e por quê
No MCP toda capability é opcional: o server declara o que suporta, e os dois lados usam só o que negociaram (negociação de capabilities). Para o client, o server MCP é o Xokepoint, não o server por trás dele. O Xokepoint declara só o que consegue governar como governa uma chamada de tool: sujeito e agente verificados, definição revisada, decisão de política e trace. Repassar uma capability sem isso abriria um caminho por fora do gateway. Um client que segue o MCP não chama nada que não foi declarado, então isso não exige conhecer o funcionamento de cada harness.
| Fica de fora | O que faz no MCP | Por quê |
|---|---|---|
tools.listChanged | O server avisa o client que a lista de tools mudou | A lista que o client vê é a do agente, filtrada pelas concessões. Um aviso do server descreveria outra lista, e o aviso que importa, uma mudança de concessão ou de revisão, teria de vir do Xokepoint. Pode entrar depois. |
prompts | prompts/list, prompts/get: modelos de mensagem do server | O texto de um prompt entra no contexto do modelo. Como a descrição de uma tool, precisaria de revisão, e o prompts/get de uma decisão. Sem isso, uma mudança no upstream chegaria ao modelo sem controle. |
resources | resources/list, resources/read, resources/subscribe: dados do server por URI | O resources/read lê dados. Precisaria da mesma autorização de uma chamada de tool (delegação, relações de recurso, condições) e de trace. Repassá-lo seria um caminho de dados fora da política. |
logging | logging/setLevel e mensagens de log do server | O logging/setLevel é um controle do client sobre o server, fora de qualquer decisão. A revisão 2026-07-28 deixa essa capability obsoleta (SEP-2577). |
completions | completion/complete: sugestões para argumentos de prompts e resources | Existe só para preencher prompts e resources, que não são atendidos. |
experimental, extensions | Métodos fora do padrão | Sem contrato padrão, não há o que validar nem governar. |
O stream do server (GET) e o DELETE de sessão | Mensagens que o server inicia fora de uma chamada; fim de uma sessão | Uma mensagem fora de uma chamada não tem sujeito, agente nem decisão. Os dois respondem 405, o que o transporte permite (escuta de mensagens, gestão de sessão). |
instructions do server | Texto livre que o client coloca no contexto do modelo | O texto nunca foi revisado e pode mudar a qualquer momento, o mesmo risco de uma descrição de tool sem revisão. |
serverInfo do server | Nome e versão da implementação | O client fala com o server governado, então recebe o nome do server no registry. A implementação e a versão do upstream ficam privadas. |
O andamento de uma chamada de tool não depende de nada disso. O server envia notifications/progress no stream da resposta da chamada, e o Xokepoint entrega cada evento quando ele chega (progress).
Chamadas longas de tool
Uma chamada de tool pode levar minutos, como um build, uma bateria de testes ou um relatório. O Xokepoint limita cada fase da chamada em separado:
| Fase | Limite | O que reinicia o limite |
|---|---|---|
| Autorização: token, delegação, permissões, recursos e condições | 6 segundos | Nada. Uma decisão é sempre rápida. |
| A tool no server, sem nenhuma mensagem | 30 segundos | Cada evento que o server envia no stream da resposta, como notifications/progress |
| A chamada inteira | 5 minutos, e nunca depois da expiração do token | Nada |
Uma tool que informa o andamento pode rodar até 5 minutos, e o harness mostra cada passo quando ele chega. Uma tool que fica 30 segundos sem enviar nada é interrompida, e o Xokepoint cancela a requisição ao server. O setup e a lista de tools mantêm o limite de 6 segundos.
O Xokepoint não recusa uma requisição MCP por excesso de carga. A capacidade cresce com o número de instâncias.