There's an interesting case to be made that MCP, as a protocol, is the right abstraction because of code execution tool definitions... but that most people aren't using it correctly.

With MCP, you do get things like persistent connections (say, to a running browser instance that's being automated).

But the entire idea that the way that an agent would handle MCP outputs is by sending all output as tokens through the LLM is almost absurd. Having standalone tools (even if they connect to some background proxy that handles persistent connections) and being able to sample and code around their output is far superior.

The cool thing, though, is that you could glue this approach into any agent system using an intermediary MCP: one that allows enumeration of skills, writing of skill code (which itself can access the intermediary's upstream MCP connections), and running skill code that saves its output into a session variable.

All of a sudden, you get all the benefits of this approach, and all the interoperability of MCP, with no more context requirements than you're currently using to tell the LLM where skills are. Best of all worlds!