I'll kick myself for not remembering, but there was a fantastic article which suggested that MCP works at org level when unified, safe, access to internal utility APIs need to be given to non-technical staff who do use internal agent tools. Codify your workflow(s) via skills and share across instances, anything that needs context aware API access should be mcp...
This one? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
Yes, exactly that one! thanks
But what is the advantage of MCP compared to having the agents access the API directly?
Agents are just a stream of text, they cannot access anything. Some kind of interpreter is needed that recognizes special patterns and runs real code.
Do you mean directly == raw shell access on your production server?
So is this in lieu of using permissions to protect apis? Because it seems like API's should have some kind of permission mechanism around them anyway.
Yes and no -- you can give internal agents access to internal APIs by using rudimentary env var, and org level agentic services tend to offer that kind of permission based access (either roll your own, use an 'enterprise' service, or be knowledgeable that if things go wrong, they'll go very wrong). APIs should, at least from my perspective, always have permission mechanisms. But internal APIs, used by 'internal' agents, have access to those the same way users on the network do, just depends on what flavour of network one is using.
Essentially it's anything that _could_ be on a dashboard, but _might_ be accessed conversationally via an agent.
Exactly right. Co’s like Runlayer are growing like wild exactly for this reason. Without a central control plane MCP is a minefield.
hadn't heard of runlayer, but it does make sense. I'm a huge advocate of skills based on the company/process or project owners perspectives and workflow habits rather than using skills.sh or similar. You will end up cosplaying as someone elses perspective and wonder why you don't understand it..