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

171–180 of 184 posts

Re: New MCP Roadmap

#171

Post by niyikiza »

_puk wrote: post #36
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…

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

This. Especially when you have agents calling other agents. Just published an article about that yesterday: https://niyikiza.com/posts/agents-to-agents/

Re: New MCP Roadmap

#172

Post by oblio »

Gormo wrote: post #71
amluto wrote: post #69

Earlier quoted context omitted.

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

Not everyone is on board with the idea of HTTP being the exclusive universal IPC bus.

What's the disadvantage? MCP doesn't strike me as a high performance protocol.

Re: New MCP Roadmap

#174

Post by qingcharles »

ricardobeat wrote: post #161
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.

This. It's amazing how long humans have screamed for good APIs, cheaply accessible for lots of web sites and all we got were crickets. LLMs come along and the same sites are falling over themselves to build extensive APIs. It's the golden age of APIs finally.

Re: New MCP Roadmap

#175

Post by 1saadcodes »

I like that this roadmap spends so much time on things like HTTP, auth, result formats and SDKs. It's a nice step up from the rough initial release and will just make the overall experience building it easier

Re: New MCP Roadmap

#177

Post by cryptonector »

Gormo wrote: post #71
amluto wrote: post #69

Earlier quoted context omitted.

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

Not everyone is on board with the idea of HTTP being the exclusive universal IPC bus.

Pros for HTTP for IPC:

1. We already use it plenty, so we have lots of implementations,

2. it's good enough.

Cons:

a. what shall be the form of HTTP IPC URIs? hostnames for http: and https: scheme URIs are kinda out of place in IPC applications (we need something like sys.ipc.arpa, d-bus.arpa, etc),

b. the overhead of HTTP is annoying -- any decent RPC can be significantly more efficient, unless one uses HTTP/2, and maybe even then.

(a) makes me want to write and submit an I-D for HTTP over IPC by using such names as in the parenthetical above.

(b) is a non-issue once H2 is widely adopted.

So IMO HTTP is pretty good for IPC.

Re: New MCP Roadmap

#180

Post by chrisweekly »

beepbooptheory wrote: post #34
chrisweekly wrote: post #31

Earlier quoted context omitted.

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

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

What kind of work have I done? All kinds of webdev and SWE-adjacent roles since the late 90s. Startups, scale-ups, SMBs, huge enterprises. FT and contract / consulting roles (w/ titles containing words like "Principal", "Architect", "Director" and "VP").

In a world where everyone followed rigid advice to stick to 3yo+ tech, Vite wouldn't exist, let alone have people to argue for it. Nor would the web, for that matter.

I'm _not_ saying "chase the new-and-shiny for its own sake", and I don't recommend introducing immature or untested dependencies in production. But it's essential to learn how to gauge the quality of a mature solution -- and IME the only way to do that is to have something to compare it to (ideally, something newer and better). Develop an instinct for separating the signal from the (considerable) noise by trying things. Newer isn't always better, but the arc does trend towards improvement. Dev tooling is rife with examples, and a great place to start.

As for "You have had a lot managers push newer frameworks/technologies on you?" On the contrary -- I've had managers wedded to outdated cruft that threatened to drag the whole enterprise down. Resistance to change is sometimes fear masquerading as wisdom.

Finally, note this whole thread is in the context of an update to the MCP spec. In the world of AI, 3 years might as well be 3 centuries.

Post reply on HN