Provides comprehensive access to Jira Cloud functionality including issue management, project administration, agile boards and sprints, epics, comments, attachments, worklogs, and JQL search capabilities through the Jira REST API v3 and Agile API 1.0.
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., "@Jira MCP Server show me open issues in the current sprint"
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 token-efficient Jira MCP server and CLI for Claude, ChatGPT, Cursor, Cline, and any other Model Context Protocol (MCP) client. Gives AI agents full access to Jira Cloud via the REST API v3 and Agile API 1.0 — without burning your context window on Jira's verbose JSON.
Built for the way real teams use AI agents with Jira: triaging tickets, planning sprints, summarizing comment threads, drafting status updates, running JQL searches, moving issues through workflows — not just for engineers writing code. If your agent talks to Jira, this server keeps it fast and cheap.
Keywords: Jira MCP server, Jira Cloud MCP, Claude Jira integration, ChatGPT Jira, Cursor Jira, Cline Jira, Atlassian MCP, AI agent for Jira, JQL agent, sprint management AI, ticket triage AI.
Most Jira MCP servers wrap the REST API one endpoint per tool and pass raw responses straight to the agent. That works on toy tickets and falls over the moment you point it at a real backlog. Here's what ultra-jira-mcp does differently:
~17× smaller per-call responses. A real "investigate this ticket with its comments" call drops from 270 KB (~67k tokens) of raw Jira JSON to 15 KB (~3,900 tokens) — same description, comments, subtasks, and links, just without Jira's self URLs, icon URLs, nested schema metadata, and ADF rich-text ASTs. See docs/BENCHMARK.md for the full table.
Up to 99× smaller tool-list cost (the bytes paid into your context window on every conversation, before the agent has done anything). 16 consolidated tools instead of 80+ thin ones; optional code-api mode collapses that to a single tool that hands the agent a shell binary.
Full responses are never lost — they're written to a session-scoped temp dir and referenced by path. The agent reads the trimmed summary by default and cats the full payload only when it actually needs the detail.
ADF flattening built in. Atlassian Document Format trees become plain text on the way out, so a 500-byte comment doesn't arrive as a 4 KB nested AST.
Works as a standalone CLI too. The same jira-cli binary runs without any MCP server in the picture — drop it in a script, a CI job, or a non-MCP agent framework.
Tool surface you can prune. JIRA_ENABLED_CATEGORIES and JIRA_DISABLED_ACTIONS let you whitelist only the operations your agent should see (and block destructive ones like issue.delete at the dispatch layer, not just hide them from the schema).
Covers REST v3 and Agile API 1.0. Issues, comments, worklogs, attachments, users, projects, boards, sprints, epics, filters, links, watchers/votes, fields, groups. Not just CRUD on issues.
Ships a Claude Code skill. One command (jira-cli install-skill) drops a SKILL.md under ~/.claude/skills/jira/ so any future Claude Code session discovers the CLI on demand whenever the user mentions Jira.
If you're building anything beyond a demo — an agent that lives in a Slack channel triaging incoming tickets, a sprint-planning assistant that reads three boards, a release-notes drafter that scans a JQL filter — the per-call savings dominate every conversation longer than a handful of calls.
Related MCP server: Jira MCP
This isn't only for coding agents. Anywhere an LLM talks to Jira:
Ticket triage and routing — agent reads new issues, classifies, assigns, sets priority.
Sprint planning and retros — pull the backlog, summarize blockers, draft sprint goals.
Status reporting — JQL → trimmed list → human-readable update for Slack, email, or a Confluence page.
Comment thread summarization — long discussion threads collapse to the decisions and open questions.
Workflow automation — agent moves issues through transitions, assigns reviewers, links related work.
Incident and bug investigation — agent pulls a rich ticket with all comments, attachments, and linked issues in one trimmed response.
Cross-tool workflows — pair with Confluence, GitHub, Slack, or Bitbucket MCP servers to drive end-to-end flows.
Coding agents — yes, this too. Claude Code, Cursor, Cline, and friends can pick up tickets, implement them, and update status without flooding context.
npx ultra-jira-mcpOr globally:
npm install -g ultra-jira-mcpSet these environment variables on the server process. With Claude Desktop or Claude Code that means the env block on the MCP server config.
Variable | Description | Required |
| Jira instance URL (e.g. | Yes |
| Atlassian account email | Yes |
| API token from Atlassian Account Settings | Yes |
| Cloud ID for scoped (ATATT/ATSTT) tokens; auto-fetched if omitted | No |
|
| No |
| Comma-separated category whitelist. Empty = all 16 categories enabled. | No |
| Comma-separated | No |
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or your ~/.claude.json:
{
"mcpServers": {
"jira": {
"command": "npx",
"args": ["-y", "ultra-jira-mcp"],
"env": {
"JIRA_HOST": "https://yourcompany.atlassian.net",
"JIRA_EMAIL": "your-email@example.com",
"JIRA_API_TOKEN": "your-api-token"
}
}
}
}Default mode is classic: 16 consolidated MCP tools, each taking an action argument plus action-specific args. For example jira_issue covers get, create, update, delete, bulkCreate, listTransitions, transition, assign, changelog — discriminated by action: "...".
Tool | Actions |
| get, create, update, delete, bulkCreate, listTransitions, transition, assign, changelog |
| issues, jqlAutocompleteData, jqlSuggestions |
| list, add, update, delete |
| myself, search, get, assignable, bulkGet |
| list, get, create, update, delete, listComponents, createComponent, listVersions, createVersion, updateVersion, statuses |
| list, get, create, delete, configuration, issues, backlog, epics |
| listForBoard, get, create, update, delete, issues, moveIssues, moveIssuesToBacklog |
| get, issues, moveIn, removeFromCurrent |
| list, add, update, delete |
| get, delete, meta |
| list, get, create, update, delete, listFavourite |
| create, get, delete, types |
| list, add, remove, listVotes, addVote, removeVote |
| list, issueTypes, priorities, statuses, resolutions, createMeta |
| search, members, myPermissions |
| info |
Every action returns a trimmed summary (e.g. IssueSummary with key, status, assignee, recent comments, attachment list) plus the full untrimmed body written to disk under ${TMPDIR}/jira-mcp/${session}/. Agents read the full response only when they need the detail.
Two env vars cut the tool-list cost paid every conversation:
"env": {
"JIRA_ENABLED_CATEGORIES": "issue,search,comment",
"JIRA_DISABLED_ACTIONS": "issue.delete,project.delete"
}JIRA_ENABLED_CATEGORIES — whitelist of consolidated tool categories (the part after jira_). Tools outside the whitelist drop from the listing.
JIRA_DISABLED_ACTIONS — category.action pairs (manifest operation names like issue.delete, permissions.mine, vote.add). Disabled actions are stripped from each tool's oneOf schema and rejected at dispatch time, so they're blocked even in code-api mode.
Concrete numbers from a recent benchmark run on a real Jira instance:
filter | tool-list bytes | ~tokens | factor |
none (16 tools) | 30.6KB | ~7,800 | 1× |
3 categories | 6.3KB | ~1,600 | 5× |
3 cats + 5 disabled actions | 4.6KB | ~1,200 | 6.6× |
code-api mode (1 tool) | 0.4KB | ~100 | 76× |
For the full v1-vs-v2 picture (per-call cost, three scenarios, ratios) see docs/BENCHMARK.md.
If your agent can run shell commands (Claude Code, etc.), set JIRA_TOOL_MODE=code-api for a ~76× smaller tool-list footprint paid on every conversation. Per-call cost is essentially the same as classic, so the savings are pure win once your agent is making more than a few Jira calls.
Set JIRA_TOOL_MODE=code-api to expose a single MCP tool, jira_code_api. Calling it returns the path to the bundled jira-cli binary plus the JIRA_MCP_SOCKET address. The agent then drives Jira from a shell:
JIRA_MCP_SOCKET=/tmp/jira-mcp/${session}/ipc.sock \
node <cli-path> issue.get --issueIdOrKey=PROJ-1
# stdout: trimmed summary as JSON, then a final `ref: /path` line
# pointing at the full response on disk (`cat` it for detail).Discovery: node <cli-path> --help lists every operation; node <cli-path> <op> --help lists its flags.
Stays as classic by default because tool-only MCP clients (no shell access) can't drive jira-cli. See docs/MIGRATION.md for the full flow.
The same jira-cli binary works without an MCP server. Set JIRA_HOST / JIRA_EMAIL / JIRA_API_TOKEN in your shell (or a .env.local in the cwd) and invoke it directly:
export JIRA_HOST=https://yourcompany.atlassian.net
export JIRA_EMAIL=you@example.com
export JIRA_API_TOKEN=...
npx -y -p github:scottlepp/ultra-jira-mcp#codeapi jira-cli issue.get --issueIdOrKey=PROJ-1The CLI auto-selects between bridge mode (JIRA_MCP_SOCKET set, talks to a running server) and direct mode (no socket, builds a JiraClient in-process). Same trim + ref output either way; credentials never leave the CLI's process.env, so they don't enter the agent's context.
For Claude Code users, install the skill once so the agent discovers the CLI on its own:
npx -y -p github:scottlepp/ultra-jira-mcp#codeapi jira-cli install-skillThis writes ~/.claude/skills/jira/SKILL.md. The skill loads on demand whenever the user mentions Jira and teaches the agent the canonical invocation, common operations, and --help discovery. Re-run with --force to update; --print dumps the rendered SKILL.md to stdout without writing.
The server also exposes Jira data via MCP resources:
jira://projects — list of accessible projects
jira://project/{key} — project details
jira://issue/{key} — issue details
jira://boards — all boards
jira://board/{id} — board details
jira://sprint/{id} — sprint details
jira://myself — current user
npm install
npm run build # tsc → build/
npm test # vitest, ~400 unit tests, no live Jira
npm run benchmark # measures tool-list + per-call bytes against live Jira
npm run inspector # @modelcontextprotocol/inspector against build/index.jsThe benchmark requires .env.local with the regular JIRA_* vars plus JIRA_BENCH_TICKET_RICH and JIRA_BENCH_TICKET_SIMPLE keys. To include v1 in the comparison, set up a sibling worktree once: git worktree add ../ultra-jira-mcp-v1 v1.0.0 && (cd ../ultra-jira-mcp-v1 && npm install && npm run build). See docs/BENCHMARK.md for the latest numbers.
MIT
Add, inspect, or delete attachments. add uploads local file(s) by path (server reads the bytes — never pass contents). To download bytes, use the streaming downloader (returns a local path).
| Name | Required | Description | Default |
|---|---|---|---|
| issueIdOrKey | No | Issue key or id to attach the file(s) to. | |
| filePath | No | Local filesystem path(s) to upload. The server reads the bytes; do not pass file contents. | |
| attachmentId | No | ||
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully informs behavior: it explains that 'add' uploads local files by path (server reads bytes), warns against passing contents, and clarifies that 'full: true' is only for read actions and rejected by mutation actions. It also mentions the streaming downloader alternative.
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 concise and front-loaded, but the input schema repeats the same text in the 'description' field, leading to redundancy. Otherwise, it is well-organized with clear action breakdown.
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 output schema, the description adequately covers all actions, parameters, and behavioral nuances. It addresses reading vs mutation, file handling, and the streaming alternative, making it complete for an agent to use correctly.
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?
Despite 60% schema coverage, the description adds crucial meaning: it explains each action's required parameters, the purpose of 'attachmentId' for get/delete, and the behavior of 'full'. It clarifies that 'filePath' should be a local path, not contents, which the schema's description does not fully capture.
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 'Add, inspect, or delete attachments,' with explicit verb+resource. It distinguishes actions via the 'action' enum and contrasts with the streaming downloader for downloading bytes, differentiating from sibling tools like jira_issue.
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 specifies when to use each action (add, get, delete, meta) and prerequisites like required parameters. It also notes that to download bytes one should use the streaming downloader. However, it lacks explicit guidance on when not to use this tool in favor of others, though the action enum provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Agile boards: list/get/create/delete, fetch configuration, list board issues, backlog, and epics.
| Name | Required | Description | Default |
|---|---|---|---|
| startAt | No | ||
| maxResults | No | ||
| type | No | ||
| name | No | ||
| projectKeyOrId | No | ||
| boardId | No | ||
| filterId | No | ||
| location | No | ||
| jql | No | ||
| fields | No | ||
| expand | No | ||
| done | No | ||
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It explains that 'full: true' works on read actions but is rejected by mutations, which adds useful behavioral context. However, it lacks details on side effects, permissions, or error handling for mutations.
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 main description is a single concise sentence that captures the tool's scope. The schema description is longer but well-organized with actions and parameters, and the critical 'full' parameter behavior is clearly noted. A minor deduction for the main description being slightly generic.
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 complexity (14 parameters, 8 actions) and lack of output schema, the description covers essential information: actions, required parameters, and the 'full' flag behavior. It could improve by describing response formats or pagination, but overall it is reasonably 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?
The schema description (within the input schema) provides action-specific parameter requirements and optional fields, adding meaning beyond the raw schema. However, with only 7% schema description coverage, many parameters remain undocumented. The main description offers no parameter details, so the 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?
The description clearly states it manages Agile boards and lists specific actions (list/get/create/delete, configuration, issues, backlog, epics). This distinguishes it from sibling tools like jira_issue or jira_sprint, which handle different resources.
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 enumerates actions but provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites or scenarios where other tools would be more appropriate, leaving the agent to infer usage from the action list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List, add, update, and delete comments on a Jira issue. Bodies are ADF documents.
| Name | Required | Description | Default |
|---|---|---|---|
| issueIdOrKey | No | ||
| startAt | No | ||
| maxResults | No | ||
| orderBy | No | ||
| expand | No | ||
| body | No | ||
| visibility | No | ||
| commentId | No | ||
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the body format (ADF documents), the behavior of the 'full' parameter, and that mutations return minimal responses. It could be more explicit about error conditions or authorization, but overall it gives solid behavioral 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 relatively long but well-structured: a concise opening sentence followed by a clear breakdown of actions and the 'full' parameter. It is front-loaded with the main purpose. Slight verbosity could be trimmed, but it remains effective.
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 complexity (10 parameters, nested objects, enum action), the description covers the main use cases and parameter requirements. It lacks details on return values (no output schema), but mentions mutation responses are minimal. Adequate for most usage scenarios.
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?
With only 10% schema description coverage, the description adds substantial meaning to parameters. It explains each parameter's role per action, the enum values for 'action', and the 'full' parameter's effect. This far exceeds the minimal schema info.
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 handles CRUD operations for comments on a Jira issue with specific verbs: list, add, update, delete. It distinguishes itself from sibling tools like jira_attachment or jira_issue.
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 explicit guidance for each action, listing required and optional parameters. It also explains when to use the 'full' parameter and that mutation actions reject it. This helps the agent choose the correct action and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect epics, list issues under an epic, and move issues into or out of epics.
| Name | Required | Description | Default |
|---|---|---|---|
| epicIdOrKey | No | ||
| jql | No | ||
| fields | No | ||
| expand | No | ||
| startAt | No | ||
| maxResults | No | ||
| issues | No | ||
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that read actions have a summary projection and can be overridden with 'full: true', while mutation actions reject that parameter. This provides useful behavioral context beyond the bare minimum.
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 concise and front-loads the main purpose, but it packs many details into a single paragraph. Breaking it into sections could improve readability, but overall it avoids 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 tool with 9 parameters and no output schema, the description provides action-specific details but does not explain all parameters (e.g., jql, fields, expand, startAt, maxResults are only listed without description). The return value is partially explained (summary projection vs raw response), but more completeness 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?
The schema description coverage is only 11%, but the description compensates by explaining each action and its required parameters (e.g., 'get' requires epicIdOrKey, 'issues' requires epicIdOrKey with optional parameters, etc.). It also clarifies the 'full' parameter's behavior in detail, 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 explicitly states the verbs: 'Inspect', 'list', and 'move', with the resource 'epics'. It clearly differentiates from sibling tools like jira_issue or jira_board by focusing on epic-specific 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?
The description implies usage by listing actions and required parameters, but it does not provide explicit guidance on when to use this tool versus alternative tools (e.g., when to use jira_issue for non-epic operations). The context is clear but lacks exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Jira metadata: fields, issue types, priorities, statuses, resolutions, and per-project createMeta.
| Name | Required | Description | Default |
|---|---|---|---|
| projectIds | No | ||
| projectKeys | No | ||
| issuetypeIds | No | ||
| issuetypeNames | No | ||
| expand | No | ||
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses behavior of the full parameter and that mutation actions reject it. Lacks details on authentication, rate limits, or error handling, but is adequate for a read-only metadata tool.
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 well-structured with a clear intro and bullet points for actions. It could be slightly more concise by removing redundant phrasing, but it is front-loaded and easy to scan.
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 7 parameters (1 required) and no output schema, the description covers purpose, actions, and the full parameter. It does not explain return data structure or error cases, but is reasonably complete for a metadata listing 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 only 14%. The description adds meaning for the action parameter (lists enum values and their purpose) and the full parameter. Other parameters (projectIds, etc.) are only mentioned briefly under createMeta, leaving most undocumented.
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 Jira metadata (fields, issue types, etc.), which is a specific verb-resource combination. It distinguishes itself from sibling tools like jira_issue or jira_project by focusing on configuration metadata rather than entities.
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 explains when to use the full parameter and that mutation actions reject full: true. However, it does not explicitly state when to avoid this tool in favor of siblings, e.g., for retrieving actual issues use jira_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage saved JQL filters: list/get/create/update/delete plus the current user's favourites.
| Name | Required | Description | Default |
|---|---|---|---|
| filterName | No | ||
| accountId | No | ||
| owner | No | ||
| groupId | No | groupname is deprecated; use groupId | |
| projectId | No | ||
| id | No | ||
| orderBy | No | ||
| maxResults | No | ||
| startAt | No | ||
| expand | No | ||
| filterId | No | ||
| name | No | ||
| jql | No | ||
| description | No | ||
| favourite | No | ||
| sharePermissions | No | ||
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that 'full: true' is only for read actions and mutation responses are minimal, but lacks details on side effects of delete, rate limits, or authorization requirements.
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 well-structured with a purpose statement, action list, and a note on 'full' parameter. Every sentence provides 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?
The description adequately covers actions and parameters but does not describe return values or pagination details for list actions, which would be helpful given the absence of an output 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?
Despite only 11% schema coverage, the textual breakdown of each action explicitly maps required/optional parameters (e.g., 'create: requires name, jql; optional description, favourite, sharePermissions'), adding significant meaning beyond the bare 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 'Manage saved JQL filters: list/get/create/update/delete plus the current user's favourites,' which precisely defines the tool's scope and distinguishes it from sibling tools like jira_issue or jira_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 provides detailed action-specific parameter requirements (e.g., 'list: optional filterName, accountId...'), but does not explicitly guide when to use this tool versus alternatives like jira_search or jira_issue for filtering operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search groups, list group members, and inspect the current user's permissions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| accountId | No | ||
| caseInsensitive | No | ||
| maxResults | No | ||
| groupId | No | Use the new groupId param (groupname is deprecated) | |
| includeInactiveUsers | No | ||
| startAt | No | ||
| projectKey | No | ||
| projectId | No | ||
| issueKey | No | ||
| issueId | No | ||
| permissions | No | Comma-separated permission keys | |
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that `full: true` bypasses summary projection for read actions and that mutation actions reject it. It also mentions that the default summary may drop content. It lacks details on authentication, rate limits, or side effects, but the disclosures are helpful.
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 moderately sized but well-structured, starting with a clear purpose then detailing actions. Every sentence adds value, but some explanations (e.g., the full flag) could be more concise. Overall, it is front-loaded and organized.
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 14 parameters, multiple actions, and no output schema, the description is fairly complete. It explains each action's parameters and the `full` flag behavior. It does not detail return values extensively, but mentions 'raw Jira API response' as a hint. Coverage of edge cases or errors is minimal, but acceptable.
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 only 21%, but the description adds significant meaning by explaining which parameters apply to each action (e.g., 'members' requires groupId) and the role of `full`. This compensates for the low schema coverage and provides context beyond the raw 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 three distinct actions: search groups, list group members, and inspect permissions. The tool name 'jira_group' aligns with these group-related operations, and it distinguishes from sibling tools that focus on other entities like attachments, boards, or issues.
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 lists actions (search, members, myPermissions) and their required parameters. It explains when to use each action and notes that mutation actions reject `full: true`. However, it does not explicitly state when NOT to use this tool or compare it to alternatives for creating or modifying groups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Jira issues: get, create, update, delete, bulk-create, list/perform transitions, assign, and read changelog. Returns trimmed summaries with refs to full payloads on disk.
| Name | Required | Description | Default |
|---|---|---|---|
| issueIdOrKey | No | ||
| fields | No | ||
| expand | No | Comma-separated expand list (e.g. changelog,transitions) | |
| update | No | ||
| historyMetadata | No | ||
| properties | No | ||
| transition | No | ||
| notifyUsers | No | ||
| deleteSubtasks | No | ||
| issueUpdates | No | Up to 50 issue update payloads | |
| accountId | No | ||
| startAt | No | ||
| maxResults | No | ||
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It explains the summary projection and full parameter behavior but omits side effects, auth requirements, or rate limits. Adequate but not thorough.
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?
Well-structured with a summary followed by action list. However, the summary sentence is duplicated in both the description and schema description. Otherwise concise and front-loaded.
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?
Covers all 9 actions and parameter requirements. Lacks details on output format beyond summary references. With 15 parameters and no output schema, completeness is moderate but adequate for an agent.
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 low (20%), but description ties parameters to specific actions (e.g., 'get: requires issueIdOrKey; optional fields, expand'). Some parameter info is repeated from schema. Compensates partially but not fully for low 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?
Description clearly states the tool's purpose: managing Jira issues with 9 distinct actions. It distinguishes from sibling tools like jira_comment, jira_attachment, etc., which handle sub-resources.
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?
Description lists actions and their required parameters but does not explicitly guide when to use this tool vs. alternatives like jira_search. Usage context is implied by the actions, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create, fetch, delete issue links, and list available link types.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Link type, e.g. { name: 'Blocks' } | |
| inwardIssue | No | e.g. { key: 'PROJ-1' } | |
| outwardIssue | No | e.g. { key: 'PROJ-2' } | |
| comment | No | ||
| linkId | No | ||
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given the absence of annotations, the description fully discloses key behavioral traits: it explains the `full` parameter effect for read vs mutation actions, and the minimal responses for mutations. It does not cover permissions or idempotency, but for a CRUD tool this is adequate.
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 concise (around 150 words) and well-structured: a single-sentence summary followed by a bulleted action list. Every sentence serves a clear purpose, avoiding 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?
Despite lacking an output schema, the description covers return behavior (default projection vs raw response for reads, minimal for writes). All actions and parameter requirements are explained, making the tool fully understandable.
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?
With only 57% schema description coverage, the description compensates by mapping actions to required parameters (e.g., create requires type, inwardIssue, outwardIssue; optional comment). This adds meaning beyond the schema, though some parameters like comment and linkId remain lightly described.
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 'Create, fetch, delete issue links, and list available link types.' This clearly identifies the resource (issue links) and the supported actions, distinguishing it from sibling tools like jira_issue or jira_attachment which handle other aspects.
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 details each action and their required parameters, providing clear context on how to use the tool. However, it does not explicitly mention when not to use it or suggest alternatives, leaving a minor gap in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Jira projects, their components, versions, and per-issue-type statuses.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| typeKey | No | ||
| categoryId | No | ||
| expand | No | ||
| status | No | ||
| startAt | No | ||
| maxResults | No | ||
| orderBy | No | ||
| projectIdOrKey | No | ||
| key | No | ||
| name | No | ||
| projectTypeKey | No | software, business, service_desk | |
| projectTemplateKey | No | ||
| description | No | ||
| leadAccountId | No | ||
| assigneeType | No | ||
| project | No | Project key the component belongs to | |
| projectId | No | Numeric project id (not key) | |
| startDate | No | ||
| releaseDate | No | ||
| released | No | ||
| archived | No | ||
| versionId | No | ||
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that mutation actions reject 'full: true' and read actions can return raw responses, which is a behavioral detail. However, no annotations are provided, and the description does not cover other behavioral traits like authentication requirements, rate limits, or side effects (e.g., deletion cascades).
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 structured into a clear list of actions with parameter requirements, making it easy to scan. It front-loads the overall purpose. However, there is slight redundancy: the opening sentence repeats the scope covered later in the action list. Overall, it is efficient and well-organized.
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 complexity (25 parameters, 11 actions) and no output schema, the description is fairly complete. It explains each action's required and optional parameters, the 'full' parameter behavior, and mutation vs read actions. Some edge cases or return value details could enhance completeness, but it adequately covers core usage.
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?
With schema description coverage at 16%, the description significantly compensates by explaining which parameters are required for each action. For instance, it states that 'listComponents' requires 'projectIdOrKey', while 'createComponent' requires 'project' and 'name'. This adds crucial meaning beyond the bare schema, though some parameters like 'query' remain unexplained.
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 manages Jira projects, components, versions, and statuses. It lists specific actions, making the purpose explicit. However, it does not distinguish itself from sibling tools like jira_board or jira_epic, which could lead to confusion about when to use this tool instead.
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 context for each action (list, get, create, etc.) and their required/optional parameters, implying when to use them. Yet it lacks explicit guidance on when not to use this tool or comparisons with alternatives. For example, it does not explain when to use jira_project vs jira_issue for project-related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Jira issues with JQL or fetch JQL autocomplete metadata. Issue results come back as a trimmed list with refs.
| Name | Required | Description | Default |
|---|---|---|---|
| jql | No | JQL query | |
| fields | No | Comma-separated field list | |
| expand | No | ||
| startAt | No | ||
| maxResults | No | ||
| nextPageToken | No | ||
| fieldName | No | ||
| fieldValue | No | ||
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description reveals important behavioral traits: results come back as a 'trimmed list with refs', and there is a 'full' parameter to bypass the summary projection. It also states that mutation actions reject full:true. This provides behavioral clarity beyond the schema.
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 main description is concise (two sentences) and front-loaded. The schema description adds necessary details without excessive verbosity. A slightly more structured presentation could improve clarity, but it is efficient overall.
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 10 parameters and low schema coverage (30%), the description explains the action logic and the full parameter but fails to cover many pagination and field selection parameters. There is no output schema, and the return value is only described as a 'trimmed list with refs', which is adequate but not exhaustive.
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?
The schema description adds meaning to the action enum and the full parameter, explaining their roles. However, with only 30% schema description coverage, many parameters (expand, startAt, maxResults, nextPageToken) are not explained in the description, leaving gaps. The description partially compensates for the low 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?
The description clearly states the tool's two main purposes: searching Jira issues with JQL and fetching JQL autocomplete metadata. This distinguishes it from sibling tools like jira_issue, which handles individual issues, and other search-related siblings.
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 does not provide guidance on when to use this tool versus alternatives. It does not mention that for specific issue operations, one should use jira_issue, or under what circumstances to use search versus other tools. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect the Jira server: version, build, deployment type.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It implies a read-only operation via 'Inspect', but does not explicitly state it is safe, non-destructive, or mention any rate limits or authentication requirements. For a simple info tool, the basic transparency is adequate but minimal.
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 top-level description is extremely concise (one sentence, 8 words) with no filler. The additional parameter details are placed logically in the schema description. Every part serves a purpose.
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 server info tool with only two parameters and no output schema, the description sufficiently explains the tool's purpose and parameter behavior. It could mention that the tool is safe to call repeatedly, but this is not a major gap.
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?
The schema description coverage is 50% (only 'full' has an individual description), but the description text inside the input schema adds meaning to both parameters: it explains the 'action' enum and the effect of 'full: true'. This compensates well for the missing per-parameter description on 'action'.
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 uses the specific verb 'Inspect' and identifies the resource as 'Jira server' with details on version, build, deployment type. It clearly distinguishes itself from sibling tools like jira_issue, jira_project, etc.
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?
No guidance is provided on when to use this tool versus other jira_* tools. There are no hints about prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Jira sprints: list/get/create/update/delete, list sprint issues, and move issues in or out.
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ||
| startAt | No | ||
| maxResults | No | ||
| state | No | ||
| sprintId | No | ||
| name | No | ||
| originBoardId | No | ||
| goal | No | ||
| startDate | No | ||
| endDate | No | ||
| completeDate | No | ||
| jql | No | ||
| fields | No | ||
| expand | No | ||
| issues | No | ||
| rankBeforeIssue | No | ||
| rankAfterIssue | No | ||
| rankCustomFieldId | No | ||
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that `full: true` is accepted only on read actions and rejected on mutations, which is helpful. However, it does not disclose potential side effects (e.g., deletion consequences), authorization requirements, or rate limits.
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 front-loaded with the core purpose and organized into a clear action list. It is somewhat long but every sentence adds value. Minor deduction for slight redundancy with schema.
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 20 parameters, multiple actions, and no output schema, the description covers all actions and key parameters adequately. It could mention error handling or idempotency, but overall it is comprehensive.
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?
With only 5% schema description coverage, the description compensates by detailing parameter usage per action. However, it does not fully clarify every parameter (e.g., `rankBeforeIssue`, `rankAfterIssue` lack detailed semantics). The baseline of 3 is appropriate given the partial compensation.
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 'Manage Jira sprints: list/get/create/update/delete, list sprint issues, and move issues in or out.' This clearly defines the tool's purpose and differentiates it from sibling tools like jira_issue or jira_board.
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 action-specific parameter requirements, but does not offer comparative guidance on when to use this tool instead of related tools like jira_issue or jira_board. The action list implies scope, but lacks explicit when-to/not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up Jira users: current authenticated user, search by query/accountId, list assignable users for a project or issue, or bulk-fetch by accountId.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | ||
| query | No | ||
| accountId | No | ||
| startAt | No | ||
| maxResults | No | ||
| property | No | ||
| sessionId | No | ||
| username | No | ||
| project | No | Project key — restricts to assignable for this project | |
| issueKey | No | Issue key — restricts to assignable for this issue | |
| actionDescriptorId | No | ||
| recommend | No | ||
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It describes read-like operations but does not explicitly state that the tool is read-only or mention any side effects, permissions, or rate limits.
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 relatively short but includes a list of actions. It could be more structured (e.g., separating actions) but is not verbose.
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 14 parameters, no output schema, and low schema coverage, the description is insufficient for an agent to understand parameter relationships, required vs optional fields per action, or return value expectations.
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?
With schema description coverage at 21%, the description should compensate for missing parameter details. However, it only lists operations without explaining parameter usage or providing context beyond what is in 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 that the tool looks up Jira users, listing several specific operations (myself, search, get, assignable, bulkGet). It distinguishes from sibling tools by focusing on user-related actions.
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 lists operations but provides no guidance on when to use this tool versus alternatives or how to choose among the actions. No exclusions or context for selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List, add, and remove watchers on an issue. Also: list votes and toggle the current user's vote.
| Name | Required | Description | Default |
|---|---|---|---|
| issueIdOrKey | No | ||
| accountId | No | ||
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It explains that mutation actions reject 'full: true' and that their responses are minimal, and that read actions with 'full: true' bypass the default summary. Missing details on authorization requirements or side effects, but the disclosed behavioral traits are valuable.
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 concise and well-structured: a summary sentence, a bullet list of actions with clear requirements, and a paragraph explaining the 'full' flag. Every sentence adds value without repetition.
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 output schema and no annotations, the description covers the tool's functionality thoroughly, including parameter dependencies and special behavior. However, it does not describe the output format or potential error responses, leaving some gaps for a complete understanding.
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 only 25% (only 'full' has a schema description). The tool description compensates fully by explaining the enum values for 'action', which parameters are required per action, and the effect of 'full'. This adds significant meaning beyond the bare 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 lists, adds, and removes watchers, as well as lists and toggles votes on an issue. The verb-resource combination is specific and distinguishes from sibling tools that focus on other aspects like issue CRUD or 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 detailed guidance on when to use each action, required parameters, and the behavior of the 'full' flag. It does not explicitly state when not to use this tool versus alternatives, but the sibling tools are sufficiently distinct that the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List, add, update, and delete worklogs on an issue. Supports remaining-estimate adjustment.
| Name | Required | Description | Default |
|---|---|---|---|
| issueIdOrKey | No | ||
| startAt | No | ||
| maxResults | No | ||
| startedAfter | No | ISO 8601 timestamp | |
| startedBefore | No | ||
| expand | No | ||
| timeSpent | No | ||
| timeSpentSeconds | No | ||
| comment | No | ||
| started | No | ||
| visibility | No | ||
| adjustEstimate | No | ||
| newEstimate | No | ||
| reduceBy | No | ||
| worklogId | No | ||
| increaseBy | No | ||
| action | Yes | ||
| full | No | If true, skip the summary projection and return the raw Jira API response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses support for remaining-estimate adjustment and explains the behavior of the 'full' parameter, including that mutation actions reject it. However, it lacks details on permissions, side effects, or error conditions.
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 structured by action and provides useful breakdowns, but it is somewhat verbose (e.g., repeating the first sentence in the schema description field). It could be more concise while retaining key 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 18 parameters, 4 actions, and no output schema, the description covers action-specific required params, estimate adjustment, and 'full' behavior. However, it does not describe the response format (e.g., returned worklog structure) or pagination details, leaving some gaps.
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?
With only 11% schema coverage, the description compensates by grouping parameters per action, listing required vs optional params, and explaining the 'full' parameter. It adds meaning beyond the schema but does not document every parameter individually.
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 that the tool can list, add, update, and delete worklogs on an issue, effectively identifying the verb+resource and distinguishing it from sibling Jira tools that handle other entities.
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 does not explicitly state when to use this tool over alternatives, but the sibling tools cover distinct resources, so context implies usage. No when-not-to-use or comparative guidance is provided.
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.
v2.4.2jira_attachment4 fields changedInput schema / descriptionPrevious value: -"Inspect or delete attachment metadata. To download bytes, use the streaming downloader (returns a local path).\nActions:\n- get: Get attachment metadata. (requires attachmentId)\n- delete: Delete an attachment. (requires attachmentId)\n- meta: Global attachment settings.\nPass `full: true` on read (GET) actions to bypass the summary projection and return the raw Jira API response. Useful when the default summary drops content you need. Mutation actions reject `full: true` — their responses are already minimal."New value: +"Add, inspect, or delete attachments. `add` uploads local file(s) by path (server reads the bytes — never pass contents). To download bytes, use the streaming downloader (returns a local path).\nActions:\n- add: Upload local file(s) as attachment(s). (requires issueIdOrKey, filePath)\n- get: Get attachment metadata. (requires attachmentId)\n- delete: Delete an attachment. (requires attachmentId)\n- meta: Global attachment settings.\nPass `full: true` on read (GET) actions to bypass the summary projection and return the raw Jira API response. Useful when the default summary drops content you need. Mutation actions reject `full: true` — their responses are already minimal."Input schema / properties / action / enumPrevious value: -[
- "get",
- "delete",
- "meta"
-]New value: +[
+ "add",
+ "get",
+ "delete",
+ "meta"
+]Input schema / properties / filePathAdded value: +{
+ "description": "Local filesystem path(s) to upload. The server reads the bytes; do not pass file contents.",
+ "oneOf": [
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ ]
+}Input schema / properties / issueIdOrKeyAdded value: +{
+ "description": "Issue key or id to attach the file(s) to.",
+ "type": "string"
+}v2.2.0jira_attachmentjira_boardjira_commentjira_epicjira_fieldjira_filterjira_groupjira_issuejira_linkjira_projectjira_searchjira_serverjira_sprintjira_userjira_watcherjira_worklogScored across 16 tools
Each tool targets a distinct Jira resource (issue, project, board, sprint, etc.) with no functional overlap. Tool names clearly indicate the resource they operate on.
All tools follow the consistent pattern 'jira_<resource_noun>', making it easy to predict tool names. No mixing of conventions.
16 tools cover the major Jira entities comprehensively without being excessive. The scope matches typical Jira usage well.
The tool set covers CRUD operations for core entities (issues, projects, boards, sprints), plus search, user management, and metadata. No obvious gaps for standard workflows.
Connect to Atlassian Jira, Confluence, Loom, and more to search, create, and manage your work.
Task manager your agent can fully operate: boards, tasks, sprints, roles, worklogs, day planner.
Give your AI agents the tools to build, manage, and run automation workflows.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
