Ask HN: Who is using MCP in production?
I’ve been following MCP since it first came out.
It got a lot of attention early on, but I haven’t come across many people using it in production.
I may simply have missed them.
If you’re using MCP in production, what are you using it for? What advantages have you found over a normal API or direct tool integration or just CLI?
232 comments
[ 0.20 ms ] story [ 90.1 ms ] threadRead more about mcp tools/resources/prompts.
This makes it a little more interesting to me, knowing those results.
It definitely underlines what we already know about the specific weaknesses of LLMs replies/results.
Does it really do that much difference? I mean in the end robots process MCP output the same way they would process API docs.
It searches to make sure it isn't a duplicate, writes up the ticket, then submits it.
Because it's a production tool, we want the cheapest possible one without it being too inaccurate. If you used a API etc, you'd end up building what's effectively a MCP-like adapter on top of it anyway so it could communicate in natural language instead of dealing with JSON and such.
Linear's MCP is also very clean and well designed, probably one of their core advantages over, say, Jira. I wouldn't know what the API looks like because the MCP works great.
I was under the impression that Linear's MCP server code isn't public. How do you know that it's well-designed beyond following spec[1][2]?
[1] https://linear.app/docs/mcp [2] https://modelcontextprotocol.io/specification/2026-07-28
Hacker News and YC promote it like crazy because they are non technical morons.
The YC founders shaping our society with their dads leading the rounds are turning it into Idiocracy one fundraising round at a time.
We have received very good feedback from clients across the enterprise and consumer segments, they really like it.
By what metric? I would expect that a thin API client (with readable code) is generally going to out-perform a tool-surface which you don't have the ability to manage/edit.
I run a lot of services to track my life and work and theoritically I could hook up their apis or mcp if supported to a harness and pretend like "oh its a talking computer that can do whatever i ask" but in reality, I can go through the native ui of those services esp with things like hot-keys for a faster and more ergonomic experience than talking to a jarvis and having to recorrect it if its wrong
Getting things like this to work well, for me, often boils down to finding out the things I don't know that I don't know in as little time as possible. I worked with Claude to create a basic debugging front-end as part of that - for my own use, inspecting the data, looking for patterns - when, largely on a whim, I asked Claude to create an MCP interface on top: last run status, what's looking good, whats not, where are the coverage gaps in the individual data points.
And I added the MVP to Claude and would check in regularly to ask how things were going.
And then - I'd ask for some nuance about why something doesn't look quite right. Or what happened to councils in general last night? And - out of nowhere, not being prompted or asked - Claude would query the MCP alongside looking at the code. Immediate production-grade insight while I'm debugging from the comfort of my chair.
And I thought "Oh."
And "this is really quite good," because the key detail is, I think, if an MCP is good and works well, and relevant to what you're doing every day at that point in time, it's yet another addition to your toolbox.
And that got me thinking about how I can do the same for my 9-5 users.
(1) https://github.com/dmtrKovalenko/fff
I wont advertise any commercial mcp I use but to give an example for a well designed and useful mcp server I could name the nixos mcp. Its useful because it bundles all the nix resources to one endpoint which is more efficient than web search and gives you better control over the sources.
https://github.com/utensils/mcp-nixos
Another one would be this filesystem mcp which is in my opinion to prefer over direct cli access. Of course this depends also on your general sandbox strategy but if you just use a generic docker image there are still many potentially dangerous binaries available and such an mcp can restrict the models capabilities.
https://github.com/modelcontextprotocol/servers/tree/main/sr...
And of course there are many service provider offering their mcp with its own llm / agent behind e.g. most web search provider. In this case you most likely already use an mcp without noticing it.
It feels like there is a significant amount of baggage with MCP. It had first mover advantage- coming in at a time when the frontier looked much different. Models were significantly less predictable, would consistently screw up tool calls- and couldn't quickly find a good path to interfacing directly with an API.
Things are much different now- and I'm frustrated to see that new projects on my team still consider MCP as a reasonable first pass solution for getting data in front of a model. Everyone uses Claude Code (cli, desktop; I also am frustrated that so many people use CC over alternatives- that's another rant) and thus, everyone has an harness that'll happily leverage shell + skills to get things done precisely. So- why? Why is it that I see my team-mates all using the same Atlassian MCP server that's flawed- which we don't control the tool surface of? Why not point an agent at the API spec? If the answer is that it's too slow to startup, having to read the API spec to figure out what to do- then, point it at your .claude/.codex/.whatever directory- find where the agent has used tools from the MCP server, and create skills or some thin client surface.
And I will grant that yes, I have observed that a well-engineered MCP server can offer better performance than giving an agent a loosely defined task to perform with an API. However- 'well-engineered' is not easy to achieve. You must run many iterations of benchmarks and evaluations, observe trajectories, and improve the tool surface over many iterations. You also cannot predict users- so you need to monitor the usage, and improve over time. It's a heavy lift.
Additionally- no-one is benchmarking this stuff. They throw MCP at the problem, and call it a day once an agent can achieve the task. Frustrating.
I tried for a while to speak up and suggest that maybe MCP might not be worth the effort compared to improving the UX (or, AX) of API surfaces, or instead putting cycles towards better data storage and presentation. But I find that I'm starting to feel like a dick for bringing vocalizing this consistently when MCP is mentioned.
I realize this is deep into rant territory by this point. However, anonymous posting on the internet can be good for the soul. Anyway- it generally feels as though others are not as interested as I am in eating their pride, generating research, and improving what we know, and how we do things. This goes back to CC- I am the only member of my team that is not using CC as their daily driver. Again- I feel like a dick, but my god, I sound like a broken record suggesting that others try different models and harnesses. I hear constant half-complaints about verbosity of output, or churn- and barely anyone has been willing to give OpenAI models a spin.
I can't bear to hear a group pity-party about how model output is exhausting to read- when the complaints are exclusive to Anthropic models, and no-one has even read the prompting guidance which states clearly how to drop the verbosity/density/flowery-ness of output.
And for the love of god. Stop trying to make models from other providers work in CC. It is not impossible; but it is by nature, a hacking-unfriendly platform. I promise you that CC cli is not the only coding-agent cli tool that you will feel comfortable using. Actually- I'm willing to double down and bet that you will loathe CC cli once you see what the grass looks like out of that orange walled garden. Bah!
-
Edit: AND! What's the obsession with these (https://artificialanalysis.ai/articles/search-api) products? What's wrong with: porridgeraisin ↗ Many of the other search APIs are better than in the inbuilt claude or codex ones. You can try this out yourself by e.g enabling exa in codex plugins.
That’s where mcp (and recently webmcp) have their benefits. By design, the protocols provide predictable structure that allows agents to discover and use the tools you provide.
I’ve had success using mcp variously as an agent friendly wrapper to an existing api and as a greenfield product designed for agentic workflows. Agentic workflows can string together multiple api endpoints together into a single tool call and or use their own dedicated backends.
To share my learnings, I’ve released a free tool at http://anc.dev . While It’s still very much a work in progress, I’d love dialog and constructive feedback.
Now we can point any voice agent platform we choose -- eleven labs, vapi, pipecat, whatever -- at our custom MCP server and it instantly has an understanding of the tools available, their inputs, and how to use them.
Compared to the alternatives everyone on HN champions, like clis and APIs, this is a no brainer. I'm honestly not even sure what the realistic alternative would even be.
Am I supposed to package and distribute a cli to ElevenLabs and ask them to use it? Give them a full API spec to implement for me?
I give them an endpoint and credentials and their platform instantly knows how to talk to mine. No one at ElevenLabs knows or cares about our implementation details.
HN has trouble seeing past the "developer in a terminal coding with Claude Code" use case for using AI. Real production agents have use cases that are very different!
When you don't own every piece of an integration with another system, there needs to be a well defined standard. That's what MCP provides.
Voice transport medium aside, the actual use case is not quite what you described.
Companies like Eleven Labs and Vapi provide a full end to end voice agent platform. They handle the STT -> LLM -> TTS pipeline and infrastructure for voice agents. Think of a customer talking to a virtual receptionist to schedule an appointment.
On the ElevenLabs platform, you provide them a system prompt (or an entire workflow/graph of system prompts) that instruct the voice agent on how to talk to the customer, tone, guardrails, how to answer specific questions, etc.
At some point we need that LLM agent, running on an infrastructure we don't control, to talk to our "CRM" (for simplicity sake). Enter MCP.
The MCP server we build and host supplies the "tools", like list_appointments, schedule_appointment, cancel_appointment-- whatever they may be.
When eleven Labs voice agent connects, it sees all the tools available and can use them per the instructions in the system prompt.
The current framework that solves this the best right now is FiPA.
Establish identity the same way we always have, AS defines the challenges, the client (voice agent in this case) goes and gets them. OAuth from there!
The biggest issues are usually that a third-party MCP server you're trying to use either has misconfigured CORS so the browser can't hit it, has a bespoke OAuth setup which doesn't work with @modelcontextprotocol/client, or they don't support Dynamic Client Registration (DCR) so you can't just point at it and use it. It's nice when none of these apply and it Just Works, the user can auth easily with the third-party and refresh tokens automatically handled in the background by the client.
That's the advantage, really - you didn't have to define the tools yourself, auth is handled for you, and the agent doesn't need to (and can't) access credentials or tokens as it knows nothing about MCP.
To put this into perspective, I was a voracious social media user for decades. For me, this is 25 years of data, close to 100,000 posts, spanning everything from LiveJournal in 2001 to Mastodon in 2026. But when put together, it is a timeline of my life.
As kind of a last minute idea, I added an MCP server because why not? Once I wired an LLM up to it, I could ask introspective questions and find new ways of looking at myself and my own history. Simple things like "what was I doing 10 years ago around this time?" to more complex things like researching past thought patterns.
[0] https://github.com/rebeccathedev/afterfeed/