Onde um servidor MCP deve ficar? Conferimos 33 endereços

Que URLs os servidores MCP públicos usam?

Na maioria, um subdomínio mcp. dedicado, em geral com /mcp como caminho. Fomos pesquisar enquanto escolhíamos entre mcp.scorestarling.com/mcp e api.scorestarling.com/v1/mcp, a forma que a ElevenLabs usa, porque queríamos saber o que os outros serviços realmente fazem.

Em 2 de outubro de 2026, entre 17h40 e 17h42 UTC, enviamos um POST sem autenticação a cada um de 33 endereços de 27 serviços, com {} como corpo, o cabeçalho Accept: application/json, text/event-stream e um tempo limite de 8 segundos, e registramos apenas o código de status. Um 401 significa que algo naquele endereço respondeu e quer um token, que é como um servidor MCP protegido inicia o login. Um 404 significa que nada é servido naquele caminho. Alguns endereços foram publicados pelos próprios serviços; outros eram variantes e palpites que testamos para ver quais caminhos respondem. É um retrato de serviços conhecidos, não um censo, e qualquer um deles pode ter mudado desde então.

Os 404 trazem a lição prática: não dá para derivar a URL de um MCP a partir de um domínio. A Stripe e a Vercel respondem no host sem caminho e devolvem 404 em /mcp; a Higgsfield é o contrário; a ElevenLabs precisa do /v1. Um cliente usa exatamente a URL que recebe, e a RFC 9728 faz dessa URL a identidade com a qual os metadados do servidor precisam coincidir, então a mesma string tem de aparecer na sua documentação, nos links de instalação e nos manifestos de plugin. Os manifestos mostram ainda mais variedade: entre os plugins que tínhamos instalados havia gitlab.com/api/v4/mcp, um caminho no próprio gitlab.com, e mcp.hubspot.com/anthropic. Não sondamos esses dois.

O endpoint MCP deve ficar no mesmo host do seu site?

Achamos que não. O endpoint é para software e a página de configuração é para pessoas, e os dois querem o endereço óbvio. Até 2 de outubro de 2026, scorestarling.com/mcp era o nosso servidor MCP, então o guia tinha de ficar em outro lugar; e, como o 401 dessa URL é como todo cliente descobre o login, ela não podia ser também uma página da web.

Consideramos servir os dois na mesma URL, uma página para os navegadores e o MCP para os clientes, e descartamos isso como configuração permanente: um palpite errado sobre uma requisição quebra a descoberta do login de todos os clientes. A especificação do transporte também permite que os clientes enviem GET ao endpoint para abrir um fluxo de eventos, e espera como resposta esse fluxo ou um 405, não uma página HTML.

Um host separado também mantém as mudanças do site longe do endpoint: um redesign não consegue movê-lo, e um cache de CDN ou um desafio de navegador que serve a um site de marketing nunca fica na frente dele. Os assistentes chamam o servidor a partir da própria infraestrutura, não de um navegador: a documentação de conectores da Anthropic diz que o Claude se conecta a partir da nuvem da Anthropic e que um firewall na frente do provedor de identidade pode quebrar o login. Dois outros serviços que examinamos fazem a mesma divisão (conferido em 2 de outubro e de novo em 3 de outubro de 2026): o guia da Higgsfield fica em higgsfield.ai/mcp e o servidor em mcp.higgsfield.ai/mcp; o guia da ElevenLabs fica em elevenlabs.io/mcp e o servidor em api.elevenlabs.io/v1/mcp.

O nosso host MCP serve só /mcp e /.well-known/*. Qualquer outro caminho recebe um 308 para o mesmo caminho e a mesma query string no site, então login, consentimento, páginas, links de download e cookies ficam em um único host. O /mcp do site agora é o guia de configuração para o Claude, o ChatGPT e outros clientes.

$ curl -si "https://mcp.scorestarling.com/login?x=1"
HTTP/2 308
location: https://app.scorestarling.com/login?x=1

mcp.example.com/mcp, um host sem caminho ou api.example.com/v1/mcp?

Qualquer um funciona; escolha pelo que mais roda nesse host. A especificação de autorização do MCP lista https://mcp.example.com/mcp e https://mcp.example.com entre os URIs canônicos válidos de servidor e pede a forma sem barra final, a menos que a barra faça diferença. A especificação do transporte só exige um caminho de endpoint que aceite POST e GET, com https://example.com/mcp como exemplo, e a documentação de conectores da Anthropic usa https://mcp.example.com/mcp.

Duas regras menores. Não termine um endpoint Streamable HTTP em /sse: a documentação da Anthropic diz que uma URL que termina assim seleciona o transporte SSE mais antigo no formulário de conector do Claude. E deixe de fora a barra final, a menos que a queira de propósito; dos 23 endereços que responderam 401, só o do GitHub foi escrito com uma.

Como mudar um servidor MCP para uma nova URL?

Sirva os dois endereços por um tempo e faça cada um completo por conta própria: o seu 401, os seus metadados e tokens para qualquer uma das audiências. Mudamos em quatro passos, todos no ar em menos de uma hora na noite de 2 de outubro de 2026 (UTC):

1. Publique o suporte a aliases enquanto nada o usa. Uma configuração lista os endereços anteriores, cada um em HTTPS e terminando em /mcp. Um token é válido se a audiência dele for o endereço atual ou um alias; qualquer outra audiência é recusada. As listas de hosts permitidos (os hosts confiáveis do Starlette e a proteção contra DNS rebinding do SDK do MCP) incluem todos os endereços mais o site. Sem nenhum alias definido, a produção se comportava como antes.

2. Adicione o host e, depois, troque o endereço e defina o alias em uma única mudança. O novo subdomínio recebeu os registros DNS, o certificado veio cerca de seis minutos depois, e o host respondeu 400 até o nosso servidor ser configurado para confiar nele. Uma mudança de configuração definiu a nova URL do recurso e listou a antiga como alias, então uma única implantação nova aplicou as duas. Fazer isso antes de o passo 1 estar no ar teria feito o código em execução recusar o próprio host do site.

3. Aponte para o novo endereço tudo o que as pessoas copiam: o guia de configuração, incluindo os links codificados de instalação com um clique para o Claude, o Cursor e o VS Code, os manifestos de plugin e a documentação.

4. Troque a audiência do token e depois desative o endereço antigo. Uma migração fez o nosso hook de token de acesso emitir a nova audiência, e o CI a aplicou antes de o código ser publicado; enquanto o alias existia, tokens com qualquer uma das audiências continuavam funcionando. Depois removemos o alias e fizemos uma nova implantação. Nos poucos minutos entre essa versão e a nova implantação, o /mcp do site mandava o guia aos navegadores e o servidor aos clientes MCP. Agora ele serve só o guia, e o endereço antigo do guia, /connect, responde com um 308 para ele.

Os metadados são a parte fácil de esquecer. A RFC 9728 exige que o seu resource seja idêntico à URL à qual o cliente se conectou, e a documentação da Anthropic exige que ele seja igual à URL digitada no Claude. Por isso, durante a sobreposição, cada host descrevia a si mesmo, e cada 401 apontava para o documento do seu próprio host:

GET https://scorestarling.com/.well-known/oauth-protected-resource/mcp
→ "resource": "https://scorestarling.com/mcp"

GET https://mcp.scorestarling.com/.well-known/oauth-protected-resource/mcp
→ "resource": "https://mcp.scorestarling.com/mcp"

Não redirecionamos o próprio /mcp. A especificação do transporte não descreve redirecionamentos para o endpoint, e a URL dele faz parte do handshake do OAuth como o recurso e a audiência do token, então servimos o MCP nos dois endereços. Para todos os outros caminhos, um 308, e não um 301, mantém o método, já que a RFC 9110 não deixa um cliente transformar um POST em GET depois de um 308. Como a audiência entra nos nossos tokens está nas nossas notas sobre OAuth em servidor MCP remoto.

Conseguimos mudar tão rápido porque o ScoreStarling ainda era um piloto pequeno, só para convidados, e ninguém dependia do endereço antigo. Depois que o alias sai, um cliente ainda configurado com scorestarling.com/mcp precisa se reconectar. O nosso runbook prevê que um cliente que já está no novo endereço, mas guarda um token com a audiência antiga, receba um 401 invalid_token, renove o token e receba a nova audiência; não vimos um cliente real do Claude ou do ChatGPT fazer isso. Com usuários reais, mantenha o alias até o tráfego para o endereço antigo parar.

O que deu errado durante a mudança?

Três pequenos problemas apareceram no caminho:

• Um script de verificação montava a URL dos metadados com resource.replace('/mcp', '/.well-known/oauth-protected-resource/mcp'). No endereço antigo, funcionava. Em https://mcp.scorestarling.com/mcp, o /mcp também coincide dentro de //mcp., e o resultado foi https://.well-known/oauth-protected-resource/mcp.scorestarling.com/.well-known/oauth-protected-resource/mcp. Monte a URL a partir das partes já analisadas: esquema e host, depois o segmento well-known, depois o caminho.
• O endereço mais longo transbordava do nosso guia numa tela de 320 pixels de largura, até deixarmos o código inline quebrar de linha.
• Apagar a variável do alias com a linha de comando da Railway apenas preparou a mudança (staged); o endereço antigo continuou sendo aceito até fazermos uma nova implantação à mão.

Uma lista de verificação para escolher o endereço de um servidor MCP

• Dê ao endpoint um host que não sirva nada para pessoas; mcp. mais o seu domínio é a escolha comum na nossa amostra.
• Escolha o caminho uma vez só. /mcp é o mais comum e um host sem caminho também é válido; evite a barra final e um caminho terminado em /sse.
• Deixe a página de configuração para pessoas no seu site principal, num endereço que elas possam adivinhar, e coloque um link para ela na navegação.
• Sirva os metadados da RFC 9728 para a URL exata, em /.well-known/oauth-protected-resource mais o seu caminho e na raiz, com resource igual ao endereço que o cliente usou.
• Faça dessa URL a audiência do token e construa o suporte a aliases antes de precisar mudar.
• Redirecione todos os outros caminhos do host MCP para o seu site com um 308, mantendo a query string.
• Mantenha desafios de navegador e cache de HTML longe do host MCP.
• Publique uma única string em todo lugar (guia, links de instalação, manifestos de plugin, documentação) e teste se todas as cópias coincidem.
• Para mudar: primeiro os aliases, depois o novo endereço e o alias em uma única mudança, todas as cópias apontadas para o novo endereço, a audiência trocada e o endereço antigo desativado depois que o tráfego dele parar.