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.
The prose on the page is very unclear. My best interpretation is that they want to continue supporting stdio but that they don’t want it to be its own special protocol. The obvious way to do that would be to speak ordinary HTTP (version 1.1? 2?) over stdio and to use the MCP-over-HTTP protocol over the resulting HTTP transport.
This would be more complex to implement for a simple server, but it’s not exactly difficult.
it's not easier for agents to work with. it's easier for organizations to work with.
for agents, they're essentially the same thing - remote endpoints, and instructions on how to call those endpoints. what MCP brings is centralized updating and distribution of the instructions, and a promise that the skill and the REST api won't be out of sync with each other.
the one thing that skill.md+REST doesn't solve is how you get that skill.md to somebody else's computer, and how you ship an update to somebody else's computer once they've got a copy of the skill. if that's a problem you need to solve, you can either start inventing skill.md distribution protocols, or you can just use MCP.
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/
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.
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.
The model has zero awareness of MCP, it’s the harness’ job to talk to the MCP server and simply present the model with the tools just like any other tool. The only giveaway to the model about where the tools come from is the ‘mcp__’ prefix in the name
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
Yeah probably. But I think the same logic that leads to using MACH architecture also leads to using agents provided by a cloud provider or a 3rd party service provider.
I.e. for a lot of tasks setting up and updating an agent to handle that task is just as commoditized as setting up and updating an operating system.
In which case MCP server or not becomes an implementation detail managed by the cloud provider, or whoever provides the container that implements the agent.
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.
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...
How does the agent auth with 1pw? How do you give it access to only the credentials it needs, with an approval flow and revocation? Who renews the token? You’ll likely end up reinventing something pretty close to what MCP is building towards.
Authn/authz is one of those things that can be really simple for pointed use cases but gets really complex when you need to support everything.
I've been working on a protocol that promises all of that and more. We're currently targeting a NOSTR/Buzz demo in the coming week as a proof of concept.
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?
It is viable. Think of workload identity federation as the mechanism for the client to get an bearer token initially, and DPoP as the mechanism for the client to present the access token to a resource server. Each DPoP proof is entirely self-contained, so resource servers don't need to manage any additional state. The only new state is the (usually ephemeral) private key held by the client:
1. Client generates a private/public keypair and uses it to generate DPoP Proofs -
JWTs containing the entire public key embedded as a JWK within
2. Client presents credentials (WIF, client creds, auth code, etc.) to the Authorization Server along with a DPoP Proof
3. Authorization Server validates DPoP Proof and adds a claim to the access token containing the thumbprint - the SHA-256 hash - of the public JWK.
4. Resource Servers will now see the thumbprint claim and now know the access token needs to be presented with a fresh DPoP proof.
5. Clients generate fresh DPoP proofs and send them along with the access token
There are lots of additional details around nonces, timestamps, per-request binding, etc. but DPoP can be rolled out to any HTTP system that speaks Bearer token already.
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'm very bullish on MCP (or at least MCP "like" implementations), as they solve a lot of problems for non-devs as they're much easier and safer to add into ChatGPT, Claude and other desktop + web apps.
They provide a set of tools and a context when to use those tools (much like a packaged version of a CLI+API and a skill) which makes them more discoverable than other options.
I've got a few folks using my open source data storage MCP - https://github.com/ExpeditedProjects/hutchdb - now and it makes a lot more sense than any other implementation for what they're doing
I agree, I've found MCP to be a waste of time. Any HTTP API + OpenAPI spec is sufficient to get my agents to do anything they need to do. Bonus that it just uses regular HTTP semantics and all the tools and infrastructure that have been developed around that for decades. Instead of some inscrutable json RPC POST-only payload that needs tons of custom tooling for introspection, logging, etc.
So I’ve been working on a personal finance app, and I added an MCP to it. Connected my Claude to it, mainly for testing purposes.
The other day I was heading to Home Depot to buy some gardening stuff and I was asking some some questions around what I could plant at this time and still harvest before winter.
It answers me, then brings up how my home improvement budget is nearing its limit for the month. I then ask it how I’m doing on my wider retirement plan and it mentions I’m a few thousand dollars ahead of schedule for the plan. So I decided it’s okay to go over budget on that category this month.
This type of emergent behavior of agents you work with having more context about you, it’s very useful in ways I didn’t expect.
MCP is essentially just a convention for APIs that standardizes the concept of a “resource”. It spares the LLM a lot of work figuring out what the “things” are in a problem domain, and how various endpoints relate to those “things”.
I’ll never understand the “I’ve never used it but am absolutely certain I would get zero value from it if I did” mentality.
I use MCP to accelerate CAD mould-making and for music production. I use it to avoid copying and pasting slack threads, and to let AI drive an eval system so I don’t have to manually configure things in a UI.
It’s just hard to imagine both not using it and being so sure it has no use.
Because you're a dev thinking for devs. No 60 year old is going to use Claude skills with the CLI. If my customers want their AI to interact with my product and MCP is the best way about it.
> If my customers want their AI to interact with my product and MCP is the best way about it.
Would be really interested to know how many of your customers actually use the MCP, who aren't already devs thinking like devs. I have doubts that many non-technical people are connecting AI to third-party services via MCP (or even using AI at all beyond "mundane" things like "generate an image of my cat as a clown" or "show me what my house looks like with blue paint and white trim").
I actually have data on this albeit it's a bit skewed. None of our clients are dev like folk but they are financial folks. We sell financial data for big players so not the analysts (seat cost is over 50k per year) and of our ~10k users within the last 6 months of us launching MCP we have 1500 DAUs on the MCP
Good. Introducing a bespoke new protocol was one of the more bone-headed things MCP did on initial release.
This would be more complex to implement for a simple server, but it’s not exactly difficult.
for agents, they're essentially the same thing - remote endpoints, and instructions on how to call those endpoints. what MCP brings is centralized updating and distribution of the instructions, and a promise that the skill and the REST api won't be out of sync with each other.
the one thing that skill.md+REST doesn't solve is how you get that skill.md to somebody else's computer, and how you ship an update to somebody else's computer once they've got a copy of the skill. if that's a problem you need to solve, you can either start inventing skill.md distribution protocols, or you can just use MCP.
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.
Are others doing this?
It seemed obvious to me, but I don't hear others saying it.
On low code/no code tools, you get additional metadata for webhooks.
it's like saying "i don't want to give Claude access to my file system but i'm fine letting it run bash" ......
Plus why spawning processes all the time.
I.e. for a lot of tasks setting up and updating an agent to handle that task is just as commoditized as setting up and updating an operating system.
In which case MCP server or not becomes an implementation detail managed by the cloud provider, or whoever provides the container that implements the agent.
"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."
"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...
Authn/authz is one of those things that can be really simple for pointed use cases but gets really complex when you need to support everything.
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 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.
And the individual work attached to making that transition will be done by agents.
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?
1. Client generates a private/public keypair and uses it to generate DPoP Proofs - JWTs containing the entire public key embedded as a JWK within
2. Client presents credentials (WIF, client creds, auth code, etc.) to the Authorization Server along with a DPoP Proof
3. Authorization Server validates DPoP Proof and adds a claim to the access token containing the thumbprint - the SHA-256 hash - of the public JWK.
4. Resource Servers will now see the thumbprint claim and now know the access token needs to be presented with a fresh DPoP proof.
5. Clients generate fresh DPoP proofs and send them along with the access token
There are lots of additional details around nonces, timestamps, per-request binding, etc. but DPoP can be rolled out to any HTTP system that speaks Bearer token already.
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.
I was getting fed up with AWS mcp telling me it is eol.
All while it is just a fancy way make your OpenSchema PAI visible to AI.
[1] https://doc.akka.io/libraries/akka-core/current/typed/actors...
Senior programmers always advised me to only use things that have been around for at least three years. Now I finally understand why.
Yikes. I can understand the desire to mitigate churn, but following this advice would be career suicide. Trying new things is essential.
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
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 had to give maintenance to things people deployed to pad their resumes with "shiny new thing", and it was not fun.
If you intend to deploy and leave that as legacy for some poor shlemiel, sure.
If you intend to stay and actually keep things running, it's much better to use tried and tested stuff.
And I’m not OP, but I would assume the senior developers made a distinction between try and use.
They provide a set of tools and a context when to use those tools (much like a packaged version of a CLI+API and a skill) which makes them more discoverable than other options.
I've got a few folks using my open source data storage MCP - https://github.com/ExpeditedProjects/hutchdb - now and it makes a lot more sense than any other implementation for what they're doing
The other day I was heading to Home Depot to buy some gardening stuff and I was asking some some questions around what I could plant at this time and still harvest before winter.
It answers me, then brings up how my home improvement budget is nearing its limit for the month. I then ask it how I’m doing on my wider retirement plan and it mentions I’m a few thousand dollars ahead of schedule for the plan. So I decided it’s okay to go over budget on that category this month.
This type of emergent behavior of agents you work with having more context about you, it’s very useful in ways I didn’t expect.
I use MCP to accelerate CAD mould-making and for music production. I use it to avoid copying and pasting slack threads, and to let AI drive an eval system so I don’t have to manually configure things in a UI.
It’s just hard to imagine both not using it and being so sure it has no use.
Would be really interested to know how many of your customers actually use the MCP, who aren't already devs thinking like devs. I have doubts that many non-technical people are connecting AI to third-party services via MCP (or even using AI at all beyond "mundane" things like "generate an image of my cat as a clown" or "show me what my house looks like with blue paint and white trim").
I build integration for DollarDeploy but it was tricky.