GoKawiilWe've started offering an MCP Server for our main $WORK tool. It's been fun, like a weird intersection between deterministic and non-deterministic worlds Despite the fact that MCP is an utterly terrible attempt at a "specification", we have hit one annoying issue: customers keep on reporting the MCP server is not working.
The reason is simple and it shows the friction between devs vibe-coding a spec and real-world users actually onboarding: if you open mcp.acme.com/mcp in a browser you get a big fat 401 and a raw JSON blob saying Unauthorized. (If authentication isn't required, adjust accordingly.)
This is a pain because users open the link, see the error, and immediately drop a support ticket saying the link isn't working. It's not working though because they need to paste it into their client of choice, but no-one thinks that far ahead. The (annoying) solution is to package our server up into a connector/plugin and release it for each and every LLM client out there. This is slow, painful, and a never ending game of whack-a-mole as we have a lot of customers starting to make their own clients embedded within their orgs.
Instead, I did something a little bit hacky: if the request is for GET /mcp and the Accept header includes text/html and NOT application/json or text/event-stream , I return a HTML page explaining to the user they're trying to view an mcp server and they need to add it to their client.
And this has worked wonders!
Number of tickets has dropped off a cliff, CS is happy, customers are getting setup a lot more quickly, and I don't have to explain that not all errors are errors. Wins all 'round, and no impact from what we can observe.
I wish the spec had some capability to mitigate for this but alas, like all things in this AI-era, it's a case of move fast and hope the AI can fix bugs faster.