Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New MCP Roadmap

blog.modelcontextprotocol.io

Post reply on HN
Print view View original

161–170 of 184 posts

Re: New MCP Roadmap

#161

Post by ricardobeat »

DarmokTanagra wrote: post #156

The entire premise of MCP is misguided and completely counter to the core value proposition of ai agents. Its insane to me how quickly people flocked to the idea of building a parallel web to maintain for non humans. I shouldnt be surprised seeing how low priority human accessibility and ux has been on the web when compared to the needs of the all consuming parasite that is ad tech.

It was actually a welcome change for 'web access'. There were very few open APIs left, MCP forced everyone to actually build public APIs again.

Re: New MCP Roadmap

#162

Post by macrolime »

I've tried many MCPs, but have yet to find any that are actually useful. It seems it's generally better to just have the agent run CLI commands and maybe use some skills. From what I can find, MCPs are nothing but bloat. Is anyone aware of any truly useful MCPs that doesn't work better and less bloaty by skipping the MCP part?

Re: New MCP Roadmap

#163

Post by tarun_anand »

colingauvin wrote: post #35
rco8786 wrote: post #8

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

Wrote about this last year and wanted to unify it... at that time the community was so excited about MCP being the best thing since sliced bread

https://github.com/modelcontextprotocol/modelcontextprotocol...

https://news.ycombinator.com/item?id=43959474

Re: New MCP Roadmap

#164

Post by bensyverson »

zackify wrote: post #43
izend wrote: post #6

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 st…

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

Yes, MCP was already overly complicated, and these new features will make it even more unapproachable.

If I need to integrate with a third party service, I'm now skipping their MCP entirely and just going straight for the CLI or API, which are usually more full-featured. An agent usually doesn't even need a dedicated Skill for this.

Re: New MCP Roadmap

#165

Post by maxwellg »

otabdeveloper4 wrote: post #152
maxwellg wrote: post #55

Earlier quoted context omitted.

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 priv…

Are you reinventing SPIFFE here?

No - this is built on top of SPIFFE/WIMSE work to enable cross-domain usage where the target domain speaks OAuth instead. You wouldn't expect, say, Slack's APIs to accept SPIFFE SVIDs from your internal deployment. This provides a path for you to exchange your SVID for a Slack-issued Access Token.

Re: New MCP Roadmap

#166

Post by sajithdilshan »

macrolime wrote: post #162

I've tried many MCPs, but have yet to find any that are actually useful. It seems it's generally better to just have the agent run CLI commands and maybe use some skills. From what I can find, MCPs are nothing but bloat. Is anyone aware of any truly useful MCPs that doesn't work better and less bloaty by skipping the MCP part?

Depends on what tool you use. As an example for github gh is way more efficient than using the github MCP because the training data of LLM actually contains gh documentation and how to use it.

However, if you have a very niche command tool or a work related internal tool, LLM has no idea on how to use it and it could waste a lot of tokens by trying to figure out what works and what doesn't and how to use it in every session. That's where MCP comes in handy. LLMs are trained to use the MCP protocol and it can efficiently figure out which tool to be called and how to process the output when a niche command tool is exposed via an MCP.

Re: New MCP Roadmap

#167

Post by sofixa »

zackify wrote: post #43
izend wrote: post #6

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 st…

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

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

And when the agent does something stupid, your long lived token is compromised. It also makes it hard to segregate access (e.g. all those "Cursor deleted by production DB and all its backups because it had an API key that could do that").

Nope, you should instead use something that give short-lived tokens, ideally ones scoped based on the desired intent / operation. Or even better, skip the "agent gets a token" part at all, and have all agent operations pass through a gateway/agent/proxy/whatever that handles that part. That way even if the agent gets comrpomised or does something dumb, it doesn't have even a short lived token to give away.

Re: New MCP Roadmap

#168

Post by elenaviter »

danappelxx wrote: post #61
zackify wrote: post #43

Earlier quoted context omitted.

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.

There might be the "agent card" - one place where the user manages what a specific agent is allowed to do. The user grants it tools, connects the accounts those tools need, narrows or revokes any of that at any time. For an autonomous agent the card is prepared and consented before the run. Such card is the primitive in so called "connection hub", a centralized component, and is rendered from what is declared there: tools declare their claims, accounts get connected in the browser (google docs tools need a google account connected), on their own or as part of preparing the card. Account credentials live in this hub, with the claims the user approved when connecting.

The agent authenticates with one token issued for this card and never receives the connected accounts credentials. Every operation is checked against the grant and this agent's binding to the account. If something is missing, the agent gets unauthorized with the details on what exactly. If the check passes, the hub, loaded by the server as a lib or reached in its internal network, releases the account credential into the operation's execution context. Account credentials renewal happens on hub. Revoking grant is also done in card and leads to agent's unauthorized on that op next call. Sub-agent and any automation are also such agents and also can be managed with such card.

So such hub develops into a useful ecosystem component, standalone, like an IdP for login. An MCP server then works together with this hub, it only declares its claims in the hub (so the hub knows what to render in the agent card). While all these auth realm duties such as approvals, the revocation and the credentials storage live "at infrastructure".

Re: New MCP Roadmap

#169

Post by ljm »

huksley wrote: post #16
izend wrote: post #6

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 st…

Such an example of overengineering, why not just use OAuth?

Any service offering MCP that doesn't already have OAuth set up is going to have to build out that support first, so instead they just go for a simple API token.

I wouldn't call it trivial to drop in OAuth either because the authentication is one part, but wiring it up into whatever authorization set up they have is another bit of work.

An AI agent would get the most benefit out of OAuth + ephemeral service accounts (the user is having a bot act on behalf of it) + fine grained scopes.

Re: New MCP Roadmap

#170

Post by DarmokTanagra »

chrisweekly wrote: post #31
jdw64 wrote: post #10

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.

Trying is not the same thing as advocating for and implementing products features using unproven tech.

Ive been in this industry nearly 40 years and I have seen many many people push new tech and later fail to deliver and suffer the consequences.

Experiment where it doesnt matter, everywhere else boring and old is a virtue.

Post reply on HN