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 simple explanation. To connect Claude for example: https://www.tredict.com/faq/connect-claude-web-with-tredict/
This way users can use Claude to create and push workouts with their Garmin devices based on a prior analysis.
We also have a 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.
This. We also thought MCP was useless, but now the workflows by ChatGPT and Claude are so good; it's as good as installing an app from the App Store. We launched MCP for our SaaS and immediately found users using it.
API and MCP all are just buzzwords for customers. What they care about is whether they can get tasks done in our SaaS using Claude or ChatGPT. If that happens, it's a success.
My company uses MCP in production to connect different AI products together that were developed by different teams. It makes the connections very easy, where a REST interface often has quirks and features that you have to understand.
That's fair. REST isn't much of a standard. MCP can be just as badly designed and documented as REST, but at least there's a standard for authenticating and listing the options. Reading through other top-level comments, this seems to be the theme. MCP usage is mostly driven by ease of connection.
Basically it's just bundling the API documentation into a standard format to plug into LLMs, if you're comfortable running prompt injection on yourself and downloading random text from random websites and telling your favorite LLM to use it to access your banking information.
MCPs are diminishing in value a bit, because AI Agents are getting smarter about using API/CLIs. For example, I use gh cli via Claude instead of their MCP, because I already had cli setup, so no need to use MCP.
MCPs can potentially have great value if they cross multiple sources and combine results. For example at work we use an in-house MCP for log/metrics search across five different (legacy) systems. It finds correlation across events in different system within minutes.
I see benchmarks a lot working on this, and I honestly think there’s too many things to cover in this comment but:
- this article doesn’t enable tool search for starters where tokens start at near zero for MCP too
- even with the above, talks of the raw token count don’t consider that for very long trajectories the prompt cache amortises much of this cost, and a feature of MCP is you can also customise the tools to a select subset, and that’s powerful
- you can add tool confirmations for write/destructive actions trivially
- the old training data on CLIs is good but actually for new features the fact MCP advertises them is also a bonus, but that takes longer to see, MCP isn’t that old
There are many more aspects, but even with GitHub MCP, where the agent has a huge amount of pre-training on the CLI, there are still reasons why people use it extensively - you don’t hear it a lot here but suffice to say usage never stopped growing to this day.
I think if CLIs are working for you then good, I also like our cli and did some work on it too, like adding gh skill subcommand.
Do use what works, and measure and improve - but this article is not doing justice to the MCP server IMHO.
> - this article doesn’t enable tool search for starters where tokens start at near zero for MCP too
Is that why I have to constantly remind Claude and ChatGPT that they do have access to a Github plugin that can access my account, instead of trying and failing to use the gh cli?
Most likely, personally I have thoughts on tool search, I don’t believe it’s the final stop on the road to MCP progressive discovery, but it does have its uses. Especially for very large tool catalogues.
Expect more on this. We are looking at the problem.
0verload.net ... I am the Author if the tool. I cloned grep and hopped it up a with a bunch of globs and stuff only a bot can really use. You can version control directorys ...its not meant to replace git.. I wronte it for my self because I was tired of wishing it hadnt been a week since i checked into github. I have not have regression at all since I started using it ..its a godsend.it increases the effective context size by a huge ammount..if you learn to use it correctly you can have hundreds of megs of context without a problem and share it between agents. Additionally theres an edit monitor that throws every file and the diff for all the things the bots edit and you cvan scroll thru the sessions edits holding alt down and page thru the days code. ITs meant to be a pair programming tool to use with claude code. I have full mcp support but I also have a more powerful scripting language.mcp support is just part of the scripting language..so is rest..the whole thing is bot centric..I have guis for itm all but you can just tell the bots to o stuff ..I made the bot interfaces for everything and then the gui. Oh..it caches all the memory contexts and all the verson controlled filex in ram so grepping stuff in the source controlled folder is considerably faster..anwhere from hundreds to I have seen 6000+ times faster grep results not thru any sort of black magic..its just what happens when a custom written grep has a in ram
The main benefit of MCP today over just giving an agent a CLI is of course that you can be a lot more certain about what the agent can or can't do.
Yes, an agent with CLI access and access to making HTTPS calls is a lot more efficient for most tasks, but also a lot more unpredictable and with much higher blast radius if it starts misbehaving compared to one that only have access to exactly the tools and data sources you want it to use.
I use MCPs all the time, but just like in your case: they're my own MCP servers.
They do exactly what I want and how I want it. They expose just the information and the features I want the LLM to have. And just like in your case, it combines multiple sources of information into 1 response.
This is not true by default. There are plenty of poorly implemented MCP servers which do that. The MCP spec supports Oauth and intends to avoid that but it is not enforced.
I definitely think that's a bridge to gap, but MCP is not the answer. OSes currently lack the tools to do this properly, but I hope they will improve. Agents need more granular sandboxing in all areas.
I use the official Blender MCP to drive Blender from Claude. Mostly creating specialized Geometry Nodes and Python utility scripts. I have made a couple of add on plug ins with it.
And Claude, more or less by itself, came up wth a workflow to create asset library Geometry Nodes that we distribute over our internal network.
An example:
I told Claude to do research on the design and nomenclature for straight back chairs and create a geometry node group that exposes the main nomenclature as parameters and generates watertight geometry. Claude produced something useful on the first try and with a little back and forth we got something very nice. I then told it to do the same thing for basic tables and it came back with a detailed plan to have a standard workflow that stores text file documentation, in markdown format, INSIDE of Blender, along with utility scripts to generate the node groups.
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.
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?
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.
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?
You first authenticate via the phone (you can run an initial api call on phone start,) save session credentials in state on 11labs side and can then pass them back to future tool calls. You can then authenticate via a passcode if you wish
MCP's are great for adoption of your service outside of developer circles. Non Technical users can click a link, trigger an OAuth flow and authenticate. You can't do that with API. API still is better for developers using a AI via a CLI but MCP is easier adoption for web or desktop based clients.
I've read many comments about how good CLIs are, and they are right. But for developers.
For non-tech people, installing the CLI is a hurdle: it involves having the right dependencies installed, controlling how you handle secrets (like API keys), and handling updates (ie. npx with a private registry). But for internal tools, once you create an MCP with OAuth, the installation (in Claude) is straightforward.
I'm surprised how non-tech people in the company use it for ad-hoc integrations, like pulling emails, getting deals from HubSpot, enriching that with the internal MCP, then drafting responses. Of course, this has scaling issues, and at some point it is better to move these everyday automations to a proper system, but I saw how MCP enables what products like Zapier, n8n, or IFTTT try to do: user-friendly ad-hoc integrations.
My only complaint: implementing MCP auth in an MCP server still isn't very streamlined. Some libraries, like Cloudflare MCP, simplify all of that, but AFAIK it's tied to using their services.
We hooked up fly.io's sprites mcp to our company claude and now all employees can spin up dev envs and actually prototype, verify or reproduce something before coming to engineering; doing it directly from web or wherever and it's properly authed and sandboxed through their accounts
I OCR'd my Chinese textbooks and made a stateless MCP that allows me to ground my Chinese language studies according to the textbook only. With this I can start a quiz, understand differences between words that have similar meanings knowing no extra grammar is fed when reviewing. I specifically use it with glm 5.3 as it is the most language specific LLM that understands nuances.
That's an awesome example! I'll definitely make use of your repo and idea for my German classes. Did you use a specific OCR method? I'm trying to get something better than tesseract :(
I used Mistral 3. It costed me literally pennies. My workflow was kinda rudimentary but it worked really well. I suggest take a look at this https://github.com/docling-project/docling as well.
I built an MCP server for my voice assistant. By default, Home Assistant offers a few tools to the models, but I felt like it was missing some, so I built it.
It has tools to get real jokes, do math, unit conversion, get stock information, search the web with Kagi, and other things I consider to be essential in a voice assistant. It even got approved by my wife.
At work I use our MCP server to debug and troubleshoot issues with our code too. Just yesterday I used it to figure out why a tag wasn’t showing up in traces; using the MCP server, the LLM was able to see that the tag was present in parent traces, but was lost along the way, and figured out why.
Could I find that without the MCP server? Yes, but I’d take me hours of going through lengthy traces, while the MCP and LLM found the issue in minutes.
"What amps and charging schedule should I set my EV to charge at, so that at peak electricity rate time my house battery is at 90%." Looks at my house battery, car battery, current weather forecast, and house solar production, all of which are integrated into my Home Assistant. Looks at my gmail calendar. "16 amps, 9:30am-3:30pm, higher than usual because you're driving to lunch from 11am-12pm" (shows math). It can even go ahead and set it for me but I haven't given it read/write access to my car yet.
I got a Pebble Index 01 ring and it has support for custom MCP servers. I run one on Tailscale and it can interact with Home Assistant, my home issue tracker, my Anki setup, etc.
I've come full circle on MCP. With agents with a shell tool they quickly became unnecessary but these days I've been coming up with more agentic use cases where I don't want to give the agent a shell, and a narrower MCP interface is a great fit.
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.
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.
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
MCP is for when your end user (the one driving an LLM Agent) is non technical. Most non technical people are not going to install a CLI on their computer. Most are not going to be driving the LLM agent via a terminal.
It also very helpful when you need auth. MCP OAuth with CIMD makes it easy instead of cumbersome process of generating API Keys.
If you are technical and already using CLIs, then MCP doesn't give you much.
I often find that a lot of models will call the `--help` flag to figure out the commands and arguments nowadays. If I use a cli repeatedly, I'll generally ask it to create a skill
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
I work for a construction design company, and marking up on PDFs is a very common task, so we use Bluebeam. I've found it's better just to have the agent call the MCP with python or edit the pdf directly, since (at least with Claude) there's no way to pipe data into the MCP directly; the agent has to output everything itself. For this reason alone I feel like command line tools are just the better way forward for most things.
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've developed and deployed my own self hosted (on cloudflare / workerd) tool here https://github.com/TAJD/projektor and the key part was to be able to add it as a custom mcp server
My company (I'm not part of the team that's responsible for anything AI related) has MCP's for Jira, Confluence, Mattermost fork and a few other integrations.
I have no idea about MCP vs API question but I always assumed that the whole point of MCP was an abstration between the model and the tool\service.
As in model does not have to know about a certain API (not to mention a particular version of it) to work with a service.
I don't use MCPs much for personal use, but I've come to see the benefits of having a standardized mechanism for distributing tools across non-dev teams, especially when they're using a hodgepodge of agents.
I'm also excited about the upcoming SEP-2640 extension to MCP, which will be allow skills to be delivered via MCP. While the skill format has been standardized, skill distribution hasn't. I know there are tools like Vercel skills CLI, but that's not a good option for non-devs.
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.
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.
> "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.
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
Yeah had mcp in prod since late 2025. Runs 100s of tools via openrouter. I don’t get when people start banging on about ‘cli’ and ‘mcp is rubbish’. It’s damn cool and it works. And if you do some legwork it doesn’t need to pollute context so you can have 1000s of tools if required.
And to add I don’t know why mcp is seen as magic. It’s just a documented api. Weird… missing the issues with it. They are never described in enough detail for me to comprehend.
MCP usage is at an all-time peak - 17M daily (!) downloads of the official SDKs.
We're using MCP for virtually all our SaaS and infra providers (CRM, ATS, banking and accounting, Notion, Linear, all dev tools and hosting platforms) it's become a hard requirement in our buy bechmark. No MCP = NOGO
The advantages are:
- baked-in auth: no need to configure anything, it just works with our employees accounts
- one click install with Codex Plugins and Claude Connectors
MCP Apps are the only way to build a connector that's actually usable from
inside the Claude and ChatGPT apps. They return chunks of UI alongside the
tool result, so a CLI simply can't provide the same functionality.
And you can't expect an average user to install a CLI on their machine just to
search for flights or do shopping for example.
I work at Alpic, where we build Skybridge, a framework for developing MCP
Apps. Our users have apps published on the ChatGPT and Claude stores, and
they've seen traffic quietly growing over the last few months. Traffic isn't massive yet, but it costs little to stake out ground on a new channel and be ready if it takes off.
I made an MCP for myself that syncs all my Microsoft mail into a local sqlite db and exposes it as read-only to the agent. `query` tool can do search (FTS5 match) or browse (by date) on mailboxes/threads and returns lists of email with FTS5 snippets + paging. `get` reads multiple emails by id.
It's very fast: most queries finish in < 10ms. Agents are able to find things quickly and efficiently even with vague questions. The app does a few things to minimize token output, but there's a long tail of potential token reduction strategies that I haven't gotten to yet.
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.
I get this use-case, but what makes an MCP server better than a custom CLI tool that exposes those same operations? That's how I've solved similar things in the past.
Mcp just wraps the existing calls with a description of when to use them. Why would you write a cli for something like this? And clis generally have a help call but that doesn’t say when to use a tool just what it does
If you have an even modestly complex software:
- start building an internal tool set with proper access rights
- put an MCP over that tool set.
You're very likely to use those tools for other things as well, so keep the MCP as just a layer.
You can add a lot of things you wouldn't usually bother with, like telemetry, detailed logs, read only database access (you can even add a llm powered query builder on top) etc.
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.
Like as a deployed component in our customer facing app stack? Not being used in that context that I'm aware of. I think there's a couple use cases being worked on though.
Are devs/engineers using MCPs to do their work? Yeah. Datadog MCP, Atlassian MCP, Gitlab MCP, backstage mcp, and we have our documentation behind an MCP. All used daily.
Incredibly useful for our SaaS. We are a niche CRM and it's very useful for our non-technical users to be able to connect our platform's data to Claude/Copilot which they then combine with other MCPs.
Advantages over our normal API:
- Much easier to provide LLM-specific explanations and descriptions to all of the tools and parameters
- None of our clients know what a CLI is
- We re-use our MCP for our own platform's agent which gives it a neatly defined list
- It handles the full OAuth flow in the application
I'll admit though it is VERY similar to a REST API, and I could see them merging at some point.
Having all of them made it trivial for the LLM to start with an alert, search the codebase for the alert source and then review the Prom stack for additional info.
Automated a lot of the toil around digging through alerts and then making changes to fix issues.
At Adidas we use MCP in production, both flavors stdio and remote. Remote is more for secure autonomous agents or agents workflows and stdio is more intended for local development. So far we are good with this still don't see the point of A2A except some really specific cases, if you have the tools and a smart model do you need really split with different agents?
We do have an MCP but all it does is wraps our OpenAPI endpoints using a bunch of tools (not exposing the 100(0?)s of endpoints as tools), but just list_resources, list_endpoints, describe_endpoint, describe_ref, execute.
The primary reason we have this is because its easier for non-tech people to connect it to their AI Claude/ChatGPT/etc. than it is to have them generate an API key and give it the base url and the openapi spec/etc.
The MCP also allows us to add expose a couple of recipe/skill tools (list_skills/read_skill) which describe common workflows on how to use to do things that might be unclear.
I just HAD to use it today, I avoided them as much as I could.
We have a figma design that's not really enterprise level with different components and not really coherent in some ways, and the management want the web pages to be the exact same as the figma designs.
Knowing the hell that awaits me in trying to be pixel perfect between about 40 pages, I set up the Figma MCP with my codex, and low and behold... it actually did what I needed, so that's one thing I'm grateful for.
For reference, feeding screenshots to the AI didn't do that well of a job at first.
We (HappySupport [1], help center with lots of automation) recently added an MCP server - this was highly requested. Our users are using it to reorganize their help center, answer questions (internally) and to create/edit/move/publish/unpublish or delete articles.
It was also pretty handy for importing existing documentation from obscure providers without having to build an integration for each of them.
We also added WebMCP [2] for agents to consume our public documentation/help center, but we haven't seen it used yet.
An API would work for all of these cases too, but since customers are using it in their AI tools anyway, MCP is just simpler for them.
I'm a tech lead at an AI enablement team in an enterprise setting. There are a few project people have built which eventually turned into functional web apps, but people mostly want to interact with these new capabilities in a Claude or ChatGPT interface. So we eventually had to build an MCP. We are beta testing it right now. You gotta meet your users where they are.
We do at our company (in the ecommerce sector). I set up a way for internal users to connect an agent to our data. We used to spend a lot of time building reports for non-technical users. It's been a fantastic way to free up our time, and allows them to "query" the system using natural language.
"How many of these shirts sold in 2024"
"Build me a chart that displays revenue over time for product XYZ"
Things like that. They love it, and we get to spend time on more pressing things.
We (Synqly) have a production MCP server which several of our customers use in their production services. The functionality ranges from mundane management capabilities such as walking through how to add an integration in natural language (e.g. support bot) to more than exciting use cases such as making complex queries across a number of tools to create aggregate reports.
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.
I use MCP for two types of things: ones where I need to give access to the memory of the process like an MCP server to inspect a Qt gui, and ones where I need to give authenticated access to my data to ChatGPT/Claude web/mobile apps. For these uses CLIs would be too cumbersome in use or auth.
For the latter, Cloudflare Tunnels + Zero Trust + Github SSO means securing them is rather easy and with the recent cf cli the agent does all the work. Their native support for base64 encoded images is also helpful to “encourage” the LLM to look at stuff without constant prodding.
Running a bunch alongside APIs for suite of internal services where domain experts are using agents to setup environments for their work. Getting them to update their LLMs to a new SDK version every time we iterate API capabilities is all the headache you'd imagine. The MCP avoids inconsistent user reports of capabilities.
The specifics, now user can ask, "Provision 200Gi PostgreSQL 18 with PostGIS 3.6 and then copy over our most recent Texas set of layers."
Behind the scene Talos, k8s, NiFi, and bunch of things go to work. Big productivity boost vs. the users needing to login to bunch of provisioning web interfaces which is the other method we publish that avoids version drift issues.
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.
We do social media community management ( https://trollwall.ai/mcp ) and our customers want to know what their followers are talking about - topics, sentiment, why are people angry, showing actual example comments, comparing to last month.. Having a conversation about this is much better UX than having dashboard or static report (.. your Claude can at the end even generate PDF report on what you talked about).
We tried to build different analytics screens for this and we always found out that different types of customers what their own angle. MCP, together with knowledge/memory of their own ChatGPT/Claude, allows them to super customize it for what they want and need.
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.
We (Prostack, UK managed hosting) launched an MCP server for our control panel- https://mcp.prostack.uk - to allow users to interact with Claude/Cursor etc, for debugging & deployment.
"Why is my site showing an error", "Deploy this project" etc are the key flows, and users have been building on top of them. It's a nice link between dev & prod, and a great debugging assistant. It's been very well received so far.
Implementation was pretty straightforward (tools mapped to our API) with appropriate guardrails for destructive actions.
MCP benefits (security, stability) outweigh your AI rolling their own API client or CLI, after which YOU/it owns the client. Talk about major technical debt! MCP has a client protocol baked in. If your 3rd party API doesn't support the API fully in their MCP, that's when you think about rolling your own or writing that 3rd party a stern letter. Stability and security over bespoke client fragility. MCP (or a 3rd party managed CLI) all the way.
In many cases, you can partition data at rest (eg parquet) on the user access key, then load it once into an agent container at runtime. In this way, one authentication pass provides access to all data in a sandbox, versus repeatedly authenticating against MCP calls. It also just reduces the connective tissue between the harness and the data. There are obviously drawbacks in that you aren’t leveraging real time APIs, but it works well for most business use cases.
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.
I use it for fully auditable agentic compliance work - many of my customers already used MCPs for their compliance work, and recent changes made that fully auditable. I have to admit that it's much easier to use and work on compliance this way than using the agent built into the app.
As a user, I use a couple of them with Claude: dash0 + linear + readonly access to a prod db, I can now understand and debug our user's issues in minutes with all the forensic automated.
In our product, we found it hard to onboard people on our platform because even though the data was rich, our features were subpar and in development.
I've opened the MCP API based on our GraphQL API (like 100 lines of code and config, piece of cake), and we got heavy usage day 1.
The adoption went from convincing them to use the platform, to them flooding us with new feautres and data requests.
MCP benefits are way more important than AI rolling their own API client or CLI, after which YOU own the client. MCP is the protocol. If your 3rd-party API doesn't support the API fully in an MCP, that's when you think about rolling your own or writing that 3rd party a stern letter. Stability and security over bespoke client fragility. MCP (or a 3rd party managed CLI) all the way.
I (SiteSpeakAI) use MCP in production in 2 ways, to analyze usage and make improvements to the app itself to hopefully improve the customer experience, and then also as a feature for each customer so they can interact with their own cx install and monitor / improve prompts etc. Been really useful, but important to note most customers are at least a bit tech savvy, so MCP makes sense for them.
Don't think it would be that useful for non-tech users.
I use feedbackjar mcp. It's a feedback tool which also collects metadata like device, os, browser console etc. So my coding agent gets all the context of the feature request or bug report. https://feedbackjar.com
We offer MCP and then consume it with our in-app assistant to go from a non technical prompt to a series of what is essentially API calls they can automate for themselves for repetitive tasks or things that require a few screens to accomplish can be done from the assistant widget itself, etc.
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.
As a consumer, I use BetterStack's MCP server pretty much daily to search server logs and resolve reported errors - super helpful! But a CLI would be equally useful here.
I've ramped up my MCP game this year, I started with Linear and Notion and I recently launched an internal MCP for internal data that is being used by my colleagues too for reporting and preparing for meetings with customers (we do upsells for hotels www.upsellguru.com ). It seems like that some of the most tech savvy customers are looking forward to use it too and we may open to them too.
at Hedgy we built an MCP to give our agents read-only access to cross-system data + context about what it means [0]. daily it helps me debug customer flows and think through features and priority.
the advantage of MCP is that the tool description names what data it has so the agents know to just use it if they want that kind of data. as new data is added, everyone’s tool description updates. with a REST api or cli I suppose we could update a checked in AGENTS.md to ship it to engineers but idk how id get that to colleagues using the it from their claude.ai or co-work.
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.
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?
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.
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.
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.
When writing agentic apps (apps which embed an agent for semantic work), exposing the same tools which are injected into the agents as an MCP allows for practically the same functionality to be debugged and run in a normal agentic harness.
Good for both development and cost reduction, as the agentic harnesses often allow for much greater amount of token usage per subscription, as opposed to API key which always is per volume.
I am active user of the MCPs for HubSpot, cal.com, search console, google ads and typeform under Perplexity Computer. They work pretty well to create reporting and propose marketing ideas.
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.
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.
In my previous company we used MCP for voice agents. It was easy to use open-source mcps, since we did all the oauth and account management on our side. This also makes it easy for customers to bring their internal tools in a standardized format.
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.
Chatbot+MCP, agentic workflow+harness seems to be the divide in my workplace: Business people want a chat UI, they get MCP. Developers want to automate things, they plug in their dotfiles and other scripts. Not sure if it reflects the larger population.
Interestingly most people in the comments talk about implementing an MCP server, while few talk about implementing an MCP client (as in actually using MCP for a specific purpose)
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.
Custom connector to paperless for processing fetching, reason... Off any physical contract or letter received by the company.
Google drive for everything digital. Paperless for more legal things.
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.
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.
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.
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
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.
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.
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.
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
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)
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)?
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
We use for jira, confluence, excel. Attlassian projects require Rovio and this is additional payments. So we wrote our mcp to connect and work with them
We built an MCP integration for agentic access to our platform, Proxybase [0]. It lets agents buy and sell bandwidth through SOCKS5 proxies directly from the platform.
The main benefit is simpler integration with agentic harnesses. MCP still accounts for only around 20% of the agents using Proxybase, but it has made the integration process much easier for those users.
I use MCP for Stackography, a tool I built that visualises my estate (hosts, apps, databases, tunnels, proxies etc), showing a force-directed graph, which includes live health, and a flexible search tool. It's very good for answering questions like "what stuff am I running under Docker", or "show me everything that makes up app X". Also shows the history of changes, summarised by LLM.
MCP is useful because it has instructions to Claude (or the agent of your choice) that tell it how and when to manage the graph. Integrating with Stackography is a one-line operation:
I use almost no MCPs and feel like I'm not missing out on anything, I just use APIs directly or CLIs. I honestly don't quite see the point of MCPs any longer.
Yup, but with some caveat. For things like backstage, which have MCP servers but are really fucking insecure, we have a wrapper API that is then linked to a skill.
Over the past 3 months we've been using it a LOT. I made one for our admins so they can work with the CMS and get statistics in their client, the statistics part has been a huge unlock. The big advantage here is that a normal API, direct tool integration or CLI are unpractical to set up for my less technical coworkers.
Other then that I've been building MCP's in pretty much all (personal) tools I'm making now, it's very useful to have a central way for an agent to look at production data without having to ssh into a server.
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!
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 simple explanation. To connect Claude for example: https://www.tredict.com/faq/connect-claude-web-with-tredict/ This way users can use Claude to create and push workouts with their Garmin devices based on a prior analysis. We also have a 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.
This. We also thought MCP was useless, but now the workflows by ChatGPT and Claude are so good; it's as good as installing an app from the App Store. We launched MCP for our SaaS and immediately found users using it.
API and MCP all are just buzzwords for customers. What they care about is whether they can get tasks done in our SaaS using Claude or ChatGPT. If that happens, it's a success.
Do you not expose a standard REST api?
We do. MCP works on top of it.
I say MCP is just lightweight layer on top of REST and as long as it works for end users I don’t see any reason not to adopt it.
MCP is not just a rest api its a layer on top
A layer than honestly doesn't do much, as I understand it. What does MCP as a protocol actually solve? Is it more than a bandwagon?
My company uses MCP in production to connect different AI products together that were developed by different teams. It makes the connections very easy, where a REST interface often has quirks and features that you have to understand.
That's fair. REST isn't much of a standard. MCP can be just as badly designed and documented as REST, but at least there's a standard for authenticating and listing the options. Reading through other top-level comments, this seems to be the theme. MCP usage is mostly driven by ease of connection.
Im not deep in there, but Id guess it offers some discovery mechanisms? (not sure if my understanding is correct)
Basically it's just bundling the API documentation into a standard format to plug into LLMs, if you're comfortable running prompt injection on yourself and downloading random text from random websites and telling your favorite LLM to use it to access your banking information.
It's a bit of a nothingburger IMO, but charitably you could think of it as a rest API + bundled agent instructions.
MCPs are diminishing in value a bit, because AI Agents are getting smarter about using API/CLIs. For example, I use gh cli via Claude instead of their MCP, because I already had cli setup, so no need to use MCP.
MCPs can potentially have great value if they cross multiple sources and combine results. For example at work we use an in-house MCP for log/metrics search across five different (legacy) systems. It finds correlation across events in different system within minutes.
FWIW, it appears that using the gh cli is much more token efficient than MCP so that's a plus.
https://medium.com/@ravi.madabhushi/mcp-is-up-to-32-more-exp...
I see benchmarks a lot working on this, and I honestly think there’s too many things to cover in this comment but: - this article doesn’t enable tool search for starters where tokens start at near zero for MCP too - even with the above, talks of the raw token count don’t consider that for very long trajectories the prompt cache amortises much of this cost, and a feature of MCP is you can also customise the tools to a select subset, and that’s powerful - you can add tool confirmations for write/destructive actions trivially - the old training data on CLIs is good but actually for new features the fact MCP advertises them is also a bonus, but that takes longer to see, MCP isn’t that old
There are many more aspects, but even with GitHub MCP, where the agent has a huge amount of pre-training on the CLI, there are still reasons why people use it extensively - you don’t hear it a lot here but suffice to say usage never stopped growing to this day.
I think if CLIs are working for you then good, I also like our cli and did some work on it too, like adding gh skill subcommand.
Do use what works, and measure and improve - but this article is not doing justice to the MCP server IMHO.
> - this article doesn’t enable tool search for starters where tokens start at near zero for MCP too
Is that why I have to constantly remind Claude and ChatGPT that they do have access to a Github plugin that can access my account, instead of trying and failing to use the gh cli?
Most likely, personally I have thoughts on tool search, I don’t believe it’s the final stop on the road to MCP progressive discovery, but it does have its uses. Especially for very large tool catalogues.
Expect more on this. We are looking at the problem.
"claude, stop shelling out to grep, your search tool uses ripgrep and it's faster."
0verload.net ... I am the Author if the tool. I cloned grep and hopped it up a with a bunch of globs and stuff only a bot can really use. You can version control directorys ...its not meant to replace git.. I wronte it for my self because I was tired of wishing it hadnt been a week since i checked into github. I have not have regression at all since I started using it ..its a godsend.it increases the effective context size by a huge ammount..if you learn to use it correctly you can have hundreds of megs of context without a problem and share it between agents. Additionally theres an edit monitor that throws every file and the diff for all the things the bots edit and you cvan scroll thru the sessions edits holding alt down and page thru the days code. ITs meant to be a pair programming tool to use with claude code. I have full mcp support but I also have a more powerful scripting language.mcp support is just part of the scripting language..so is rest..the whole thing is bot centric..I have guis for itm all but you can just tell the bots to o stuff ..I made the bot interfaces for everything and then the gui. Oh..it caches all the memory contexts and all the verson controlled filex in ram so grepping stuff in the source controlled folder is considerably faster..anwhere from hundreds to I have seen 6000+ times faster grep results not thru any sort of black magic..its just what happens when a custom written grep has a in ram
"claude: my harness tells me to use python's pathlib"
The main benefit of MCP today over just giving an agent a CLI is of course that you can be a lot more certain about what the agent can or can't do.
Yes, an agent with CLI access and access to making HTTPS calls is a lot more efficient for most tasks, but also a lot more unpredictable and with much higher blast radius if it starts misbehaving compared to one that only have access to exactly the tools and data sources you want it to use.
In practice that’s a lot of the value MCPs are providing.
Technically it’d work just as well to have a thin API wrapper or cli tool the agent is allowed to access.
I use MCPs all the time, but just like in your case: they're my own MCP servers.
They do exactly what I want and how I want it. They expose just the information and the features I want the LLM to have. And just like in your case, it combines multiple sources of information into 1 response.
MCP doesn't expose service credentials to the AI.
This is not true by default. There are plenty of poorly implemented MCP servers which do that. The MCP spec supports Oauth and intends to avoid that but it is not enforced.
I definitely think that's a bridge to gap, but MCP is not the answer. OSes currently lack the tools to do this properly, but I hope they will improve. Agents need more granular sandboxing in all areas.
gh cli prbly has a lot of training data so maybe not a fair comparison
No it's because any model can do gh --help
cli tools are a natural fit for llms.
actually run it now and see it wont do the help command you are talking about
I use the official Blender MCP to drive Blender from Claude. Mostly creating specialized Geometry Nodes and Python utility scripts. I have made a couple of add on plug ins with it.
And Claude, more or less by itself, came up wth a workflow to create asset library Geometry Nodes that we distribute over our internal network.
An example:
I told Claude to do research on the design and nomenclature for straight back chairs and create a geometry node group that exposes the main nomenclature as parameters and generates watertight geometry. Claude produced something useful on the first try and with a little back and forth we got something very nice. I then told it to do the same thing for basic tables and it came back with a detailed plan to have a standard workflow that stores text file documentation, in markdown format, INSIDE of Blender, along with utility scripts to generate the node groups.
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.
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?
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.
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?
You first authenticate via the phone (you can run an initial api call on phone start,) save session credentials in state on 11labs side and can then pass them back to future tool calls. You can then authenticate via a passcode if you wish
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!
MCP's are great for adoption of your service outside of developer circles. Non Technical users can click a link, trigger an OAuth flow and authenticate. You can't do that with API. API still is better for developers using a AI via a CLI but MCP is easier adoption for web or desktop based clients.
This (points up)!
I've read many comments about how good CLIs are, and they are right. But for developers.
For non-tech people, installing the CLI is a hurdle: it involves having the right dependencies installed, controlling how you handle secrets (like API keys), and handling updates (ie. npx with a private registry). But for internal tools, once you create an MCP with OAuth, the installation (in Claude) is straightforward.
I'm surprised how non-tech people in the company use it for ad-hoc integrations, like pulling emails, getting deals from HubSpot, enriching that with the internal MCP, then drafting responses. Of course, this has scaling issues, and at some point it is better to move these everyday automations to a proper system, but I saw how MCP enables what products like Zapier, n8n, or IFTTT try to do: user-friendly ad-hoc integrations.
My only complaint: implementing MCP auth in an MCP server still isn't very streamlined. Some libraries, like Cloudflare MCP, simplify all of that, but AFAIK it's tied to using their services.
>implementing MCP auth in an MCP server still isn't very streamlined.
That's why services like https://zapier.com/mcp provide still a ton of value, because it helps non technical folks have the MCP server ready to run.
yes, this is the proper use case.
We hooked up fly.io's sprites mcp to our company claude and now all employees can spin up dev envs and actually prototype, verify or reproduce something before coming to engineering; doing it directly from web or wherever and it's properly authed and sandboxed through their accounts
I OCR'd my Chinese textbooks and made a stateless MCP that allows me to ground my Chinese language studies according to the textbook only. With this I can start a quiz, understand differences between words that have similar meanings knowing no extra grammar is fed when reviewing. I specifically use it with glm 5.3 as it is the most language specific LLM that understands nuances.
Here's the repository: https://github.com/iodize6399/xuexi-keben
And here's the server itself: https://keben.555420.xyz
That's an awesome example! I'll definitely make use of your repo and idea for my German classes. Did you use a specific OCR method? I'm trying to get something better than tesseract :(
I used Mistral 3. It costed me literally pennies. My workflow was kinda rudimentary but it worked really well. I suggest take a look at this https://github.com/docling-project/docling as well.
I built an MCP server for my voice assistant. By default, Home Assistant offers a few tools to the models, but I felt like it was missing some, so I built it.
It has tools to get real jokes, do math, unit conversion, get stock information, search the web with Kagi, and other things I consider to be essential in a voice assistant. It even got approved by my wife.
At work I use our MCP server to debug and troubleshoot issues with our code too. Just yesterday I used it to figure out why a tag wasn’t showing up in traces; using the MCP server, the LLM was able to see that the tag was present in parent traces, but was lost along the way, and figured out why.
Could I find that without the MCP server? Yes, but I’d take me hours of going through lengthy traces, while the MCP and LLM found the issue in minutes.
> Home Assistant
I've been using https://github.com/homeassistant-ai/ha-mcp for my Home Assistant instance and it has been awesome.
"What amps and charging schedule should I set my EV to charge at, so that at peak electricity rate time my house battery is at 90%." Looks at my house battery, car battery, current weather forecast, and house solar production, all of which are integrated into my Home Assistant. Looks at my gmail calendar. "16 amps, 9:30am-3:30pm, higher than usual because you're driving to lunch from 11am-12pm" (shows math). It can even go ahead and set it for me but I haven't given it read/write access to my car yet.
I use MCP for a voice assistant as well.
I got a Pebble Index 01 ring and it has support for custom MCP servers. I run one on Tailscale and it can interact with Home Assistant, my home issue tracker, my Anki setup, etc.
I've come full circle on MCP. With agents with a shell tool they quickly became unnecessary but these days I've been coming up with more agentic use cases where I don't want to give the agent a shell, and a narrower MCP interface is a great fit.
You just convinced me to buy a Pebble Index, which I was on the fence about. No idea it supported MCP servers.
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...
How is this better than using MCP?
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.
The lazy loading is a harness concern.
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.
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
MCP is for when your end user (the one driving an LLM Agent) is non technical. Most non technical people are not going to install a CLI on their computer. Most are not going to be driving the LLM agent via a terminal.
It also very helpful when you need auth. MCP OAuth with CIMD makes it easy instead of cumbersome process of generating API Keys.
If you are technical and already using CLIs, then MCP doesn't give you much.
Even with a cli it doesn’t have a nice list of all commands and a nice description of when to call such a tool
I often find that a lot of models will call the `--help` flag to figure out the commands and arguments nowadays. If I use a cli repeatedly, I'll generally ask it to create a skill
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.
[0] https://github.com/rebeccathedev/afterfeed/
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
I work for a construction design company, and marking up on PDFs is a very common task, so we use Bluebeam. I've found it's better just to have the agent call the MCP with python or edit the pdf directly, since (at least with Claude) there's no way to pipe data into the MCP directly; the agent has to output everything itself. For this reason alone I feel like command line tools are just the better way forward for most things.
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
Same here. I was inspired by your post https://simonwillison.net/2026/Jul/31/stateless-mcp/
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/
me three (at this point)
I've developed and deployed my own self hosted (on cloudflare / workerd) tool here https://github.com/TAJD/projektor and the key part was to be able to add it as a custom mcp server
My company (I'm not part of the team that's responsible for anything AI related) has MCP's for Jira, Confluence, Mattermost fork and a few other integrations.
I have no idea about MCP vs API question but I always assumed that the whole point of MCP was an abstration between the model and the tool\service.
As in model does not have to know about a certain API (not to mention a particular version of it) to work with a service.
I don't use MCPs much for personal use, but I've come to see the benefits of having a standardized mechanism for distributing tools across non-dev teams, especially when they're using a hodgepodge of agents.
I'm also excited about the upcoming SEP-2640 extension to MCP, which will be allow skills to be delivered via MCP. While the skill format has been standardized, skill distribution hasn't. I know there are tools like Vercel skills CLI, but that's not a good option for non-devs.
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.
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.
> "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.
If you don’t use the MCP Claude will default to taking screenshots of figma designs.
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
not OP, but then I'm washing the dishes and don't need to do anything else.
When you are holding a pet, or washing the dishes?
Yeah had mcp in prod since late 2025. Runs 100s of tools via openrouter. I don’t get when people start banging on about ‘cli’ and ‘mcp is rubbish’. It’s damn cool and it works. And if you do some legwork it doesn’t need to pollute context so you can have 1000s of tools if required.
And to add I don’t know why mcp is seen as magic. It’s just a documented api. Weird… missing the issues with it. They are never described in enough detail for me to comprehend.
CC with Jetbrain's IDE MCPs. get rid of those greps, seds, awks, heads and tails!
MCP usage is at an all-time peak - 17M daily (!) downloads of the official SDKs.
We're using MCP for virtually all our SaaS and infra providers (CRM, ATS, banking and accounting, Notion, Linear, all dev tools and hosting platforms) it's become a hard requirement in our buy bechmark. No MCP = NOGO
The advantages are:
- baked-in auth: no need to configure anything, it just works with our employees accounts
- one click install with Codex Plugins and Claude Connectors
MCP Apps are the only way to build a connector that's actually usable from inside the Claude and ChatGPT apps. They return chunks of UI alongside the tool result, so a CLI simply can't provide the same functionality.
And you can't expect an average user to install a CLI on their machine just to search for flights or do shopping for example.
I work at Alpic, where we build Skybridge, a framework for developing MCP Apps. Our users have apps published on the ChatGPT and Claude stores, and they've seen traffic quietly growing over the last few months. Traffic isn't massive yet, but it costs little to stake out ground on a new channel and be ready if it takes off.
I made an MCP for myself that syncs all my Microsoft mail into a local sqlite db and exposes it as read-only to the agent. `query` tool can do search (FTS5 match) or browse (by date) on mailboxes/threads and returns lists of email with FTS5 snippets + paging. `get` reads multiple emails by id.
It's very fast: most queries finish in < 10ms. Agents are able to find things quickly and efficiently even with vague questions. The app does a few things to minimize token output, but there's a long tail of potential token reduction strategies that I haven't gotten to yet.
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.
I get this use-case, but what makes an MCP server better than a custom CLI tool that exposes those same operations? That's how I've solved similar things in the past.
Mcp just wraps the existing calls with a description of when to use them. Why would you write a cli for something like this? And clis generally have a help call but that doesn’t say when to use a tool just what it does
I assume the target audience for the question is developers. That will generate many responses along the lines of ”just use a CLI”.
The current, main driver I see for MCP servers are non-technical people who want to securely connect data sources to their AI application.
If you have an even modestly complex software: - start building an internal tool set with proper access rights - put an MCP over that tool set.
You're very likely to use those tools for other things as well, so keep the MCP as just a layer.
You can add a lot of things you wouldn't usually bother with, like telemetry, detailed logs, read only database access (you can even add a llm powered query builder on top) etc.
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.
For us it's pretty much a standard request from our clients now: that they are able to use their chatbot to interact with the ERP systems.
What do you mean "using MCP in production"?
Like as a deployed component in our customer facing app stack? Not being used in that context that I'm aware of. I think there's a couple use cases being worked on though.
Are devs/engineers using MCPs to do their work? Yeah. Datadog MCP, Atlassian MCP, Gitlab MCP, backstage mcp, and we have our documentation behind an MCP. All used daily.
Incredibly useful for our SaaS. We are a niche CRM and it's very useful for our non-technical users to be able to connect our platform's data to Claude/Copilot which they then combine with other MCPs.
Advantages over our normal API: - Much easier to provide LLM-specific explanations and descriptions to all of the tools and parameters - None of our clients know what a CLI is - We re-use our MCP for our own platform's agent which gives it a neatly defined list - It handles the full OAuth flow in the application
I'll admit though it is VERY similar to a REST API, and I could see them merging at some point.
Past job had MCPs for the following:
- Loki
- Prometheus
- Grafana
- Incident.io
- GitHub for our codebase
- A custom MCP for our server inventory/nodes
Having all of them made it trivial for the LLM to start with an alert, search the codebase for the alert source and then review the Prom stack for additional info.
Automated a lot of the toil around digging through alerts and then making changes to fix issues.
At Adidas we use MCP in production, both flavors stdio and remote. Remote is more for secure autonomous agents or agents workflows and stdio is more intended for local development. So far we are good with this still don't see the point of A2A except some really specific cases, if you have the tools and a smart model do you need really split with different agents?
We do have an MCP but all it does is wraps our OpenAPI endpoints using a bunch of tools (not exposing the 100(0?)s of endpoints as tools), but just list_resources, list_endpoints, describe_endpoint, describe_ref, execute.
The primary reason we have this is because its easier for non-tech people to connect it to their AI Claude/ChatGPT/etc. than it is to have them generate an API key and give it the base url and the openapi spec/etc.
The MCP also allows us to add expose a couple of recipe/skill tools (list_skills/read_skill) which describe common workflows on how to use to do things that might be unclear.
My employer Notion offers an MCP that’s mentioned in a few posts here.
Notion’s monorepo has 16+ MCP configs with many in opt-in plugins developers choose to activate.
Very useful; i particularly like sending an agent to debug an alert across slack/honeycomb/incident.io/materialize db
SaaS where I work has an MCP, it's popular with our customers. They can use it without knowing what a CLI is, just from however they use their AI.
I use MCP all the time at work as well from Claude code etc, it's convenient with uniformity of configuration and access inside the harness.
I just HAD to use it today, I avoided them as much as I could. We have a figma design that's not really enterprise level with different components and not really coherent in some ways, and the management want the web pages to be the exact same as the figma designs.
Knowing the hell that awaits me in trying to be pixel perfect between about 40 pages, I set up the Figma MCP with my codex, and low and behold... it actually did what I needed, so that's one thing I'm grateful for.
For reference, feeding screenshots to the AI didn't do that well of a job at first.
We (HappySupport [1], help center with lots of automation) recently added an MCP server - this was highly requested. Our users are using it to reorganize their help center, answer questions (internally) and to create/edit/move/publish/unpublish or delete articles.
It was also pretty handy for importing existing documentation from obscure providers without having to build an integration for each of them.
We also added WebMCP [2] for agents to consume our public documentation/help center, but we haven't seen it used yet.
An API would work for all of these cases too, but since customers are using it in their AI tools anyway, MCP is just simpler for them.
[1] https://www.happysupport.ai/en [2] https://developer.chrome.com/docs/ai/webmcp
I'm a tech lead at an AI enablement team in an enterprise setting. There are a few project people have built which eventually turned into functional web apps, but people mostly want to interact with these new capabilities in a Claude or ChatGPT interface. So we eventually had to build an MCP. We are beta testing it right now. You gotta meet your users where they are.
We do at our company (in the ecommerce sector). I set up a way for internal users to connect an agent to our data. We used to spend a lot of time building reports for non-technical users. It's been a fantastic way to free up our time, and allows them to "query" the system using natural language.
"How many of these shirts sold in 2024" "Build me a chart that displays revenue over time for product XYZ"
Things like that. They love it, and we get to spend time on more pressing things.
We (Synqly) have a production MCP server which several of our customers use in their production services. The functionality ranges from mundane management capabilities such as walking through how to add an integration in natural language (e.g. support bot) to more than exciting use cases such as making complex queries across a number of tools to create aggregate reports.
It's a very popular part of our platform.
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 use MCP for two types of things: ones where I need to give access to the memory of the process like an MCP server to inspect a Qt gui, and ones where I need to give authenticated access to my data to ChatGPT/Claude web/mobile apps. For these uses CLIs would be too cumbersome in use or auth.
For the latter, Cloudflare Tunnels + Zero Trust + Github SSO means securing them is rather easy and with the recent cf cli the agent does all the work. Their native support for base64 encoded images is also helpful to “encourage” the LLM to look at stuff without constant prodding.
Running a bunch alongside APIs for suite of internal services where domain experts are using agents to setup environments for their work. Getting them to update their LLMs to a new SDK version every time we iterate API capabilities is all the headache you'd imagine. The MCP avoids inconsistent user reports of capabilities.
The specifics, now user can ask, "Provision 200Gi PostgreSQL 18 with PostGIS 3.6 and then copy over our most recent Texas set of layers."
Behind the scene Talos, k8s, NiFi, and bunch of things go to work. Big productivity boost vs. the users needing to login to bunch of provisioning web interfaces which is the other method we publish that avoids version drift issues.
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.
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.
Reporting is what we use MCP for.
We do social media community management ( https://trollwall.ai/mcp ) and our customers want to know what their followers are talking about - topics, sentiment, why are people angry, showing actual example comments, comparing to last month.. Having a conversation about this is much better UX than having dashboard or static report (.. your Claude can at the end even generate PDF report on what you talked about).
We tried to build different analytics screens for this and we always found out that different types of customers what their own angle. MCP, together with knowledge/memory of their own ChatGPT/Claude, allows them to super customize it for what they want and need.
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.
We (Prostack, UK managed hosting) launched an MCP server for our control panel- https://mcp.prostack.uk - to allow users to interact with Claude/Cursor etc, for debugging & deployment.
"Why is my site showing an error", "Deploy this project" etc are the key flows, and users have been building on top of them. It's a nice link between dev & prod, and a great debugging assistant. It's been very well received so far.
Implementation was pretty straightforward (tools mapped to our API) with appropriate guardrails for destructive actions.
MCP benefits (security, stability) outweigh your AI rolling their own API client or CLI, after which YOU/it owns the client. Talk about major technical debt! MCP has a client protocol baked in. If your 3rd party API doesn't support the API fully in their MCP, that's when you think about rolling your own or writing that 3rd party a stern letter. Stability and security over bespoke client fragility. MCP (or a 3rd party managed CLI) all the way.
In many cases, you can partition data at rest (eg parquet) on the user access key, then load it once into an agent container at runtime. In this way, one authentication pass provides access to all data in a sandbox, versus repeatedly authenticating against MCP calls. It also just reduces the connective tissue between the harness and the data. There are obviously drawbacks in that you aren’t leveraging real time APIs, but it works well for most business use cases.
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.
I use it for fully auditable agentic compliance work - many of my customers already used MCPs for their compliance work, and recent changes made that fully auditable. I have to admit that it's much easier to use and work on compliance this way than using the agent built into the app.
https://auditbadger.com/auditable-agentic-compliance/
As a user, I use a couple of them with Claude: dash0 + linear + readonly access to a prod db, I can now understand and debug our user's issues in minutes with all the forensic automated.
In our product, we found it hard to onboard people on our platform because even though the data was rich, our features were subpar and in development. I've opened the MCP API based on our GraphQL API (like 100 lines of code and config, piece of cake), and we got heavy usage day 1. The adoption went from convincing them to use the platform, to them flooding us with new feautres and data requests.
MCP benefits are way more important than AI rolling their own API client or CLI, after which YOU own the client. MCP is the protocol. If your 3rd-party API doesn't support the API fully in an MCP, that's when you think about rolling your own or writing that 3rd party a stern letter. Stability and security over bespoke client fragility. MCP (or a 3rd party managed CLI) all the way.
I (SiteSpeakAI) use MCP in production in 2 ways, to analyze usage and make improvements to the app itself to hopefully improve the customer experience, and then also as a feature for each customer so they can interact with their own cx install and monitor / improve prompts etc. Been really useful, but important to note most customers are at least a bit tech savvy, so MCP makes sense for them.
Don't think it would be that useful for non-tech users.
I use feedbackjar mcp. It's a feedback tool which also collects metadata like device, os, browser console etc. So my coding agent gets all the context of the feature request or bug report. https://feedbackjar.com
We offer MCP and then consume it with our in-app assistant to go from a non technical prompt to a series of what is essentially API calls they can automate for themselves for repetitive tasks or things that require a few screens to accomplish can be done from the assistant widget itself, etc.
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.
As a consumer, I use BetterStack's MCP server pretty much daily to search server logs and resolve reported errors - super helpful! But a CLI would be equally useful here.
I've ramped up my MCP game this year, I started with Linear and Notion and I recently launched an internal MCP for internal data that is being used by my colleagues too for reporting and preparing for meetings with customers (we do upsells for hotels www.upsellguru.com ). It seems like that some of the most tech savvy customers are looking forward to use it too and we may open to them too.
at Hedgy we built an MCP to give our agents read-only access to cross-system data + context about what it means [0]. daily it helps me debug customer flows and think through features and priority.
the advantage of MCP is that the tool description names what data it has so the agents know to just use it if they want that kind of data. as new data is added, everyone’s tool description updates. with a REST api or cli I suppose we could update a checked in AGENTS.md to ship it to engineers but idk how id get that to colleagues using the it from their claude.ai or co-work.
[0]: setoku.com
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.
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?
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.
>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.
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.
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.
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?
360°? That's weak.
The real experts have a 720° FoV with multiverse time travel.
lol!
I’d be willing to believe that!
Corporate still runs lots of bullshit for compliance, though.
what happens when openai offers compliance as a service?
Why don’t you tell us instead of asking questions
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).
When writing agentic apps (apps which embed an agent for semantic work), exposing the same tools which are injected into the agents as an MCP allows for practically the same functionality to be debugged and run in a normal agentic harness.
Good for both development and cost reduction, as the agentic harnesses often allow for much greater amount of token usage per subscription, as opposed to API key which always is per volume.
I am active user of the MCPs for HubSpot, cal.com, search console, google ads and typeform under Perplexity Computer. They work pretty well to create reporting and propose marketing ideas.
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.
Atlassian’s MCP is phenomenal and they e had theirs longer than Linear
>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]?
[1] https://linear.app/docs/mcp [2] https://modelcontextprotocol.io/specification/2026-07-28
They probably mean the tool APIs that the MCP server exposes are well designed. Definitely makes a big difference.
That's what we used in our product - a bug report tool that uses Linear MCP to create a task. Works great.
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.
In my previous company we used MCP for voice agents. It was easy to use open-source mcps, since we did all the oauth and account management on our side. This also makes it easy for customers to bring their internal tools in a standardized format.
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.
Chatbot+MCP, agentic workflow+harness seems to be the divide in my workplace: Business people want a chat UI, they get MCP. Developers want to automate things, they plug in their dotfiles and other scripts. Not sure if it reflects the larger population.
Interestingly most people in the comments talk about implementing an MCP server, while few talk about implementing an MCP client (as in actually using MCP for a specific purpose)
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.
Custom connector to paperless for processing fetching, reason... Off any physical contract or letter received by the company. Google drive for everything digital. Paperless for more legal things.
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.
We use MCP in our monitoring systems.
A claude routine runs without access to internet except for Slack (API) and Sentry (MCP).
It reads the Sentry MCP, compare the errors to the app source code and post a daily digest to Slack.
The reports are very accurate.
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.
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.
I use MCP to create and manage forms on Tally (tally.so). It works very well.
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
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.
Our company has an MCP which hooks into a bunch of metrics/analytics that we've been using to do RCA on a whole slew of issues.
I do, was using Grafana MCP to a local Grafana instance for QA-testing my web server.
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.
I use fff [1] For the performance improvements when reading files. I prefer in most scenarios to use skills.
(1) https://github.com/dmtrKovalenko/fff
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.
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
We used to use the jira mcp, then a jira skill, and now simply use the jira acli. Much cheaper and works fine
Jira/Atlassian APIs are so convoluted anyways, I'd rather use the MCP
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
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)
Linear MCP, custom made Node-RED MCP and a custom made ERP vendor MCP.
All prove great value.
well it is in production but very low usage mapkin.eu and jotkin.eu mainly tools i use myself to send stuff to clients basically persist chat via mcp.
even if you try to provide an MCP of your existing product so any AI client can interact with it, I would argue APIs are a better implementation.
many things once needed a MCP server now could be easily done via using CLI by agent
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)?
This is the answer.
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
We use for jira, confluence, excel. Attlassian projects require Rovio and this is additional payments. So we wrote our mcp to connect and work with them
We use MCP in production.
We built an MCP integration for agentic access to our platform, Proxybase [0]. It lets agents buy and sell bandwidth through SOCKS5 proxies directly from the platform.
The main benefit is simpler integration with agentic harnesses. MCP still accounts for only around 20% of the agents using Proxybase, but it has made the integration process much easier for those users.
[0]: https://proxybase.xyz
I use MCP for Stackography, a tool I built that visualises my estate (hosts, apps, databases, tunnels, proxies etc), showing a force-directed graph, which includes live health, and a flexible search tool. It's very good for answering questions like "what stuff am I running under Docker", or "show me everything that makes up app X". Also shows the history of changes, summarised by LLM.
MCP is useful because it has instructions to Claude (or the agent of your choice) that tell it how and when to manage the graph. Integrating with Stackography is a one-line operation:
Now when Claude builds me something new, it knows to update Stackography.invite link: https://stackography.com/invite/8J22NXZSFT
I use almost no MCPs and feel like I'm not missing out on anything, I just use APIs directly or CLIs. I honestly don't quite see the point of MCPs any longer.
Yup, but with some caveat. For things like backstage, which have MCP servers but are really fucking insecure, we have a wrapper API that is then linked to a skill.
Over the past 3 months we've been using it a LOT. I made one for our admins so they can work with the CMS and get statistics in their client, the statistics part has been a huge unlock. The big advantage here is that a normal API, direct tool integration or CLI are unpractical to set up for my less technical coworkers.
Other then that I've been building MCP's in pretty much all (personal) tools I'm making now, it's very useful to have a central way for an agent to look at production data without having to ssh into a server.
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.
i’m a day or two from releasing my programming language’s new mcp
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!
-
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)
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.
cgarvis is the only one who’s right
All the others are cringe ad bots and the gullible/liars plugging MCP
I give this thread: 8/10 cringe
Dead tech