A URL do servidor MCP é o endereço web que seu cliente de IA chama para acessar um servidor remoto do Model Context Protocol. Este artigo mostra como o endereço é montado, exemplos reais do Notion, do GitHub e do Sentry, e onde encontrar o endereço exato de que você precisa.
Você cola um link em um cliente de IA, clica em conectar e nada acontece. Ou uma tela de configuração pede uma "URL do servidor MCP" e você não faz ideia de onde esse endereço vem. A resposta curta é esta: uma URL do servidor MCP é o endereço web de um servidor remoto do Model Context Protocol. É o endpoint exato que seu cliente de IA chama para listar ferramentas, ler dados e executar ações em seu nome.
Este artigo explica o que o endereço significa, como ele é montado, quais exemplos reais você pode usar como comparação e os lugares onde pode encontrar o que precisa. Você também verá os erros por trás da maioria das conexões que falham, além de um jeito rápido de conferir a configuração antes de culpar o servidor.
O Model Context Protocol (MCP) é um padrão aberto que permite a um aplicativo de IA conversar com ferramentas externas por meio de uma linguagem previsível. Três papéis estão envolvidos: o host (o aplicativo de IA que você usa), o cliente que roda dentro desse aplicativo e o servidor que expõe ferramentas, recursos e prompts. As mensagens entre cliente e servidor trafegam em JSON-RPC.
Quando o servidor fica na internet, em vez de na sua própria máquina, o cliente precisa saber para onde enviar essas mensagens. Esse local é a URL do servidor MCP. Pense nela como o número de telefone de um fornecedor de ferramentas específico: você liga, e o servidor responde com a lista do que ele consegue fazer.
A especificação oficial chama esse endereço de endpoint MCP. Trata-se de um único caminho HTTP, e a especificação exige que ele aceite tanto POST quanto GET. Toda mensagem do seu cliente é um POST novo para esse caminho. Opcionalmente, o cliente abre um GET no mesmo caminho para ouvir mensagens que o servidor queira enviar. Um endereço só, sem uma lista extensa de rotas para decorar.
💡 Dica: Se uma página de configuração diz "server URL", "endpoint URL", "connector URL" ou "remote MCP URL", quase sempre ela se refere a este mesmo endereço único.
A URL não descreve as ferramentas. Ela não guarda seu login. É apenas a porta de entrada. O que o servidor oferece aparece depois que o cliente se conecta e pergunta. Por isso, dois servidores com endereços parecidos podem se comportar de formas muito diferentes, e uma URL que funciona não prova sozinha que a configuração está certa.
Uma URL do servidor MCP é uma URL web padrão. A sintaxe não tem surpresas. A própria especificação usa este exemplo:
https://example.com/mcp
Divida esse exemplo em partes e cada uma tem uma função.
| Parte | Exemplo | O que faz |
|---|---|---|
| Esquema | https:// | Indica ao cliente que use HTTP criptografado. Servidores remotos devem sempre usar. |
| Host | mcp.example.com | O nome de domínio do servidor. Costuma começar com mcp. ou api.. |
| Porta (opcional) | :8443 | Só aparece quando o servidor não usa a porta HTTPS padrão. |
| Caminho | /mcp | O endpoint único que trata o tráfego MCP. |
| Query (opcional) | ?workspace=123 | Rara, mas alguns provedores acrescentam configurações, como um workspace. |
Servidores locais de desenvolvimento costumam usar http://localhost:3000/mcp puro. Isso é aceitável na sua própria máquina. Nunca exponha um endereço sem criptografia à internet aberta.
A especificação diz apenas que o endpoint "pode ser uma URL como" o exemplo acima. O caminho é uma convenção, não uma regra. Mesmo assim, dois sufixos dominam na prática:
/mcp geralmente aponta para um servidor Streamable HTTP, o transporte padrão atual./sse geralmente aponta para o transporte HTTP+SSE mais antigo, da versão de protocolo 2024-11-05.Trate o sufixo como uma pista, não como garantia. Um provedor pode publicar o endpoint em /v1/mcp ou na raiz de um subdomínio. Copie a URL exatamente como está impressa, incluindo qualquer barra final. O servidor remoto do GitHub, por exemplo, termina com /mcp/.
O Streamable HTTP substituiu o antigo transporte HTTP+SSE. No modelo mais novo, o cliente sempre envia um POST com um cabeçalho Accept que lista tanto application/json quanto text/event-stream. O servidor responde com um único objeto JSON ou com um fluxo de eventos. Um servidor também pode devolver um cabeçalho Mcp-Session-Id, que o cliente repete em todas as requisições seguintes, e os clientes enviam um cabeçalho MCP-Protocol-Version para que os dois lados concordem com a revisão da especificação.
A documentação do Claude Code agora descreve o SSE como obsoleto e recomenda servidores HTTP sempre que existirem. Muitos provedores mantêm um endereço /sse ativo para clientes antigos, por isso você ainda encontra os dois estilos.
💡 Dica: Um cliente que quer ser compatível com servidores antigos aceita uma URL informada pelo usuário e tenta um POST primeiro. Se o servidor responder com um erro 4xx, ele recorre a um GET e espera um fluxo SSE. Esse recurso de fallback é o motivo de a mesma URL colada às vezes funcionar em um aplicativo e falhar em outro.
Nem todo servidor MCP tem uma URL. Isso surpreende muita gente e explica por que algumas configurações pedem um comando em vez de um endereço.
No transporte stdio, o cliente inicia o servidor como um subprocesso no seu computador. As mensagens passam pela entrada e saída padrão. Não há salto de rede nem endereço. Você informa um comando e seus argumentos, por exemplo npx mais o nome de um pacote, e isso é tudo o que o cliente precisa. A especificação orienta os clientes a oferecer suporte a stdio sempre que possível, então ele continua sendo o padrão para ferramentas locais.
Com o Streamable HTTP, o servidor roda como um processo independente e pode atender muitos clientes ao mesmo tempo. É nesse cenário que a URL se torna essencial, porque o cliente precisa encontrar o servidor pela rede.
| Transporte | Tem URL? | Configuração típica | Status |
|---|---|---|---|
| stdio | Não | command e args em um arquivo de configuração | Padrão, os clientes devem oferecer suporte |
| Streamable HTTP | Sim, um endpoint | Cole https://…/mcp | Transporte remoto padrão |
| HTTP+SSE | Sim, muitas vezes /sse | Cole https://…/sse | Obsoleto, mantido para clientes antigos |
Use a segunda coluna como regra de decisão. Se seu provedor entrega uma linha de comando, você está no stdio. Se entrega um link, você está em um transporte remoto.
Quando um servidor roda na sua própria máquina por HTTP, a especificação diz que ele deve se vincular a 127.0.0.1 em vez de 0.0.0.0, e precisa validar o cabeçalho Origin para bloquear ataques de DNS rebinding. Em outras palavras: um servidor MCP local em localhost nunca deveria ser acessível a outros dispositivos da sua rede, a menos que você queira isso de propósito.
Os endereços abaixo vêm de páginas de documentação oficiais e de listas públicas. Os fornecedores mudam os endpoints, então trate esta tabela como referência de padrões e confirme cada URL na documentação atual do provedor antes de confiar nela.
| Provedor | URL de exemplo | Estilo |
|---|---|---|
| Exemplo da especificação | https://example.com/mcp | Streamable HTTP |
| Notion | https://mcp.notion.com/mcp | Streamable HTTP |
| GitHub | https://api.githubcopilot.com/mcp/ | Streamable HTTP |
| Sentry | https://mcp.sentry.dev/mcp | Streamable HTTP |
| Supabase | https://mcp.supabase.com/mcp | Streamable HTTP |
| PostHog | https://mcp.posthog.com/mcp | Streamable HTTP |
| Asana | https://mcp.asana.com/sse | SSE legado |
| Servidor de teste local | http://localhost:3000/mcp | Streamable HTTP na sua própria máquina |
mcp. dedicado: mcp.notion.com, mcp.sentry.dev, mcp.supabase.com.api.githubcopilot.com.Authorization.A documentação do Claude Code mostra estas formas exatas para Notion e Asana:
claude mcp add --transport http notion https://mcp.notion.com/mcp
claude mcp add --transport sse asana https://mcp.asana.com/sse
A única diferença está no valor de --transport e no caminho. O resto, incluindo o nome que você escolhe, fica a seu critério.
Como a URL pertence ao dono do servidor, a fonte mais confiável é sempre o próprio dono. Esta ordem economiza mais tempo.
Pesquise na documentação do provedor por "MCP", "remote MCP" ou "connectors". Os portais para desenvolvedores costumam ter uma página dedicada, muitas vezes com um botão de copiar ao lado do endereço. Essa página informa o sufixo /mcp ou /sse de forma explícita, então você não precisa adivinhar.
Alguns produtos mostram o endereço na sua conta. Uma página de configurações de integrações, conexões ou ferramentas para desenvolvedores pode listá-lo junto com os passos de configuração para cada cliente. Se a página exige login, isso é normal: muitos provedores vinculam a conexão à sua conta.
Servidores de código aberto se descrevem em um arquivo README. Procure uma seção chamada "Usage", "Installation" ou "Configuration". Se o README mostra apenas um command e um args, o servidor é somente stdio e não tem URL pública até que alguém o publique.
Diretórios públicos como o MCPservers.org mantêm listas de servidores MCP remotos e seus endpoints. Use-os para encontrar candidatos e depois confirme o endereço na própria documentação do provedor. Entradas de diretório podem ficar desatualizadas.
Se um colega já conectou o servidor, peça que ele rode claude mcp list ou claude mcp get <name> no Claude Code. Os dois comandos mostram como um servidor está configurado, e é aí que você pode identificar o endereço. Dentro de uma sessão em execução, o comando /mcp mostra o status de cada servidor.
Quando você tiver o endereço certo, a configuração leva menos de um minuto. Três caminhos servem para quase todos os clientes.
O Claude Code recebe um transporte, um nome e a URL:
claude mcp add --transport http <name> <url>
Para enviar um token em cada requisição, adicione um cabeçalho:
claude mcp add --transport http secure-api https://api.example.com/mcp \
--header "Authorization: Bearer your-token"
A maioria dos clientes também lê um arquivo JSON. Os nomes dos campos variam entre aplicativos, então confira a documentação do seu cliente, mas a estrutura fica próxima desta:
{
"mcpServers": {
"notion": {
"type": "http",
"url": "https://mcp.notion.com/mcp"
},
"local-files": {
"command": "npx",
"args": ["-y", "example-mcp-package"]
}
}
}
A primeira entrada é remota e usa url. A segunda é stdio e usa command. Mantenha um estilo por entrada.
Apps de chat com uma tela de conector personalizada geralmente pedem duas coisas: um nome e a URL. Cole o endereço, salve e conclua o pedido de login, se ele aparecer. Nada mais é necessário, porque o app encontra as ferramentas sozinho assim que a conexão é aberta.
A maioria das conexões que falham se resume a uma lista curta de causas. Verifique-as nesta ordem antes de mexer em qualquer outra coisa.
Um nome de host sozinho, como https://mcp.example.com, muitas vezes não basta. O cliente precisa do caminho exato do endpoint. Se aparecer um 404, copie o endereço de novo na documentação atual do provedor e compare caractere por caractere, incluindo a barra final.
A URL base de uma API REST comum não é uma URL MCP. Uma base como https://api.example.com/v1 atende requisições comuns e não fala JSON-RPC pelo transporte MCP. Se um provedor oferece as duas, a documentação as lista em páginas separadas. Nunca cole uma base de API em um campo chamado URL do servidor MCP esperando que as ferramentas apareçam.
Uma URL correta ainda falha sem permissão para usá-la. Os servidores respondem com 401 quando seu token está ausente ou expirado, e com 403 quando sua conta não consegue acessar aquele workspace. Faça login de novo pelo cliente ou atualize o Bearer token que você passa no cabeçalho Authorization.
💡 Dica: Mantenha os tokens fora da URL. Se um provedor pedir que você cole um segredo em uma query string, trate esse link como uma senha e nunca o compartilhe em capturas de tela ou tickets.
| Sintoma | Causa provável | Correção |
|---|---|---|
| 404 Not Found | Caminho errado, ou o provedor mudou o endpoint | Copie a URL de novo a partir da documentação atual |
| 405 Method Not Allowed | POST enviado a um endereço somente SSE, ou GET enviado a um somente POST | Teste o endereço /mcp ou troque o transporte para sse |
| 401 Unauthorized | Token ausente ou expirado, OAuth não concluído | Faça login de novo ou atualize o Bearer token |
| 403 Forbidden | Conta sem acesso àquele servidor ou workspace | Verifique o plano, o workspace e as permissões |
| Connection refused | Servidor local não está rodando, ou porta errada | Inicie o servidor e confira a porta |
| Erro de certificado | Certificado HTTPS autoassinado ou não correspondente | Use um certificado válido |
| Funciona em um só app | Suporte a transporte diferente | Ajuste o transporte (http ou sse) ao cliente |
Uma nuance evita muita confusão: a especificação permite que um servidor responda a um GET com 405 para indicar que não oferece um fluxo SSE naquele endpoint. Um 405 apenas num GET, portanto, nem sempre é uma falha.
A PicassoIA publica uma API para desenvolvedores em https://api.picassoia.com/v1. Ela usa endpoints no estilo Replicate, como POST /v1/models/{owner}/{name}/predictions e GET /v1/predictions/{id}, e autentica com um Bearer token que começa com pia_sk_. Esse endereço pertence à API REST. Ele não é uma URL de servidor MCP, então não o cole em um campo MCP.
As conexões MCP são gerenciadas na sua conta em picassoia.com/en/mcp/accounts, que exige login. A URL do servidor MCP não aparece nas páginas públicas, então comece por lá em vez de tentar adivinhar uma. Regras de plano se aplicam, então confira a página de preços para ver o que o seu plano inclui.
Quatro modelos estão disponíveis tanto pela API quanto pelo MCP:
As tarefas rodam de forma assíncrona: você cria uma previsão, consulta o status e depois busca o resultado. O limite é de 5 previsões simultâneas por conta, compartilhadas entre tokens e conexões MCP, com prompts de até 4.000 caracteres.
O modelo Claude Sonnet 5 lida bem com tarefas de programação e uso de ferramentas, o que o torna um segundo par de olhos útil para um arquivo de configuração. Aqui está uma rotina curta na PicassoIA:
💡 Dica: Trate a resposta como uma pista, não como um veredito. A documentação do provedor sempre prevalece quando as duas divergem.
GPT 5.6 Sol funciona da mesma forma, se você preferir uma segunda opinião.
Um servidor conectado só é útil quando você tem algo para construir com ele. Abra a Picasso IA, escolha PicassoIA Image ou Seedance 2.5 Lite, escreva um prompt descrevendo a cena que imagina e gere seu primeiro resultado em poucos minutos. Experimente uma foto para o seu próximo artigo, uma imagem de produto ou um clipe curto, depois refine o texto e execute de novo. A plataforma recompensa quem experimenta, então comece seu primeiro prompt hoje e veja o que suas próprias palavras podem produzir.
Escolha seu idioma
