alt Hacker NewsAll of these things are perfectly possible with a plain REST API with an Open API spec and using some standard auth options, and an AI client that implements a reasonable “make api request tool” (just like the AI clients implement MCP today).
I think the real value of MCP is that it allowed companies to say “we’re doing AI!” When they built an MCP server. Just saying “use our api” was a lot less exciting.
Giving it a different name probably also helped cut through politics at companies where non-technical people didn’t want to open up user data with an API, but they did want to do AI.
Replies
> For a while it also felt like MCP was a convenient answer for companies that were under pressure to have “an AI strategy” but didn’t really know how to do that.
MCP was a convenient answer for companies that had spent the last few years shutting down APIs because allowing API access bad.
Pretty much, MCP is still a bad idea.
LLMs perform significantly better and faster when you strap them to plain old apis/and an open api spec with a search tool.
My current MCP design is… grab a fastapi spec shove it into fastmcp, shallow wrapper, search tool for the full schema.
Oh boy so exciting I just wrapped an api spec for no reason and have to host infra for the translation layer. If only we invented api gateways.
But I am Mr. AI now.
it's mostly true but the mcp also installs the knowledge of that REST API in a standard way so that a user can ask "what's projected revenue this month?" and it'll know how to hit your company brain and answer
Hah, I made that same point last December: https://simonwillison.net/2025/Dec/31/the-year-in-llms/#the-...
> For a while it also felt like MCP was a convenient answer for companies that were under pressure to have “an AI strategy” but didn’t really know how to do that.
I've since come back to MCPs, because I want to build my own agents without first having to solve the problem of effectively sandboxing Bash.