Ask HN: Who is using MCP in production?

>MCP apparently reduces probabilistic failures

Does it really do that much difference? I mean in the end robots process MCP output the same way they would process API docs.

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.

I don't know if it counts as production, but I use it for my task tracking, as well as a web GUI. When talking to Claude and working on a plan for a feature, I tell it to cut the tasks into small tickets and write it to my selfmade Ticketboard.

My phone's AI assistant can talk to it too, so if I remember a task mid walk out in the sun, I can just talk to it and it can write it down.

I'm using in production for one of my physical products. The product is a set of 50 printed cards for facilitation. The MCP server can be used by the facilitator to plan their workshop. The reason behind providing MCP is simple: my end-users do not need traditional API, they need something that they can install in their Claude Desktop app and work with the proprietary data of the product. My product's data lives at edge in Cloudflare Workers. (Of course, a determined user can scrap the data if they want, but that's fine.)

Other uses of other people's production MCP I'm using is Dodo Payments' MCP server. It has helped me a ton for looking up their documentation etc. 10xed my OpenCode agent's speed in building payment integration. This was the first serious usage and benefit I experienced of MCP servers.

Reference: My production MCP server: https://www.npmjs.com/package/@sisyphus-consulting/wuwei-mcp

I work with corporate customers, and it has become (literally) the new API management layer, to isolate and audit connections between systems and prevent people from developing random API clients.