Esta página aborda os MCP Gateways, endpoints voltados aos clientes que agrupam os MCP Servers upstream aos quais o Toqan Router se conecta. Trata-se de uma funcionalidade diferente do servidor MCP do próprio Toqan Router, ao qual os assistentes de programação se conectam para administrar o workspace.
- Name: a chave do gateway
- Servers: os MCP Servers vinculados, como uma pilha de avatares de servidores, com uma contagem
+Nquando a lista é longa - Exposed tools: quantas ferramentas o gateway expõe aos clientes
- Access: quais projetos podem usar o gateway
- Public URL: o endpoint ao qual os clientes se conectam, com um controle para copiar
Como funciona
Um servidor MCP virtual é um único endpoint que dá aos clientes acesso a ferramentas de vários MCP Servers upstream. O gateway agrega esses servidores por trás de um único endereço, cuida da autenticação e do roteamento e resolve internamente os conflitos de nomes de ferramentas. Os clientes se conectam a uma única URL e veem todas as ferramentas vinculadas como se viessem de um único provedor.Casos de uso
- Expor vários servidores MCP por meio de um único endpoint para clientes que não conseguem gerenciar várias conexões.
- Criar aliases para as ferramentas dos servidores com nomes consistentes, para que os clientes não quebrem quando os nomes das ferramentas upstream mudarem.
- Governar o acesso a ferramentas por equipe: os administradores montam um MCP Gateway a partir de um subconjunto selecionado de ferramentas de vários MCP Servers, para que as equipes de Marketing e de Pesquisa possam compartilhar os mesmos servidores acessando ferramentas diferentes.
Configurar um MCP Gateway
- AI Studio
- API e SDK
Clique em MCP Gateway.General
- Description (opcional): uma observação sobre o que este MCP Gateway oferece.
- Key (obrigatório): letras minúsculas, dígitos,
-e_, com até 64 caracteres. Compõe a URL do MCP Gateway e não pode ser alterada após a criação.
- Tool exposure mode: como o MCP Gateway apresenta as ferramentas aos clientes conectados. Code mode (padrão) expõe uma única ferramenta fornecida pelo MCP Gateway que cuida da descoberta e da execução internamente. Direct expõe cada ferramenta upstream individualmente.
- Tool naming: como os nomes das ferramentas recebem namespace entre os servidores. Always prefix with server key (padrão) adiciona a todas as ferramentas o prefixo da chave do servidor, ou do alias dele, se houver um definido por vínculo. Prefix only on collision adiciona prefixo apenas aos nomes conflitantes.
- Cada limite listado em Limites de execução, preenchido com seu valor padrão.
Após a criação
O Toqan Router redireciona para a aba MCP Servers do novo MCP Gateway. Clique em + Add server para vincular qualquer servidor já configurado em MCP Servers. Apenas servidores que concluíram a sincronização inicial podem ser vinculados. Pela API, PATCH /v2/mcp-gateways/ comserver_links substitui os servidores vinculados. Um array server_links vazio não altera nada; envie clear_server_links: true para desvincular todos os servidores. Os dois campos não podem ser combinados.
Vincule apenas MCP Servers cujo acesso por projeto inclua o acesso por projeto do MCP Gateway. Um MCP Gateway em All projects, portanto, precisa de MCP Servers em All projects; altere o escopo de um servidor na aba Settings dele, conforme descrito em MCP Servers.
- Overview: o tráfego do MCP Gateway e a seção Connect, com o comando que os clientes usam para acessá-lo.
- MCP Servers: os servidores vinculados e as ferramentas que cada um expõe.
- Filtre com Search servers and tools…. Cada linha mostra
N / Mferramentas expostas; expanda-a para ver a lista de ferramentas, Select all e o contadorN of M tools exposed. - As caixas de seleção são aplicadas imediatamente. Cada ferramenta tem um selo Open world, Read only, Idempotent ou Destructive.
- O painel lateral mostra Traffic, o prefixo Alias e os detalhes de Connection.
- Filtre com Search servers and tools…. Cada linha mostra
- Clients: os clientes MCP autorizados por OAuth, com a opção de revogar o acesso deles.
- Settings: a descrição do MCP Gateway, as configurações de ferramentas, plugins e limites de execução e o acesso por projeto, editáveis após a criação.
Funções e permissões
As funções do workspace definem quem pode visualizar e gerenciar o MCP Portal. As permissões de MCP seguem a função e não são configuráveis por equipe nem por gateway.
A autorização de um cliente é self-service: a pessoa que faz login a aprova no navegador e fica com o token resultante. Revogar um cliente autorizado exige Admin.
As permissões das funções se aplicam a pessoas. As chaves de API são autorizadas separadamente, pelo acesso concedido à própria chave.
Acesso por projeto
- AI Studio
- API e SDK
Um MCP Gateway fica visível para os projetos que podem usá-lo. A coluna Access da lista de gateways mostra o escopo atual: All Projects, No projects ou os nomes dos projetos compartilhados. Um novo gateway é compartilhado com todos os projetos.Altere o escopo na aba Settings. Em Access control, escolha All projects para compartilhar o gateway com todo o workspace, ou Custom e defina cada projeto como Enabled ou Disabled.
O escopo de projeto define quais projetos podem acessar o gateway. Uma chave de API acessa os gateways dos projetos aos quais está delimitada; uma chave gerada para uma sessão de Agent também acessa apenas os gateways anexados a esse Agent.
Excluir um gateway
- AI Studio
- API e SDK
Exclua um gateway pelo item Delete no menu da linha da lista de gateways, pelo item Delete no menu adicional da página de detalhes ou pelo botão Delete gateway na aba Settings. Cada um pede confirmação.
Configurações de segurança
A aba Settings contém os plugins, os Guardrails e os limites de execução que controlam o que o MCP Gateway encaminha e quanto ele encaminha. Os mesmos campos de limites de execução aparecem no formulário Create MCP Gateway.Plugins
Os plugins anexados a um MCP Gateway são executados em todas as chamadas de ferramentas que ele atende. As Guardrail Rules não são executadas em chamadas de ferramentas. Para verificar o tráfego de ferramentas, use plugins e os próprios Guardrails do gateway. Clique em Add Plugin para anexar um. Cada plugin listado tem um ícone para configurá-lo e um ícone para removê-lo.Os plugins impostos no nível do workspace funcionam como um mínimo: um MCP Gateway pode adicionar plugins ou tornar suas configurações mais rígidas, mas não pode remover nem enfraquecer um plugin imposto.
Guardrails
Os Guardrails anexados a um MCP Gateway verificam as chamadas de ferramentas que ele atende. Em Guardrails, clique em Add para escolher um Evaluator e defina onde ele é executado:- Input: verifica o nome e os argumentos da ferramenta antes que a chamada chegue ao MCP Server upstream. As leituras de recursos também são verificadas nesta etapa.
- Output: verifica o resultado da ferramenta antes que ele retorne ao cliente.
- Both: é executado nas duas etapas.
Limites de execução
Limites aplicados ao tráfego que passa pelo MCP Gateway. Defina-os no formulário Create MCP Gateway ou na aba Settings de um gateway existente: todos os limites são configurados apenas no console, e nenhum campo da API ou método do SDK os define. Cada campo aceita um número inteiro a partir de0.
Atingir um limite de requisição, de resposta, de timeout ou de taxa, ou perder o servidor upstream, faz a chamada ser respondida com um erro que o cliente MCP exibe. Três deles também alteram o status HTTP; os demais chegam como uma resposta
200 contendo o erro.
Uma ferramenta que é executada e relata a própria falha não é um erro: o gateway retorna um resultado normal de
tools/call com isError: true e o conteúdo upstream.
Delimitar ferramentas
Um gateway expõe uma única superfície de ferramentas a todos os projetos com os quais é compartilhado. Quais ferramentas um chamador acessa depende então da exposição do gateway e daquilo a que o chamador está vinculado.
Um projeto acessa toda a superfície de ferramentas exposta ou nenhuma parte dela. Logins pelo navegador e chaves não vinculadas a uma sessão de Agent acessam toda a superfície exposta.
Dar a uma equipe suas próprias ferramentas
Duas equipes que acessam o mesmo gateway veem as mesmas ferramentas, então dê a uma equipe suas próprias ferramentas com um gateway exclusivo: crie um MCP Gateway para o projeto da equipe, exponha apenas as ferramentas que a equipe pode chamar e compartilhe-o apenas com esse projeto. Os outros projetos não conseguem acessá-lo. Atribua projetos a equipes em Settings → Organization → Teams. Consulte Membros e equipes.Delimitação de ferramentas por usuário
Não é possível delimitar ferramentas a um usuário individual. Ferramentas individuais não podem ser concedidas nem negadas a um usuário específico. O acesso segue a exposição do gateway e os projetos que o chamador acessa. Um token OAuth acessa um MCP Gateway como um todo, e não ferramentas individuais, e seus scopes definem quais métodos ele pode chamar:mcp:tools abrange ferramentas, e mcp:resources abrange recursos e skills. Uma chamada fora dos scopes do token retorna 403 com um desafio insufficient_scope que indica o scope ausente.
Para servidores gerenciados pela empresa, o provedor de identidade também decide se o usuário pode acessar o aplicativo upstream. Uma ferramenta pode aparecer no catálogo do gateway mesmo quando esse provedor nega a chamada do usuário.
Conectar um cliente
Qualquer cliente compatível com MCP pode acessar o MCP Gateway, na maioria das vezes um agente de programação como Claude Code, Cursor ou Codex. Consulte Agentes de programação para ver a lista completa. Versões do protocolo
Extensões
O gateway anuncia estas extensões na capability
extensions de initialize e server/discover:
Um cliente que não envia nenhuma revisão, ou que envia uma mais antiga que as da lista, é atendido com
2024-11-05: initialize responde com essa revisão, e o gateway responde às notificações com 200 em vez do 202 exigido pelo Streamable HTTP. Uma revisão mais recente que a mais nova suportada retorna UnsupportedProtocolVersion, com as revisões aceitas em supported.
Os exemplos abaixo usam
https://router.toqan.ai/eu como host padrão. Para São Paulo, use https://router.toqan.ai/br. O campo public_url da API retorna o endpoint de conexão completo (que pode ser relativo quando nenhuma URL base pública está configurada).- OAuth (padrão): login pelo navegador. Use para clientes interativos.
- Client credentials: um cliente pré-registrado obtém tokens de curta duração sem a presença de um usuário. Use para serviços e automações.
- Autorização gerenciada pela empresa: o provedor de identidade da empresa emite um ID-JAG que o cliente troca por um token, sem tela de consentimento.
- Chave de API: um token bearer na configuração do cliente. Use para clientes headless que não conseguem executar um fluxo OAuth.
ENTERPRISE_AUTH_REAUTH_REQUIRED.
OAuth
O OAuth é o padrão. O cliente faz login pelo navegador e recebe um token delimitado a este MCP Gateway e à pessoa que fez login, então nenhuma chave de API do workspace fica armazenada na configuração do cliente.Este fluxo autentica clientes MCP no MCP Gateway. As credenciais que o gateway usa para acessar cada MCP Server upstream são configuradas no próprio servidor. Consulte MCP Servers.
1
Configure o cliente
A seção Connect na aba Overview mostra a chave do gateway e este comando. Copie-o de lá ou execute-o substituindo Registre o MCP Gateway diretamente no cliente, substituindo O Claude Code abre o navegador para aprovação no primeiro uso. Confirme com
<gateway-key>:<gateway-key> pela chave do gateway da seção Connect:- Claude Code
- Cursor
- Codex
- VS Code
claude mcp list.2
Aprove o acesso
No primeiro uso, o cliente abre o navegador. A página de aprovação indica o cliente e o MCP Gateway ao qual ele está solicitando acesso. Clique em Approve para emitir o token ou em Deny para rejeitar a solicitação.
- Descoberta: uma requisição não autenticada ao gateway retorna
401com um headerWWW-Authenticateque aponta para os documentos de metadados do gateway. O documento de recurso protegido em/.well-known/oauth-protected-resource/v3/mcp/<gateway-key>indica o servidor de autorização; o documento do servidor de autorização em/.well-known/oauth-authorization-server/v2/auth/mcp, que atende todos os gateways, lista seus endpoints. - Registro dinâmico de clientes: o cliente se registra no endpoint de registro do servidor de autorização, então nenhum client ID ou secret precisa ser provisionado com antecedência.
- Authorization code com PKCE: o login usa o fluxo authorization code com Proof Key for Code Exchange (PKCE) e o método de desafio
S256, que vincula o código de autorização ao cliente que o solicitou.
mcp:tools e mcp:resources por padrão, apenas neste MCP Gateway. Um cliente registrado com o grant refresh_token o renova sem um novo login até que o acesso seja revogado; qualquer outro cliente faz login novamente quando o token expira. Cada renovação substitui o refresh token; apresentar um token substituído mais de 60 segundos depois revoga o acesso do cliente, e a pessoa precisa fazer login novamente.
Metadados do servidor de autorização
/.well-known/oauth-authorization-server/v2/auth/mcp anuncia:
Client credentials
Um cliente pré-registrado se autentica como ele mesmo e recebe um token de acesso de 10 minutos vinculado a um MCP Gateway, sem navegador e sem refresh token. O cliente é seu próprio principal e tem as mesmas configurações de acesso de uma chave de API: projeto e permissões.1
Registre o cliente
Em Settings → API Keys → OAuth Clients, clique em + Client. Escolha o grant Client credentials, o acesso (projeto e permissões) e como o cliente se autentica:
- Client secret (Basic) ou Client secret (POST): o secret é exibido uma única vez após a criação. Use Rotate secret para substituí-lo.
- Private key JWT: cole um JSON Web Key Set ou uma URL de JWKS com as chaves públicas. O cliente assina asserções RFC 7523 com
RS256,PS256ouES256.
2
Solicite um token
Envie a URL do gateway como o A resposta contém
resource da RFC 8707:access_token, token_type, expires_in e o scope concedido. Envie o token como Authorization: Bearer <access_token> e solicite um novo antes que ele expire.- Client secret
- Private key JWT
- Python
Autorização gerenciada pela empresa
O provedor de identidade da empresa decide quais usuários podem usar quais clientes MCP. Um cliente conectado por SSO solicita ao provedor de identidade um Identity Assertion JWT Authorization Grant (ID-JAG) e o troca no Toqan Router por um token do gateway, então o usuário nunca vê a página de aprovação.1
Conecte o provedor de identidade
Configure primeiro a conexão SSO: Configurar SSO.
2
Confie no provedor de identidade
Em Settings → SSO, abra a conexão SSO e habilite ID-JAG trust. Liste os clientes autorizados a resgatar ID-JAGs: client IDs pré-registrados ou URLs de Client ID Metadata Document. Opcionalmente, limite os scopes. Conexões OIDC confiam apenas no issuer do SSO; conexões SAML precisam da URL do issuer que o provedor de identidade coloca em seus ID-JAGs.
3
Configure o provedor de identidade
Registre o cliente MCP no provedor de identidade e permita a troca de tokens para o Toqan Router. O ID-JAG deve usar:
aud: o issuer do servidor de autorização,https://router.toqan.ai/eu/v2/auth/mcp.resource: a URL do gateway,https://router.toqan.ai/eu/v3/mcp/<gateway-key>, ou omita-o e envieresourcena requisição de token.client_id: o ID do cliente no Toqan Router.
4
Troque o ID-JAG
sub do ID-JAG a uma conta na primeira vez que o vê e reutiliza esse vínculo depois. No primeiro uso, o ID-JAG precisa conter email_verified: true e um email em um dos domínios permitidos da conexão SSO que corresponda a uma conta já existente no workspace. O Toqan Router nunca cria contas nem associações a partir de um ID-JAG; uma requisição sem membro correspondente é rejeitada com invalid_grant. Alterar o issuer da conexão apaga seus vínculos.
Cada ID-JAG é aceito uma única vez, deve ter validade de 10 minutos ou menos e é verificado em relação às chaves publicadas pelo provedor de identidade.
Chave de API
Passe uma chave de API como token bearer em vez de fazer login. DefinaTOQAN_API_KEY e registre o MCP Gateway:
- Claude Code
- Cursor
- Codex
- VS Code
TOQAN_API_KEY antes de executar o comando. Confirme com claude mcp list.Sessões
Cada requisição MCP é independente. Não há uma sessão de gateway que o cliente precise inicializar, manter ativa, retomar após uma reconexão ou encerrar.Monitorar o uso
A aba Overview reporta como os clientes usam o MCP Gateway. Ela abre nos últimos 7 dias, e cada card compara esse período com o anterior. Altere o período com o seletor de intervalo de tempo no canto superior direito.
Traffic and reliability detalha ainda mais o mesmo período:
- Tool calls by outcome: volume de chamadas ao longo do tempo, dividido entre sucessos e erros.
- Tools leaderboard: as ferramentas mais chamadas, com a contagem de chamadas e a latência P95, listadas com seus nomes com namespace.
Auditar alterações
As alterações no MCP Gateway são registradas nos Audit Logs, para que uma alteração na superfície de ferramentas exposta possa ser rastreada até quem a fez. As entradas são gravadas em dois tipos de entidade:
Filtre por qualquer um dos tipos de entidade na página Audit Logs para ver apenas a atividade do MCP Portal. As entradas dos dois tipos de entidade podem ser exportadas como arquivo; consulte Exportar audit logs.

