You set up an MCP connector for one of Cloudflare's product servers a while back. You pasted in an /sse URL, signed in, and moved on. This morning the connector is dead. You are not a developer reading changelogs. You are the person who was handed a config and told it would work.
Here is what happened. On October 22, Cloudflare ended SSE on its product-specific MCP servers. The announcement was a two-paragraph changelog entry. Those servers now serve only /mcp. If a request goes to /sse, it comes back as 410 Gone, and the response carries the server's /mcp URL. According to the entry, that is a URL "which most MCP clients show in their connection error."
So the fix may be sitting right in the error you are looking at. You change your configuration from the /sse address to the /mcp one, using https://docs.mcp.cloudflare.com/mcp as the pattern. Because you originally signed in through /sse, you sign in again. If your connection was already on /mcp, nothing changes for you at all.
The post from APIs.io gives the entry credit for its choices, and says there is no vendor number to discount here. A 410 says the old address is gone on purpose, which a 404 does not. Putting the replacement inside the failure means the fix travels to the person holding the broken configuration. The post argues that matters more for an MCP client than for most API consumers, because the person configuring a connector is often not a developer reading changelogs. The cost is stated plainly too: re-authentication for anyone who came in through /sse.
There is one soft phrase, and it is the one that could catch you. The entry says "most MCP clients." If your client hides the error body, you are left with a dead connector and no hint, and the entry does not say which clients those are.
Then the post turns to the company's own record in the APIs.io catalog, and the finding is that this retirement does not map cleanly to one API page. Cloudflare has 651 API pages in the catalog. Only three carry MCP in their names, including the Cloudflare MCP Portal API, and those are portal surfaces rather than the product-specific servers the changelog names. So the retirement lands on a transport underneath the REST estate, not on any contract in it. The post calls that the useful finding in itself.
The measurements mostly agree with what you just saw. Cloudflare holds a Kin Score of 80.6, rated exemplar, and an Agent Readiness of 72.5, rated agent-native. The MCP server, error semantics, delegated identity, protected resource metadata and dynamic client registration dimensions are all lit. The post puts it this way: a clean 410 is what a lit error semantics dimension looks like in practice. The agentic access profile records 5,254 operations, 2,628 of them acting and 106 human-in-the-loop.
The catalog also files two weak spots against the same company. Contract governance is the lowest facet at 45.5, and the well-known catalog dimension is unlit. That second one connects back to your morning. A server that tells you where it moved is good, the post says, and a published catalog would let a client learn the address before it ever needs the error.
What you take away is practical. If a Cloudflare MCP connector of yours fails, look for the /mcp URL in the error, swap it in, and sign in again. If your client shows you nothing, go to the changelog entry and use the pattern it gives. And if you maintain connectors for other people, know that the 410 with a named successor is a good model, while the pointer you would most want, a catalog your client could read in advance, is still missing.
Read the original: https://apis.io/2026/10/30/cloudflare-retired-sse-with-a-410-that-names-the-way-forward/