Yes, quite a few uses in prod, main use case being abstracting API access for agents. In our case these are mostly in-house MCP servers, purpose built for the given agent.

Why MCP instead of CLI or agent accessing API directly?

Direct access (Curl/own small function): This requires agent to have full understanding of the API spec. Yes, context can be protected using progressive disclosure, but this essentially means agent needing to understand the API again and again, before every use in that context. Also, a typical API spec may or may not be agent-friendly. If there are nuances when calling an endpoint, where do we put these? Into OAS description? Works, but clunky.

CLI: It works beautifully, especially when a 3rd party CLI already exists for a complex backend. Assumes a well documented, agent friendly CLI, most CLIs are designed for human or CI/CD consumption. Talking about MCP taking up too much context, think about agent starting with my_cli --help, and going down through the switches and parameters one at a time to figure out how the CLI should be called. Less of a problem when calling a well know CLI (e.g. aws), but anything more niche (or custom) requires multiple turns to compose the final CLI command.

MCP: Has its issues, but offers an agent-native solution. Everything agent needs to know about a tool becomes available at once. In an enterprise environment MCPs can be served through an MCP Gateway, providing governance and permission management, this is quite contrast against running a CLI that requires agent to have execute permissions in its shell.

I must mention that we also utilise lazy-loading of MCPs. In use cases where 10s of tools needs to be loaded, only the most common ones are pre-loaded, then agent kernel connects the others as an when needed, and release them after a timeout (in case of long running sessions). This keeps the context lean.

We have taken to letting our agents use specific CLIs directly and we narrow down their access control with nono tool sandboxing via a customized Pi agent running headless. We have one agent that can use the aws CLI and nono feeds in a phantom SigV4 credential and then policy limits to just read-only http methods and certain L7 filtering on paths to limit its abilities - this means we can have it monitor and debug deployment failures without it doing any damage.

It was all largely based off this example https://github.com/nolabs-ai/nono/tree/main/tool-sandbox-exa...

I'm really curious how you're dealing with lazy loading. Is the MCP then more like a tool-helper instead of the tools themselves?

I was trying to find out if the MCP has some sort of lazy loading feature/primitive in the works, but there seem to be a lot of disagreements about it.

Intuitively, lazy loading seems to be somewhere between a CLI and vanilla MCP. In the end, it sounds very similar to tiered/ progressive loading similar to images on low bandwidth connections.