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.
MCP can also handle authorization, since you don't want to put your password to skills.md and send it to China
New MCP Roadmap
101–110 of 184 posts
Re: New MCP Roadmap
#102[dead]
Re: New MCP Roadmap
#103> With the 2026-07-28 release, a remote MCP server is now no different from any other HTTP workload Good. Introducing a bespoke new protocol was one of the more bone-headed things MCP did on initial release.
It's unreal how bad the initial rollout was between HTTP/streaming and stdio, bearer auth and OAuth. Virtually every client/MCP server pair had a different portion of that matrix implemented.
The real disaster was making it stateful. Need to get some adults in the room.
Re: New MCP Roadmap
#104Earlier 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.
Oh sorry I didn't explain that we are not dumping the entire endpoint list to the MCP. We have 400+ endpoints so this would be terrible.
We tag each endpoint by category in the OpenAPI spec and require the MCP to request actions by tag and optional query term. At most we return 10 endpoints at a time and the LLM can request more using pagination.
These tags also create your categories in API doc websites like swagger/mintlify so its a win win.
OpenAPI spec is the single source of truth.
Re: New MCP Roadmap
#105I think MCP is jumping some sharks here.
Nobody needs to have every functionality of HTTP offloaded to MCP at all, at this point.
I'll stick to the bare minimum that works.
Re: New MCP Roadmap
#106Earlier quoted context omitted.
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 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.
Re: New MCP Roadmap
#107Earlier quoted context omitted.
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 :)
> 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.
Re: New MCP Roadmap
#108[flagged]
Re: New MCP Roadmap
#109I think MCP is jumping some sharks here. Nobody needs to have every functionality of HTTP offloaded to MCP at all, at this point. I'll stick to the bare minimum that works.
Agree 100%, the elegance of JSON-RPC is a virtue.
Re: New MCP Roadmap
#110Earlier 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.
Just because a MCP server offers 100 MCP tools doesn't mean that they all have to be in your context. Any decent harness will let you filter out ones you don't want. And to take that concept further you really should be designing specialized subagents that only have access to a small subset of total MCP tools in the first place.