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
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.
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.
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.
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.
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.
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.
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.
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.
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 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
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!
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
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
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.
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.
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.
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.
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 use fff [1] For the performance improvements when reading files. I prefer in most scenarios to use skills.
(1) https://github.com/dmtrKovalenko/fff
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.
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?
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 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.
>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.
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.
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 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
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!
many things once needed a MCP server now could be easily done via using CLI by agent
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
i’m a day or two from releasing my programming language’s new mcp