It seems like the core value add of MCP as described here is text only documentation for an API, as opposed to the human standard of HTML-like docs. Is that ro

It seems like the core value add of MCP as described here is text only documentation for an API, as opposed to the human standard of HTML-like docs. Is that roughly accurate? We are talking about a technology that would allow SaaS API vendors to publish a second set of documentation (or adapt the same one to both human and LLM targetted channels)? I'm being a bit cynical, but here's my minimal naïve alternative solution, not proposing it be used, but just saying that this would be equivalent: 1- Publish a well known endpoint like /docs_url , which could return something like "docs.domain". 2- Support an alternative content-type header, where instead of 'text/html' the client could ask for 'text/plain', or 'text/markdown' 2b- Alternatively, changing the extension type could achieve the same result, where requesting docs.domain/endpoint.txt would return the docs in text instead of in html So now I ask, how is MCP better than the solution I proposed? Did I grossly misunderstand something? Or am I on track to avoiding hundreds of engineering hours due to accidental complexity by recognizing and avoiding a privately funded protocol that serves to increase vendor lock instead of reducing complexity of our systems?