Live data from Hacker News

New MCP Roadmap

blog.modelcontextprotocol.io

31–40 of 184 posts

Re: New MCP Roadmap

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

Re: New MCP Roadmap

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

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

Re: New MCP Roadmap

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

Re: New MCP Roadmap

#36
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 input stuff.

Re: New MCP Roadmap

#37
I still struggle to see how a MCP endpoint is easier for agents to work with compared with a REST endpoint and a skills.md file.

Re: New MCP Roadmap

#38
post #16
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?

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.

Re: New MCP Roadmap

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

Keeping up with changes is valuable.

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

Re: New MCP Roadmap

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

Three years is nothing, what kind of work do you do where you need something released in the last three years?

And I’m not OP, but I would assume the senior developers made a distinction between try and use.

Post reply on HN