Rendered at 07:29:35 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Aldipower 20 minutes ago [-]
We use MCP in production since March 26 for user-facing endurance sports analytics and planning that integrates directly with the MCP host, in this case the chat interfaces of ChatGPT, Claude, Grok, Perplexity.ai, Mistral, you name it. All of those let users add either custom MCP servers, which users can do with a simply explanation. To connect Claude for example: https://www.tredict.com/faq/connect-claude-web-with-tredict/
This way a users can use Claude f.ex. to create and push workouts with their Garmin devices based on an prior analysis.
We also have an ChatGPT App, which uses MCP in the background: https://chatgpt.com/plugins/plugin_asdk_app_69aef5b699a08191...
The point here is, MCP is the backbone behind the product and enables regular users to do things without knowing anything about it.
The whole "is MCP useless?" discussion is totally pointless from a regular consumer-user perspective, they even do not know what MCP is sometimes. The Tredict ChatGPT App connects with one click and a simple oauth flow. That's it.
SegmentTree 22 minutes ago [-]
We use MCP when security and tight capability boundaries are important.
For example, even GitHub’s fine-grained tokens aren’t always fine-grained enough for our use cases. In those situations, it’s straightforward to build a small MCP server that exposes exactly the operations we want an agent to have access to.
That gives us a much smaller and more explicit attack surface, without having to manually audit every possible GitHub CLI invocation the agent might make.
simonw 1 hours ago [-]
I recently started using it as a way to make my own custom software available to regular ChatGPT and Claude, both of which support MCP if you dig around deep enough. Here's my TIL: https://til.simonwillison.net/llms/mcp-in-claude-and-chatgpt
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.
My context is realtime visual effect creation, but I’ve used MCP extensively in my (native) custom harness as a way to drive in—app UI updates and of course bidirectional state queries, including framebuffer capture for closed loop verification.
I feel like CLI would probably work too but then I’d end up implementing something similar.
That being said, I’ve been bitten by the usual suspects: too many tools will cause context windows to grow quickly and some agents will sometimes skim through a subset of the tool list without querying the entire thing, causing incorrect behavior.
Another kind of cool use of MCP that I’ve encountered is actually from… the French government! They do it for their open data initiative: https://github.com/datagouv/datagouv-mcp
RebeccaTheDev 4 hours ago [-]
For what I am using it for, I recently wrote a little web app called Afterfeed [0] that lets you view backups from social media websites as a single unified timeline.
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.
Interesting idea. I left social media over half a decade ago and just nuked my accounts. Something like this could have been useful. Like a personal archive
MitziMoto 4 hours ago [-]
We use MCP in production for our customer facing voice agents. Our custom MCP server defines tools and resources that the voice agents need access to to interact with our customers. (E.g. scheduling appointments, checking order status, etc).
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.
denkmoon 4 hours ago [-]
Excuse me for being dense but I'd love to know more, if you can share. So you offer a voice agent for checking appointments and orders and stuff, is that through your app or website or something? So you make a button in your app which says "talk to our AI", and you've got the button set up so that it can send the customer's input query, along with a bit of text saying "our MCP is here, use it to answer the query", to any one of the voice agent providers? then you get some audio data in return that you play to the user?
MitziMoto 4 hours ago [-]
We use a Twilio integration to make it work over a real phone line, but it could just as well be an app or websocket connection in a browser.
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.
jdironman 3 hours ago [-]
How is security handled in a situation like this? (I'll end up reading up on it). But I mean things like how does the API let a specific session with a specific user only surface information for that specific user from the available tooling?
cco 2 hours ago [-]
Not the poster, but working on this right now.
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!
cagz 1 hours ago [-]
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.
earthdeity 6 hours ago [-]
I hooked up claude code to Jira and Figma.
This is more a condemnation of Jira than anything, but being able to interact with it in natural language in the terminal is a huge relief.
Sadly, it's still limited in some ways.
If it's available, it makes things a tiny bit easier than interfacing directly via api, so it's a nice to have.
jadar 5 hours ago [-]
I did this as well. I found that it was really inefficient because if I was doing anything with a significant amount of text, it has to shuttle all of that through the model to the MCP invocation. It was way better to work with temporary files and pipe them around CLI tools once you’re happy with the contents. E.g. developing a user story and creating the Jira issue.
agentdev001 6 hours ago [-]
> "it makes things a tiny bit easier than interfacing directly via api"
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.
altmanaltman 2 hours ago [-]
This is what I don't get often when people say "ai will be the ui". Like pressing a button to get an action done for me will always be quicker than asking an LLM to do an action and then waiting for it to understand and do that action. Why will I not prefer to just press the button?
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
lazyasciiart 19 minutes ago [-]
When you are holding a pet, or washing the dishes?
fl0id 15 minutes ago [-]
not OP, but then I'm washing the dishes and don't need to do anything else.
Our_Benefactors 5 hours ago [-]
If you don’t use the MCP Claude will default to taking screenshots of figma designs.
rcarmo 28 minutes ago [-]
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.
VanTodi 57 minutes ago [-]
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.
hnlmorg 43 minutes ago [-]
Advantages vs skills: connecting to enterprise systems via OAuth.
Yeah you could call CLI tools that support OAuth, but then you have two sets tools (CLI plus a skills file) to manage manually instead of a hosted MCP server.
cjonas 2 hours ago [-]
We use mcp as a "gateway" for a customer facing cloud agent. It basically is just a tool registry and could have been built using open-api... but MCP is arguably more robust/aligned for context management and the agent frameworks and observability tools support it first class.
spiderfarmer 9 minutes ago [-]
For some of my projects I use it instead of a CMS. I still have that CMS, but I rarely use it anymore.
Could I have used an API? Maybe. But Laravel MCP makes it very easy to run a MCP server.
ma2kx 5 hours ago [-]
In general the advantage of MCP would be the possibility for a fine grained control over the tools the agent is allowed to use. But unfortunately there is a myriad of nightmarish awful mcp servers around which are worse than direct API access or even a cli integration.
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.
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.
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.
boltguo 7 hours ago [-]
I built a small MCP service tool to my own learning; it retrieves study materials and course content, enabling me to learn through voice-based interactive conversations with ChatGPT. logs my learning data, which I can then retrieve and analyze to assess my overall progress.
brettdav 4 hours ago [-]
I’ve deployed mcp to prod on numerous internal apps where ai-integration has been first party requirement. Obviously, agents can use an existing api, however maximum capability requires it to be well designed and documented. As many of you may have experienced, that is not something that can be assumed and improvements may be “impossible” or at least out of current scope.
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 https://anc.dev . While It’s still very much a work in progress, I’d love dialog and constructive feedback.
hhh 2 hours ago [-]
We use it for access to gitlab, ado, github, datadog, rancher. I think the rancher one is the worst. We develop custom MCP servers for our internal stuff for agents to use, and it all gets accessed thru agentgateway.
I don’t really like having to use MCP but we don’t have a good solution for authorizing individual calls outbound from a sandbox without choosing to just not care about the sandbox.
mootothemax 6 hours ago [-]
I recently created a planning applications scraper for every council/local planning authority in the UK, very much with Claude's help. As you can no doubt imagine, it's the type of task where the mechanics are far less important than everything surrounding them.
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.
skiing_crawling 2 hours ago [-]
Having a hard time understanding what MCP is really for. Even for my small local models, if MCP is not available, they seem to do just fine connecting to anything I need with an API and falling back to using a browser.
4 hours ago [-]
Surac 2 hours ago [-]
My Company developed a MCP ti control our product we ship to Customers. So we use it inhouse for testing. It was so convenient that multiple Software developer adopted the mcp tosetup there test environents
xcf_seetan 2 hours ago [-]
I am being working on a new ui framework and will deliver a mcp, a lsp and a skill to help create new apps, because as it is new, it is not in any data used for training any llm.
willsmith72 1 hours ago [-]
Internally we have MCPs for many many tools, I would expect if anyone builds a product or new feature today it has an MCP or skill
igor_nast 19 hours ago [-]
We have it, a fresh tool that landed recently in prod. Makes it easier to communicate with the app resources. And it's a standardised way for agents to talk to a remote resource, easier for them to understand what is available and how to use it.
Read more about mcp tools/resources/prompts.
latchkey 6 hours ago [-]
I don't understand the need to make things easier for a robot. Point them at an API and they can figure it out. Can you explain in more detail what is easier?
DANmode 6 hours ago [-]
MCP apparently reduces probabilistic failures - aka the common fatal flaw of all of these robots (hallucinations, missing stuff in the API doc, etc).
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.
mapcars 1 hours ago [-]
>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.
latchkey 6 hours ago [-]
I think that was a problem 6 months ago, but GPT 5.6 Sol on xhigh doesn't have those sorts of issues. I don't think it'll last. Things are moving fast.
bigstrat2003 5 hours ago [-]
People say that with every single model release, and every single time they're wrong. I bet you anything that it's no different this time than the last dozen times.
latchkey 5 hours ago [-]
i'm burning 500m tokens a day "writing code" for 83 days straight. one of those projects i'm building integrates netbox, stripe, quickbooks, mercury and deel all together via api. i wrote zero lines of code and read zero api docs. it does exactly what i want and gives me a 360 degree view of every aspect of my multi million dollar arr biz.
how about you?
hypfer 2 hours ago [-]
360°? That's weak.
The real experts have a 720° FoV with multiverse time travel.
DANmode 6 hours ago [-]
I’d be willing to believe that!
Corporate still runs lots of bullshit for compliance, though.
latchkey 6 hours ago [-]
what happens when openai offers compliance as a service?
ballsac 5 hours ago [-]
Why don’t you tell us instead of asking questions
DANmode 5 hours ago [-]
I’m getting most of it, but fair critique lol
It’s not clear, but if you have a handle on how it might go, I’m interested in that take (saying this to anyone).
muzani 19 hours ago [-]
I used one for an AI tool that allows people to report bugs/feature request directly.
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.
blackqueeriroh 2 hours ago [-]
Atlassian’s MCP is phenomenal and they e had theirs longer than Linear
InfiniteLoup 12 hours ago [-]
>Linear's MCP is also very clean and well designed, probably one of their core advantages over, say, Jira.
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]?
They probably mean the tool APIs that the MCP server exposes are well designed. Definitely makes a big difference.
tbrntbqm 11 hours ago [-]
That's what we used in our product - a bug report tool that uses Linear MCP to create a task. Works great.
caudena 6 hours ago [-]
Caudena released some of its enterprise capabilities within MCP last year, and made them available to the consumer market this year at https://mcp.caudexcatena.com/.
We have received very good feedback from clients across the enterprise and consumer segments, they really like it.
Motheki 5 hours ago [-]
I use fff [1] For the performance improvements when reading files. I prefer in most scenarios to use skills.
Building an agent runtime at cadenya.com and MCP servers have been the hardest part to create adapters for. For a two year old spec, there's far too many permutations.
reilly3000 6 hours ago [-]
MCP is still the main way I use Cursor with enterprise systems like Glean, Jira, and Port. Other than that, everything, especially you GitHub, is moved to CLIs (+skills as needed)
insin 4 hours ago [-]
I work on an F100's internal, vendor/model-independent LLM chat app whose agent runs in your browser, so CLI isn't an option, direct API is out as the agent deliberately doesn't have any tools for hitting arbitrary URLs and it can't access the network via its iframe-sandboxed code execution tool, so we use MCP in the harness to let it do third-party things, with e.g. Atlassian and GitHub MCP servers pre-configured and support for BYO MCP if there are compatible third-party servers you want to use, or are running your own locally to provide tools to let it do things on your machine (it can already be given R/W access to your local filesystem via showDirectoryPicker()).
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.
mrubon 9 hours ago [-]
I find clis or calling apis directly to be waaay cheaper and faster. The only mcp i use at this point is the jira mcp only because i set it up a while ago and it's been there for a long time now
sonofaragorn 6 hours ago [-]
We used to use the jira mcp, then a jira skill, and now simply use the jira acli. Much cheaper and works fine
altbdoor 7 hours ago [-]
Jira/Atlassian APIs are so convoluted anyways, I'd rather use the MCP
ntlm1686 7 hours ago [-]
many things once needed a MCP server now could be easily done via using CLI by agent
branislav 1 hours ago [-]
I’m curious, how do you handle authorization of the user without leaking tokens/api keys to model context without an MCP server (which supports OAuth, in principle)?
royal__ 6 hours ago [-]
This is the answer.
sonofaragorn 6 hours ago [-]
yes! I think it's yet another fad that is slowyly dying. I wish my company hadn't spent a whole team working for like 6 months creating an MCP server that no one will ever really use at scale
vips7L 2 hours ago [-]
Dead tech
JohnHaugeland 6 hours ago [-]
i’m a day or two from releasing my programming language’s new mcp
agentdev001 5 hours ago [-]
I am not using MCP in be production- but, my team is. My team also produces MCP servers for other teams, and I find it a bit maddening. I wonder if anyone can relate to my experience here.
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!
The point here is, MCP is the backbone behind the product and enables regular users to do things without knowing anything about it.
The whole "is MCP useless?" discussion is totally pointless from a regular consumer-user perspective, they even do not know what MCP is sometimes. The Tredict ChatGPT App connects with one click and a simple oauth flow. That's it.
For example, even GitHub’s fine-grained tokens aren’t always fine-grained enough for our use cases. In those situations, it’s straightforward to build a small MCP server that exposes exactly the operations we want an agent to have access to.
That gives us a much smaller and more explicit attack surface, without having to manually audit every possible GitHub CLI invocation the agent might make.
I reversed engineered my supermarket API and made a custom MCP to automate my grocery shopping. Now I can fill my cart through ChatGPT.
More details about it on https://ducret.dev/grocery-shopping-with-ai/
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 feel like CLI would probably work too but then I’d end up implementing something similar. That being said, I’ve been bitten by the usual suspects: too many tools will cause context windows to grow quickly and some agents will sometimes skim through a subset of the tool list without querying the entire thing, causing incorrect behavior.
If you have tokens to burn I invite you to check out the source code see how extensively it’s being used: https://github.com/sxp-studio/subjective-zero
(video to see the MCP in action, it’s a bit long so feel free to skip: https://www.youtube.com/watch?v=DcI1tsPJ8eM)
Another kind of cool use of MCP that I’ve encountered is actually from… the French government! They do it for their open data initiative: https://github.com/datagouv/datagouv-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/
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!
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.
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
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.
Yeah you could call CLI tools that support OAuth, but then you have two sets tools (CLI plus a skills file) to manage manually instead of a hosted MCP server.
Could I have used an API? Maybe. But Laravel MCP makes it very easy to run a MCP server.
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.
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 https://anc.dev . While It’s still very much a work in progress, I’d love dialog and constructive feedback.
I don’t really like having to use MCP but we don’t have a good solution for authorizing individual calls outbound from a sandbox without choosing to just not care about the sandbox.
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.
Read 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.
how about you?
The real experts have a 720° FoV with multiverse time travel.
Corporate still runs lots of bullshit for compliance, though.
It’s not clear, but if you have a handle on how it might go, I’m interested in that take (saying this to anyone).
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
We have received very good feedback from clients across the enterprise and consumer segments, they really like it.
(1) https://github.com/dmtrKovalenko/fff
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.
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: https://platform.claude.com/docs/en/agents-and-tools/tool-us... and https://developers.openai.com/api/docs/guides/tools-web-sear... (or, OpenAI's alpha/search endpoint)