Which integrations are available for this server?

Provides tools for interacting with Jira Cloud, enabling issue tracking, project management, and agile features such as searching, creating, updating, transitioning issues, managing sprints, comments, attachments, and user assignments.

How do I use opencode-jira-mcp?

1. Click on "Install 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., "@opencode-jira-mcp Find all high-priority bugs in the PROJ project" 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.

opencode-jira-mcp

by DevelopmentAgentSDD

Overview Schema Related Servers Score Discussions

TypeScript

Local

opencode-jira-mcp

MCP (Model Context Protocol) server that connects opencode with Jira Cloud, exposing issue tracking, project management, and agile features as structured tools for AI agents.

GitHub Packages License: MIT

Requirements

Node.js >= 18
A Jira Cloud account with an API token
An MCP client (such as opencode, Claude Desktop, or any MCP-compatible host)

Related MCP server: Jira MCP Server

Installation

1. Authenticate with GitHub Packages

Create or edit your ~/.npmrc file and add:

//npm.pkg.github.com/:_authToken=YOUR_GITHUB_TOKEN
@DevelopmentAgentSDD:registry=https://npm.pkg.github.com

Get a GitHub token at Settings → Developer settings → Personal access tokens → Tokens (classic) with the read:packages scope.

2. Global install (recommended)

npm install -g @DevelopmentAgentSDD/opencode-jira-mcp

3. Using npx (no install)

npx @DevelopmentAgentSDD/opencode-jira-mcp

From source

git clone https://github.com/DevelopmentAgentSDD/MCP-JiraCloud.git
cd MCP-JiraCloud
npm ci
npm run build

Configuration

The server requires three environment variables:

Variable	Description
`JIRA_HOST`	Your Jira Cloud domain (e.g., `my-company.atlassian.net`) — do not include `https://`
`JIRA_EMAIL`	Email address of your Atlassian account
`JIRA_API_TOKEN`	API token generated at https://id.atlassian.com/manage-profile/security/api-tokens

Configuring in opencode

Add the server to your opencode.json:

{
  "mcp": {
    "jira": {
      "type": "local",
      "command": ["npx", "-y", "@DevelopmentAgentSDD/opencode-jira-mcp"],
      "env": {
        "JIRA_HOST": "my-company.atlassian.net",
        "JIRA_EMAIL": "me@my-company.com",
        "JIRA_API_TOKEN": "your-api-token-here"
      }
    }
  }
}

Security tip: avoid hardcoding the token. Use {env:JIRA_API_TOKEN} interpolation so opencode reads it from the environment at runtime.

Configuring in Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "jira": {
      "command": "npx",
      "args": ["-y", "@DevelopmentAgentSDD/opencode-jira-mcp"],
      "env": {
        "JIRA_HOST": "my-company.atlassian.net",
        "JIRA_EMAIL": "me@my-company.com",
        "JIRA_API_TOKEN": "your-api-token-here"
      }
    }
  }
}

Available Tools

The server exposes 9 tools to the MCP host:

1. `search_issues`

Search for issues in Jira using structured parameters or raw JQL.

"Find all high-priority bugs in the PROJ project assigned to me"
"Search for issues containing 'login' in the summary or description"

Parameters: projectKey, issueType, status, assignee, priority, labels, sprint, text, jql, startAt, maxResults, orderBy, fields

2. `create_issue`

Create a new Jira issue of any type (Task, Bug, Story, Epic, Subtask).

"Create a bug in PROJ: 'Login page crashes on mobile' with priority High"
"Create an Epic called 'Q2 Platform Migration' in the PROJ project"

Parameters: projectKey, summary, issueType, description, priority, assignee, labels, parentKey (Subtask), epicName (Epic)

3. `update_issue`

Modify fields on an existing Jira issue.

"Update PROJ-123: change priority to Critical, add label 'security'"
"Set the assignee of PROJ-456 to unassigned"

Parameters: issueKey, summary, description, priority, labels, assignee, components, customFields

4. `transition_issue`

Move an issue through its workflow or list available transitions.

"Move PROJ-123 to In Progress"
"What transitions are available for PROJ-456?"
"Close PROJ-789 with resolution 'Done'"

Parameters: issueKey, transitionName, transitionId, resolution, comment, listTransitions

5. `get_sprints`

Retrieve sprints from a Jira board with optional issue details.

"Show me active sprints on the PROJ Scrum Board"
"List all sprints on board ID 42, including their issues"

Parameters: boardId, boardName, state (active|future|closed), includeIssues, startAt, maxResults

6. `assign_user`

Assign or unassign a user to/from an issue.

"Assign PROJ-123 to John Doe"
"Unassign PROJ-456"

Parameters: issueKey, accountId (set to null or "unassigned" to unassign)

7. `manage_comments`

List or add comments on a Jira issue.

"Show all comments on PROJ-123"
"Add a comment to PROJ-123: 'Fixed in PR #42, ready for review'"

Parameters: action (list|add), issueKey, body (for add), startAt, maxResults

8. `attach_file`

Attach a file from the local filesystem to a Jira issue.

"Attach the file error-screenshot.png to PROJ-123"

Parameters: issueKey, filePath (must exist, be readable, and <10 MB)

9. `jira_health_check`

Verify connectivity to Jira Cloud and validate authentication credentials.

"Check if the Jira connection is working"

Parameters: none

Security

Token safety: the JIRA_API_TOKEN is never written to stdout, stderr, or error messages. All log entries and error responses redact the token.
Headers sanitization: Authorization headers are replaced with Basic [REDACTED] in all logs.
Config sanitization: when logging the configuration, the token is displayed as ***SET***.
Token rotation: generate new tokens at https://id.atlassian.com/manage-profile/security/api-tokens. The server picks up the new token on restart.

Troubleshooting

"JIRA_HOST is required"

Set the JIRA_HOST environment variable to your Jira Cloud domain without https://:

export JIRA_HOST=my-company.atlassian.net

"JIRA_API_TOKEN is required"

Generate an API token at https://id.atlassian.com/manage-profile/security/api-tokens and set it:

export JIRA_API_TOKEN=your-generated-token

"Authentication failed"

Verify your email matches the Atlassian account email
Ensure the API token is active (not revoked)
Check that JIRA_HOST is correct and does not include https://

"Access denied"

Your account does not have permission for the requested action. Verify your project permissions in Jira.

"Rate limit exceeded"

The server automatically retries with exponential backoff (up to 3 retries, max ~210s total). If you consistently hit rate limits, reduce request frequency or check your Jira Cloud plan limits.

Development

# Install dependencies
npm ci

# Run in development mode (with auto-reload)
npm run dev

# Type check
npm run typecheck

# Lint
npm run lint

# Format
npm run format

# Run tests
npm test

# Run tests with coverage
npm run test:coverage

# Build for production
npm run build

Project structure

src/
  index.ts                  # Entry point (shebang, main function)
  config/                   # Zod-based env var validation
  auth/                     # Basic Auth header builder
  services/                 # JiraClient (HTTP client with retry)
  tools/                    # 9 MCP tool handlers + centralized registration
  transport/                # Stdio transport setup
  types/                    # TypeScript interfaces
  utils/                    # Errors, retry logic, sanitization
tests/
  unit/                     # Unit tests (vitest)
  integration/              # Integration tests (nock for HTTP mocking)
  fixtures/                 # Mock Jira responses

Tech stack

Category	Technology
Language	TypeScript 5.5+ (strict mode)
Runtime	Node.js >= 18
MCP SDK	@modelcontextprotocol/sdk ^1.0
Validation	Zod ^3.24
Logging	Pino ^9.0
Testing	Vitest + nock
Linting	ESLint + Prettier

License

MIT — see LICENSE for details.

Available Tools

9 tools

assign_userA

Assign a user to an issue or unassign the current user. Provide the issue key and the account ID of the user to assign. To unassign, use accountId: null or accountId: "unassigned". The assignee must have access to the issue's project.

ParametersJSON Schema

Name	Required	Description	Default
`issueKey`	Yes	Issue key (e.g., "PROJ-123"). REQUIRED.
`accountId`	Yes	Atlassian Account ID of the user to assign. Use null or "unassigned" to unassign. REQUIRED.

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It clearly states the mutation (assign/unassign), the unassignment method, and an access constraint. It omits potential errors or rate limits, but for a simple operation this is sufficient.

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?

Three sentences, each adding essential information: purpose, usage details, and a constraint. No redundant words. Front-loaded with the primary action.

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?

No output schema exists, so the description could have mentioned return values or success/failure indicators. However, the core action and key constraints are well-covered. Given the tool's simplicity, this is nearly complete.

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%, so baseline is 3. The description adds value by explaining the unassignment syntax ('use accountId: null or accountId: "unassigned"') and the access requirement ('assignee must have access'), which are not fully captured in the schema 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 starts with a clear verb-resource pair: 'Assign a user to an issue or unassign the current user.' It distinguishes the tool from siblings (e.g., update_issue, search_issues) by focusing specifically on assignment actions.

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 provides how-to details (provide issueKey and accountId, use null or "unassigned" to unassign) and a prerequisite (assignee must have project access). It does not explicitly compare with alternatives, but the specialized purpose makes usage obvious.

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

attach_fileA

Attach a local file to a Jira issue. Provide the issue key and the absolute or relative path to the file on the local filesystem. The file must exist and be readable. Maximum file size is 10 MB (Jira Cloud limit). Common file types are supported: images, PDFs, documents, logs. Returns attachment metadata including filename, size, MIME type, and URL.

ParametersJSON Schema

Name	Required	Description
`fileName`	No	Optional custom filename to use as the attachment name in Jira.
`filePath`	Yes	Absolute or relative path to the file. REQUIRED.
`issueKey`	Yes	Issue key (e.g., "PROJ-123"). REQUIRED.
`mimeType`	No	Optional MIME type override (e.g., "image/png", "text/plain").

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Discloses constraints (file existence, size limit, types) and return metadata. Does not mention destructive behavior, but attachment is additive.

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?

Three concise sentences, front-loaded with action. Every sentence provides essential information without fluff.

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?

No output schema, but description specifies return metadata (filename, size, MIME, URL). Covers constraints and usage context adequately for a 4-parameter tool.

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 description coverage is 100%. Description reinforces schema properties but adds little beyond per-parameter semantics (e.g., size limit and return metadata are global). Baseline 3 applies.

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?

Description clearly states 'Attach a local file to a Jira issue' with specific verb and resource. Distinguishes from siblings which deal with issues, users, sprints, and comments.

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 conditions for use: file must exist, be readable, max size 10 MB, supported types. Lacks explicit when-not-to-use or alternatives, but context is sufficient.

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

create_issueA

Create a new issue in Jira. Requires at minimum: projectKey, summary, and issueType. Optionally accepts description, priority, assignee, labels, components, sprint assignment, parent issue (for subtasks), epic link, and custom fields. Returns the created issue key, ID, and URL. Before creating, consider using search_issues to check for potential duplicates.

ParametersJSON Schema

Name	Required	Description
`labels`	No	Labels to apply to the issue.
`sprint`	No	Sprint name or ID to add the issue to.
`dueDate`	No	Due date in YYYY-MM-DD format.
`summary`	Yes	Issue title/summary. REQUIRED. Max 255 characters.
`assignee`	No	Account ID of the user to assign. Omit for automatic assignment.
`epicLink`	No	Epic issue key to link (e.g., "PROJ-10"). For Story, Task, Bug types.
`epicName`	No	Epic name. REQUIRED when issueType is "Epic".
`priority`	No	Priority level. Default: project default.
`issueType`	Yes	Issue type. REQUIRED. "Subtask" requires parentKey. "Epic" requires epicName.
`parentKey`	No	Parent issue key. REQUIRED when issueType is "Subtask".
`components`	No	Component names to associate with the issue.
`projectKey`	Yes	Project key (e.g., "PROJ"). REQUIRED.
`description`	No	Issue description. Supports Jira markdown and Atlassian Document Format (ADF).
`storyPoints`	No	Story point estimate (0–100).
`customFields`	No	Map of custom field IDs to values. Keys must be like "customfield_10014".

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It describes required fields, optional parameters, and return values, but lacks details on permissions, rate limits, or failure modes.

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 a single concise paragraph that front-loads the main purpose, then lists requirements and options efficiently without unnecessary words.

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 15 parameters and no output schema, the description covers required/optional fields, special constraints, and return values, though it omits error handling or output format details.

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 description coverage is 100%, so baseline is 3. The description adds value by summarizing required fields and special constraints (e.g., 'Subtask requires parentKey'), going beyond the schema alone.

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 verb 'Create' and resource 'new issue in Jira'. It distinguishes from siblings like search_issues and update_issue by focusing on creation and listing required fields.

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 suggests using search_issues beforehand to check for duplicates, providing a clear usage hint. However, it does not elaborate on when not to use the tool or compare with other mutation siblings.

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

get_sprintsA

Get sprints from a Jira board. You can specify a boardId directly or provide a boardName to look it up. Filter sprints by state: active, future, or closed. Optionally include the issues within each sprint. Use this to see what work is planned or in progress for a team.

ParametersJSON Schema

Name	Required	Description	Default
`state`	No	Sprint state filter. Default: "active".	active
`boardId`	No	Numeric board ID (e.g., 42). Alternative to boardName.
`startAt`	No	Pagination offset.
`boardName`	No	Board name to look up (e.g., "PROJ Scrum Board"). Alternative to boardId.
`maxResults`	No	Max sprints to return.
`includeIssues`	No	If true, includes issues within each sprint in the response.

TDQS

A4.4/5.0

Behavior4/5

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 adequately describes the read behavior (getting sprints) with parameters for filtering, pagination, and issue inclusion. No contradictions or hidden effects.

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?

Three sentences, each earning its place: first sentence defines the main action, second explains parameters, third gives usage context. No unnecessary words, front-loaded with key action.

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?

For a straightforward list tool with no output schema, the description covers board identification, state filtering, pagination, and issue inclusion. It is complete enough for an agent to use, though it does not detail return structure.

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 description coverage is 100%, baseline 3. The description adds value by explaining the board identification alternatives (boardId vs boardName) and the state filter options, plus the optional includeIssues, which enriches understanding beyond the 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 verb 'Get' and resource 'sprints from a Jira board', specifies filtering by state and optional inclusion of issues, and distinguishes from sibling tools that focus on issues.

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 provides clear usage context ('see what work is planned or in progress') and explains the two alternative ways to specify the board (boardId or boardName). It does not explicitly state when not to use it, but no alternatives among siblings exist.

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

jira_health_checkA

Verify connectivity to Jira Cloud and validate the current authentication credentials. Makes a lightweight call to the Jira API to confirm the host, email, and API token are correctly configured. Returns the authenticated user's identity and Jira instance information. Use this to diagnose connection issues before running other tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It accurately describes a non-destructive, read-only operation (lightweight call, returns identity and instance info) with no contradictions.

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

Conciseness5/5

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

The description is three sentences, front-loaded with the main purpose, and contains no redundant information. Every sentence adds value.

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 parameters and no output schema, the description adequately explains what the tool does and what it returns (user identity and instance info). It is complete enough for a health check tool.

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?

The schema has no parameters (0 params, 100% coverage), so baseline is 4. The description adds meaning by explaining the tool's function, but no parameter details are needed.

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's purpose: verifying connectivity and validating authentication credentials. It specifies it makes a lightweight call and returns user identity and instance info, distinguishing it from sibling tools that deal with issue management.

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 advises using this tool to diagnose connection issues before running other tools, providing clear use-case guidance. It lacks explicit exclusions but the context is sufficient.

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

manage_commentsA

Manage comments on a Jira issue. Use action "list" to read all comments, or action "add" to create a new comment. Comments support Jira markdown syntax including @mentions. When adding, the body field is required. The list action supports pagination.

ParametersJSON Schema

Name	Required	Description
`body`	No	Comment text. Supports Jira markdown. REQUIRED when action is "add".
`action`	Yes	Action to perform: "list" to read comments or "add" to create a new comment.
`startAt`	No	Pagination offset (for "list" action).
`issueKey`	Yes	Issue key (e.g., "PROJ-123"). REQUIRED.
`maxResults`	No	Max comments to return (for "list" action).

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It mentions Jira markdown support and pagination, but lacks details on permissions, failure modes, or rate limits. Adequate but not comprehensive.

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?

Two efficient sentences covering purpose, actions, markdown, and key constraints. No unnecessary words, well-front-loaded.

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, the description covers key usage aspects for a simple tool. It could mention return format (e.g., list returns array of comments), but the pagination hints are helpful. Reasonably complete for its complexity.

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 description coverage is 100%, so the schema already documents all parameters. The description reinforces the body requirement for 'add' and pagination for 'list', but adds limited novel information beyond the 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 it manages comments on Jira issues with two distinct actions ('list' and 'add'). This differentiates it from sibling tools like search_issues or create_issue, which focus on different resources.

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?

It specifies when to use 'list' (reading comments) vs 'add' (creating), and notes body required for add. However, it does not explicitly exclude editing/deleting, which are not supported.

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

search_issuesA

Search for issues in Jira using JQL (Jira Query Language). Supports filtering by project, type, status, assignee, priority, labels, sprint, and free-text search. Results are paginated. By default returns the first 50 matching issues. Use this to find existing issues before creating duplicates.

ParametersJSON Schema

Name	Required	Description
`jql`	No	Raw JQL query string. If provided, all other filter parameters are ignored.
`text`	No	Free-text search in summary and description fields.
`fields`	No	Specific fields to include in response (e.g., ["summary", "status", "assignee"]). If omitted, returns default issue view.
`labels`	No	Filter by labels (issues must have ALL specified labels).
`sprint`	No	Filter by sprint name or ID.
`status`	No	Filter by status name (e.g., "In Progress", "Done").
`orderBy`	No	Sort field and direction (e.g., "created DESC", "priority ASC").
`startAt`	No	Pagination offset. Default: 0.
`assignee`	No	Filter by assignee. Use account ID, "currentUser()", or "unassigned".
`priority`	No	Filter by priority level.
`issueType`	No	Filter by issue type.
`maxResults`	No	Maximum results to return. Default: 50, Max: 100.
`projectKey`	No	Project key (e.g., "PROJ"). Filters issues by project.

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It states pagination behavior and default max results but does not disclose rate limits, authentication needs, or that JQL overrides other filters (only implied by schema). Adequate but not rich.

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 two concise, front-loaded sentences with zero wasted words. It efficiently communicates purpose, filters, pagination, and usage guidance.

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?

For a search tool with 13 parameters and no output schema, the description covers purpose, filters, pagination, and duplicate prevention. Lacks details on return format or JQL behavior, but overall is complete enough for a search operation.

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 description coverage is 100%, so the description adds minimal value beyond listing filter types. Baseline score of 3 is appropriate; no additional semantic meaning for parameters is provided.

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 'Search for issues in Jira using JQL' and enumerates supported filter types. It explicitly guides the agent to use this tool before creating duplicates, distinguishing it from sibling tools like create_issue.

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 provides clear context: use for finding existing issues before creating duplicates, and mentions pagination defaults. However, it does not explicitly state when not to use it or suggest alternatives among siblings.

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

transition_issueA

Transition an issue through its workflow. You can either execute a transition by name or ID, or list all available transitions from the current state. Some transitions require a resolution (e.g., "Done" may require "Fixed", "Won't Fix", etc.). Use listTransitions=true to discover what transitions are available before attempting one.

ParametersJSON Schema

Name	Required	Description
`comment`	No	Optional comment to add during the transition.
`issueKey`	Yes	Issue key (e.g., "PROJ-123"). REQUIRED.
`resolution`	No	Resolution name. Required for some transitions (e.g., "Done", "Fixed", "Won't Fix").
`transitionId`	No	Numeric transition ID. Use if transition name is ambiguous or not found.
`transitionName`	No	Human-readable transition name (e.g., "In Progress", "Done", "Start Progress").
`listTransitions`	No	If true, only lists available transitions without executing one.

TDQS

A4.1/5.0

Behavior3/5

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

Discloses the dual mode (list/execute) and resolution requirement, but does not mention side effects (e.g., notifications, irreversibility) or behavior when issue is already in target state. Without annotations, more detail would be beneficial.

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?

Three sentences, front-loaded with main action, no fluff. Every sentence provides essential information.

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?

No output schema; description does not explain return values after executing a transition. Could elaborate on allowed resolution values or error conditions. Adequate but not complete.

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?

Adds value beyond the schema by explaining the relationship between transitionId and transitionName and the purpose of listTransitions. Schema coverage is 100%, so baseline 3 plus extra context.

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 it transitions an issue through its workflow, with the ability to execute by name/ID or list transitions. Distinguishes from sibling tools like update_issue (field modification) and create_issue (creation).

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 guidance to use listTransitions=true before attempting a transition and notes that some transitions require a resolution. Lacks explicit comparison to alternatives or when not to use.

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

update_issueA

Update editable fields of an existing issue. You can modify: summary, description, priority, labels, components, and custom fields. To change the issue status, use transition_issue instead. At least one field besides issueKey must be provided. Labels and components completely replace existing values.

ParametersJSON Schema

Name	Required	Description
`labels`	No	New labels. REPLACES all existing labels.
`summary`	No	New summary for the issue.
`issueKey`	Yes	Issue key (e.g., "PROJ-123"). REQUIRED.
`priority`	No	New priority level.
`components`	No	New components. REPLACES all existing components.
`description`	No	New description. Supports Jira markdown and ADF.
`customFields`	No	Custom field updates.

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, description discloses replacement semantics for labels and components. Does not mention permissions or rate limits, but covers key behavioral details for an update tool.

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?

Three sentences, front-loaded with purpose, no fluff. Every sentence adds useful information.

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 full schema descriptions and no output schema, description adequately covers usage constraints and behavior. Could mention return value, but not critical.

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 provides full descriptions (100% coverage). Description adds value by noting replacement behavior and requirement for at least one non-key field, complementing 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?

Description clearly states 'Update editable fields of an existing issue', specifying verb and resource. It lists modifiable fields and distinguishes from sibling tool transition_issue for status changes.

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 provides alternative for status changes ('use transition_issue instead'), requires at least one field besides issueKey, and clarifies replacement behavior for labels and components.

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. Dates show when Glama detected each change.

9 tool updatesv1.0.1Jul 30, 2026
- First observedassign_user
- First observedattach_file
- First observedcreate_issue
- First observedget_sprints
- First observedjira_health_check
- First observedmanage_comments
- First observedsearch_issues
- First observedtransition_issue
- First observedupdate_issue

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct aspect of Jira: searching, creating, updating, transitioning issues, health check, sprint retrieval, user assignment, comment management, and file attachment. No overlap in functionality.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern (search_issues, create_issue, update_issue, transition_issue, get_sprints, assign_user, manage_comments, attach_file). 'jira_health_check' breaks the pattern but remains descriptive and distinguishable.

Tool Count5/5

9 tools is well-scoped for a Jira MCP server, covering essential CRUD and lifecycle operations without bloat. Each tool serves a necessary role.

Completeness4/5

Covers core issue management: search, create, update, transition, assign, comments, attachments, and sprint visibility. Minor gaps like absence of a dedicated get_issue, comment editing, or project-level tools, but still highly functional for typical workflows.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
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
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
SmartBear MCPOAuth
com.smartbear
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
Monitoring Testing & QA Tools API Testing
144

Related MCP Servers

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 MCP Server
Project Management Developer Tools
motola10
A
license
Not graded
quality
C
maintenance
A server that exposes Jira Cloud operations as MCP tools, enabling programmatic management of Epics, Stories, Tasks, and Sprints directly from an AI chat or agentic workflow.
Updated 2 months ago (2026-06-26 04:26 UTC)
1
MIT
@avidian/mcp-jira
Project Management Developer Tools
avidianity
A
license
Not graded
quality
A
maintenance
MCP server for Jira Cloud — gives AI agents full context and control over Jira issues, projects, sprints, and workflows.
Updated 11 days ago (2026-08-25 22:07 UTC)
228
MIT
mcp-jira-server
dev-pradeep-singh
F
license
Not graded
quality
B
maintenance
MCP server that provides AI assistants with access to Jira Cloud for issue management, search, and workflow operations.
Updated a month ago (2026-07-31 10:43 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DevelopmentAgentSDD/MCP-JiraCloud'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

opencode-jira-mcp

Requirements

Installation

1. Authenticate with GitHub Packages

2. Global install (recommended)

3. Using npx (no install)

From source

Configuration

Configuring in opencode

Configuring in Claude Desktop

Available Tools

1. search_issues

2. create_issue

3. update_issue

4. transition_issue

5. get_sprints

6. assign_user

7. manage_comments

8. attach_file

9. jira_health_check

Security

Troubleshooting

"JIRA_HOST is required"

"JIRA_API_TOKEN is required"

"Authentication failed"

"Access denied"

"Rate limit exceeded"

Development

Project structure

Tech stack

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `search_issues`

2. `create_issue`

3. `update_issue`

4. `transition_issue`

5. `get_sprints`

6. `assign_user`

7. `manage_comments`

8. `attach_file`

9. `jira_health_check`