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.

Because it's a separate marketing term.

Instead of the CEO mandating that the API server has to be agent compatible (where who knows what that means), they can just say "our product has an MCP".

On a technical level, who knows what it actually is (is it actually the new stateless version, does it have all the endpoints, is the regular API more feature-rich, do I need those features for my workflow?, etc.). But at a surface-level, the intention is clearer, and lets other gears (like sales and marketing) keep spinning without getting bogged down in technical details.

Not all agents have access to a sandbox/cli/code execution environment to run arbitrary api calls etc. MCP helps by essentially having another tool call without needing a sandbox. If you do have a sandbox, then might as well do codemode if you insist on mcp https://blog.cloudflare.com/code-mode/

At my company Parallel AI, I just built an extremely well documented openapi spec and then MCP builds from that. Complete alignment with UI/API/MCP so there is no extra work.

Are others doing this?

It seemed obvious to me, but I don't hear others saying it.

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

Me too, it is just another RPC endpoint, heck all of this kind of stuff could even be done with Sun RPC.

or a CLI

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.

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...

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?

And here I thought I was old.

What do you mean "as code mode"?

> "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.