The set reaches past issue CRUD into the work that usually means clicking — activating a sprint with its dates, ranking epics against each other, pulling velocity and burndown data — and it does all of it per instance, so several Jira sites are one server rather than one each. detect_project_fields is the piece that saves the most grief: the custom field IDs for story points, sprint and epic link are discovered per project instead of guessed. The strategic plan tools answer only on Jira Premium.
57 tools over Jira's REST and Agile APIs. Every call names an instance, so one install addresses several Jira sites, and the mapping from projects to instances is itself readable through a tool.
- Issues created, listed, read, updated, commented on and deleted, carrying epic link, sprint, story points, labels, priority and original estimate
- Valid workflow transitions read first, then applied by transition_id, plus bulk updates and relative ranking across issues
- Sprints created, activated with start and end dates, filled with issues and closed, with a details view showing progress
- Epics created — including an epic and its issues in one call — updated, ranked against each other, and their issues listed or moved
- Boards with their configuration, quickfilters and reports, JQL search with saved filters, and the agile metrics over them: sprint report, velocity chart, burndown and cumulative flow
- Versions and components with progress breakdowns, project workflow statuses and issue types, and Premium strategic plans
- Custom-field discovery: story points, sprint and epic link IDs detected per project, or every field on the instance listed
A Jira account and a .jira-config.json describing your instances and their project mappings — every call takes an instance parameter, and list_instances returns what is configured. Node on your PATH.
One command plus a key — npx -y jira-server, then supply credentials