MCP — What Changed?

MCP is making a comeback in my working life. I first noticed it when working on my Signals feed: it kept coming up in the posts I was reading.

As an MCP hater since it came out, I was surprised. So I looked into it and guess what: I'm not a hater anymore. In fact, I'm now a big fan. To the point where I bring it up in most of my customer projects now.

For anyone new to it, MCP—the Model Context Protocol—is a standard way for AI applications to discover and use tools and data exposed by other systems. An MCP server describes what's available; a compatible client connects and uses it.

Let me unpack what changed, as simply as I can.

Adapted from my LinkedIn article, “MCP – What Changed?”, published October 9, 2026.

1. Context management

An early frustration was that an MCP client would drop all its connected tools' descriptions into your context and basically hijack it. Not just the names, but the entirety of each description. Before you could do anything, you could be allocating thousands of tokens just to know what the server could do. You could be interested in one tool—it didn't matter, you got them all.

Some clients are now designed more intelligently, with lazy loading and progressive discovery, very similar to skills. They load enough to find the right tool, then read its full description when needed. This is a client design choice, not something every MCP integration automatically does.

Anthropic's explanation of code execution with MCP describes both the context problem and ways to discover tools on demand.

2. Code mode

Another useful development is code-based tool orchestration. Instead of calling each tool separately, dumping its output into the context, doing the analysis and proceeding to the next tool, a supporting client can package that logic into a little script, including conditions if needed.

Then it runs the script, for example in a JavaScript sandbox. Intermediate output can be processed deterministically outside the model's context; only the results the script returns or logs need to come back to the model.

Suppose you have a tool that reads user records and another that updates a specific user. A script can find the right record, check a condition and call the update tool without passing the whole table through the model. Filtering at the database is still preferable when the tool supports it.

Pi's account of its change of mind about MCP gives a concrete example of this approach. It isn't a feature you should assume every client implements.

Two strengths of a well-designed MCP server make this easier:

Documentation. I like to call MCP “marketing for your API.” A connected client can discover tool descriptions and input schemas without a separate hunt through your documentation. It's a bit like Swagger, but with descriptions written to help an agent choose and use an action. Examples and guidelines can make those descriptions much more useful.

Structured outputs. When a server supplies structured results and output schemas, the script can work with data rather than guess at the meaning of a text response. Not every MCP tool does this well.

CLIs can return structured JSON too, and raw APIs can be composed in code. My preference for MCP here is about putting discovery, descriptions and tool contracts behind a common interface—not claiming that CLI workflows can't be composed.

3. Session management

Session management was another source of complexity. The 2026-07-28 MCP specification removes protocol-level sessions and the initialization handshake: each request carries the information needed to identify its protocol version and client capabilities.

Between the client and server, it's much closer to a “you do your thing, I do mine” relationship. That is less protocol state for a server designer to manage.

Existing deployments may still use older revisions, and your application may still need state—for example, a saved job or an event subscription. Stateless protocol requests don't make that business state disappear.

4. Adoption

I haven't done the quantitative research on this one, to be honest. My feed is how I noticed the renewed attention; it isn't a measurement of industry-wide adoption.

But there are concrete developments worth looking at. OpenAI now documents MCP Events, which lets supported ChatGPT environments subscribe to updates from an MCP server.

Another project that popped onto my radar was WebMCP, an open-source JavaScript library for connecting a web page to MCP clients. It offers a way to expose page actions as tools.

The most recent signal for me came from the team behind Pi. They wrote about why they changed their minds and brought MCP into the core. As a fellow former sceptic, that caught my attention.

5. Orchestration

This is the one that surprised me the most.

If you have a user-facing agentic workflow, and your API is designed around atomic actions that your agent orchestrates behind the scenes, what happens if you let your customers do the orchestration?

Suppose you have read and write endpoints that your agent calls to perform a more complicated task useful to all your customers. You use whatever economical model can get the job done.

But now there's one customer with very specific, complicated business logic, only applicable to them. It wouldn't necessarily make sense for you to build a whole new product feature just for that use case.

With an MCP server exposing the relevant actions, you can let them connect a compatible client, describe their workflow and get out of the way. They can choose a more powerful or expensive model if they need one. It's their model tokens, not yours—although you still pay to run your API and enforce its limits.

The permissions don't move to the customer's prompt. Your backend still has to control which records they can access and which actions they can take, with approval for consequential writes where needed.

Conclusion

All in all, MCP has earned another look from me. I think it's here to stay this time.

If you have backend endpoints, at minimum you should be asking yourself whether exposing some of them through MCP would bring a real benefit to your customers. For me, customer-led orchestration is the strongest reason to ask that question.