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

111–120 of 184 posts

Re: New MCP Roadmap

#111

Post by notatoad »

boredumb wrote: post #106
stillpointlab wrote: post #79

Earlier quoted context omitted.

It is the automatic distribution and automatic update. The questions isn't "how does one download a text file to another persons computer?". It is "how does someone with a skill.md file on their computer discover that a new version of that file is available". This isn't a "bottleneck" but rather a capability (or lack thereof). As you add more and more capabilities, especially ones relevant to enterprise situations li…

I see. In my head it would be something like the agents harness having a list of services it interacts with, reaches out to service.com/agents.md for a fresh copy every so often and uses that to resolve the relevant tool calls.

>reaches out to service.com/agents.md for a fresh copy every so often and uses that to resolve the relevant tool calls.

that is basically what MCP is. except it answers all the questions that your version handwaves away - how often do you get a fresh copy, how do you describe the relevant tool calls, how are the tools organized, and how does auth work.

Re: New MCP Roadmap

#112

Post by stillpointlab »

boredumb wrote: post #106
stillpointlab wrote: post #79

Earlier quoted context omitted.

It is the automatic distribution and automatic update. The questions isn't "how does one download a text file to another persons computer?". It is "how does someone with a skill.md file on their computer discover that a new version of that file is available". This isn't a "bottleneck" but rather a capability (or lack thereof). As you add more and more capabilities, especially ones relevant to enterprise situations li…

I see. In my head it would be something like the agents harness having a list of services it interacts with, reaches out to service.com/agents.md for a fresh copy every so often and uses that to resolve the relevant tool calls.

Valid. There are many ways to do it.

But for enterprise there may be teams, each developing their own way to do it. Then there will be many different ways that it is done throughout the enterprise, which is hard re: governance. Better/easier to adhere to an industry standard which can be audited, especially for enterprises where that is a legal requirement.

That isn't a reason you should use it, just an explanation about why someone has to use it.

Re: New MCP Roadmap

#113

Post by amluto »

ranger_danger wrote: post #107
amluto wrote: post #83

Earlier quoted context omitted.

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 :)

> if you’re building a protocol that needs to map to HTTP anyway I don't think there is any guarantee that HTTP will always be involved. For example I might be calling a local LLM via CLI/script on a server with a stdio MCP connector that just runs other CLI commands, and never sends any HTTP traffic.

Right. But there is a lot of real-world usage of MCP-over-HTTP-over-the-Internet, and a lot of “harnesses” want to support that use case, so they’re stuck either implementing the HTTP-based protocol or using a shim.

Re: New MCP Roadmap

#115

Post by amluto »

arccy wrote: post #99
amluto wrote: post #89

Earlier quoted context omitted.

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

grpc mcp is a thing... https://cloud.google.com/blog/products/networking/grpc-as-a-...

Wow, that looks like a huge mess.

Re: New MCP Roadmap

#116

Post by lubujackson »

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.

I work on an MCP server and I agree. There is no need to make MCP servers the gateway for agentic or programmatic integration - that's exactly what API servers handle out of the box. The value of MCP servers is fine-toothed access on a tool-by-tool basis and leaving output digestion to the LLM.

LLMs do GREAT utilizing well-defined tools to accomplish tasks. Look at Datadog's MCP, instead of figuring out a multitude of filter and navigation options your LLM can immediately navigate to what you want and extract the precise data you need. Tool instructions with defined I/O structures let LLMs fly.

But for a nightly cron job pulling down stats or something like that? Why the hell do you want to route through a protocol built for in-person consumption? This is such a pointless overreach for the protocol. What would have been better is blessing a standardized pattern for exporting any MCP tool definition into a well-structured API endpoint. Then everything related to API endpoints like doc generation, comes along for free.

Instead we get this kitchen sink protocol that is going headlong toward polyfill hell, since no two IDEs support the same protocol features like structured content, local state, elicitations, etc., even from the same provider - Claude Code/Desktop/web all handle MCP connections differently. It's a shitshow.

Almost every major MCP service uses the same baseline default features (plain context) rather than build around partially-supported features. Why add more and more specs on the pile when adoption is so far behind?

Re: New MCP Roadmap

#117

Post by blazarquasar »

danappelxx wrote: post #61
zackify wrote: post #43

Earlier quoted context omitted.

I think the spec overcomplicates everything honestly. Its not that hard to add a long running auth token and put it in the MCP config as a header to send along and then avoid all the extra special rules. "Oh no it's a long lived token that's bad" Put it in a secret manager like 1pw cli and now start an agent...

How does the agent auth with 1pw? How do you give it access to only the credentials it needs, with an approval flow and revocation? Who renews the token? You’ll likely end up reinventing something pretty close to what MCP is building towards. Authn/authz is one of those things that can be really simple for pointed use cases but gets really complex when you need to support everything.

Quite a few options as of now:

https://www.1password.dev/get-started/secure-ai-access#secur...

https://1password.com/blog/1password-trusted-access-layer-fo...

Still far from perfect tho.

Re: New MCP Roadmap

#118

Post by ethbr1 »

kelseyfrog wrote: post #54
_puk wrote: post #36

Earlier quoted context omitted.

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.

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 they can alert as rarely as possible.

But that's an all-of-ecosystem change: the OS (providing usable boundaries), applications (updating to use minimal boundaries), and users (understanding what they'll need to approve/deny).

Re: New MCP Roadmap

#119

Post by jonathanhefner »

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…

No need to invent skill.md distribution protocols. Use `/.well-known/agent-skills/index.json` -- see https://github.com/agentskills/agentskills/pull/254.

It's already in use in several places (e.g., https://www.mintlify.com/docs/ai/skillmd#skills-discovery-en...) and is supported by `npx skills add`.

Re: New MCP Roadmap

#120

Post by wilj »

skinfaxi wrote: post #3

> We’re starting a progressive discovery effort so a server can offer a small entry point and reveal more of its catalog as the conversation narrows. Kind of late to the party. I've had to implement lazy loading of mcps in a couple of harnesses now but am moving to implement everything as code mode instead.

+1 for code mode. It's a game changer for runtime performance, flexibility of orchestrating lots of tool calls with complex logic, and all sorts of other goodies.

I'm in the process of switching all my personal stuff to a self-hosted fork of cloudflare-os right now. It's taking a lot of rearchitecting how my stuff works to fit within the cloudflare "no local files" paradigm, but for now I've got a container gatekeeper they can drive and they can check repos out in it.

Post reply on HN