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

51–60 of 184 posts

Re: New MCP Roadmap

#51

Post by pjmlp »

davidrichards wrote: post #48
cube00 wrote: post #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.

At my company Parallel AI, I just built an extremely well documented openapi spec and then MCP builds from that. Complete alignment with UI/API/MCP so there is no extra work. Are others doing this? It seemed obvious to me, but I don't hear others saying it.

Yes, for .NET and Java backend stuff, it is basically extending what is already there.

On low code/no code tools, you get additional metadata for webhooks.

Re: New MCP Roadmap

#53

Post by MikhailTal »

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

Not all agents have access to a sandbox/cli/code execution environment to run arbitrary api calls etc. MCP helps by essentially having another tool call without needing a sandbox. If you do have a sandbox, then might as well do codemode if you insist on mcp https://blog.cloudflare.com/code-mode/

Re: New MCP Roadmap

#54

Post by kelseyfrog »

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

I am Jack's synaesthesia.

Re: New MCP Roadmap

#55

Post by maxwellg »

gz5 wrote: post #19
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…

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 private/public keypair and uses it to generate DPoP Proofs - JWTs containing the entire public key embedded as a JWK within

2. Client presents credentials (WIF, client creds, auth code, etc.) to the Authorization Server along with a DPoP Proof

3. Authorization Server validates DPoP Proof and adds a claim to the access token containing the thumbprint - the SHA-256 hash - of the public JWK.

4. Resource Servers will now see the thumbprint claim and now know the access token needs to be presented with a fresh DPoP proof.

5. Clients generate fresh DPoP proofs and send them along with the access token

There are lots of additional details around nonces, timestamps, per-request binding, etc. but DPoP can be rolled out to any HTTP system that speaks Bearer token already.

Re: New MCP Roadmap

#56

Post by aliasxneo »

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've been working on a protocol that promises all of that and more. We're currently targeting a NOSTR/Buzz demo in the coming week as a proof of concept.

Re: New MCP Roadmap

#57

Post by notatoad »

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

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 get that skill.md to somebody else's computer, and how you ship an update to somebody else's computer once they've got a copy of the skill. if that's a problem you need to solve, you can either start inventing skill.md distribution protocols, or you can just use MCP.

Re: New MCP Roadmap

#58

Post by wolttam »

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

The model has zero awareness of MCP, it’s the harness’ job to talk to the MCP server and simply present the model with the tools just like any other tool. The only giveaway to the model about where the tools come from is the ‘mcp__’ prefix in the name

Re: New MCP Roadmap

#59

Post by techscruggs »

davidrichards wrote: post #48
cube00 wrote: post #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.

At my company Parallel AI, I just built an extremely well documented openapi spec and then MCP builds from that. Complete alignment with UI/API/MCP so there is no extra work. Are others doing this? It seemed obvious to me, but I don't hear others saying it.

The challenge with this is that it often causes a proliferation of MCP tools which bloats context, which is one of the reasons that MCP was created.

Re: New MCP Roadmap

#60

Post by mikeocool »

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

Companies got to release an MCP server for their product and tell their investors they were pivoting to be AI native.
Post reply on HN