Nucleus logonucleus
‹ All use cases
Custom MCP server · self-hosted Jira

Their Jira isn't in the cloud. It's in Claude anyway.

A development team runs Jira on its own servers. They wanted to work it from Claude, but Claude's Jira connector targets Jira Cloud. Instead of asking every developer to run a Jira MCP server on their laptop, a Nucleus developer built one hosted server for everyone. Each person connects as themselves, and the server now works with any self-hosted Jira.

To first working versionday 1 To team-ready< 2 weeks Tools today15 Installed per laptopnothing
A developer, in Claude
What's left in the current sprint on the web board? Move WEB-412 to In Progress and note that I've picked it up.
Claude, through Nucleus, as that developer
list_boardslist_sprintsget_sprint_issueschange_ticket_status
Sprint 38 ends Friday. Open items:
WEB-412Locale switcher drops query stringIn Progress WEB-415Sitemap missing hreflang for /frTo Do WEB-409Cache headers on translated assetsTo Do WEB-401Upgrade the render workerDone
Moved WEB-412 and added your comment. Both show you as the author in Jira.
01

The connector stopped at the cloud

Plenty of engineering teams still run Jira Server or Data Center on their own infrastructure, for compliance, cost or history. The off-the-shelf Jira connector for Claude speaks to Jira Cloud. That left this team three options.

Option 1

Go without

  • Keep copying ticket text into Claude by hand
  • Claude can read what you paste, but can never update a ticket
  • The tracker stays the one system the assistant can't touch
Option 2

Everyone runs a local server

  • Every developer installs, configures and updates their own copy
  • Tokens sit in config files on every laptop
  • Versions drift, and whoever doesn't want to set it up is left out
Option 3 · chosen

One hosted server, in Nucleus

  • Built once and installed in Nucleus, like any other tool
  • Each person connects with their own Jira token, kept in the vault
  • Fixes and new tools reach everyone at once
02

From first commit to the whole team in under two weeks

The server follows the Nucleus template, so the hard parts were already done: transport, authentication, identity, metering, rate limits and audit. The developer's job was Jira itself. It's a dependency-light Go service that calls Jira's REST API directly.

Day 1Working, with 4 tools

Running end to end against the team's real Jira, through Nucleus, on the first day.

Day 3Any Jira, not just this one

The Jira address moved from server configuration to each install. That one change made the server multi-tenant.

Day 7Fit for daily use

More tools and tests, and searching by assignee: the shape the team's everyday questions needed.

Since then15 tools, grown from use

Sprints and boards, issue links and labels, and full-length descriptions. Each one was added as the team used the server and found what was missing.

Issues 9 tools

list_projectscreate_issueget_issuesearch_issuesupdate_ticketadd_commentchange_ticket_statuslink_issueslist_assignable_users

Sprints & boards 6 tools

list_boardslist_sprintsget_sprint_issuescreate_sprintadd_issues_to_sprintchange_sprint_state
03

Everyone connects as themselves

A Jira personal access token acts with the permissions of the person who created it. So each developer gets their own install holding their own token, and the server is built so it can't work any other way.

What each person's install holds

Stored encrypted in the Nucleus vault, never on a laptop.

  • Their own Jira personal access token
  • The address of their Jira, set per install
  • The token is passed to Jira only at the moment of a tool call
  • Revoking the install, or the token, cuts access immediately

What that guarantees

Jira's own rules, applied to the real person.

  • Claude sees only the projects and issues that person can see
  • Tickets, comments and transitions show that person as the author
  • Jira's audit history stays true, with no shared "bot" user
  • Nucleus adds its own record of every call, by person
The server deliberately has no fallback to a shared token. A single team token would have been quicker to set up, and it would quietly have made every developer act as one person, with that person's permissions, on every ticket. The design rules that out.
04

Built for one team, ready for any self-hosted Jira

Because the Jira address belongs to the install rather than the deployment, the server carries no customer-specific configuration. Another team or another company with Jira Server or Data Center connects the same way, with no new deployment and no code change.

Install: Jira (self-hosted)personal
Jira address
https://jira.example.com
Your Jira Server or Data Center, REST API v2
Personal access token
••••••••••••••••
Created in your Jira profile. Stored encrypted, sent only to your Jira.
Connect

What a new team needs

Two fields, filled in once by each person.

  • Their Jira's address
  • A personal access token from their own Jira profile
  • Nothing to install, run or update on any machine
  • The same 15 tools from Claude, Dispatch or any MCP client
05

Shaped by how an assistant actually uses Jira

A wrapper around the API would have worked. What made it good were the details found by watching Claude use it on a real instance.

288 → 4

Your projects, not every project

One real account could browse 288 projects and had touched 4. Listing projects defaults to the ones you've actually opened, and you can still search all of them by name.

whole

Descriptions come back complete

A spec or a stack trace isn't cut off at some arbitrary length. A caller can page through a long description deliberately, and the pages join back into the original text.

exact

Errors that say what's wrong

Jira requires issue types to match exactly and reports a mismatch as a missing field. The tool lists each project's real issue types first, so tickets get filed correctly the first time.

This is the same pattern as the Flatten use case: a gap between what an off-the-shelf product supports and what a team actually runs. A Nucleus developer closes it once, with governance included, and everyone benefits. The next team on self-hosted Jira needs a token, not a project.
The difference

One server, built in under two weeks, used by everyone as themselves.

What Nucleus is → More use cases