This feels like less of a hack and more of discovering what some of the HTTP headers are for. You’re choosing rather reasonably how to present the resource found at /mcp when a client is asking for the resource to be presented in HTML format. It’s perfectly fine to offer an HTML response that says “hey this is not really presentable in HTML. Do this instead.”

The specification still leaves a lot to be desired, especially as it relates to auth. There are lots of bad ways to do auth with MCP and only a couple of good ways. It also puts a lot of pressure on the various IdP vendors and relies on lesser used areas of OAuth 2.0/2.1 (like DCR, token exchange, etc.). It started out in a place where the assumption was you were running an MCP Server on a laptop or you were a SaaS provider serving lots of individual users -- somehow DCR in the initial spec iteration seemed like a good idea (spoiler: it wasn't) and fortunately, the latest revision has somewhat addressed that. XAA/ID-JAG & CIMD should continue to round-out some client management and auth solutions for the enterprise.

Gateways are another area that needs to be addressed in the spec. There isn't a formal definition of one in the spec, and yet, there are lots of "gateways" out there. What a gateway is and what it should do is an open question and it means different things to different people depending on who you ask. For example, who does token exchange: the MCP server or the MCP gateway? Both are valid answers right now depending on the implementation or your opinion of which is best.

More spec iterations should be coming this year. I'm still pretty optimistic about MCP as a whole, as it remains a good way to standardize tool calls across agents and some of the other entities that it provides like resources and prompts are genuinely useful to add more determinism to an agent. Interceptors and skills will be good, too.

If you're interested in helping to evolve the spec further, the MCP Contributors Discord is active. There are lots of IGs/WGs that solicit feedback and you can participate in meetings with your feedback.

"Sorry, you have been blocked

You are unable to access hybridlogic.co.uk

Why have I been blocked?

This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data."

I think this probably also helps when truly clueless users drop the link into an agent directly, because then the agent will relay the message to the user.

Is this not the intended use of request headers?

Spec-based implementations of OAuth 2.0/2.1, including dynamic client registration and token exchanges, are absolutely necessary on a large scale but are an enormous barrier for adoption during early deployments. Cookie tricks ignore the spec and produce special cases when client credentials need to be rotated.

Solution in the real world: configure the server to provide the WWW-Authenticate header with value "Bearer" on unauthorized requests, issue limited-scoped tokens, leave the rest up to mcp-remote. The client authenticates once, uses bearer token in its requests, server verifies against scopes. No dynamic client registration required.

The authentication solution becomes clearer if you distinguish between "what the spec allows" and "what you need in your deployment." Not many servers really require OAuth on day 1.

I once worked for $COMPANY and we had a network scanning application. Always generated a lot of tickets from angry people wanting to scream about bots.

So we put a web page page on each worker that would inherit some details from whatever job was running, and say “I’m a $TYPE_OF_SCANNER FROM $COMPANY doing $THING_THAT_BENEFITS_YOU.

This behavior is covered by our terms of service page at $LINK.

If you believe that we should not be doing this, please contact $SUPPORT and provide this code:

$SCAN_JOB_IDENTIFIER”

Call volume and unhappy customers went way down.

You can still keep using Rest API with swagger docs and tell the AI to read the swagger docs. It's the same thing. The entire Rest API specification is a lot more flexible than the JSON RPC format /mcp uses.

In fact, this is how Kubernetes APIs work. Even the CLI asks YAML or JSON content type when `-o yaml` or `-o json` is specified.

Also, some other sites (albeit sometimes looking at the User-Agent header, hence more hacky) also doing the same. For example `ipinfo.io` returns HTML page when opened in a browser but a JSON (prettified) when requested via cURL.

Can I just say that anybody involved with MCP's launch should be ashamed of what they put out there. I understand tool calling. I understand specs. I read MCP's "spec" and I used useless word salad that alternates between baby's first wire format and pie-in-the-sky marketing speak. Several of the navigation links I encountered were broken.

Poorly thought out, poorly communicated, but it's the only thing out there that 1) meets the need, and 2) published by people with a huge amount of reach. Right place, right time, shit effort. So it gets adoption. Like the history of PCs, of the internet, or everything, I guess. Worse truly is better.

I like their solution. It feels like because remote MCP servers are built on HTTP that they are actually using the spec as intended. Serving html when asked for it.

Isn't this literally against the entire point of MCP