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

11–20 of 184 posts

Re: New MCP Roadmap

#11

Post by bandofthehawk »

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…

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.

Re: New MCP Roadmap

#13

Post by willio58 »

LowTechHN wrote: post #9

[flagged]

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.

Re: New MCP Roadmap

#14

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

Re: New MCP Roadmap

#15

Post by petcat »

LowTechHN wrote: post #9

[flagged]

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.

Re: New MCP Roadmap

#16

Post by huksley »

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?

Re: New MCP Roadmap

#17

Post by ewild »

LowTechHN wrote: post #9

[flagged]

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.

Re: New MCP Roadmap

#18

Post by jstummbillig »

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…

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.

Re: New MCP Roadmap

#19

Post by gz5 »

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…

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?

Re: New MCP Roadmap

#20

Post by alasano »

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…

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.

Post reply on HN