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

141–150 of 184 posts

Re: New MCP Roadmap

#141

Post by anon84873628 »

nostrebored wrote: post #137
anon84873628 wrote: post #90

Earlier quoted context omitted.

For antiquated "enterprise" APIs that were already a mess of legacy cruft, yes. MCP forced vendors to reconsider the ergonomics of their interface.

What do you mean by this? It certainly sounds technical but it seems to not mean anything. MCP has not smoothed over legacy cruft, and it is generally bad at exactly what you’re describing (many unintentionally coupled APIs with unintentional side effects). These require near deterministic trajectories and you’d be better off creating a consumer with a series of well known good patterns with useful results. If you ta…

Of course MCP can still be implemented poorly by just making a 1:1 clone of the existing API.

But there are also folks who put thought into omitting extraneous fields, combining multiple low-level calls into a single tool that covers a common end-to-end use case, and writing much better documentation. With the political air cover that it is in service of the AI boom. Essentially it gave everyone the opportunity to implement API vN+1.

Re: New MCP Roadmap

#143

Post by lll-o-lll »

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?

The dpop thing is oauth. It’s providing a significant enhancement to preventing token replay, or token theft, at the cost of some request size bloat + an additional key verification.

Re: New MCP Roadmap

#144

Post by jauntywundrkind »

pstuart wrote: post #82
Gormo wrote: post #71

Earlier quoted context omitted.

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

Would you prefer gRPC, thrift, avro, etc... ?

I'm pretty ok with http, but, I'd throw https://varlink.org in as my second pick.

Re: New MCP Roadmap

#145

Post by nevon »

esalman wrote: post #94
notatoad wrote: post #57

Earlier quoted context omitted.

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…

> it's easier for organizations to work with. I can see that. I am developing my first custom agents. I am finding that if I offload some workflow to another agent (e.g. Claude Code), the simplest way to control what it can or cannot do is via an MCP server (which only lets it access tools that I develop/approve myself). I do need that control in the corporate environment. Maybe there are easier ways to do it, just l…

This is how I'm doing it as well, for an internal enterprise platform for agentic workflows. Let's me implement as fine-grained access rules as I want, and gives me somewhere that can hold credentials without exposing them to the agent.

Re: New MCP Roadmap

#147

Post by gf000 »

youre-wrong3 wrote: post #139

People seem to ignore the fact that with MCP you can serve up the tools the user wants and has access to instead of a rest api doc specifying every endpoint and bloating the context.

All those tools still get into context. Also, it's not hard to filter a rest api doc - like with a special tool for that the harness itself could pre-filter it and add only the relevant ones as tools to be even more leaner than what an MCP returns.

Re: New MCP Roadmap

#150

Post by mooreds »

ethbr1 wrote: post #118
kelseyfrog wrote: post #54

Earlier quoted context omitted.

I am Jack's synaesthesia.

What people who care about security want -- finely grained permissions that guarantee security boundaries, at the expense of bad UX What most end users want -- for the machine to do what they want, as often as possible, while bothering them as little as possible Windows' UAC journey is a microcosm of the space. The real long-term win is defining ground level permissions around common use cases, so that when composed…

Yeah. If we want fine grained "intelligent" authorization, there's a lot of work to be done. You can't simply slap a gateway on existing systems.

I wrote about this more on my employer's blog[0].

> The real long-term win is defining ground level permissions around common use cases, so that when composed they can alert as rarely as possible.

And this is an even larger effort to implement, especially as agent capabilities change over time (and they are changing rapidly).

0: https://fusionauth.io/blog/ai-authorization

Post reply on HN