This MCP server enables an AI agent to comprehensively manage a self-hosted Jira instance via the Jira REST API v2 and Agile/GreenHopper APIs, providing 16 tools across the following areas:
Story Management
Create, retrieve, update, search (JQL-backed), and delete stories
Specify summary, description, acceptance criteria, labels, priority, story points, and optional Outline PRD links
Add comments to stories
Workflow & Guarded Actions
Transition stories through workflow states (e.g., To Do → In Progress → Done)
Terminal transitions (e.g., Done/Closed) and destructive actions (e.g., delete) require explicit confirm: true
Multi-Project & Admin Management
List all visible projects and retrieve project metadata (priorities, issue types)
Create new projects and global issue types (admin only, requires confirm: true)
Agile Management (Jira Software required)
List Agile boards (scrum/kanban) and sprints with state and date info
Retrieve sprint burndown data (committed vs. completed vs. remaining points, issue counts, GreenHopper time-series) for AI analysis
Create boards and sprints (requires confirm: true)
Safety Features
Read-only tools (get_*, search_*, list_*) are annotated as safe
High-impact or destructive operations require confirm: true or return a warning without acting
All tools return structured JSON, including structured error objects
Configuration & Transport
Configured via environment variables or a JSON config file (Jira URL, credentials, default project key, custom field IDs)
Uses HTTP Basic Auth (email + API token)
Communicates via stdio using MCP JSON-RPC
Manages Jira Stories via the Jira REST API v2, providing CRUD operations, workflow transitions, search, and project info for Jira issues.
Provides agile burndown data, sprint and board listing for Jira Software projects, enabling AI-driven analysis of sprint progress.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-jira show me open stories in project PRD"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that lets an AI agent manage a self-hosted Jira instance over the Jira REST API v2 — create and edit Stories, search, transition workflows, manage boards & sprints, read burndown data, and (with confirmation) perform admin actions. Built for a PRD automation workflow, usable as a general Jira agent backend.
Transport: stdio
Auth: HTTP Basic (email:api_token)
16 tools across Story CRUD, workflow, multi-project, and Agile
Safety first: read/write/destructive annotations + server-enforced confirmation on risky actions
Related MCP server: Jira MCP Integration
Once published, run it directly with npx (no global install needed):
npx -y @deomi/mcp-server-jiraOr install globally:
npm install -g @deomi/mcp-server-jira
mcp-server-jiraOr from source:
git clone https://github.com/sina-haseli/mcp-server-jira.git
cd mcp-server-jira
npm install
npm run build
node dist/index.jsThe server reads config from the environment, so it won't do anything useful until you supply credentials (see below). It logs to stderr and speaks MCP JSON-RPC on stdout.
Provide settings in either of two ways. Per-setting precedence is: environment variable → config file.
Point JIRA_MCP_CONFIG at a JSON file:
{
"baseUrl": "https://jira.yourcompany.com",
"userEmail": "you@yourcompany.com",
"apiToken": "your_api_token_here",
"projectKey": "PRD",
"storyIssueType": "Story",
"outlineLinkField": "customfield_10100",
"storyPointsField": "customfield_10016"
}A template is provided in jira-mcp.config.example.json. Keep your
real file out of version control (the default .gitignore already ignores jira-mcp.config.json).
Variable | Required | Description |
| ✅ | Base URL, e.g. |
| ✅ | Account email/username for Basic Auth |
| ✅ | API token / Personal Access Token (or password) for Basic Auth |
| ➖ | Default project key (optional — override per call) |
| ➖ | Story issue type name (default |
| ➖ | Custom field id for the Outline link (e.g. |
| ➖ | Custom field id for story points (default |
| ➖ | Path to a JSON config file (Option A) |
Required settings are validated at startup; if any are missing the server logs a clear error to
stderr and exits. JIRA_PROJECT_KEY is optional — see Multiple projects.
All API calls target ${JIRA_BASE_URL}/rest/api/2 (core), /rest/agile/1.0 (boards & sprints),
and /rest/greenhopper/1.0 (burndown).
Open Settings → Developer → Edit Config (creates %APPDATA%\Claude\claude_desktop_config.json
on Windows, ~/Library/Application Support/Claude/claude_desktop_config.json on macOS) and add:
{
"mcpServers": {
"jira": {
"command": "node",
"args": ["D:\\projects\\mcp-server-jira\\dist\\index.js"],
"env": {
"JIRA_MCP_CONFIG": "D:\\projects\\mcp-server-jira\\jira-mcp.config.json"
}
}
}
}Or, once published to npm, with no local checkout:
{
"mcpServers": {
"jira": {
"command": "npx",
"args": ["-y", "@deomi/mcp-server-jira"],
"env": {
"JIRA_MCP_CONFIG": "D:\\projects\\mcp-server-jira\\jira-mcp.config.json"
}
}
}
}Fully quit Claude Desktop (tray → Quit, not just close the window) and reopen. Then run
get_project_info from the chat to confirm auth and connectivity.
Tool | Purpose |
| Create a Story from a PRD (acceptance criteria + Outline link) |
| Fetch a Story's key fields by issue key |
| Update selected fields of a Story |
| JQL text search for Stories (duplicate detection) |
| Project metadata: priorities, issue types, story type id |
| Add a plain-text comment to a Story |
Tool | Purpose |
| List or perform workflow transitions. Transitions to Done/Closed need |
| Permanently delete a Story. Requires |
Tool | Purpose |
| List all visible projects (discover |
| Admin. Create a project. Requires |
| Admin. Create a global issue type. Requires |
Tool | Purpose |
| List Agile boards (scrum/kanban) — get a board id |
| List a board's sprints with start/end dates and state |
| Burndown data for AI analysis (committed vs done vs remaining) |
| Create a scrum/kanban board from a saved filter. Requires |
| Create a sprint on a board. Requires |
Every tool returns structured JSON. Errors are returned as structured objects
({ error: true, message, ... }) — the server never throws unhandled exceptions out of a tool.
Two complementary mechanisms protect destructive and high-impact operations:
MCP annotations — every tool declares readOnlyHint / destructiveHint / idempotentHint /
openWorldHint. The host (e.g. Claude) uses these to decide when to prompt the human. Read-only
tools (get_*, search_*, list_*) are flagged as such; update_story and delete_story are
flagged destructive.
Server-enforced confirmation — delete_story, terminal transition_story calls, and all
admin create_* tools (create_project, create_issue_type, create_board, create_sprint)
require an explicit confirm: true. Without it the tool makes no API call and returns a
requires_confirmation warning describing the impact, so the agent (and human) must opt in
deliberately.
JIRA_PROJECT_KEY / projectKey is an optional default. Every project-scoped tool
(create_story, search_stories, get_project_info, list_boards) accepts an optional
project_key argument that overrides the default for that call. Use list_projects to discover
available keys. If no project_key is passed and no default is configured, the tool returns a clear
error rather than guessing.
An MCP server can't return a rendered chart image, but get_sprint_burndown returns the underlying
data: a reliable computed summary (committed / completed / remaining story points and issue
counts by status, derived from the sprint's issues) plus a best-effort raw GreenHopper burndown
time-series (burndown_chart_raw) when that internal endpoint is available. The AI can summarize
progress, flag scope changes, and describe the burndown from this data. Story points are read from
JIRA_STORY_POINTS_FIELD.
npm install
npm run dev # ts-node src/index.ts
npm run build # tsc -> dist/
npm start # node dist/index.jsProject layout:
src/
├── index.ts # bootstrap (stdio transport)
├── config.ts # env / config-file loading + validation
├── logger.ts # stderr logger
├── jira/
│ ├── client.ts # axios clients (core / agile / greenhopper) + browseUrl
│ └── errors.ts # error mapping + ok()/fail() result helpers
└── tools/
├── index.ts # registerAllTools()
├── shared.ts # registerTool wrapper, annotations, confirm + project helpers
└── *.ts # one file per toolReleases are automated by .github/workflows/release.yml: pushing a
v* tag builds the package, publishes it to npm (with provenance), and creates a GitHub Release with
auto-generated notes.
One-time setup: add a repo secret NPM_TOKEN (an npm Automation access token) under
Settings → Secrets and variables → Actions.
Cut a release:
npm version patch # or minor / major — bumps package.json and creates the tag
git push --follow-tagsThe workflow verifies the tag matches package.json before publishing.
MIT © Sina Haseli
Adds a plain-text comment to a Story. Used, for example, to log when the PRD doc is updated in Outline. Returns { success, comment_id }.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Plain text comment body | |
| issue_key | Yes | Issue key, e.g. "PRD-42" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) but non-destructive. The description adds the return shape { success, comment_id } and mentions plain-text limitation. This adds context beyond annotations, though permissions or side effects aren't detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core action, and provides an example and return info without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the action, return value, and a typical use case. It is adequate but could mention who can use it or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters have descriptions. The description echoes 'plain text' and the issue key example, but adds minimal new meaning beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Adds a plain-text comment to a Story,' providing a specific verb and resource. It distinguishes from sibling tools like create_story or update_story by focusing solely on adding comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage example ('to log when the PRD doc is updated in Outline'), implying appropriate contexts. However, it does not explicitly state when not to use or mention alternatives for similar actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a Jira Software Agile board (scrum/kanban) from an existing saved filter. Guarded: requires confirm:true. Requires Jira Software and permission to manage boards.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Board name | |
| type | Yes | Board type | |
| confirm | No | Must be set to true to actually perform this irreversible/high-impact action. If omitted, the tool returns a warning instead of acting. | |
| filter_id | Yes | Id of an existing saved filter that scopes the board's issues (boards are backed by a filter). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context beyond annotations: it flags the confirm guard and permission requirements. Annotations already indicate non-readOnly, non-destructive, but description clarifies the irreversible nature and authorization needs, adding value without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words, front-loaded with the core action. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (4 parameters, no output schema), the description covers the key functional aspects: action, prerequisites, guard. It could mention what happens on success/failure, but the high parameter description coverage compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The description reinforces the filter_id parameter by mentioning 'from an existing saved filter' but does not add substantial new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Creates a Jira Software Agile board (scrum/kanban) from an existing saved filter.' This clearly identifies the verb (creates), resource (board), and scope (from filter), distinguishing it from sibling tools like create_project or create_sprint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the guard 'requires confirm:true' and prerequisite 'Requires Jira Software and permission to manage boards.' This provides clear context on when to use, though it does not explicitly compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new issue type in Jira (admin only). Guarded: requires confirm:true. Issue types are global across the instance.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the new issue type, e.g. "Spike" | |
| type | No | Issue type kind (default standard) | |
| confirm | No | Must be set to true to actually perform this irreversible/high-impact action. If omitted, the tool returns a warning instead of acting. | |
| description | No | Optional description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description adds 'Guarded: requires confirm:true' and 'Issue types are global across the instance.' It also implies high-impact action via the schema, which annotations (destructiveHint: false) do not fully capture. The 'admin only' requirement is extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with no fluff. It front-loads the core purpose and critical constraints, making it easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers guard, admin requirement, and global scope, it does not describe the return value or error cases. For a creation tool with no output schema, mentioning what the tool returns (e.g., the created issue type details) would improve completeness. Current description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about the guard (confirm parameter) but does not substantially improve understanding beyond what the parameter descriptions already provide. It mentions 'admin only' which is not in schema, adding some value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'creates', resource 'new issue type', and scope 'global across the instance'. It effectively distinguishes from sibling tools like create_story and create_project, as no other sibling creates issue types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions 'admin only' and 'requires confirm:true', providing clear context on when to use. However, it does not explicitly state when not to use or suggest alternatives, but given the unique resource, the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new Jira project (admin only). Guarded: requires confirm:true. Some Jira versions require a template_key; if creation fails for that reason, retry with template_key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Project key, uppercase, e.g. "NEW" (must be unique) | |
| lead | Yes | Project lead. On Jira Server/DC this is the username; on Cloud it is the account id. | |
| name | Yes | Project display name | |
| confirm | No | Must be set to true to actually perform this irreversible/high-impact action. If omitted, the tool returns a warning instead of acting. | |
| description | No | Optional project description | |
| template_key | No | Optional project template key (some Jira versions require this, e.g. com.pyxis.greenhopper.jira:gh-simplified-scrum-classic). | |
| assignee_type | No | Default assignee policy | |
| project_type_key | No | Project type key, e.g. "software" or "business" (default "software") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description calls creation 'irreversible/high-impact' yet annotations have destructiveHint=false, creating a direct contradiction. This undermines the agent's ability to trust the metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences cover the essential purpose and key behavioral caveats without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a creation tool with schema coverage, but missing return value details and incomplete behavioral disclosure due to the contradiction. No output schema, so description should ideally give more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100%). Description adds value with 'admin only' and the confirm requirement, but does not significantly elaborate beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Creates a new Jira project' (verb + resource) and includes 'admin only', clearly distinguishing it from sibling tools like create_board or create_issue_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides useful guidance: requires confirm:true and retry with template_key if creation fails. Does not explicitly contrast with alternatives, but the sibling tools are for different entities so no strong need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a sprint on a scrum board. Guarded: requires confirm:true. Requires Jira Software.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | Optional sprint goal | |
| name | Yes | Sprint name | |
| confirm | No | Must be set to true to actually perform this irreversible/high-impact action. If omitted, the tool returns a warning instead of acting. | |
| board_id | Yes | Id of the scrum board to create the sprint on | |
| end_date | No | Optional end date, ISO 8601 | |
| start_date | No | Optional start date, ISO 8601 (e.g. 2026-07-01T09:00:00.000Z) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses guarded nature requiring confirmation, which is not fully covered by annotations (idempotentHint false, destructiveHint false). Also notes prerequisite 'Requires Jira Software'. Adds relevant context beyond structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences with no filler. Front-loaded with purpose, then key behavior (guarded) and prerequisite. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (2 required) and no output schema, the description covers purpose, guarding, and dependency. Lacks return value description, but schema descriptions for parameters are good. Reasonably complete for a simple creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The tool description adds no additional parameter-specific meaning beyond what's already in the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Creates a sprint on a scrum board' with specific verb and resource. Distinguishes from siblings like create_board, create_story by specifying sprint creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'requires confirm:true' which guides usage, but lacks explicit when-not-to-use or comparison with alternative tools. Could be improved with scenarios where other creation tools are preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new Jira Story from a PRD. Formats the description with acceptance criteria and an optional Outline PRD link, sets labels and priority, and (if an Outline URL is supplied) attaches it as a remote link. Returns the created issue key, id, and browse URL.
| Name | Required | Description | Default |
|---|---|---|---|
| labels | Yes | Labels, e.g. ["external", "feature"] | |
| summary | Yes | Story title / summary | |
| priority | Yes | Issue priority | |
| description | Yes | Full description in plain text | |
| project_key | No | Project key to target (e.g. "PRD"). Defaults to the configured JIRA_PROJECT_KEY if omitted. | |
| story_points | No | Optional story point estimate | |
| outline_doc_url | No | Optional URL of the Outline PRD doc to link back to | |
| acceptance_criteria | Yes | Acceptance criteria as a plain text list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutability (readOnlyHint=false). Description adds value by detailing formatting of description with acceptance criteria, setting labels/priority, and attaching remote link. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficient and front-loaded with primary action. Every sentence adds information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (5 required) and no output schema, description covers creation process and return values. Could add more about error behavior if Outline link fails, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds minimal extra meaning beyond schema (e.g., 'formats the description with acceptance criteria' hints at combined usage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new Jira Story from a PRD, with specific formatting and optional linking. It distinguishes from sibling tools like update_story and delete_story.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a PRD, but does not explicitly state when to use this tool versus alternatives like update_story or search_stories. No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PERMANENTLY deletes a Story by issue key. This is irreversible. Guarded: without confirm:true it returns a warning instead of deleting. Intended for human-approved cleanup only.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Must be set to true to actually perform this irreversible/high-impact action. If omitted, the tool returns a warning instead of acting. | |
| issue_key | Yes | Issue key to delete, e.g. "PRD-42" | |
| delete_subtasks | No | If true, also delete any subtasks (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses permanence, irreversibility, guarded behavior (confirm flag), and intended use case. Annotations already indicate destructiveHint true, but description adds the critical detail about warning vs deletion, which is beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding value. Front-loaded with the core action and irreversibility. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description adequately covers behavior, parameter effects, and return conditions (warning vs deletion). It is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter descriptions in schema are sufficient. The description reinforces the confirm parameter's guarded behavior but does not add new meaning beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), resource (Story), and input (issue key). It distinguishes from sibling tools like create_story, update_story, and get_story by specifying a destructive operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: irreversible, requires confirmation, intended for human-approved cleanup. It implicitly warns against casual or automated use but does not explicitly name alternatives like transition_story or update_story for deactivation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns metadata for a Jira project: project key/name, available priorities, and the issue type id for Stories. Defaults to the configured project; pass project_key to target another. Use this to validate input before creating issues.
| Name | Required | Description | Default |
|---|---|---|---|
| project_key | No | Project key to target (e.g. "PRD"). Defaults to the configured JIRA_PROJECT_KEY if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true; description adds specifics about returned data and default project, complementing the annotations well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then default behavior, then use case. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single optional param and no output schema, description fully covers purpose, parameters, return details, and use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100%, so baseline 3. Description adds that project_key defaults to configured value if omitted, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns project metadata (key/name, priorities, story issue type id) and distinguishes from sibling tools like list_projects by targeting a specific project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for input validation before creating issues, and explains the default project behavior, guiding when to pass project_key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns burndown data for a sprint so the AI can analyze/summarize progress (this is data, not a rendered chart image). Includes a reliable computed summary (committed vs completed vs remaining story points, issue counts by status) plus best-effort raw GreenHopper burndown time-series. Requires Jira Software.
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | Board id (rapid view id) the sprint belongs to | |
| sprint_id | Yes | Sprint id (from list_sprints) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by describing the returned data (summary and best-effort raw time-series), partially addressing behavioral traits like reliability ('best-effort').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words, and clearly structured to present key information first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description adequately explains the return data (computed summary and raw time-series) and includes a prerequisite. Parameter coverage is complete via schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description does not add any additional detail beyond the schema, so it meets the baseline without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'returns', the resource 'burndown data for a sprint', and distinguishes itself from a chart image, which differentiates it from sibling tools like get_story or list_sprints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing/summarizing progress and notes a prerequisite ('Requires Jira Software'), but does not explicitly exclude alternative tools or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves a Story by its issue key (e.g. PRD-42). Returns the key fields an AI agent needs: summary, description, status, labels, priority, and browse URL.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_key | Yes | Issue key, e.g. "PRD-42" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) already indicate safe read behavior. The description adds that it returns specific fields, which is useful but does not disclose additional traits like rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose is front-loaded and the description is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, read-only, no output schema). The description covers the return fields adequately for an AI agent, though a bit more detail on output structure would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter 'issue_key' is already described in the schema. The description reinforces the expected format (e.g., 'PRD-42') but adds no new semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Retrieves', the resource 'Story', and the input (issue key). It also lists the returned fields, clearly distinguishing it from siblings like 'search_stories' that perform broader searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single story by key but does not explicitly state when to use this tool over alternatives (e.g., 'search_stories' for queries). No guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists Jira Software Agile boards (scrum/kanban). Returns board id, name and type. The board id is needed to list sprints and fetch burndown data. Requires Jira Software (Agile) on the instance.
| Name | Required | Description | Default |
|---|---|---|---|
| project_key | No | Project key to target (e.g. "PRD"). Defaults to the configured JIRA_PROJECT_KEY if omitted. | |
| all_projects | No | If true, list boards across all projects; otherwise only boards for the target project (default). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to restate. The description adds the critical prerequisite ('Requires Jira Software'), which is beyond what annotations cover. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences cover purpose, output, and usage context without redundancy. Front-loaded with the main action. One more sentence could be trimmed but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately describes return values (id, name, type). It also links to downstream tools (list_sprints, burndown). With readOnlyHint annotation covering safety, the tool is well contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have detailed descriptions including default behavior. The description does not add new information beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists Jira Agile boards (scrum/kanban) and specifies returned fields (id, name, type). Distinct from sibling tools like create_board or list_sprints, establishing its role as a prerequisite for other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions that Jira Software (Agile) is required and that the board id is needed for listing sprints and fetching burndown data, implicitly guiding when to use this tool first. Could explicitly exclude scenarios, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all Jira projects visible to the account. Returns key, name, id and project type for each. Use this to discover which project_key to pass to other tools when working across multiple projects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds context by specifying that it returns only visible projects and lists the exact fields returned. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, extremely concise, front-loaded with key information (lists all projects), no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and annotations present, the description is complete enough. It states what is returned and how to use it. Minor omission: no mention of pagination or limits, but acceptable for a list-all tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% (empty). The description adds full meaning by explaining that the tool lists all projects without any filtering needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all Jira projects visible to the account, and specifies the returned fields (key, name, id, project type). This distinguishes it from siblings like get_project_info (single project) and create_project (write operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool to discover which project_key to pass to other tools when working across multiple projects, providing clear context. It does not explicitly state when not to use it, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists sprints for a given Agile board. Returns sprint id, name, state, and start/end dates. Use the sprint id with get_sprint_burndown. Requires a scrum board.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional filter by sprint state | |
| board_id | Yes | Board id (from list_boards) whose sprints to list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so description adds return field details but no extra behavioral traits like pagination or rate limits. Consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loading purpose and returns, then usage tip and requirement. No unnecessary words, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 2 well-documented params and annotations, description is fairly complete. Could explicitly tie board_id to the board that must be a scrum board, but overall good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters (board_id and state) with source and enum, so baseline of 3 is appropriate. Description does not add further parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists sprints for a given Agile board and specifies returned fields (id, name, state, dates). Distinguishes from sibling tools like get_sprint_burndown and list_boards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context: use sprint id with get_sprint_burndown and requires a scrum board. Does not explicitly state when not to use or list alternatives, but gives clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for Stories in the configured project using a plain-text query (wrapped in JQL). Useful for checking duplicates before creating a new Story. Returns an array of { key, summary, status, labels, url }.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Plain text search; matched against issue text via JQL ~ | |
| max_results | No | Maximum results to return (default 10) | |
| project_key | No | Project key to target (e.g. "PRD"). Defaults to the configured JIRA_PROJECT_KEY if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, non-destructive read operation. The description adds that the query is 'wrapped in JQL' and returns a specific set of fields, providing useful behavioral context beyond the annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first defines the core action, second gives a use case and return format. It is front-loaded, no redundant words, and every sentence adds value. Perfectly concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema (but description specifies return format), and annotations cover safety/open world, the description is fairly complete. It includes purpose, usage hint, and return structure. Missing details like pagination or error behavior, but acceptable for a simple search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters (query, max_results, project_key). The description mentions the query as 'plain-text query' but does not add meaningful extra semantics beyond the schema. The return format hint helps slightly, but overall parameter info is adequately covered by schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Searches for Stories'), the resource ('Stories in the configured project'), and the input ('plain-text query wrapped in JQL'). It distinguishes from siblings like 'get_story' (single retrieval) and 'list_*' tools by specifying a text-based search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a use case: 'Useful for checking duplicates before creating a new Story.' This provides clear context for when to use the tool. However, it does not explicitly mention when not to use it or compare to alternatives among siblings like 'get_story' for single retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Moves a Story through its workflow (e.g. To Do -> In Progress -> Done). Call without transition to list available transitions. Transitions into a terminal status (Done/Closed/Resolved) are guarded and require confirm:true.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | No | Optional comment to add as part of the transition | |
| confirm | No | Must be set to true to actually perform this irreversible/high-impact action. If omitted, the tool returns a warning instead of acting. | |
| issue_key | Yes | Issue key, e.g. "PRD-42" | |
| transition | No | Target transition name (e.g. "Done") or transition id. Omit to just list the available transitions for this issue. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it reveals that transitions into terminal statuses are guarded and require confirmation, and that omitting the transition parameter lists available transitions. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, extremely concise and front-loaded with the core action. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers the key behaviors. However, since there is no output schema, mentioning what the listing of transitions returns would improve completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds meaning beyond the schema: it explains the effect of omitting `transition` (lists available transitions) and the special role of `confirm` for irreversible actions. This enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: moving a Story through its workflow, with concrete examples (To Do -> In Progress -> Done). It distinguishes from sibling tools like update_story or create_story by focusing specifically on workflow transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call without `transition` to list available transitions and notes that terminal statuses require `confirm:true`. It provides clear context for usage but does not explicitly compare to alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates fields of an existing Story (e.g. after human approval edits). Only the fields you supply are changed. Returns { success, key }.
| Name | Required | Description | Default |
|---|---|---|---|
| labels | No | Replacement labels list | |
| summary | No | New summary / title | |
| priority | No | New priority | |
| issue_key | Yes | Issue key, e.g. "PRD-42" | |
| description | No | New plain-text description | |
| story_points | No | New story point estimate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and readOnlyHint=false, consistent with 'Updates'. Description adds key behavioral detail: only supplied fields are changed (partial update). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core action and behavior. Every word adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, description covers return value, partial update behavior, and usage context. Missing details on idempotency (annotations hint) or error handling, but adequate for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description adds no new parameter info but reinforces partial update behavior. Baseline 3 due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'updates' and resource 'Story'. Includes a usage hint ('after human approval edits') and distinguishes from create/delete by implying modification of existing entity. Returns format is specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies typical use case (after human approval), but does not explicitly state when not to use or compare to sibling tools like transition_story. Provides context but lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_boardcreate_issue_typecreate_projectcreate_sprintcreate_story1 field changedInput schema / properties / project_keyAdded value: +{
+ "description": "Project key to target (e.g. \"PRD\"). Defaults to the configured JIRA_PROJECT_KEY if omitted.",
+ "type": "string"
+}get_project_info2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / project_keyAdded value: +{
+ "description": "Project key to target (e.g. \"PRD\"). Defaults to the configured JIRA_PROJECT_KEY if omitted.",
+ "type": "string"
+}list_boards2 fields changedInput schema / properties / all_projects / descriptionPrevious value: -"If true, list boards across all projects; otherwise only boards for the configured project (default)."New value: +"If true, list boards across all projects; otherwise only boards for the target project (default)."Input schema / properties / project_keyAdded value: +{
+ "description": "Project key to target (e.g. \"PRD\"). Defaults to the configured JIRA_PROJECT_KEY if omitted.",
+ "type": "string"
+}list_projectssearch_stories1 field changedInput schema / properties / project_keyAdded value: +{
+ "description": "Project key to target (e.g. \"PRD\"). Defaults to the configured JIRA_PROJECT_KEY if omitted.",
+ "type": "string"
+}v1.0.0add_commentcreate_storydelete_storyget_project_infoget_sprint_burndownget_storylist_boardslist_sprintssearch_storiestransition_storyupdate_storyScored across 16 tools
Every tool targets a distinct resource and action: story CRUD, comments, transitions, project metadata, and Agile board/sprint operations are clearly separable. Even with shared verbs like 'get' or 'create', the noun targets prevent confusion.
Tool names consistently follow verb_noun conventions with get/create/update/delete/list/transition/add prefixes. Minor pluralization in search_stories and the info suffix in get_project_info do not break the overall pattern.
16 tools is slightly above the ideal 3-15 range but appropriate for a Jira server covering both story lifecycle management and Agile board/sprint operations. Each tool appears purposeful with minimal redundancy.
The story lifecycle is well covered: get, create, update, delete, search, transition, and comment. Some minor gaps exist around generic issue operations and board/sprint deletion, but the set covers the core PRD-to-Jira and Agile tracking workflows well.
Task manager your agent can fully operate: boards, tasks, sprints, roles, worklogs, day planner.
Connect to Atlassian Jira, Confluence, Loom, and more to search, create, and manage your work.
Track stories, organize sprints, and manage project workflows across your team
Give your AI agents the tools to build, manage, and run automation workflows.
