Yep. I’ve found that having an endpoint that serves a well, documented openapi.yaml is very effective for agentic usage. The biggest difference is that you can break down a REST API into RPC-like chunks and save on some tokens if you break up the tools well. But pragmatically, I think saying “tell your agent to hit /api/v3/openapi.yaml” is quite useful
It's unreal how bad the initial rollout was between HTTP/streaming and stdio, bearer auth and OAuth. Virtually every client/MCP server pair had a different portion of that matrix implemented.
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 think the spec overcomplicates everything honestly. Its not that hard to add a long running auth token and put it in the MCP config as a header to send along and then avoid all the extra special rules.
"Oh no it's a long lived token that's bad"
Put it in a secret manager like 1pw cli and now start an agent...
Why, directionally all of them. What they say is obviously true. Having to manually click things in the browser is a bottleneck and will be less and less acceptable for serious users.
And the individual work attached to making that transition will be done by agents.
agree. it seems there are two streams and they could diverge or converge?
1. workloads use existing credentials
support RFC 7523 and OIDC discovery, 'trust the trust (credentials) which has already been established'. basically extend current dominant NHI paradigm.
2. DPoP
mandate a signed proof for each request. so tie credential to a client-held key and specific request detail or context. viable to do at scale with #1, or does it diverge (e.g. because most #1 methods as most are not designed for DPoP?
Even now, the mcp server itself doesn't have to implement all of the possible security options. You can use something like agentgateway to act as an auth proxy for your mcp servers.
WIF works far better when you don’t want humans in the loop. For example, we’d do our development on cloud instances, those have identity linked to our humans via our IdP. Our IdP governs all access, for example: it lets devs use Datadog. If an agentic workflow needs Datadog access and the MCP requests OAuth that slows the loop down. At the same time, we don’t want Service Accounts everywhere because we need to be able to answer “who” a lot for compliance reasons.
> 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.
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.
Just curious, what kind of work have you done where this conceit feels valid in your mind? My career, at least, feels like an exception to this, but I guess its conceivable to me that it could be otherwise. You have had a lot managers push newer frameworks/technologies on you? Is this more VC startup land, or something else?
Maybe I'm old, but at least in web dev it doesn't feel that long ago that someone had to argue for, e.g., Vite over webpack, Svelte over React, etc..
I still struggle to see how an MCP endpoint is easier for agents to work with compared with a standard REST service with a skills.md file.
Yep. I’ve found that having an endpoint that serves a well, documented openapi.yaml is very effective for agentic usage. The biggest difference is that you can break down a REST API into RPC-like chunks and save on some tokens if you break up the tools well. But pragmatically, I think saying “tell your agent to hit /api/v3/openapi.yaml” is quite useful
or a CLI
> 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.
It's unreal how bad the initial rollout was between HTTP/streaming and stdio, bearer auth and OAuth. Virtually every client/MCP server pair had a different portion of that matrix implemented.
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 think the spec overcomplicates everything honestly. Its not that hard to add a long running auth token and put it in the MCP config as a header to send along and then avoid all the extra special rules.
"Oh no it's a long lived token that's bad"
Put it in a secret manager like 1pw cli and now start an agent...
Authorization for sub-entities is what is needed.
Having to define what an agent can do when it identifies on my behalf is cumbersome, especially when you start to get specialised agents.
Pattern based would be too easy for AI to game, but there's got to be a service independent way to limit permissions based on role.
I am Jack's right ear - awesome you get to hear stuff.
I am jack's right hand - great you get to input stuff.
Hopefully quite a few.
I really love the idea of fully enabled agents and being able to cut down on human in the loop moments.
Things like https://projects.dev/ for example.
A ton of security problems and others to solve but it's still where I want the future of all this to go.
Why, directionally all of them. What they say is obviously true. Having to manually click things in the browser is a bottleneck and will be less and less acceptable for serious users.
And the individual work attached to making that transition will be done by agents.
agree. it seems there are two streams and they could diverge or converge?
1. workloads use existing credentials support RFC 7523 and OIDC discovery, 'trust the trust (credentials) which has already been established'. basically extend current dominant NHI paradigm.
2. DPoP mandate a signed proof for each request. so tie credential to a client-held key and specific request detail or context. viable to do at scale with #1, or does it diverge (e.g. because most #1 methods as most are not designed for DPoP?
Even now, the mcp server itself doesn't have to implement all of the possible security options. You can use something like agentgateway to act as an auth proxy for your mcp servers.
Such an example of overengineering, why not just use OAuth?
WIF works far better when you don’t want humans in the loop. For example, we’d do our development on cloud instances, those have identity linked to our humans via our IdP. Our IdP governs all access, for example: it lets devs use Datadog. If an agentic workflow needs Datadog access and the MCP requests OAuth that slows the loop down. At the same time, we don’t want Service Accounts everywhere because we need to be able to answer “who” a lot for compliance reasons.
Oauth assumes interactivity
When I see "MCP" I still translate that to Master Control Program.
And here I thought I was old.
> 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.
What do you mean "as code mode"?
Basically https://blog.cloudflare.com/code-mode/
I was getting fed up with AWS mcp telling me it is eol.
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.
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.
> "only use things that have been around for at least three years"
Yikes. I can understand the desire to mitigate churn, but following this advice would be career suicide. Trying new things is essential.
Keeping up with changes is valuable.
At the same time, it's often smart to avoid putting things into production that haven't matured or demonstrated staying power.
Or, to badly mangle Postel's law:
Be liberal in what you learn, and conservative in what you deploy
Three years is nothing, what kind of work do you do where you need something released in the last three years?
And I’m not OP, but I would assume the senior developers made a distinction between try and use.
Just curious, what kind of work have you done where this conceit feels valid in your mind? My career, at least, feels like an exception to this, but I guess its conceivable to me that it could be otherwise. You have had a lot managers push newer frameworks/technologies on you? Is this more VC startup land, or something else?
Maybe I'm old, but at least in web dev it doesn't feel that long ago that someone had to argue for, e.g., Vite over webpack, Svelte over React, etc..