Most of MCP servers and Apps are way under-designed today. A lot of MCP B2B servers still wrap legacy APIs, and most MCP Apps try to reproduce a website experience instead of trying to reinvent the experience from scratch.
It feels like we're in the early mobile years where companies have not figured out what to do with this new technology. I hope the Uber and Candy Crushes of the AI era will land in 2026! (well maybe not candy crush, but some IA native games would be nice)
Every week these model providers are coming out with new toys. I don't fault orgs for minimally investing in MCP when the space is moving so fast and there's no telling whether or not MCP is here to stay.
So management can cancel all of last week’s projects when they told us all we had to be using skills because the CEO read about them in the in flight magazine. Routines are the future, baby. DevOps already made a big announcement that they’re centralizing the Routines Hub. If you can’t keep up, we’ll get someone who says they can.
This is the new challenge. Every vibecoder is larping as a SWE and rewriting systems left and right when all they need is a new feature or two. 6000 line PRs that could be 60. The challenge in the current era is evolving existing systems to ensure they meet previous requirements in terms of capabilities and performance. This is the new role of the SWE. Same as the old role, but with less typing.
They are mass copying any idea they see out there. They are not happy enough being a platform, they want to be everything. Their dream is to be the one AI that eats it all. It's so stupid that folks are using their system. I will never get on board with a platform that competes with me or try to compete with me. They are the Microsoft of AI model providers.
you're telling me dispatchagents.ai :) (open to new names if anyone has cool ones, didn't expect anthropic to start using dispatch with their agents, naming is way too hard)
Just wait for the new wave of github issues about things they silently broke or degraded.
Progress, I guess :)
(I had the most hilariously bad session with Sonnet 4.6 today. I asked it a reasonably simple question and linked to resources, it refused to fetch the resources, didn't ask for pdf/txt I could provide, and confidently printed absolute BS, barely in the same category but completely unrelated.
I called it off pointing the idiocy, asked if it wants more data, and requested the hallucination be fixed.
It apologised profusely and hallucinated even worse.
Maybe I'll try Opus 4.6 tomorrow because frankly Gemma-4-E4B was more coherent than that....
> In the Desktop app, click New task and choose New remote task; choosing New local task instead creates a local Desktop scheduled task, which runs on your machine and is not a routine.
Just wait until they get into the phase where they're big enough that they're eating all the baby startups and have to pick winners and losers amongst the myriad of overlapping features while also having the previous baby startups they acquired crank out new features.
"MCP is less discoverable than a CLI" -> not true anymore with Tool_search. The progressive discovery and context bloat issue of MCP was a MCP Client implementation issue, not a MCP issue.
"MCPs needs to be wrapped to be composed." -> Also not true anymore, Claude Code or Cowork can chain MCP calls, and any agent using bash can also do it with mcpc
"MCPs needs to implement stateful behavior, shell + cli gives it to you for free." -> having a shell+cli running seems like a lot more work than adding a sessionId into an MCP server. And Oauth is a lot simpler to implement with MCP than with a CLI.
MCP's biggest value today is that it's very easy to use for non-tech users. And a lot of developers seem to forget than most people are not tech and CLI power users
Just to poke some holes in this in a friendly way:
* What algorithm does tool_search use?
* Can tool_search search subcommands only?
* What's your argument for a harness having a hacked in bash wrapper nestled into the MCP to handle composition being a better idea than just using a CLI?
* Shell + CLI gives you basically infinite workflow possibilities via composition. Given the prior point, perhaps you could get a lot of that with hacked-in MCP composition, but given the training data, I'll take an agent's ability to write bash scripts over their ability to compose MCPs by far.
I don't see a reason a cli can't provide oauth integration flow. Every single language has an oauth client.
> - generalistic IA assistants adoption. If you want to be inside ChatGPT or Claude, you can't provide a CLI.
This is actually a valid point. I solved it by using a sane agent harness that doesn't have artificial restrictions, but I understand that some people have limited choices there and that MCP provides some benefits there.
Same story as SOAP, even a bad standard is better than no standard at all and every vendor rolling out their own half-baked solution.
Oauth with mcp is more than just traditional oauth. It allows dynamic client registration among other things, so any mcp client can connect to any mcp server without the developers on either side having to issue client ids, secrets, etc. Obviously a cli could use DCR as well, but afaik nobody really does that, and again, your cli doesn't run in claude or chatgpt.
Stateful at the application layer, not the transport layer. There are tons of stateful apps that run on UDP. You can build state on top of stateless comms.
It feels like we're in the early mobile years where companies have not figured out what to do with this new technology. I hope the Uber and Candy Crushes of the AI era will land in 2026! (well maybe not candy crush, but some IA native games would be nice)
reply