It has been about a month since the largest revision to the MCP spec since the protocol launched, and as I talk to some of our largest enterprise customers, I wanted to give an honest read on what’s actually changed.
I’ll start with the prediction I made before the spec shipped. I said this release would be the last time I would have to defend MCP as the right way for agents to talk to the business systems where work actually happens (Salesforce, Workday, GitHub, etc.). By and large, that has happened. I have not had a single conversation in weeks where someone asked me whether MCP is the right protocol, or whether they should reach for a CLI instead. That argument is settled.
To build or not to build with MCP is a dead question. The conversations now are about how to build well.
Stateless made scalable servers the default
The new spec made a singular bet on stateless over stateful, and that one decision has already done a lot to clean up the architecture and clear up confusion.
When session IDs went away, the question of how you scale a server stopped being a puzzle every team had to solve on its own. We are seeing people build servers correctly now, in a real, scalable way, mostly by default. Any request can land on any instance. You do not have to stand up a session store and babysit it just to run one server for 10,000 employees.
This increase in MCP server quality, at scale, is not a small thing. It’s the ecosystem maturing.
Long-running tool calls finally work
The win I did not expect this early came from tasks. Using tasks for long-running operations, we have been able to run tool calls that take real time to finish without locking up the agent while they run. That was painful to do before, and often not possible at all. Long-running, non-blocking tool calls open up work that used to be off the table, like an agent running a large data migration, a deep research pass across dozens of sources, or a workflow that waits on a human approval, all while the rest of its work keeps moving.
What I’m watching over the next two releases
The work developing MCP is far from done. Three potential future additions that I’d love to see instituted:
Skills that distribute remotely
Everybody has been adopting agent skills over the last few months, and for good reason. Teams are turning their repeatable workflows — how finance closes the books, how support triages a ticket, how a rep researches an account — into skills an agent can run on demand.
Inside Arcade.dev, we have built skills for nearly every department and function we run. But they are still managed locally, as files on someone’s machine, and that becomes a pain the moment you want a team or a company to share them.
MCP is converging toward making skills part of the protocol so they can be distributed remotely. That is exactly what enterprises need, and it’s the natural next step.
Triggers and bi-directional communication
Say you want an agent to alert you the moment a client emails you back. Today, there is really no clean way for an MCP server or a subsystem to reach back into Claude, wake it up, and alert you that something you were waiting for just happened. Currently, everything has to originate from inside the agent, which ultimately just isn’t efficient.
There are active conversations in the community about solving this with bi-directional communication, and when it lands, a lot of new use cases come with it.
Workload identity for agents
This one may matter more than the other two features. Some people call it agent identity, or non-human identity. When an agent calls an MCP server, or another agent, or another service, how do we know it is in fact the agent we think it is? How do I know this is really my Claude mobile app, or a specific custom application? Not because it claims to be, but because it proved it with strong authentication.
Answer that well and you unlock advanced functionality for the systems where the stakes are highest, like a bank moving money, a hospital opening patient records, or any regulated workflow where you truly need to know who the caller is before you let the action through.
That last point is where Arcade sits. Arcade is the actions runtime for enterprise AI agents, and knowing exactly who is acting, on whose behalf, before an action runs is the whole game for us. Authorization at the intersection of the user and the agent, evaluated on every action. The transport underneath can keep changing. That control stays steady.
Thirty days in, the headline is boring in the best way. MCP works, people trust it, and the debates have moved to executing on use cases. The next year is about closing the gaps that only show up once you are running agents in production at scale. Skills, triggers, and identity sit at the top of that list, and we will be building against every one of them.
That’s the future of agentic work. See you there.
