Project management is already hard enough without the manual work underneath it. In this post, I walk through how we've reduced that manual work using AI and MCP, and how it has let us focus more on actually delivering results.
A note before diving deep We use Jira to track and manage our tasks, therefore this post focuses on Jira. But the same strategy would work for other tools as well.
The role nobody has a title for
We're a small team, and we don't have dedicated roles for Project Manager, Product Owner, or Scrum Master. It's basically one person without any dedicated title managing all of these responsibilities, and if you look at other small companies, I think that's normal.
What we noticed was that we were spending more time and energy managing our sprint board (on Atlassian Jira) than looking into what really matters for the project: people, business, product. Some of the tasks that took more time than necessary were backlog grooming, turning a rough idea into a well-formed ticket, and sprint planning.
So we evaluated how we could improve on this front, and it turns out AI is really good at exactly this kind of work. That, in theory, frees us up to think about the goal for the next sprint instead of which tickets go where. The same shift applies to meetings too, instead of digging through a transcript afterward to pull out action items, we can go straight from the meeting to tickets already in the backlog.
The setup
We use Claude for this, connected through MCP Express to our Atlassian instance.
Step 1: Connect Atlassian to MCP Express
Add a new tool inside your MCP Express Server
Search for and Add the Atlassian connector
Provide you Atlassian Server URL and connect over OAuth
Filter down to the tools you'll actually use
Step 2: Connect Claude to MCP Express
Retrieve your MCP Server URL from MCP Express.
Add a new custom MCP connector in Claude
Fill in the information and Connect.
That's it. No custom integration code, no maintaining an auth flow, no separate deployment to babysit.
Answering the whys
Looking at the setup, you might already have a few questions. I had a few of them myself and worked through them before landing on this. Maybe it helps you too.
- Why not use the Jira MCP directly? Possible, but then every function it offers would be directly available to my LLM. I couldn't restrict things like deleting tickets or comments. And with that many tools available at once, the model has more room to reach for the wrong one, which crowds the context and can hurt performance.
- Why not use an open source MCP? Also possible, but I don't want to manage the connection separately on every device I use, and I'd like this to work while I'm on the move too, on my phone included. I'd also want to know whether a given open source MCP is actively maintained or was a weekend project that stalled.
- Why go through an MCP gateway at all? It's what lets me control exactly which functionality and which credentials are exposed, tool by tool. It also lets me mix multiple tools and services into a single connection instead of managing one integration per tool.
What this actually unlocks
This isn't full automation
It's a second pair of hands for the mechanical half of the job. The judgment calls are still mine.
With that connection in place, a few things moved from "task I do" to "task I check":
- Sprint planning. I point Claude at the backlog and the sprint goal, and it comes back with a first pass at what belongs in the next sprint and what doesn't. I still make the call, but I'm reacting to a draft instead of building one from a blank board.
- Notes to tickets. This is the one that actually got us to start using this setup. Before, we'd talk something through in a meeting, agree on it, and then just forget to turn it into a ticket. Now I run the meeting notes or transcript through it and get several properly formatted tickets back at once, right fields, right project, right prefix if it's a bug. Nothing discussed gets lost, and I'm reviewing what came out instead of trying to remember it later.
- Duplicate issue cleanup. Instead of scrolling the backlog looking for the third copy of the same request, I can ask for anything that looks like a duplicate of a given ticket and get a shortlist to review. Still early days on this one, so no numbers on it yet below.
This was a deliberate line to draw, not a side effect. I want to stay on top of what's actually happening with the product, the people, and the business, and think strategically about what fits. What I don't need to be doing is the data entry underneath that.
What actually changed
It's been three weeks since we put this in place, and the effort that's gone into sprint planning has dropped noticeably. We now discuss high-level strategic direction as a team, then use Claude to pull the actual tickets together. For our four-person team, that's cut roughly an hour of sprint planning per person, per sprint.
Ticket grooming is faster too. With tickets created properly from meeting notes and transcripts in the first place, we're saving around 2 hours of effort every two weeks, on average.
But the biggest effect wasn't the hours. As a small team, we've never been more aligned on what our business goals actually are and what matters to the users and the product. The conversation has shifted from what should go in the ticket to what we're actually trying to achieve.
Using a different tool? This walkthrough is Jira specific because that's what we run on. If you manage your board somewhere else, tell us at hello@mcp-express.com and we'll help you get started.
