*gets up on soap box* With the announcement of this new "code mode" from Anthropic and Cloudflare, I've gotta rant about LLMs, MCP, and tool-calling for a second Let's all remember where this started LLMs were bad at writing JSON So OpenAI asked us to write good JSON schemas & OpenAPI specs But LLMs sucked at tool calling, so it didn't matter. OpenAPI specs were too long, so everyone wrote custom subsets Then LLMs got good at tool calling (yay!) but everyone had to integrate differently with every LLM Then MCP comes along and promises a write-once-integrate everywhere story. It's OpenAPI all over again. MCP is just a OpenAPI with slightly different formatting, and no real justification for doing the same work we did to make OpenAPI specs and but different MCP itself goes through a lot of iteration. Every company ships MCP servers. Hype is through the roof. Yet use of MCP use is super niche But now we hear MCP has problems. It uses way too many tokens. It's not composable. So now Cloudflare and Anthropic tell us it's better to use "code mode", where we have the model write code directly Now this next part sounds like a joke, but it's not. They generate a TypeScript SDK based on the MCP server, and then ask the LLM to write code using that SDK Are you kidding me? After all this, we want the LLM to use the SAME EXACT INTERFACE that human programmers use? I already had a good SDK at the beginning of all this, automatically generated from my OpenAPI spec (shout-out @StainlessAPI) Why did we do all this tool calling nonsense? Can LLMs effectively write JSON and use SDKs now? The central thesis of my rant is that OpenAI and Anthropic are platforms and they run "app stores" but they don't take this responsibility and opportunity seriously. And it's been this way for years. The quality bar is so much lower than the rest of the stuff they ship. They need to invest like Apple does in Swift and XCode. They think they're an API company like Stripe, but their a platform company like an OS. I, as a developer, don't want to build a custom chatgpt clone for my domain. I want to ship chatgpt and claude apps so folks can access my service from the AI they already use Thanks for coming to my TED talk

Nov 7, 2025 · 10:23 PM UTC

Replying to @stevekrouse
this is the tech tweet of the year imo
1
4
🥹 thank you!
3
Replying to @stevekrouse
fcking agree 100% ive been thinking of this too yes i can build my own clone, but whats the point? just utilize the reach of chatgpt or claude and let me ship inside as an app been exploring lots of chat apps sdk in chatgpt usecases, so freaking fun
day 3/30 of @OpenAI chat apps with @Cloudflare @RedwoodJS MCPUI 🚀 petting dewey the cat in chatgpt, cause i dont have a cat in real life 😿 showing a single widget with picture in picture calling diff tools to pet + scratch dewey chatgpt cat is better than real cat😽
1
4
Replying to @stevekrouse
imo, there is a major difference between MCP/tool calls and code-mode with code mode control logic can be written once and then eval'd on the client. for multi-step processes it can significantly speed & and simplify. .... BUT that doesn't take away from your main point: "The central thesis of my rant is that OpenAI and Anthropic are platforms and they run "app stores" but they don't take this responsibility and opportunity seriously. And it's been this way for years. The quality bar is so much lower than the rest of the stuff they ship." 💯 My assumptions is that it is a mix of needing to iteratively figure out what it means to have an app store (features, business, integrations, ...) - and a software dev process that doesn't fit When OpenAI launched codex (web) bragging about how it was dramatically changing every day for the last couple weeks (by using the tool) - it showed. The web ui was (and still is) a mess. Many features didn't work if you deviated from the golden path. (a canonical example of vibe coding)
1
7
Replying to @stevekrouse
TBH i'm surprised by how slowly/quickly they all seemed to realize MCP was a mistake. There was so much critique of MCP a year ago, but everyone raced to announce support so it effectively became a standard. Unfortunately, none of them were particularly useful so it became kinda easy to dump the standard too.
6
Replying to @stevekrouse
We have been thinking about this a lot at Metorial. First of all, MCP is a horribly designed protocol and it took us months to write a platform that fixed all its faults. Our implementation is MCP compatible but not even real MCP. Code mode as a next step makes no sense and it shows that these people have not talked to a single enterprise about their actual needs -- you need permission control, observability, OAuth configs, scopes for particular IP addresses, etc. that can be shared across an organization.
6
Replying to @stevekrouse
we keep building abstraction layers on top of abstraction layers when LLMs just wanna write code function calling was literally "hey can you return JSON pls?" and now we're writing schemas for the schemas sometimes the simpler solution is just letting it do what it was trained to do
1
1
Replying to @stevekrouse
You have a point. The dev churn is real, but I think both can coexist remembering that MCP was developed before models could write SDK code reliably: MCP handles distribution and discovery (installable apps like connectors exposing capabilities), while code mode handles just pure execution (models generate code using auto-generated SDKs from MCP schemas). MCP then is more of a packaging layer and you get both ecosystem benefits and composability.
Replying to @stevekrouse
preach. unfortunately there’s just no incentive for the labs to be good at platform thinking. it’s not obvious there’s a huge revenue opportunity. once there is - like say apps SDK hits - you’ll see better formats solidify & a bunch of frustrated engineers hired to clean it up
2
Replying to @stevekrouse
This is justified. Tool calling and code gen are fundamentally the same thing to an LLM because it's either generating functions as code or functions as tool calls. All that matters is how reliably, for as few tokens as possible
Replying to @stevekrouse
imo removing statefulness and making MCP just POST per endpoint would make it a lot better through simplification and throw in types like @headinthebox has been preaching
1
Replying to @stevekrouse
One thing I have also trouble understanding is that most of the MCP servers are just some lightweight shims or proxies that you need to run on your local system and they are distributed like they were some packages. Like why, if they are servers, just host them like an API.
4
Replying to @stevekrouse
Totally agree. Codex love to write python scripts to edit files. It may well just write scripts to use the battle tested SDKs and APIs for services.
Replying to @stevekrouse
Imo a big part of what you're missing here is how rapidly models have been improving. A lot of emergent model behavior takes time to understand and is almost impossible to reliably predict. When MCP first launched, models had barely started writing good code. Tab complete was still the primary way most people used AI and Claude Code was not a thing. Fast forward to today and it's a completely different world. Hindsight is a funny thing
11
Replying to @stevekrouse
You had me until "like XCode"
2
Replying to @stevekrouse
They’re* Otherwise agree!
Replying to @stevekrouse
This! At the current stage, MCPs are just standardised APIs. Also, most MCP servers are poorly designed. There is little incentive for smaller companies or developers to additionally develop and maintain quality MCP servers.
Replying to @stevekrouse
they are doing the right thing. What actually changed is that they now use code instead of xml with json inside. MCP is still needed to define schemas and methods. Any random SDK would be way to complex
Replying to @stevekrouse
excellently written. I was reading that Anthropic blog from last week and my only response was “wtf man”
1
Replying to @stevekrouse
Should have just given the LLM access to your GraphQL API.
1
Replying to @stevekrouse
To be fair, we still need a protocol for remote/out of proc uses so MCP isn’t a total loss.
1
Replying to @stevekrouse
curl is the end state.
16
Replying to @stevekrouse
Writing code is the end state. Mcp is dogshit. Codeact is all we have ever needed for agents.
1
Replying to @stevekrouse
the famously developer friendly xCode 💀
Replying to @stevekrouse
OpenAPI is convoluted and incomplete By trying to please everyone, it pleases nobody. MCP is: - Simpler - OpenAPI-compatible - Attached to the service itself (genius) - Only one concept: Typed Functions - Gonna take over the Web
Replying to @stevekrouse
With MCP, Anthropic solo-pushed it and Google/OpenAI dragged their feet on supporting it until the hype got too big and it was basically a fait accompli. Unless labs coordinate, which they seemingly don’t, seems like the first-mover advantage fears prejudice platform building
Replying to @stevekrouse
the churn benefits whoever the leader is — they keep spitting out new formats and everyone else is always wasting their time catching up
Replying to @stevekrouse
Do you know what it does to people like us building for enterprise? We stop taking such innovation seriously. Impossible to get the review board to agree to changes like this without losing your credibility
MCP as it is diverges too much from the ethos of LSP, its inspiration. If MCP really was a protocol for context control, it would be able to allow things like “replace all previously generated code blocks with optimized versions” or “use your ctx to be a video editor program”
2
Replying to @stevekrouse
We’re all just figuring it out together. I find it exhilarating 🤷‍♂️
Replying to @stevekrouse
The big unlock of MCP isn't standardizing APIs, it's standardizing auth for M-to-N networks, which OpenAPI doesn't yet do well enough. But it could.
The big advantage of MCP over OpenAPI is that it is very clear about auth. OpenAPI supports too many different auth mechanisms, and the schema doesn't necessarily have enough information for a robot to be able to complete the auth flow.
10
Replying to @stevekrouse
So funny but true. Since people wrote all of these tools we are exploring SDK generation from MCP but OpenAPI has been here all along MCP is still good for distribution if MCP clients are adopted by businesses Definitely need OpenAI/Anthropic to build out the marketplace well
2
Replying to @stevekrouse
in retrospect, it seems obvious that LLMs trained on human behavior are good at behaving like humans
1
Replying to @stevekrouse
I assume people who are Anti-MCP are the type of people who dont turn lights and other unused electronics off to save power.
1
Replying to @stevekrouse
TLDR?
Listen to our new Christmas EP - BEGOTTEN SON
54
3
836