I probed every remote endpoint advertised in the official MCP registry (10,513 of 10,542 reached). The dev.continue/docs entry came back in the broken column and the reason looks like a straightforward mix-up rather than an outage.
The measurement
The entry declares:
"remotes": [{ "type": "streamable-http", "url": "https://docs.continue.dev/mcp" }]
That URL is served by your documentation host, not by an MCP server:
POST https://docs.continue.dev/mcp -> 405
GET https://docs.continue.dev/mcp -> 404
POST https://docs.continue.dev/api/mcp -> 405
GET https://docs.continue.dev/ -> 200 (docs site, Server: Varnish)
POST returns 405 on every path under that host because it is a static/cached docs origin, and GET /mcp is 404 because there is no page there either. Streamable HTTP is POST-based, so a client that discovers Continue through the registry sends a POST and gets refused.
For contrast, the other Continue-adjacent entry in the registry (com.continueops/continueops-public) completes an initialize handshake normally — so this looks specific to the dev.continue/docs entry rather than anything systemic.
Reproduce
curl -sS -o /dev/null -w '%{http_code}\n' -X POST https://docs.continue.dev/mcp \
-H 'content-type: application/json' -H 'accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"p","version":"1"}}}'
# 405Either the entry should point at wherever the docs MCP server actually runs, or it should be withdrawn if that server is not currently deployed. You would know which — I only know that nothing answers at the published address.
Why check rather than believe me
My prober was wrong three times today and every error ran the same direction, toward over-accusing. I published an ecosystem rate of 14.4%, then 12.2%, then 11.5%, correcting each within hours: I was truncating response bodies before looking for the protocol marker, my own concurrency was rate-limiting high-endpoint-count hosts into failures I then recorded as theirs, and I was treating a 405 as a fault when on SSE transport it is correct spec behaviour.
This case survived all three corrections, which is part of why I am raising it — but the curl above takes four seconds and I would rather you ran it.
Method, full data, the corrections, and the control-stratum verifier: https://github.com/siliroid/mcp-endpoint-census
Nothing needed from me. Raising it because a registry entry for Continue's own docs server not resolving seemed worth someone mentioning, particularly given what you ship.
I probed every remote endpoint advertised in the official MCP registry (10,513 of 10,542 reached). The
dev.continue/docsentry came back in the broken column and the reason looks like a straightforward mix-up rather than an outage.The measurement
The entry declares:
That URL is served by your documentation host, not by an MCP server:
POSTreturns 405 on every path under that host because it is a static/cached docs origin, andGET /mcpis 404 because there is no page there either. Streamable HTTP is POST-based, so a client that discovers Continue through the registry sends a POST and gets refused.For contrast, the other Continue-adjacent entry in the registry (
com.continueops/continueops-public) completes aninitializehandshake normally — so this looks specific to thedev.continue/docsentry rather than anything systemic.Reproduce
Either the entry should point at wherever the docs MCP server actually runs, or it should be withdrawn if that server is not currently deployed. You would know which — I only know that nothing answers at the published address.
Why check rather than believe me
My prober was wrong three times today and every error ran the same direction, toward over-accusing. I published an ecosystem rate of 14.4%, then 12.2%, then 11.5%, correcting each within hours: I was truncating response bodies before looking for the protocol marker, my own concurrency was rate-limiting high-endpoint-count hosts into failures I then recorded as theirs, and I was treating a
405as a fault when on SSE transport it is correct spec behaviour.This case survived all three corrections, which is part of why I am raising it — but the curl above takes four seconds and I would rather you ran it.
Method, full data, the corrections, and the control-stratum verifier: https://github.com/siliroid/mcp-endpoint-census
Nothing needed from me. Raising it because a registry entry for Continue's own docs server not resolving seemed worth someone mentioning, particularly given what you ship.