The degree to which this idea has been overcomplicated is confusing. This could have been solved with some relatively simple patterns wrapped around HTTP and WebSockets (and if absolutely necessary, SSE).
New MCP Roadmap
121–130 of 184 posts
Re: New MCP Roadmap
#122I 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 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...
The perceived difficulty is not what is at play here. People and employers are not comfortable with the idea of long lived credentials to begin with -- and even less in the 'hands' of an AI agent.
The complexity in these protocols is mostly essential in nature (to the extent that you're not willing to totally reinvent the protocol, like AAuth).
Re: New MCP Roadmap
#123[flagged]
Re: New MCP Roadmap
#124[flagged]
Re: New MCP Roadmap
#125Earlier quoted context omitted.
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.
If that truly is the main selling point - it seems like a shallow moat versus skills + rest..
Re: New MCP Roadmap
#126I 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 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...
That doesn't work well for enterprise-managed MCP, where you actually do want the user to overtly authorize their agent to user their identity for MCP services, rather than the MCP server just setting a user ID in an HTTP header somewhere and everyone hoping for the best.
Re: New MCP Roadmap
#127Sometimes I really respect senior developers. When specs change, you obviously have to update existing work too. Looking at this MCP change, it seems like it's becoming stateless—I'm already wondering how to adapt. Senior programmers always advised me to only use things that have been around for at least three years. Now I finally understand why.
At this point, I think 5 or even 10 years would be a more appropriate number (except for minor updates over things that have been around for a long time).
I clearly remember there was a time coffeescript looked really like the future of javascript.
Re: New MCP Roadmap
#128I 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 determinism, flexibility, and language.
To the LLM, the a skill input is deterministic, inflexible, and outputs natural language.
A REST API (not the REST itself, but modern output being JSON primitives) outputs are deterministic, flexible, but doesn't output natural language.
An MCP as an input is deterministic, flexible, outputs natural language.
Then we ask the same question on whether the LLM gets back a response that is deterministic. Skills output are not deterministic, it requires LLM to generate tokens to take action. It may or may not take the specific actions instructed by the skill.
So, Skills + REST API = MCP only if you can deterministically call on the REST API.
Re: New MCP Roadmap
#129I 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 determinism, flexibility, and language. To the LLM, the a skill input is deterministic, inflexible, and outputs natural language. A REST API (not the REST itself, but modern output being JSON primitives) outputs are deterministic, flexible, but doesn't output natural language. An MCP as an input is deterministic, flexible, outputs natural language. Then we ask the same question on whether the LLM gets back a res…
In other words:
* /skill may or may not call on the instructed action
* /tool (or @tool) will guarantee the action is taken
This is overgeneralizing and we need to talk about harness-specific features like hooks (which adds a deterministic action to skill usage).
Re: New MCP Roadmap
#130Why not just give the model a prompt?
Every gain in LLMs is either through increases in compute efficiency, Architecture or Harnesses...
The rest seems like bells and whistles