151–160 of 184 posts
Earlier quoted context omitted.
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.
What are you, some sort of luddite?
Earlier quoted context omitted.
agree. it seems there are two streams and they could diverge or converge? 1. workloads use existing credentials support RFC 7523 and OIDC discovery, 'trust the trust (credentials) which has already been established'. basically extend current dominant NHI paradigm. 2. DPoP mandate a signed proof for each request. so tie credential to a client-held key and specific request detail or context. viable to do at scale with…
It is viable. Think of workload identity federation as the mechanism for the client to get an bearer token initially, and DPoP as the mechanism for the client to present the access token to a resource server. Each DPoP proof is entirely self-contained, so resource servers don't need to manage any additional state. The only new state is the (usually ephemeral) private key held by the client: 1. Client generates a priv…
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.
* Your agent can easily be configured to always allow certain MCP tools. This is very hard to do for only certain REST endpoints. This is even more relevant in enterprise settings, where permission configs might be done centrally.
* If the provider wants to change how an endpoint works, it's a breaking change for a REST API. Not with MCP, as the "endpoints" (tools) are dynamic and tell the agent how to use them.
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.
Off the top of my head: * Your agent can easily be configured to always allow certain MCP tools. This is very hard to do for only certain REST endpoints. This is even more relevant in enterprise settings, where permission configs might be done centrally. * If the provider wants to change how an endpoint works, it's a breaking change for a REST API. Not with MCP, as the "endpoints" (tools) are dynamic and tell the age…
Its insane to me how quickly people flocked to the idea of building a parallel web to maintain for non humans.
I shouldnt be surprised seeing how low priority human accessibility and ux has been on the web when compared to the needs of the all consuming parasite that is ad tech.
People seem to ignore the fact that with MCP you can serve up the tools the user wants and has access to instead of a rest api doc specifying every endpoint and bloating the context.
All those tools still get into context. Also, it's not hard to filter a rest api doc - like with a special tool for that the harness itself could pre-filter it and add only the relevant ones as tools to be even more leaner than what an MCP returns.
100% up to the harness. Most harnesses either fixed (or dymanically depending on size) nowadays add a "search_tool" tool to prevent spamming the context with all tools.
The entire premise of MCP is misguided and completely counter to the core value proposition of ai agents. Its insane to me how quickly people flocked to the idea of building a parallel web to maintain for non humans. I shouldnt be surprised seeing how low priority human accessibility and ux has been on the web when compared to the needs of the all consuming parasite that is ad tech.