alt Hacker NewsBased on the comments here, a lot of folks are assuming the primary users of mcp are the end users connecting their claude/vscode/etc to whatever saas platform they're working on. While this _is_ a huge benefit and super cool to use, imo the main benefit is for things like giving complex tool access to centralized agents. Where the mcp servers allow you to build agents that have the tools to do a sort of "custom deep research."
We have deployed this internally at work where business users are giving it a list of 20 jira tickets and asking it to summarize or classify them based on some fuzzy contextual reasoning found in the description/comments. It will happly run 50+ tool calls poking around in Jira/confluence and respond in a few seconds what would have taken them hours to do manually. The fact that it uses mcp under the hood is completely irrelevant but it makes our job as builders much much easier.
Replies
As someone who does both, I have to say that the only reason I am writing MCP stuff is that all the user-side tools seem to support it.
And the moment we, as an industry, settle on something sane, I will rip out the whole thing and adopt that, because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling.
Then again, I have run the whole gamut since the EDI and Enterprise JavaBeans era, XML-RPC, etc. - the works. Our industry loves creating new API surfaces and semantics without a) properly designing them from the start and b) aiming for a level of re-use that is neither pathological nor wasteful of developer time, so I'm used to people from "new fields of computing" ignoring established wisdom and rolling their own API "conventions".
But, again, the instant something less contrived and more integratable comes along, I will gleefully rm -rf the entire thing and move over, and many people in the enterprise field feel exactly the same - we've spent decades builting API management solutions with proper controls, and MCP bodges all of that up.
Where I struggle conceptually is this works fine without MCP.
Write a CLI tool that does the same thing (including external service access) and tell any agentic CLI tool (or Cursor or IDE tool) to use the tool. Much simpler, established security models, etc.
I’ve managed to do the same thing!
It’s actually surprising just how powerful 1-5 tools can be if you document it well and the llm knows how to pass arguments from other tool responses you had higher up in the thread
curious which MCP servers are you using for accessing JIRA/Confluence ? So far haven't found any good/official ones.
I'm doing the same thing now (with Slack as a medium of interaction with the agent) --- but not with MCP, just with straight up tool call APIs.
I've found it to be amazing purely as a new form factor for software delivery. There's a middle ground so common in enterprise where there's a definite need for some kind of custom solution to something, but not enough scale or resourcing to justify building out a whole front end UI, setting up servers, domains, deploying, and maintaining it. Now you can just write a little MCP tool that does exactly what the non-technical end user needs and deliver it as a locally installed "plugin" to whatever agentic tooling they are using already (Claude Desktop, etc). And using Smithery, you don't even have to worry about the old updating concerns of desktop software either; users get the latest version of your tooling every time they start their host application.
I suppose it shouldn't bother me that the people doing that are 'business users' but I have to wonder if adults these days are so illiterate that they can't read through 20 jira tickets and categorize them in less than an hour.