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

71–80 of 184 posts

Re: New MCP Roadmap

#71

Post by Gormo »

amluto wrote: post #69
ihuman wrote: post #63

Earlier quoted context omitted.

Is stdio being deprecated? I couldn't tell from this page

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.

Re: New MCP Roadmap

#72

Post by intrasight »

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.

Count me as not on board

Re: New MCP Roadmap

#73

Post by intrasight »

mathisfun123 wrote: post #66
ihuman wrote: post #64

Earlier quoted context omitted.

I don't want to expose my API key to Claude. An stdio MCP server wrapping an API lets me hide it

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.

Re: New MCP Roadmap

#74

Post by ulrikrasmussen »

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

Yep. I’ve found that having an endpoint that serves a well, documented openapi.yaml is very effective for agentic usage. The biggest difference is that you can break down a REST API into RPC-like chunks and save on some tokens if you break up the tools well. But pragmatically, I think saying “tell your agent to hit /api/v3/openapi.yaml” is quite useful

We did a prototype to integrate an agent into our application and basically just gave it a tool to discover the OpenAPI spec and call endpoints. It worked surprisingly well! One caveat was that some responses were too big and would poison the context, but then I gave the agent a GraalJS engine and allowed it to save responses and post-process them using JS. For the little amount of work required this gives the agent a lot of power without having to give it full CLI and without having to create bespoke tools.

Re: New MCP Roadmap

#75

Post by dmix »

mmaunder wrote: post #70
brap wrote: post #65

Earlier quoted context omitted.

I mean… so just HTTP + OpenAPI spec?

It actually doesn’t matter. Pick your favorite way of giving a dev access to capability on a remote server.

Plus You're likely building an API already if you have an MCP. Not everyone using MCP is a dev, we have random corporate workers using our MCP. They don't know what an API is but they can add a plugin from an agent marketplace (which can also contain skills) and MCP is a bit narrower with a clear authorization system, tool discovery, and annotations (agents ask "confirm you want you want to write this").

Just give your end-users flexible options. If they have Claude Code then build more around the API side if needed.

Re: New MCP Roadmap

#77

Post by rolisz »

nozzlegear wrote: post #25
willio58 wrote: post #13

Earlier quoted context omitted.

So I’ve been working on a personal finance app, and I added an MCP to it. Connected my Claude to it, mainly for testing purposes. The other day I was heading to Home Depot to buy some gardening stuff and I was asking some some questions around what I could plant at this time and still harvest before winter. It answers me, then brings up how my home improvement budget is nearing its limit for the month. I then ask it…

Is that really much different from building an API for your app though? Claude can use those just as easily.

With authentication and on mobile?

I agree that on desktop it's not particularly relevant. Or through openclaw.

But for most people who use it through mobile, MCP solves some problems.

Re: New MCP Roadmap

#78

Post by tass »

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?

Because it’s something else that’s non-standard between providers.

Re: New MCP Roadmap

#79

Post by stillpointlab »

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?

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 like authentication, authorization, governance, etc. then MCP starts to pay off.

If you do not need those capabilities, then you do not need MCP. And then you shouldn't use it. But if you do need those capabilities then it might be worth using MCP rather than inventing your own way to do them.

Re: New MCP Roadmap

#80

Post by AznHisoka »

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…

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?
Post reply on HN