121–124 of 124 posts
Before you get too far into the usual “MCP is dead, Skills forever” debate The real valuable capability MCP offers over skills/CLI is isolating the auth flow outside of the agent’s context window, and potentially out of the harness completely. This is valuable from a security perspective obviously. It’s also just a much easier user experience for normies and large businesses adopting AI tools. I hear all the context…
Earlier quoted context omitted.
We had the same issue with the client_id and for security reason we weren't willing to enable DCR. What we ended up doing, was the app proxying the OAuth flow, to inject a hardcoded client_id. So we lie to the MCP client telling it we support DCR while behind the hood we use a standalone client_id as usual for the MCP. If you want to take example at it https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...
Depending on the setup, you just have to be really careful to avoid confused deputy scenarios. I wrote about it: https://den.dev/blog/mcp-confused-deputy-api-management/
Earlier quoted context omitted.
I think that this extension points out other benefits to MCP over skills: * centralized control * ease of use for employees * auditing/compliance * deployment model It seems the state of the art for deploying skills is "copy this file and put it in this place" or "check out this repo and add a symlink" or "run this slash command to install the skill". (I'm not aware of any solution that pushes skills out.) These opti…
Isn’t tool drift/version also a benefit? Especially in scenarios where the use must be standardized and up to date?