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 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.
> "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.
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 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.
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 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 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.
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
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 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 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.
> "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.
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 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.
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?
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 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
That's what we used in our product - a bug report tool that uses Linear MCP to create a task. Works great.
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.
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
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