Resposta rápida
Para conectar um servidor MCP privado à Cloudflare, mantenha o endpoint do servidor em um hostname privado ou em uma faixa IP alcançável por Cloudflare Tunnel, WARP Connector, Cloudflare One Client ou outro conector compatível. No Zero Trust, adicione o servidor ao MCP Portal, ative Route traffic through Cloudflare Gateway, conclua a autenticação e aguarde o estado Ready antes de incluí-lo no portal.
O servidor MCP e o documento OAuth Protected Resource Metadata podem ficar privados. Os endpoints OAuth de autorização e token precisam continuar acessíveis publicamente. Se o cliente OAuth for criado por Dynamic Client Registration, o endpoint de registro também deve ser público. Não publique todo o servidor apenas para fazer o OAuth funcionar.
O que mudou em 22 de setembro de 2026
A Cloudflare passou a permitir que MCP Server Portals se conectem a servidores MCP disponíveis somente em uma rede privada. Antes, o servidor upstream precisava estar exposto publicamente. O portal continua oferecendo um único endpoint HTTP protegido para clientes e agentes, mas agora a origem pode permanecer atrás de uma rota privada.
A mudança reduz a necessidade de criar uma URL pública apenas para integrar uma ferramenta interna. Ela não elimina autenticação, autorização nem segmentação de rede. O portal agrega servidores e aplica controles; cada origem ainda precisa limitar credenciais, ações e dados ao menor escopo possível.
Arquitetura segura: portal público, origem privada
O desenho recomendado separa as funções. O cliente acessa a URL do portal terminada em /mcp e passa pela política do Cloudflare Access. O portal envia a requisição ao hostname privado pela rede conectada. Apenas os endpoints necessários ao fluxo OAuth ficam públicos.
Esconder um servidor da lista do portal não protege o endereço direto. A documentação alerta que uma política do Access aplicada ao portal determina quem enxerga e usa aquele servidor dentro do portal, mas não bloqueia uma URL upstream que já esteja pública. Se existir acesso direto, proteja-o também com Access, OAuth ou regras equivalentes; de preferência, mantenha a origem privada.
Pré-requisitos antes de abrir o painel
O portal aceita servidores MCP remotos por HTTP. Um servidor disponível apenas por stdio precisa ser hospedado atrás de um transporte HTTP compatível antes da integração. A rede privada deve estar conectada à Cloudflare e precisa ter uma rota por hostname privado ou CIDR que alcance a origem.
Mapeie antecipadamente o endereço do servidor, o Protected Resource Metadata e os endpoints de autorização, token e registro. Essa lista evita o erro comum de tornar pública a aplicação inteira quando somente parte da infraestrutura OAuth exige acesso externo.
- Confirme que o servidor usa transporte HTTP remoto e responde na rede privada.
- Crie ou valide a conexão por Cloudflare Tunnel, WARP Connector, Cloudflare One Client ou outro conector compatível.
- Configure uma rota de hostname privado ou CIDR para a origem.
- Defina quais endpoints OAuth serão públicos e quais componentes permanecerão privados.
- Separe uma ferramenta somente de leitura para o primeiro teste.
Como adicionar o servidor MCP privado
No painel do Cloudflare One, abra Access controls, MCP Portals e escolha o portal. Em MCP Servers, adicione o servidor e informe a URL privada. Ative Route traffic through Cloudflare Gateway; essa opção é necessária para o registro e para a sincronização de capacidades quando a origem está na rede privada.
Conclua o fluxo OAuth ou cadastre as credenciais manuais exigidas pela origem. Aguarde o status Ready e só então inclua o servidor no portal. Por padrão, todas as ferramentas e todos os prompts descobertos são disponibilizados; desative o que o agente não precisa antes de liberar usuários.
- Abra Zero Trust > Access controls > MCP Portals e selecione o portal.
- Em MCP Servers, escolha Add MCP server e informe a URL privada do servidor.
- Ative Route traffic through Cloudflare Gateway.
- Faça a autenticação administrativa necessária para o registro e a sincronização.
- Espere o servidor aparecer como Ready.
- Revise ferramentas e prompts, desative capacidades desnecessárias e adicione o servidor ao portal.
- Teste a URL do portal com um usuário sujeito à política do Access.
OAuth: o que pode ser privado e o que precisa ser público
A URL do servidor MCP e o endpoint de Protected Resource Metadata podem usar o hostname privado. Já os endpoints de autorização e token precisam ser alcançados publicamente para que navegador, cliente e portal completem o fluxo. Quando houver Dynamic Client Registration, o endpoint de registro também precisa ser público.
Isso não significa deixar esses endpoints sem proteção. Use TLS válido, validação estrita de redirect URI, clientes e escopos mínimos, expiração curta e logs sem segredos. Evite parâmetros genéricos, credenciais compartilhadas e redirecionamentos curingas. A separação de rede reduz superfície, mas uma configuração OAuth permissiva ainda pode conceder acesso excessivo.
Access, escopo de ferramentas e acesso direto
Crie uma política do Access para o portal e restrinja usuários ou grupos autorizados. Depois limite, dentro do portal, quais servidores, ferramentas e prompts cada público pode usar. A configuração padrão expõe todas as capacidades descobertas, por isso uma revisão explícita é importante antes do primeiro agente real.
Teste também o endereço upstream. Se ele responder pela internet sem o portal, a política do portal não é uma barreira para esse caminho. Remova a rota pública desnecessária ou aplique autenticação independente. Para ações de escrita, mantenha confirmação humana, idempotência quando possível e trilha de auditoria.
Gateway e DLP: onde aplicar as regras
O roteamento pelo Gateway permite inspecionar requisições MCP em tempo real. As políticas podem ser aplicadas ao portal inteiro ou a servidores específicos. Ao criar uma política DLP, use o hostname do servidor MCP upstream como destino, não a URL do portal.
Há limites importantes. Perfis de AI prompt DLP não se aplicam a esse tráfego; use perfis DLP padrão. O transporte SSE não é suportado quando a requisição passa pelo Gateway. Além disso, a sincronização de ferramentas e prompts executada em segundo plano não passa pelo Gateway: a inspeção cobre as solicitações do usuário em tempo real.
Por que o servidor não chega a Ready
Comece pela rota privada, DNS interno, certificado e conectividade do conector. Depois confirme que Route traffic through Cloudflare Gateway está ativo e que os endpoints OAuth públicos respondem. Um provedor que bloqueia tráfego de proxy pode devolver 403 e impedir a integração.
Estados Error ou Sync Required também podem aparecer quando a credencial OAuth usada pelo administrador expira. Reautentique o servidor e repita a sincronização. Ao analisar erros, preserve status_code, mcp_code, retryable, is_upstream e cause, mas nunca registre tokens, cookies ou cabeçalhos de autorização.
- Confira o Cloudflare Status para descartar um incidente amplo.
- Teste a resolução e a rota do hostname privado a partir da rede conectada.
- Valide publicamente apenas autorização, token e registro OAuth, quando usado.
- Reautentique a credencial administrativa se houver Error ou Sync Required.
- Teste uma ferramenta de leitura com dados não sensíveis antes de habilitar escrita.
Limitações que precisam entrar no desenho
MCP Server Portals aceitam transporte HTTP remoto, não stdio isolado, e cada portal suporta até 80 servidores. O primeiro acesso exige autenticação pelo navegador; device authorization não é suportado. A credencial administrativa usada para descobrir e sincronizar capacidades precisa continuar válida, e a atualização automática ocorre aproximadamente a cada duas horas.
A integração não torna uma ferramenta confiável por si só. Prompt injection, retorno malformado, permissões excessivas e ações destrutivas continuam possíveis. Trate descrições e respostas do servidor como entrada não confiável, limite saída de dados e não conceda ao agente credenciais mais amplas do que as do usuário.
Próxima ação útil
Este guia foi verificado em 23 de setembro de 2026. Faça um inventário do servidor MCP, do transporte, da rota privada e dos endpoints OAuth. Confirme que a origem não está exposta diretamente, conecte uma ferramenta somente de leitura e valide Access, Gateway e logs com uma conta de teste.
Depois do teste, habilite apenas as ferramentas necessárias, documente quem pode alterar o portal e monitore o status oficial. Reavalie a arquitetura sempre que adicionar um novo servidor, mudar o provedor OAuth ou liberar uma ação de escrita.
Faça o próximo teste
Fontes consultadas
Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.
- Connect private MCP servers to MCP server portalsCloudflare Changelog
- MCP server portalsCloudflare Docs
- Cloudflare TunnelCloudflare Docs
- Traffic policiesCloudflare Docs
- Cloudflare StatusCloudflare