Which integrations are available for this server?

Provides tools to interact with Atlassian Jira, enabling management of issues, attachments, and search via JQL.

How do I use mcp-server-atlassian-jira?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-atlassian-jira list all issues assigned to me in project PROJ" 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.

mcp-server-atlassian-jira

by asky74

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

mcp-server-atlassian-jira (UFC fork)

Private UFC fork of aashari/mcp-server-atlassian-jira (forked at upstream commit aab8b7f2, one commit past v3.3.0), carrying:

Binary response corruption fix - upstream's fetchAtlassian() (src/utils/transport.util.ts) read every response body via response.text(); for binary endpoints (attachment content, thumbnails, exports) that is a lossy, irreversible UTF-8 decode. Fixed: non-JSON/text/XML bodies are read via arrayBuffer() and returned as { __binary: true, contentType, byteLength, base64 }. Covered by regression tests in src/utils/transport.util.test.ts.
Ported upstream community PR #173 (author cedral) - jira_attach (multipart upload) and jira_get_attachment (byte-exact download to a local file).
DOTENV_CONFIG_PATH with ~-expansion in src/utils/config.util.ts@loadFromEnvFile, plus USE_DOTENV toggle - credentials live in a per-user file outside any repo/package tree (team convention: ~/.claude/jira.env).
Unconditional main() in src/index.ts (the upstream require.main === module guard broke startup under embedded Node runtimes).
node:https transport fallback (safeFetch in src/utils/transport.util.ts) - in some MCP host processes the global fetch (undici) fails with TypeError: fetch failed despite a live network (observed 2026-07-14 in a Claude-Code-session-spawned connector instance, while a Desktop-spawned instance on the same machine was fine). On that failure the request is retried through the classic node:https stack (multipart encoded via new Response(FormData), redirects followed with Authorization dropped cross-host). FORCE_HTTPS_FALLBACK=true forces the fallback path (diagnostics / emergency lever). Verified live: JSON GET, JQL search, and a byte-exact 2.1 MB binary download through the media-CDN redirect.
Unresolved-template env guard + creds-path fallback - some hosts pass the MCPB manifest env without substituting ${user_config.*}; a literal "${...}" value is non-empty and would shadow the .env file and leak into the URL ("ENOTFOUND ${user_config...}.atlassian.net"). Such values are now treated as unset, and when no DOTENV_CONFIG_PATH survives, the .env lookup falls back to <cwd>/.env, then ~/.claude/jira.env.

Full background and verification evidence: tools/jira-mcp-plugin/README.md in the 1C_Workspace repo.

How this repo is consumed

This repo exists as a standalone git package so that npx can install it directly (npx cannot install from a monorepo subdirectory). The jira@ufc-1c Claude Code plugin (marketplace arcankostenko/1C_Workspace) declares:

"command": "npx",
"args": ["-y", "github:asky74/mcp-server-atlassian-jira#v3.3.0-ufc.3"]

On first start npm clones this repo (using your system git - your existing GitHub credentials cover the private access), installs devDependencies, and the prepare script compiles TypeScript into dist/. Subsequent starts run from the npx cache. No manual npm install step.

Releases are tags (v<upstream>-ufc.<n>, e.g. v3.3.0-ufc.1). To ship an update: commit, tag, push the tag, then bump the tag in the plugin's .mcp.json.

Local working-clone convention: 1C_Workspace/mcp-servers/mcp-server-atlassian-jira/

an inner repo like BAS_KUP_local/ (own .git/origin, not tracked by the monorepo's whitelist .gitignore).

Credentials: ~/.claude/jira.env with ATLASSIAN_SITE_NAME, ATLASSIAN_USER_EMAIL, ATLASSIAN_API_TOKEN (see .env.example). Never commit credentials here.

Related MCP server: Jira MCP Server

Development

npm install        # also builds (prepare -> tsc)
npm test           # 6 suites / 61 tests

manifest.json + .mcpbignore here build the optional Claude Desktop MCPB bundle (npx @anthropic-ai/mcpb pack .) - a personal, per-machine option. The 2026-07-13 "built-in-node fetch blocker" is not reproducible on current Desktop (>=1.20186, Electron 42.5.1 / node 24.17): a probe script run inside the real MCP runtime on 2026-07-14 got HTTP 200 from both undici fetch and classic https.get, and the packed bundle works with the stock command: "node" - no node.exe workaround needed. .mcpbignore caveat: patterns are gitignore-style, keep them anchored (/src/, not src/) - an unanchored src/ strips node_modules/*/src and breaks the bundle.

Licensing

Upstream declares "license": "ISC" in package.json but ships no LICENSE file. This fork keeps the declared license and upstream attribution (original work: Andi Ashari; attachment tools: cedral, PR #173).

Available Tools

7 tools

jira_attachJira Attach FileA

Read-only

Upload a file attachment to a Jira issue.

Two ways to attach files:

Local file: Provide filePath to upload an existing file

jira_attach({
  issueIdOrKey: "PROJ-123",
  filePath: "/path/to/screenshot.png"
})

Text content: Provide textContent and fileName to create and upload a text file

jira_attach({
  issueIdOrKey: "PROJ-123",
  textContent: "Error log contents here...",
  fileName: "error.log"
})

Supported file types: Images (png, jpg, gif), documents (pdf, doc, xls), text (txt, csv, json, md, log), archives (zip, tar), code files, and more.

Returns: Attachment metadata including ID, filename, size, and URL.

To list existing attachments: Use jira_get with:

path: /rest/api/3/issue/{issueKey}
jq: fields.attachment[*].{id:id,filename:filename,size:size}

ParametersJSON Schema

Name	Required	Description
`fileName`	No	Filename to use when uploading textContent (e.g., "notes.txt", "report.md")
`filePath`	No	Path to the local file to upload. Use this OR textContent/fileName, not both.
`textContent`	No	Text content to upload as a file. Requires fileName to be specified.
`issueIdOrKey`	Yes	The Jira issue ID or key to attach the file to (e.g., "PROJ-123" or "10001")

TDQS

A3.8/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations declare readOnlyHint=true, but the description describes a write operation ('upload'). This is a direct contradiction. Beyond that, the description adds useful behavioral context (supported file types, returns metadata), but the contradiction is critical.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with sections, bullet points, and code blocks. Every sentence serves a purpose, no fluff. It is concise yet comprehensive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the annotation contradiction, the description covers the two attachment methods, supported file types, and return metadata. It lacks permission or size limit info, but is generally complete for the task.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant meaning: explains mutual exclusivity of filePath vs textContent/fileName, provides example values, and clarifies the required relationship between textContent and fileName.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Upload a file attachment to a Jira issue' with specific verb and resource. It distinguishes from sibling tools like jira_get_attachment and provides two concrete usage modes with examples.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly details two ways to attach files and the required parameters. It also directs users to jira_get for listing attachments, guiding usage context. Could mention when not to use, but it's effective.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jira_deleteJira DELETE RequestB

Read-only

Delete Jira resources. Returns TOON format by default.

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

Delete issue: /rest/api/3/issue/{issueIdOrKey} Query param: deleteSubtasks=true to delete subtasks
Delete comment: /rest/api/3/issue/{issueIdOrKey}/comment/{commentId}
Delete worklog: /rest/api/3/issue/{issueIdOrKey}/worklog/{worklogId}
Delete attachment: /rest/api/3/attachment/{attachmentId}
Remove watcher: /rest/api/3/issue/{issueIdOrKey}/watchers Query param: accountId={accountId}

Note: Most DELETE endpoints return 204 No Content on success.

API reference: https://developer.atlassian.com/cloud/jira/platform/rest/v3/

ParametersJSON Schema

Name	Required	Description
`jq`	No	JMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "issues[].{key: key, summary: fields.summary}" (extract specific fields), "issues[0]" (first result), "issues[].key" (keys only). See https://jmespath.org
`path`	Yes	The Jira API endpoint path (without base URL). Must start with "/". Examples: "/rest/api/3/project", "/rest/api/3/search/jql", "/rest/api/3/issue/{issueIdOrKey}"
`queryParams`	No	Optional query parameters as key-value pairs. Examples: {"maxResults": "50", "startAt": "0", "jql": "project=PROJ", "fields": "summary,status"}
`outputFormat`	No	Output format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.

TDQS

B3.2/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description claims delete operations while annotations set readOnlyHint=true, a direct contradiction. Additionally, it does not disclose authentication needs or error behavior beyond noting 204 responses.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately structured but contains redundant explanations (output format details) and lengthy bullet lists that could be condensed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While it explains output format and status codes, the critical behavioral contradiction undermines completeness. It omits error handling and permission requirements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description repeats some examples but adds little new meaning beyond the schema's own parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it deletes Jira resources and lists specific operations (delete issue, comment, worklog, attachment, remove watcher), distinguishing it from sibling tools like jira_get or jira_post.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit common operations and endpoint patterns, but does not explicitly state when not to use this tool or suggest alternatives, though sibling names imply boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jira_getJira GET RequestA

Read-only

Read any Jira data. Returns TOON format by default (30-60% fewer tokens than JSON).

IMPORTANT - Cost Optimization:

ALWAYS use jq param to filter response fields. Unfiltered responses are very expensive!
Use maxResults query param to restrict result count (e.g., maxResults: "5")
If unsure about available fields, first fetch ONE item with maxResults: "1" and NO jq filter to explore the schema, then use jq in subsequent calls

Schema Discovery Pattern:

First call: path: "/rest/api/3/search/jql", queryParams: {"maxResults": "1", "jql": "project=PROJ"} (no jq) - explore available fields
Then use: jq: "issues[*].{key: key, summary: fields.summary, status: fields.status.name}" - extract only what you need

Output format: TOON (default, token-efficient) or JSON (outputFormat: "json")

Common paths:

/rest/api/3/project - list all projects
/rest/api/3/project/{projectKeyOrId} - get project details
/rest/api/3/search/jql - search issues with JQL (use jql query param). NOTE: /rest/api/3/search is deprecated!
/rest/api/3/issue/{issueIdOrKey} - get issue details
/rest/api/3/issue/{issueIdOrKey}/comment - list issue comments
/rest/api/3/issue/{issueIdOrKey}/worklog - list issue worklogs
/rest/api/3/issue/{issueIdOrKey}/transitions - get available transitions
/rest/api/3/user/search - search users (use query param)
/rest/api/3/status - list all statuses
/rest/api/3/issuetype - list issue types
/rest/api/3/priority - list priorities

JQ examples: issues[*].key, issues[0], issues[*].{key: key, summary: fields.summary}

Example JQL queries: project=PROJ, assignee=currentUser(), status="In Progress", created >= -7d

API reference: https://developer.atlassian.com/cloud/jira/platform/rest/v3/

ParametersJSON Schema

Name	Required	Description
`jq`	No	JMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "issues[].{key: key, summary: fields.summary}" (extract specific fields), "issues[0]" (first result), "issues[].key" (keys only). See https://jmespath.org
`path`	Yes	The Jira API endpoint path (without base URL). Must start with "/". Examples: "/rest/api/3/project", "/rest/api/3/search/jql", "/rest/api/3/issue/{issueIdOrKey}"
`queryParams`	No	Optional query parameters as key-value pairs. Examples: {"maxResults": "50", "startAt": "0", "jql": "project=PROJ", "fields": "summary,status"}
`outputFormat`	No	Output format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint. Description adds significant behavioral details: default TOON output format, token efficiency, cost warnings, deprecation notice for '/rest/api/3/search', and schema exploration workflow. All 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured with headings, bullet points, and code examples. Every section adds value (purpose, cost optimization, schema discovery, common paths, examples). Minor redundancy (jq examples appear twice) but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a GET tool with 4 params and no output schema, the description is remarkably complete: return format, cost optimization, schema discovery pattern, common paths, example requests, JQL syntax, API reference link. An agent can confidently invoke this tool without additional documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions. Description adds extensive context: jq examples, common path list, query parameter examples (maxResults, jql), output format explanation (TOON vs JSON), and JQL query examples. Goes well beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs GET requests to read Jira data, with 'Read any Jira data.' and a title 'Jira GET Request'. It distinguishes from sibling write tools (jira_post, jira_patch, etc.) by its read-only nature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit cost optimization guidance (use jq, maxResults), a schema discovery pattern, and common paths. Does not explicitly state when not to use this tool, but sibling tools are all write operations so differentiation is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jira_get_attachmentJira Get AttachmentA

Read-only

Download a Jira attachment to a local file.

Usage:

jira_get_attachment({
  attachmentId: "12345",
  outputPath: "/tmp/report.pdf"  // optional
})

Parameters:

attachmentId (required): The attachment ID from issue metadata
outputPath (optional): Where to save the file. If not provided, saves to system temp directory with original filename.

To find attachment IDs: Use jira_get with:

path: /rest/api/3/issue/{issueKey}
jq: fields.attachment[*].{id:id,filename:filename,size:size}

Returns: Download result with file path, filename, MIME type, and size.

ParametersJSON Schema

Name	Required	Description	Default
`outputPath`	No	Local file path where to save the attachment. If not provided, saves to system temp directory with original filename.
`attachmentId`	Yes	The Jira attachment ID to download. Get this from issue metadata using jira_get with path "/rest/api/3/issue/{issueKey}" and jq "fields.attachment[*].{id:id,filename:filename}"

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true; description confirms download behavior. Discloses default save location (temp dir) and return fields. No contradiction 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Structured with usage block, parameter list, tip, and return info. Length is justified by informative content; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers: how to use, parameter defaults, prerequisite (finding IDs via sibling tool), and return values (file path, filename, MIME type, size). No output schema needed given description richness and annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%. Description adds usage example, explains default behavior for outputPath, and cross-references jira_get for attachmentId. Provides marginal additional value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Download a Jira attachment to a local file.' Differentiates from siblings: jira_get gets metadata, jira_attach uploads, etc. The verb 'download' and resource 'attachment' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage example and parameter details. Shows how to find attachment IDs via jira_get. Does not explicitly state when not to use, but context is sufficient for typical use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jira_patchJira PATCH RequestA

Read-only

Partially update Jira resources. Returns TOON format by default.

IMPORTANT - Cost Optimization: Use jq param to filter response fields.

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

Update issue fields: /rest/api/3/issue/{issueIdOrKey} body: {"fields": {"summary": "Updated title"}} (only updates specified fields)
Update comment: /rest/api/3/issue/{issueIdOrKey}/comment/{commentId} body: {"body": {"type": "doc", "version": 1, "content": [{"type": "paragraph", "content": [{"type": "text", "text": "Updated comment"}]}]}}
Update worklog: /rest/api/3/issue/{issueIdOrKey}/worklog/{worklogId} body: {"timeSpentSeconds": 7200}

Note: PATCH only updates the fields you specify, leaving others unchanged.

API reference: https://developer.atlassian.com/cloud/jira/platform/rest/v3/

ParametersJSON Schema

Name	Required	Description
`jq`	No	JMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "issues[].{key: key, summary: fields.summary}" (extract specific fields), "issues[0]" (first result), "issues[].key" (keys only). See https://jmespath.org
`body`	Yes	Request body as a JSON object. Structure depends on the endpoint. Example for issue: {"fields": {"project": {"key": "PROJ"}, "summary": "Issue title", "issuetype": {"name": "Task"}}}
`path`	Yes	The Jira API endpoint path (without base URL). Must start with "/". Examples: "/rest/api/3/project", "/rest/api/3/search/jql", "/rest/api/3/issue/{issueIdOrKey}"
`queryParams`	No	Optional query parameters as key-value pairs. Examples: {"maxResults": "50", "startAt": "0", "jql": "project=PROJ", "fields": "summary,status"}
`outputFormat`	No	Output format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.

TDQS

A3.7/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description claims 'Partially update' (write operation), but annotations include readOnlyHint: true, creating a direct contradiction. No disclosure of side effects 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with sections, but slightly verbose with repeated mentions of TOON. Front-loaded purpose and examples make it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers parameters and common operations well, but lacks return value details (no output schema) and the annotation contradiction undermines completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions; the description adds extensive examples for body, path, jq, and outputFormat, significantly improving usability.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Partially update Jira resources' and distinguishes from siblings like jira_post and jira_put by emphasizing PATCH semantics. Examples reinforce the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides good usage context with common operations and cost optimization tip, but does not explicitly state when to use alternatives (e.g., PUT for full updates).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jira_postJira POST RequestA

Read-only

Create Jira resources. Returns TOON format by default (token-efficient).

IMPORTANT - Cost Optimization:

Use jq param to extract only needed fields from response (e.g., jq: "{key: key, id: id}")
Unfiltered responses include all metadata and are expensive!

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

Create issue: /rest/api/3/issue body: {"fields": {"project": {"key": "PROJ"}, "summary": "Issue title", "issuetype": {"name": "Task"}, "description": {"type": "doc", "version": 1, "content": [{"type": "paragraph", "content": [{"type": "text", "text": "Description"}]}]}}}
Add comment: /rest/api/3/issue/{issueIdOrKey}/comment body: {"body": {"type": "doc", "version": 1, "content": [{"type": "paragraph", "content": [{"type": "text", "text": "Comment text"}]}]}}
Add worklog: /rest/api/3/issue/{issueIdOrKey}/worklog body: {"timeSpentSeconds": 3600, "comment": {"type": "doc", "version": 1, "content": [{"type": "paragraph", "content": [{"type": "text", "text": "Work done"}]}]}}
Transition issue: /rest/api/3/issue/{issueIdOrKey}/transitions body: {"transition": {"id": "31"}}
Add attachment: /rest/api/3/issue/{issueIdOrKey}/attachments Note: Requires multipart form data (complex - use Jira UI for attachments)

API reference: https://developer.atlassian.com/cloud/jira/platform/rest/v3/

ParametersJSON Schema

Name	Required	Description
`jq`	No	JMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "issues[].{key: key, summary: fields.summary}" (extract specific fields), "issues[0]" (first result), "issues[].key" (keys only). See https://jmespath.org
`body`	Yes	Request body as a JSON object. Structure depends on the endpoint. Example for issue: {"fields": {"project": {"key": "PROJ"}, "summary": "Issue title", "issuetype": {"name": "Task"}}}
`path`	Yes	The Jira API endpoint path (without base URL). Must start with "/". Examples: "/rest/api/3/project", "/rest/api/3/search/jql", "/rest/api/3/issue/{issueIdOrKey}"
`queryParams`	No	Optional query parameters as key-value pairs. Examples: {"maxResults": "50", "startAt": "0", "jql": "project=PROJ", "fields": "summary,status"}
`outputFormat`	No	Output format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.

TDQS

A3.7/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description contradicts the annotation readOnlyHint: true by stating it creates resources (mutating operation). This is a serious inconsistency that misleads the agent. The description fails to disclose any further behavioral details beyond the creation aspect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections and front-loaded purpose, but contains verbose examples that could be shortened without losing clarity. Still, each sentence contributes to usability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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 lacks details about return values or error responses. It compensates somewhat with request examples, but an agent is left guessing about response structure, which is critical for post-creation handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

While schema covers 100% of parameters with descriptions, the description significantly enhances understanding by providing real-world usage examples for body, jq, and outputFormat. This adds value beyond the schema's bare descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create Jira resources' and provides specific common operations (create issue, add comment, etc.) that uniquely identify this as a POST/creation tool, distinguishing it from sibling tools like jira_get (read) or jira_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Includes explicit cost optimization guidance (using jq param) and provides example operations with exact API paths and body structures. However, it does not explicitly state when NOT to use this tool or list alternative tools for specific scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jira_putJira PUT RequestA

Read-only

Replace Jira resources (full update). Returns TOON format by default.

IMPORTANT - Cost Optimization: Use jq param to extract only needed fields from response

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

Update issue (full): /rest/api/3/issue/{issueIdOrKey} body: {"fields": {"summary": "New title", "description": {...}, "assignee": {"accountId": "..."}}}
Update project: /rest/api/3/project/{projectIdOrKey} body: {"name": "New Project Name", "description": "Updated description"}
Set issue property: /rest/api/3/issue/{issueIdOrKey}/properties/{propertyKey} body: {"value": "property value"}

Note: PUT replaces the entire resource. For partial updates, prefer PATCH.

API reference: https://developer.atlassian.com/cloud/jira/platform/rest/v3/

ParametersJSON Schema

Name	Required	Description
`jq`	No	JMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "issues[].{key: key, summary: fields.summary}" (extract specific fields), "issues[0]" (first result), "issues[].key" (keys only). See https://jmespath.org
`body`	Yes	Request body as a JSON object. Structure depends on the endpoint. Example for issue: {"fields": {"project": {"key": "PROJ"}, "summary": "Issue title", "issuetype": {"name": "Task"}}}
`path`	Yes	The Jira API endpoint path (without base URL). Must start with "/". Examples: "/rest/api/3/project", "/rest/api/3/search/jql", "/rest/api/3/issue/{issueIdOrKey}"
`queryParams`	No	Optional query parameters as key-value pairs. Examples: {"maxResults": "50", "startAt": "0", "jql": "project=PROJ", "fields": "summary,status"}
`outputFormat`	No	Output format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.

TDQS

A3.9/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description correctly states that PUT performs a full update, which is a write operation. However, the annotations set readOnlyHint=true, directly contradicting the description's behavior. This is a serious inconsistency, scoring 1 as per guidelines.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections and markdown, front-loading key information. It is somewhat lengthy but each part serves a purpose (examples, cost tips, note on PATCH). Minor redundancy in API reference URL.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and nested objects, the description provides rich context: common operations, examples, output format details, and cost optimization. It lacks explicit explanation of TOON format behavior but covers most aspects adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. The description adds value by explaining the jq parameter for cost reduction, providing concrete examples for path and body, and detailing outputFormat. This goes beyond the schema's basic descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool replaces Jira resources via full update. It lists specific endpoints and operations, and distinguishes from PATCH for partial updates. The verb 'Replace' and resource context are well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises using jq for cost optimization, specifies default output format (TOON), and mentions that PUT is for full replacement while PATCH is for partial updates. This provides clear when-to-use and 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv3.3.0-ufc.3Jul 14, 2026
- First observedjira_attach
- First observedjira_delete
- First observedjira_get
- First observedjira_get_attachment
- First observedjira_patch
- First observedjira_post
- First observedjira_put

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-07-14 13:20 across 7 tools

Disambiguation5/5

Each tool maps to a distinct HTTP verb or operation (e.g., attach, delete, get, patch, post, put) with clear boundaries. Even jira_get_attachment (download) is separate from jira_get (read data) and jira_attach (upload).

Naming Consistency5/5

All tools follow the 'jira_' prefix with an HTTP-method-like verb (attach, delete, get, get_attachment, patch, post, put). The naming is consistent, predictable, and clearly indicates the action.

Tool Count5/5

With 7 tools covering core CRUD, file attachment, and flexible generic operations, the count is well-scoped for a Jira server. It provides sufficient functionality without unnecessary bloat.

Completeness4/5

The tool set covers all major CRUD operations and file attachments. While jira_get handles searches and listings, a dedicated search tool could improve completeness, but the current surface is largely complete for common Jira workflows.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
Atako A
ai.atako
Remote MCP server to read and manage your Atako AI agents, messages, files, and integrations.
Agent Orchestration AI & Machine Learning
31
ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297
Danushkumar-V-mcp-discordOAuth
ai.smithery
An MCP server that integrates with Discord to provide AI-powered features.
Communication Social Media App Automation
2

Related MCP Servers

Jira MCP Server
Project Management Search Developer Tools
brianstone
A
license
C
quality
D
maintenance
An MCP server that enables communication with Jira, allowing users to perform operations like getting, searching, creating, and editing issues through natural language interaction.
Updated a year ago (2025-05-04 16:58 UTC)
1
60 npm
MIT
Jira MCP Server
Project Management Developer Tools
AlexVulaj
A
license
Not graded
quality
D
maintenance
An MCP server for integrating with Jira Server instances, enabling natural language interactions to create, update, search, and manage issues and comments.
Updated a year ago (2025-09-12 14:27 UTC)
60 npm
1
MIT
Jira MCP Server
Project Management Developer Tools
Devparihar5
A
license
Not graded
quality
D
maintenance
A comprehensive MCP server for Atlassian Jira that enables AI assistants to manage issues, sprints, comments, and worklogs through natural language.
Updated a year ago (2025-08-28 11:22 UTC)
MIT
Jira Cloud MCP Server
Project Management Developer Tools
aaronsb
A
license
Not graded
quality
A
maintenance
MCP server for interacting with Jira Cloud instances. Enables issue management, JQL queries, project and sprint management, and batch operations via natural language interfaces.
Updated 10 days ago (2026-09-05 02:51 UTC)
195 npm
4
MIT