Registry entry `dev.continue/docs` points at a docs-site path, not an MCP server

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"}}}'
# 405

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 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.

Start by running the supplied curl against https://docs.continue.dev/mcp and inspect the registry definition for dev.continue/docs. Confirm whether a deployed MCP endpoint exists; done means the entry points to a working endpoint or is withdrawn, with the registry check passing.