> With the 2026-07-28 release, a remote MCP server is now no different from any other HTTP workload
Good. Introducing a bespoke new protocol was one of the more bone-headed things MCP did on initial release.
show comments
izend
I am very curious how many MCP servers will actually implement all of this:
"MCP authorization today is built around a person approving access in a browser. That works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present, or delegating narrower authority to sub-agents. We want MCP servers to have a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long-lived tokens.
The work here covers finalizing Demonstrating Proof of Possession (DPoP) and driving its adoption, and defining an opinionated path for agent identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange. We will also continue to grow our engagement with the OAuth standards bodies, including the IETF OAuth and WIMSE working groups, to help the underlying standards evolve with the building blocks that agent identity needs."
show comments
cube00
I still struggle to see how a MCP endpoint is easier for agents to work with compared with a REST endpoint and a skills.md file.
show comments
threecheese
I wish the “sampling” feature - which is being removed - had found more use. BYO Inference could be really useful in a walled garden like Claude Code, where you are unable to leverage inference outside of that garden without paying per token. Maybe that feature was just more interesting than it was useful.
mmaunder
My dream was for MCP to allow services like ours (cybersecurity) to provide a self documenting endpoint with authentication, and we just give users a URL and it just frikkin works. Instead from day 1 it’s been multiple standards as they pivoted, a context hungry feature, and feels like a kludge. That burned the idea of MCP for me and I’ve had such success with local tools and APIs that it’ll take a lot for me to go back.
show comments
mikeegg1
When I see "MCP" I still translate that to Master Control Program.
show comments
rglover
The degree to which this idea has been overcomplicated is confusing. This could have been solved with some relatively simple patterns wrapped around HTTP and WebSockets (and if absolutely necessary, SSE).
skinfaxi
> We’re starting a progressive discovery effort so a server can offer a small entry point and reveal more of its catalog as the conversation narrows.
Kind of late to the party. I've had to implement lazy loading of mcps in a couple of harnesses now but am moving to implement everything as code mode instead.
show comments
huksley
In v.1 making MCP stateful was such a deployment-unfriendly way to do it - you need a complicated persistence layer for it to work.
All while it is just a fancy way make your OpenSchema PAI visible to AI.
vatsachak
Why not just give the model a prompt?
Every gain in LLMs is either through increases in compute efficiency, Architecture or Harnesses...
The rest seems like bells and whistles
vkaku
I think MCP is jumping some sharks here.
Nobody needs to have every functionality of HTTP offloaded to MCP at all, at this point.
Sometimes I really respect senior developers. When specs change, you obviously have to update existing work too. Looking at this MCP change, it seems like it's becoming stateless—I'm already wondering how to adapt.
Senior programmers always advised me to only use things that have been around for at least three years. Now I finally understand why.
show comments
firatsarlar
Truth doesn't move much. It moves slowly, so that those holding onto it don't fall. Keep up.
simianwords
Is there a way in MCP where I can "approve" certain privileged actions? Like imagine an MCP for buying stuff in Amazon but it can do everything including payment but is behind a gate that the human needs to approve
> With the 2026-07-28 release, a remote MCP server is now no different from any other HTTP workload
Good. Introducing a bespoke new protocol was one of the more bone-headed things MCP did on initial release.
I am very curious how many MCP servers will actually implement all of this:
"MCP authorization today is built around a person approving access in a browser. That works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present, or delegating narrower authority to sub-agents. We want MCP servers to have a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long-lived tokens.
The work here covers finalizing Demonstrating Proof of Possession (DPoP) and driving its adoption, and defining an opinionated path for agent identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange. We will also continue to grow our engagement with the OAuth standards bodies, including the IETF OAuth and WIMSE working groups, to help the underlying standards evolve with the building blocks that agent identity needs."
I still struggle to see how a MCP endpoint is easier for agents to work with compared with a REST endpoint and a skills.md file.
I wish the “sampling” feature - which is being removed - had found more use. BYO Inference could be really useful in a walled garden like Claude Code, where you are unable to leverage inference outside of that garden without paying per token. Maybe that feature was just more interesting than it was useful.
My dream was for MCP to allow services like ours (cybersecurity) to provide a self documenting endpoint with authentication, and we just give users a URL and it just frikkin works. Instead from day 1 it’s been multiple standards as they pivoted, a context hungry feature, and feels like a kludge. That burned the idea of MCP for me and I’ve had such success with local tools and APIs that it’ll take a lot for me to go back.
When I see "MCP" I still translate that to Master Control Program.
The degree to which this idea has been overcomplicated is confusing. This could have been solved with some relatively simple patterns wrapped around HTTP and WebSockets (and if absolutely necessary, SSE).
> We’re starting a progressive discovery effort so a server can offer a small entry point and reveal more of its catalog as the conversation narrows.
Kind of late to the party. I've had to implement lazy loading of mcps in a couple of harnesses now but am moving to implement everything as code mode instead.
In v.1 making MCP stateful was such a deployment-unfriendly way to do it - you need a complicated persistence layer for it to work.
All while it is just a fancy way make your OpenSchema PAI visible to AI.
Why not just give the model a prompt?
Every gain in LLMs is either through increases in compute efficiency, Architecture or Harnesses...
The rest seems like bells and whistles
I think MCP is jumping some sharks here.
Nobody needs to have every functionality of HTTP offloaded to MCP at all, at this point.
I'll stick to the bare minimum that works.
This reminds me of the actor model[1]
[1] https://doc.akka.io/libraries/akka-core/current/typed/actors...
Half the battle is just knowing this exists
Sometimes I really respect senior developers. When specs change, you obviously have to update existing work too. Looking at this MCP change, it seems like it's becoming stateless—I'm already wondering how to adapt.
Senior programmers always advised me to only use things that have been around for at least three years. Now I finally understand why.
Truth doesn't move much. It moves slowly, so that those holding onto it don't fall. Keep up.
Is there a way in MCP where I can "approve" certain privileged actions? Like imagine an MCP for buying stuff in Amazon but it can do everything including payment but is behind a gate that the human needs to approve