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

81–90 of 184 posts

Re: New MCP Roadmap

#81

Post by [deleted] »

boredumb wrote: post #67
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…

How is distributing a markdown file the bottleneck?

[deleted]

Re: New MCP Roadmap

#82

Post by pstuart »

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.

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

Re: New MCP Roadmap

#83

Post by amluto »

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.

I’m not really a fan. But if you’re building a protocol that needs to map to HTTP anyway, then maybe using the HTTP binding everywhere is not totally awful.

In the flip side: I’m currently designing an AI-adjacent protocol, and it will be able to map to WebTransport, but I don’t plan to define non-WebTransport HTTP bindings unless a very compelling reason appears. The main implementations will not use HTTP at all :)

Re: New MCP Roadmap

#84

Post by JV00 »

intrasight wrote: post #73
mathisfun123 wrote: post #66

Earlier quoted context omitted.

wtf is the difference when 1) you put a key in front of the mcp 2) you mcp a whole bunch of privileged access. it's like saying "i don't want to give Claude access to my file system but i'm fine letting it run bash" ......

The difference is that the LLM never sees your keys/secrets. My understanding is that can make a big difference.

Does mcp guarantee that, per se?

Re: New MCP Roadmap

#85

Post by skybrian »

notatoad wrote: post #57
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…

It seems like organizations will mostly want remote access via http and the other flavors of MCP aren’t so useful? Although, I suppose if you install an app locally, it might have an MCP interface.

Re: New MCP Roadmap

#86

Post by mickdarling »

techscruggs wrote: post #59
davidrichards wrote: post #48

Earlier quoted context omitted.

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.

I created MCP AQL, which is an extension to the MCP spec, specifically to reduce the bloat for MCP tools.

It only has five CRUDE endpoint: Create, Read, Update, Delete, and Execute using a GraphQL-like structure for tool calling of the operations within the endpoints. It's very efficient, and robust. there's all kinds of exemplar tools and components to make adapters for any MCP server. You don't even need to rewrite your own MCP server. Just create an adapter for it.

All open source at MCPAQL.com

Re: New MCP Roadmap

#87

Post by simianwords »

Is there a way in MCP where I can "approve" certain privileged actions? Like imagine an MCP for buying stuff in Amazon but it can do everything including payment but is behind a gate that the human needs to approve

Re: New MCP Roadmap

#88

Post by cube00 »

skybrian wrote: post #85
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 seems like organizations will mostly want remote access via http and the other flavors of MCP aren’t so useful? Although, I suppose if you install an app locally, it might have an MCP interface.

I guess it's similar to SOAP, it was usually over HTTP but sometimes the alternatives were used (eg. email [1])

[1]: https://www.w3.org/TR/soap12-email/

Re: New MCP Roadmap

#89

Post by amluto »

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

Those are mostly at a different layer. You can speak Thrift or Avro or Protobuf over stdio or HTTP or TCP or carrier pigeon.

gRPC spans layers, and it uses HTTP in a more intrusive way than even MCP does — it expects to own the entire URL space at the IP/port in question. Using gRPC in a nontrivial way for MCP would be fairly heavy-weight: you would probably need to set up reflection and figure out how to bind all the MCP calls to it unless you just use it as a tunnel.

Re: New MCP Roadmap

#90

Post by anon84873628 »

AznHisoka wrote: post #80
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…

Maybe I just need more patience, but I took a look at some tools that have MCPs, and their "setup guide" on how to start using the MCP server really gave me brain damage. Is this really easier to work with?

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