Let me take the other position in this comment: I also see that how MCP works really helped its quick adoption. Because you could just build a local MCP server as a proxy around existing APIs and functionality, there is no need to touch anything existing. And MCP often starts as "MCP Server" that is basically a software artifact that you'd just configure and run - often locally. I don't think that just doing REST or extending existing REST APIs wouldn't have delivered this part of the MCP success story.

But now that many companies focus on MCP as a remote API, the question obviously comes up why not just use standard API protocols for that and just optimize the metadata for AI consumption.

Is this not what https://www.utcp.io tries to solve?

What MCP should have been.

I find it odd that a language model gets communicated to in JSON. Hardly the most natural language

What bothers me about MCP is that there is not even a standard way to describe an entire MCP server in a single JSON file. Like OpenAPI for REST. This makes exchanging metadata and building catalogs unnecessarily unstandardized.

The article also mentioned that OpenAPI is too verbose: I totally see that, but you could optimize this by stripping an OpenAPI file down to the basics that you need for LLM use, maybe even using the Overlay spec. Or you convert your OpenAPI files to the https://www.utcp.io format that pylotlight mentioned.

Some "curation" of what's really relevant for AI consumption may be a helpful anyway, as too many tools will also lead to problems in picking the right ones.

As someone not familiar with MCP, so the tool definition is just the request spec and resource definition is just the response?

Then I have the same question with the article, why do we need this standard? If it's just to let the LLM know to call the tool in JSON format