thoughts on why mcp didn’t work, what’s next

mcp came out when the best models were sonnet 3.5 and GPT 4o

not a lot was known about how to properly work with these tools yet, we were still incredibly concerned on models having access to tools, context bloat, etc

in turn we got a bunch of mcp servers that were basically useless, for example the vercel mcp server only had ~7 tools at launch, couldn’t really do much, and there was a lot of security paranoia so companies locked down who can call it

around feburary claude code came out and with that people realized “oh lets just give the agents a bash tool”, giving the agent a bash tool let them chain commands, filter output, and dynamically install CLIs

there was a realization the less tools you have, the better the model does - although this isn’t actually true. think about how many “tools” the github cli contains, it’s thousands, especially when you consider that the model can call the api directly via gh api

compare the experience of using mcp to using a cli, you can just tell the agent “hey install this CLI” and immediately start using it. most harnesses that support MCP require you to fully restart the client to call it which is a ton of friction to put on the user. bash benefitted from 37 years of incredible development on amazing primitives, mcp implementations were mostly vibe coded in a month.

mcp is in a weird state now. back to the vercel example, to their CLI they’ve shipped vercel api that gives your agent the full api to call anything. this is great, however, their MCP is only at 20 tools now most of which are read only. along with that, there’s only ~16 allowed clients who can integrate with it, this makes no sense when you have a CLI that people are running in dangerously skip permissions!

so should we just embrace CLIs? i’d push back on this a fair amount. most CLIs are literally just wrapping APIs and that’s it. by making a good CLI auth flow but not API auth flow, you’re introducing a ton of statefulness into the equation. an agent that is just reading emails should not have to spin up an entire container to run the google workspace cli when lazy tool loading or code mode works.

another thing on CLIs is not understanding the action space of a CLI. you can trivially convert from an MCP to a CLI, you cannot convert from a CLI to an MCP in that same way. CLIs also don’t have the same annotations the MCP or OpenAPI specs do around what actions are destructive, although LLMs are getting good enough that this doesn’t matter as much

myths that surround MCP today:

lots of tools bloat context

for a poorly implemented client this is true, but most clients have lazy loading implemented by now and the model can just discover the tools.

poor support of the spec

i’ll have another article coming on this but you can work around most of the MCP spec being unsupported by being creative. there’s a chicken and egg problem to be solved

auth sucks

sort of, some clients have poor support and need to improve it but in Claude Code I never get signed out and it works great

we should just be calling the APIs directly

yes i agree! i literally started a company (executor.sh) partly based on this. our harnesses should not care what we are trying to integrate with. MCP, CLI, API, GraphQL, all of it should be supported and agents can call it all.

this is the beauty of what Executor, is it doesn’t care what you bring just that it can get it into a catalog of tools

do we have to commit to MCP? i’ll leave that up to the teams building the harnesses like Codex, Claude Code, OpenCode, etc. If you guys can all get together and propose a spec that will get adoption as strong as MCP has (basically ever client supports it at this point) then it’d be great, however from my perspective the broad adoption of MCP has solved the hard part and now we just need to push through to make it good.

i’m personally really excited about the future of MCP. stateless elicitation is awesome, more clients adopting codemode is great. MCP apps have a ton of potential for unlocking new interaction patterns over the next 6 months. skill loading through MCP is also going to be excellent for providing context with remote sources on how to call them

the world i’d like to end up in is one where all companies support CIMD OAuth to their MCP server and their OpenAPI spec. the OpenAPI spec is able to be used for raw data access, bulk processing, and the MCP is able to provide a more curated experience with maybe a api tool similar to how the CLIs of Vercel and GitHub feel

some closing thoughts:

• plugins are bad and should be avoided, it’s creating a bunch of lock in and portability problems which will lead to closed ecosystems

• this technology is incredibly new and it’s easier to be a critic than a player, mcp overall has done an incredible job at driving adoption

• most MCP servers could just be direct calls to an API, the same way most CLIs could just be direct calls to an API