Ferramenta gratuita

Testador MCP SSE

Verifique se o seu servidor MCP realmente responde no transporte HTTP+SSE, e se isso ainda basta para os clientes que importam para você.

Funciona com endpoints Streamable HTTP e SSE, por exemplo https://mcp.example.com/mcp
Este servidor exige autenticação
Usado apenas nesta requisição e nunca armazenado.

Funcionar não é a mesma coisa que ser vendável

Com o transporte resolvido, resta o problema de ninguém ver o que o seu servidor faz. O MCP Showcase transforma a mesma URL em um playground ao vivo com documentação para cada ferramenta.

Como funciona

link
Cole o seu endpoint SSE

Normalmente o caminho terminado em /sse, embora os servidores o montem em lugares variados.

play_circle
Conectamos como um cliente conecta

Streamable HTTP primeiro, depois SSE, e o resultado diz qual realmente respondeu.

checklist
Veja o que o transporte suporta

Handshake, versão do protocolo e a lista completa de ferramentas, além do log bruto de requisições.

O que HTTP+SSE é de fato

O transporte HTTP original do MCP. O cliente abre um fluxo Server-Sent Events de longa duração para receber as mensagens do servidor e envia as suas por POST em um endpoint separado. Dois endpoints, um sentido cada. Funciona, e é tão incômodo atrás de proxies e balanceadores quanto se imagina.

Cole o seu endpoint acima e nós conectamos do jeito que um cliente de verdade conecta — Streamable HTTP primeiro, depois SSE — e dizemos qual realmente respondeu.

Por que um servidor só-SSE pode sumir de um cliente

Esta é a falha que vale entender, porque ela não produz nenhuma mensagem de erro. Os clientes atuais tentam Streamable HTTP primeiro, e nem todos recorrem ao SSE. Um servidor que só fala SSE simplesmente não está ali para aquele cliente: ele relata um servidor vazio ou nada, em vez de uma falha de transporte. Nada nos seus logs vai parecer errado, porque nada chegou até você.

Se o seu servidor aparecia em um cliente e parou depois de uma atualização, é a primeira coisa a verificar.

Você deveria migrar?

Se você controla o servidor, sim. Streamable HTTP é um endpoint em vez de dois, reconecta de forma limpa e é onde o ecossistema chegou. Suporte os dois enquanto tiver usuários em clientes antigos e depois abandone o SSE. Se você não controla o servidor, esta página pelo menos diz com qual transporte você está lidando antes de começar a depurar o seu cliente.

Ferramentas relacionadas

O transporte não é a parte difícil

Depois que um cliente consegue alcançar o seu servidor, resta o problema de ninguém conseguir dizer o que ele faz. Uma lista de ferramentas não é uma demonstração, e um prospect não vai instalar um cliente para descobrir. O MCP Showcase aponta para a mesma URL e produz um playground ao vivo com documentação gerada para cada ferramenta, para que avaliar o seu servidor custe um clique.

Perguntas frequentes

O transporte HTTP original do MCP: o cliente abre um fluxo Server-Sent Events de longa duração para receber mensagens do servidor e envia as suas por POST em um endpoint separado. Foi substituído pelo Streamable HTTP, que faz as duas coisas em um único endpoint.

Foi substituído, não removido. Muitos servidores ainda falam apenas SSE e muitos clientes ainda o suportam, mas os clientes mais novos tentam Streamable HTTP primeiro e alguns já não recorrem ao SSE. Por isso um servidor só-SSE pode sumir em silêncio de um cliente que antes o via.

Quase sempre por causa do comportamento de fallback. Um cliente que tenta Streamable HTTP e não recorre ao SSE não encontrará nada em um endpoint só-SSE, e normalmente vai relatar isso como servidor vazio em vez de falha de transporte.

Se você controla o servidor, sim: um endpoint em vez de dois, reconexões mais limpas, e é o que os clientes atuais esperam. Suporte os dois durante a transição se tiver usuários já existentes.

Este testador informa explicitamente no resumo do resultado, junto com a versão do protocolo negociada. O log de requisições abaixo mostra as chamadas reais se você precisar ver por que uma falhou.

Mais ferramentas MCP gratuitas