What can you do with this server?

This MCP server connects AI assistants to Jira via SSO-authenticated REST API, enabling search, read, create, update, delete, and attachment operations. * Run JQL searches (execute_jql) * Read full issue JSON (get_ticket/get_task) or compact views (read_ticket/read_task/get_only_ticket_name_and_description) * Create, edit, and delete Jira issues (create_ticket, edit_ticket, delete_ticket) * List projects (list_projects) and Jira Software boards (list_boards) * Assign issues (assign_ticket) and query assignable users (query_assignable) * Get all issue statuses (get_all_statuses) * Attach files from Confluence (add_attachment_from_confluence) or public URLs (add_attachment_from_public_url) * Authenticate via browser SSO (jira_login) with session keep-alive

Which integrations are available for this server?

Supports adding attachments from Confluence pages to Jira issues using Confluence REST API and authentication. Provides tools for searching, reading, creating, updating, deleting, and assigning Jira issues, as well as managing projects, boards, statuses, and attachments. Integrates with Jira Software boards for listing boards and creating tickets with board context.

How do I use Jira MCP OAuth gateway?

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., "@Jira MCP OAuth gateway show me recent issues assigned to me" 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.

Jira MCP OAuth gateway

by Wasim-Shaikh25

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

Jira MCP OAuth gateway

A Model Context Protocol (MCP) server that connects AI assistants (for example Cursor Composer or Agent) to your Jira site. Configure JIRA_BASE_URL for Atlassian Jira Cloud or Jira Data Center / Server—this project is not limited to one company or hosting model. You can search issues, read and edit tickets, manage assignments, and more, authenticating with a browser SSO session (cookies). Auth is SSO-cookie only — there is no token/PAT mode. A background session keep-alive helps the cookie stay warm while the server runs.

What this project is


Role	Runs as a small Node.js process that speaks MCP over standard input/output (stdio). Your editor starts it; you do not usually run it by hand except when debugging.
Target product	Jira (Cloud or Data Center) via REST. Paths default to `/rest/api/3`; use `/rest/api/2` if your server only exposes v2 (common on Data Center).
Auth model	SSO cookies only — complete `jira_login` once and every REST call uses those cookies. There is no token/PAT mode.
SSO login	Uses Playwright + Chromium to open a real browser, let you sign in (SAML, OIDC, etc.), and saves session cookies for later API calls.
Session keep-alive	A background loop pings `/myself` on an interval (`JIRA_KEEPALIVE_SECONDS`, default 240) to keep the session warm and warn early if the cookie goes stale.

The design matches the idea behind confluence-mcp-oauth: use a real browser session for corporate SSO, and treat Jira as a normal REST API with those cookies.

Why use it

Works behind SSO: Many organizations do not expose simple API-password flows. A real browser SSO session fits Data Center and many federated setups where only interactive login is allowed.
No secrets in config: There are no tokens to store or accidentally commit — auth is the browser session cookie, saved locally and gitignored.
Familiar Jira operations: JQL search, full issue JSON, compact “read” views, create/update/delete, projects, assignees, statuses, and optional attachments from Confluence or a public URL.

How it fits in your workflow

You add this server to Cursor (or another MCP client) via mcp.json.
You set at least JIRA_BASE_URL in that config’s env block.
Cursor starts the server when needed; the assistant calls MCP tools by name (for example “run execute_jql with …”).
If you rely on SSO, you run jira_login once (tool or npm run login); cookies are stored under cookies/session.json on disk (ignored by git and not published to npm).

┌─────────────┐    stdio (JSON-RPC)    ┌──────────────────┐    HTTPS     ┌─────────────┐
│ Cursor /    │ ◄────────────────────► │  This MCP server  │ ───────────► │ Jira REST   │
│ MCP client  │                        │  (Node + fetch)   │   Cookies    │ (and opt.   │
└─────────────┘                        └──────────────────┘   Cookies      │ Confluence) │
                                                                            └─────────────┘

MCP tools (reference)

Tools are exposed to the assistant under the names below. Exact parameters are defined in the server’s tool schemas (your client may show them in the UI).

Authentication

Tool	Purpose
`jira_login`	Opens a browser, completes SSO, saves the session cookie file. Run once before using other tools, and again if the session expires.

Search and read

Tool	Purpose
`execute_jql`	Run JQL and return matching issues (with configurable `maxResults`).
`get_ticket` / `get_task`	Full issue JSON from the REST API (aliases for task-style issues).
`read_ticket` / `read_task`	Compact issue view (summary, description as plain text, status, assignee, etc.).
`get_only_ticket_name_and_description`	Only summary and plain-text description.

Create, update, delete

Tool	Purpose
`create_ticket`	Create an issue (summary, description, issuetype; optional project, boardName, boardId, parent). If project is omitted, uses JIRA_DEFAULT_PROJECT, resolves from a board, or auto-picks when only one project appears on your boards—otherwise fails with a message listing boards (use `list_boards`).
`list_boards`	List Jira Software boards (Agile REST). Helps choose boardName / boardId for `create_ticket`. Not available if your site has no Software boards (use explicit project).
`edit_ticket`	Update fields such as summary, description, labels, parent.
`delete_ticket`	Delete an issue (requires permission in Jira).

Projects, people, workflow

Tool	Purpose
`list_projects`	List projects (v3: search API; v2: `GET /project`).
`assign_ticket`	Assign an issue by Atlassian account ID.
`query_assignable`	List users assignable for a project key.
`get_all_statuses`	Return issue statuses from Jira.

Attachments

Tool	Purpose
`add_attachment_from_confluence`	Pull a named attachment from a Confluence page (needs `CONFLUENCE_BASE_URL` and Confluence SSO cookies) and attach it to a Jira issue.
`add_attachment_from_public_url`	Download a file from a public URL and attach it to an issue.

Prerequisites

Node.js 18+
Network access to your Jira (and Confluence, if you use that tool)
One-time browser install for Playwright (Chromium), required only if you use jira_login or SSO fallback:

npm install
npm run install-browser

How to use it

Option A — Published package (`npx`)

After the package is on npm, you do not need to clone the repo. Cursor (or your host) can start the server with:

npx -y jira-mcp-oauth

Pin a version if you want reproducibility:

npx -y jira-mcp-oauth@0.1.4

The process speaks MCP on stdio. In normal use the IDE starts it; you only run the command yourself to verify installation or debug.

Option B — Clone this repository

git clone <your-repo-url>
cd jira-mcp-oauth
npm install
npm run install-browser

Run the server locally:

npm start

Same stdio behavior as npx; again, the typical pattern is to let Cursor spawn node with a path to src/index.js (see below).

Configure Cursor (`mcp.json`)

Put URLs and timeouts in env. There are no secrets to configure — auth is the browser SSO session saved by jira_login.

Using npx (after publish):

{
  "mcpServers": {
    "jira-sso": {
      "command": "npx",
      "args": ["-y", "jira-mcp-oauth"],
      "env": {
        "JIRA_BASE_URL": "https://jira.company.com",
        "JIRA_LOGIN_WAIT_SECONDS": "90"
      }
    }
  }
}

Using a local checkout (development):

{
  "mcpServers": {
    "jira-sso": {
      "command": "node",
      "args": ["C:/path/to/jira-mcp-oauth/src/index.js"],
      "env": {
        "JIRA_BASE_URL": "https://jira.company.com"
      }
    }
  }
}

Replace jira-sso if you prefer another server id; it is only a label in Cursor.
Fully quit and restart Cursor after any change to mcp.json.

First-time SSO

Ensure JIRA_BASE_URL is correct (include /jira in the path only if your instance uses that context path).
In chat, run the jira_login tool or from the repo run npm run login (uses the same merged config as the MCP server).
Complete login in the opened browser; wait until the tool finishes (up to JIRA_LOGIN_WAIT_SECONDS, default 90).
On success, the server also discovers your Agile board(s) and their project keys and caches them to cookies/boards-<host>.json. From then on, create_ticket defaults to your board's project when you don't pass one (auto-selected only when a single project is cached; otherwise pass project, boardName, or boardId). Re-run jira_login to refresh the cache.
Use execute_jql, read_ticket, etc., as needed.

Using tools from the assistant

You do not type REST URLs yourself. Ask the assistant in natural language, for example:

“Search Jira for project = KEY AND status = Open using execute_jql.”
“Read issue KEY-123 with read_ticket.”
“Create a Bug in project KEY with summary … using create_ticket.”

The client maps these to the tool calls above.

Environment variables

Required

Variable	Meaning
`JIRA_BASE_URL`	Root URL of your Jira site (example: `https://jira.company.com` or `https://intranet.example.com/jira` if you use a context path).

Optional (Jira)

Variable	Meaning
`JIRA_REST_API_PREFIX`	REST base path (default `/rest/api/3`). Use `/rest/api/2` if your server only exposes v2.
`JIRA_DESCRIPTION_FORMAT`	`auto` (default: plain string for v2, ADF for v3), `adf`, or `plain` — overrides description encoding if your site differs.
`JIRA_LOGIN_URL`	Login page URL (default `{JIRA_BASE_URL}/login.jsp`).
`JIRA_LOGIN_WAIT_SECONDS`	Browser SSO wait, in seconds (default 90).
`JIRA_MAX_ATTACHMENT_BYTES`	Max upload size in bytes (default 10 MiB).
`JIRA_MCP_SERVER_KEY`	If several MCP entries share the same path to `src/index.js`, set this to that entry’s id (e.g. `jira-local`) so config discovery matches the right block.
`JIRA_DEFAULT_PROJECT`	Default project key when `create_ticket` is called without project / boardName / boardId and board-based resolution is ambiguous or unavailable.
`JIRA_KEEPALIVE_SECONDS`	Background session keep-alive interval in seconds (default 240). Set `0` to disable. Keeps the SSO session warm and warns early if the cookie goes stale.
`JIRA_LOGIN_POLL_MS`	During `jira_login`, how often to probe `/rest/api/.../myself` so login can finish early (default 2000 ms).

Optional (Confluence attachment helper)

Variable	Meaning
`CONFLUENCE_BASE_URL`	Confluence root URL for `add_attachment_from_confluence`.
`CONFLUENCE_MCP_SERVER_KEY`	Optional; used to name the Confluence cookie file for `add_attachment_from_confluence` (`cookies/cf-<key>.json`) so it aligns with your Confluence MCP server id.

Cookie files: Jira SSO uses cookies/session-<JIRA_MCP_SERVER_KEY or hostname>.json. Confluence attachments from this package use cookies/cf-<CONFLUENCE_MCP_SERVER_KEY or hostname>.json (separate from Jira). Both come from SSO login — there is no token mode.

Where to set them

Cursor: %USERPROFILE%\.cursor\mcp.json (Windows) or ~/.cursor/mcp.json (macOS/Linux) → mcpServers.<name>.env. Restart the IDE after edits.
Local npm run login: Env is merged from the discovered mcp.json block (same path as this src/index.js, or legacy jira-sso) for keys that are unset—set JIRA_MCP_SERVER_KEY when multiple entries share that path.

Configuration reference (files & precedence)

Topic	Detail
Auth	SSO cookies only — no tokens are read from `.env` or `mcp.json`. Complete `jira_login` once.
CLI login merge	Fills only undefined env keys from the discovered block (never overwrites Cursor).
Cookie files	One file per instance: `cookies/session-<id-or-host>.json` for Jira; `cookies/cf-<id-or-host>.json` for Confluence attachment helper.
Cookies	SSO sessions are saved under this package's `cookies/` directory (gitignored). `jira_login` and `confluence_login` (in the Confluence package) each use their own repo's `cookies/` directory.
`add_attachment_from_confluence`	Needs `CONFLUENCE_BASE_URL` in the same `jira-sso` `mcp.json` `env`. Uses the Confluence SSO cookie file in this repo — if Confluence is a different SSO realm, run login from the Confluence MCP package and align cookie usage.

Defaults (when omitted)

Variable	Default
`JIRA_REST_API_PREFIX`	`/rest/api/3`
`JIRA_DESCRIPTION_FORMAT`	`auto` (plain description for v2 prefix, ADF for v3)
`JIRA_LOGIN_URL`	`{JIRA_BASE_URL}/login.jsp`
`JIRA_LOGIN_WAIT_SECONDS`	`90`
`JIRA_MAX_ATTACHMENT_BYTES`	`10485760` (10 MiB)
`JIRA_DEFAULT_PROJECT`	(none — set when you want `create_ticket` without project when board resolution does not apply)

Boards and Agile: list_boards and board-based create_ticket resolution use /rest/agile/1.0 (Jira Software). If that API returns 404 or an empty list, your site may not expose Software boards—set project or JIRA_DEFAULT_PROJECT instead.

Authentication (summary)

Auth is SSO cookies only. Run jira_login once; the session cookie file is used for every REST call.
A background keep-alive (JIRA_KEEPALIVE_SECONDS, default 240) pings /myself to keep the session warm and warns on stderr if it goes stale.
When the session truly expires, tools fail with a clear error — run jira_login again to refresh it. (SSO cookies cannot be renewed headlessly.)

Validation

Step	Command / action
Unit tests (features)	`npm test` — runs `node --test` on `tests/jira-features.test.js` (REST v2/v3 paths, description plain vs ADF, `listProjects` URL shape, board helpers).
Syntax + config (no Jira calls)	`npm run validate` — syntax-checks `src/`; with `JIRA_BASE_URL` set, prints resolved REST prefix and description format.
MCP wiring	Cursor Settings → MCP: server shows connected. Restart Cursor after `mcp.json` changes.
Interactive tools	In Agent, call `execute_jql` with a narrow query, or `list_projects`, after completing `jira_login`.
Inspector (optional)	Install/run the official MCP Inspector (see modelcontextprotocol/inspector) and point it at `node path/to/jira-mcp-oauth/src/index.js` with the same `env` as Cursor.

Local tarball sanity check

npm pack
# Creates e.g. jira-mcp-oauth-0.1.4.tgz

Windows (cmd):

set JIRA_BASE_URL=https://jira.example.com
npx .\jira-mcp-oauth-0.1.4.tgz

macOS / Linux:

export JIRA_BASE_URL=https://jira.example.com
npx ./jira-mcp-oauth-0.1.4.tgz

The first npx run may take a moment while dependencies install. If your mcp.json already defines JIRA_BASE_URL, the process may stay running on stdio (normal for MCP).

Security

Treat session cookies like passwords. Do not commit the cookies/ directory (it is gitignored and excluded from the npm package).
A saved cookie file grants roughly the same access as your browser user; lock down the machine and project directory.

Troubleshooting

Symptom	What to do
`JIRA_BASE_URL is not set`	Add `JIRA_BASE_URL` under `mcpServers.<name>.env` and restart Cursor.
401 / HTML instead of JSON	Session expired or wrong API version — try `JIRA_REST_API_PREFIX`, or run `jira_login` again to refresh cookies.
SSO in the browser but REST still 401	Delete the per-server file under `cookies/` (see `JIRA_MCP_SERVER_KEY` in the env table) and run `jira_login` again, completing SSO fully. `jira_login` output lists the cookie path.
`jira_login` times out in chat	Increase `JIRA_LOGIN_WAIT_SECONDS` or run `npm run login` in a terminal (same config).
Browser closes immediately	Session detection requires JSON from `/myself`, not 200 HTML after redirects. `Execution context was destroyed` during navigation is caught and retried in the poll loop. If SSO still fails, re-run login and complete it fully.
`ENOENT` on `cookies/*.lock`	Ensure the `cookies/` directory exists under the installed package (some `npx` extracts can omit it). Create `cookies` next to `src/` or use a local `node …/src/index.js` install.
Half-installed `@modelcontextprotocol/sdk` under `_npx`	Clear `%LocalAppData%\npm-cache\_npx` for that hash, or run from a git clone with `npm install` so `node_modules` is complete.

Repository and npm metadata

Package repository, homepage, and bugs in package.json point to https://github.com/Wasim-Shaikh25/jira-mcp-auth. Update those fields if you fork to another org.

The npm package name is jira-mcp-oauth (unscoped). If you previously published under @svasimahmed283/jira-mcp-oauth, keep that version for backward compatibility or deprecate it on npm after publishing this name.

License

See package.json for the declared license. Add a LICENSE file in the repo if you publish publicly.

Available Tools

17 tools

add_attachment_from_confluenceA

Download an attachment from Confluence (CONFLUENCE_BASE_URL + CONFLUENCE_PAT or SSO cookies) and upload it to a Jira issue.

ParametersJSON Schema

Name	Required	Description
`pageId`	Yes	Confluence page ID
`issueIdOrKey`	Yes	Issue ID or key to add attachment to
`attachmentName`	Yes	Name of the attachment in Confluence

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden. It mentions authentication requirements but lacks details on side effects (e.g., does it modify Confluence?), error conditions, rate limits, or permissions required. This is insufficient for a cross-system operation.

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?

Single sentence efficiently conveys the action and authentication method. No unnecessary words; all information is relevant and front-loaded.

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?

The description covers the high-level process and auth but lacks details about result handling, failure scenarios, and the linking between Confluence attachment and Jira issue. Given no output schema and moderate complexity, it is minimally adequate but not complete.

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%, and the description adds no additional meaning to individual parameters beyond their schema descriptions. The verb 'Download and upload' frames the action but does not enhance parameter semantics. Baseline score 3 is appropriate.

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 the tool downloads an attachment from Confluence and uploads it to a Jira issue, specifying the source and target. It distinguishes itself from sibling 'add_attachment_from_public_url' by mentioning Confluence authentication (PAT or SSO cookies).

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

Usage Guidelines3/5

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

The description implies usage for Confluence attachments but does not explicitly state when to use this tool versus 'add_attachment_from_public_url' or any prerequisites. No exclusion criteria or guidance on alternatives is provided.

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

add_attachment_from_public_urlA

Download a file from a public URL and attach it to a Jira issue.

ParametersJSON Schema

Name	Required	Description	Default
`imageUrl`	Yes	Public URL of the file to attach
`issueIdOrKey`	Yes	Issue ID or key to add attachment to

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description should disclose more about the operation. It mentions downloading and attaching but omits details like file size limits, supported types, authentication requirements, 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.

Conciseness5/5

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

Single sentence, front-loaded with the action, no wasted words. Highly efficient.

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?

The description is too brief for the tool's complexity, lacking details on return values, behavior, and error handling. No output schema exists to compensate. Also fails to reference the sibling tool for comparison.

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% with parameter descriptions. The tool description adds no extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the action ('Download a file from a public URL and attach it to a Jira issue'), specifying both the source (public URL) and destination (Jira issue), which distinguishes it from sibling 'add_attachment_from_confluence'.

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

Usage Guidelines3/5

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

The description implies when to use (public URL attachments) but does not explicitly state when not to use it or mention alternatives like 'add_attachment_from_confluence' for Confluence sources.

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

assign_ticketC

Assign an issue by Atlassian account ID.

ParametersJSON Schema

Name	Required	Description	Default
`accountId`	Yes	Assignee's account ID
`issueIdOrKey`	Yes	Issue ID or key to assign

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must carry the full behavioral burden. It states only the basic action without disclosing side effects (e.g., notifications, status changes), required permissions, or constraints like issue status prerequisites.

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 sentence, front-loaded with the action and resource. It is concise but skips important behavioral context, slightly reducing its effectiveness.

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?

For a simple mutation tool with no output schema, the description lacks completeness. It does not explain the result of the operation, whether the assignment might fail due to assignability, or how to handle errors. The presence of a sibling 'query_assignable' hints at missing context.

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 baseline is 3. The tool description adds no extra meaning beyond the schema; it merely echoes the accountId purpose. No additional context for issueIdOrKey is given.

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

Purpose4/5

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

The description clearly states the action ('assign') and resource ('issue'), specifying the identifier type ('by Atlassian account ID'). It distinguishes the tool from siblings like create_ticket or edit_ticket, as assignment is a specific operation. However, it could be more precise about 'assign' meaning setting the assignee.

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

Usage Guidelines2/5

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 alternatives like edit_ticket, which might also handle assignments. There are no context switches, prerequisites, or exclusion criteria mentioned.

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

create_ticketA

Create an issue in a project. project is optional if the destination is unambiguous: set JIRA_DEFAULT_PROJECT in MCP env, pass boardName or boardId (Jira Software Agile boards), or omit when your account sees exactly one project across boards—otherwise the tool fails with a clear error listing boards (use list_boards). Description is plain text: v3 → ADF, v2 → string (JIRA_REST_API_PREFIX, JIRA_DESCRIPTION_FORMAT). Does not set sprint/backlog placement—use the UI or Agile REST for that.

ParametersJSON Schema

Name	Required	Description
`parent`	No	Parent issue key (for subtasks)
`boardId`	No	Agile board id as string (from list_boards or the board URL). Resolves the board's project key when project is not set.
`project`	No	Project key (e.g. PROJ). If omitted, resolution uses JIRA_DEFAULT_PROJECT, boardName/boardId, or a single board project.
`summary`	Yes	Ticket summary
`boardName`	No	Jira Software board name (substring match). Resolves the board's project key when project is not set.
`issuetype`	Yes	Issue type name (Bug, Story, Task, etc.)
`description`	Yes	Ticket description (plain text)

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description effectively discloses key behaviors: project resolution logic, description format dependency on environment variables, error behavior when ambiguous, and what the tool does not do. Minor omission: no mention of return value or permissions.

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 front-loaded with the main action and uses bold for emphasis. It is concise but dense, packing multiple details into one paragraph. Slight improvement could break into bullet points for clarity.

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 7 parameters and no output schema, the description covers project resolution and description format well. However, it lacks information about the return value (e.g., created ticket key) and does not mention any potential side effects or idempotency.

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?

Input schema has 100% coverage, but the description adds meaning for project and board parameters by explaining resolution strategies and the role of environment variables. It also clarifies description format nuances beyond the schema's plain text description.

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 an issue in a project,' using a specific verb and resource. It distinguishes from sibling tools like edit_ticket and delete_ticket by focusing on creation and providing unique project resolution details.

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?

The description provides explicit guidance on when to use project, boardName, boardId, or omit project, including fallback behavior and error handling. It also advises using list_boards for disambiguation and clarifies that sprint/backlog placement is not set, directing to UI/Agile REST.

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

delete_ticketB

Delete an issue (requires permission).

ParametersJSON Schema

Name	Required	Description	Default
`issueIdOrKey`	Yes	Issue ID or key to delete

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided; the description barely discloses that deletion is destructive and permission-dependent. It fails to mention irreversibility, cascading effects, or return behavior.

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?

Single sentence with no unnecessary words. Efficient and well-structured for the minimal content.

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 tool's low complexity (one parameter, no output schema), the description is minimally viable but still lacks behavioral context like reversibility or typical use cases.

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% and the parameter description is already present. The tool description adds no extra semantic value beyond what the schema provides.

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

Purpose4/5

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

The description clearly states the action ('Delete') and resource ('issue'), distinguishing it from siblings like create or assign. However, it could be more specific by noting the system (e.g., 'Jira issue').

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like edit or assign. The only hint is 'requires permission', which is vague and not actionable.

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

edit_ticketB

Update issue fields (summary, description, labels, parent).

ParametersJSON Schema

Name	Required	Description
`labels`	No	Labels to set
`parent`	No	New parent issue key
`summary`	No	New summary
`description`	No	New description (plain text)
`issueIdOrKey`	Yes	Issue ID or key to edit

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only says 'Update issue fields' without explaining side effects, required permissions, or whether unspecified fields are unchanged. For a mutation tool, this is insufficient.

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 a single concise sentence with no wasted words. It is front-loaded with the verb and resource.

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?

No output schema exists, but the description does not mention return values. It also does not clarify that only specified fields are updated. Given the complexity of updating issues, more context is needed.

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 the schema already documents all parameters. The description lists field names but adds no extra meaning beyond the schema. Baseline of 3 is appropriate.

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 'Update' and the resource 'issue fields', listing specific fields (summary, description, labels, parent). This distinguishes it from sibling tools like create_ticket or delete_ticket.

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

Usage Guidelines3/5

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

No explicit when-to-use or when-not-to-use guidance. The description implies updating fields, but does not mention alternatives like assign_ticket for assignment. It is adequate but lacks differentiation context.

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

execute_jqlC

Run a JQL search and return issues (summary fields).

ParametersJSON Schema

Name	Required	Description	Default
`jql`	Yes	JQL query string
`maxResults`	No	Maximum number of results (default 10, max 100).

TDQS

C2.9/5.0

Behavior2/5

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

The description minimally indicates a read operation ('search') but lacks disclosure on authentication, rate limits, error handling, or behavior beyond returning summary fields, especially given no 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?

Extremely concise single sentence; no wasted words, though could benefit from a brief usage hint.

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?

Adequate for a simple search tool but lacks output schema and does not describe pagination, error states, or relationship to sibling tools.

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?

Input schema provides 100% coverage for both parameters; the description adds only that results include summary fields, not adding significant meaning beyond schema.

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

Purpose4/5

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

The description clearly states the tool runs a JQL search and returns issues with summary fields, distinguishing it from single-ticket retrieval tools like get_ticket.

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

Usage Guidelines2/5

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

No guidance on when to use this tool over alternatives (e.g., get_ticket, read_ticket) or when not to use it.

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

get_all_statusesB

Return all issue statuses from Jira.

ParametersJSON Schema

Name	Required	Description	Default
`maxResults`	No	Ignored; kept for parity with official tool shape.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are present, so the description should disclose behavioral traits. It only states that the tool 'returns all issue statuses' without mentioning read-only nature, authentication requirements, or any side effects. The warning in the schema about maxResults being ignored is not reinforced in the description.

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 clear sentence with no extra words. It is appropriately brief for a simple list operation, though it could be slightly improved by including usage context.

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?

The tool lacks an output schema and annotations. The description does not explain what 'issue statuses' entails (e.g., structure, list of strings vs objects), whether it scopes to a project, or pagination behavior. Given the ignored maxResults parameter, the agent may need more details.

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% and the schema description for maxResults explicitly states it is ignored. The tool description adds no further parameter information, but the baseline is 3 due to high coverage.

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 'return' and the resource 'all issue statuses from Jira', distinguishing it from sibling tools like get_ticket (single ticket) and list_projects (list projects). It is 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 Guidelines2/5

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 alternatives like list_boards or execute_jql. The description does not specify prerequisites (e.g., Jira login) or scenarios where this tool is appropriate.

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

get_only_ticket_name_and_descriptionA

Return only summary and plain-text description for an issue.

ParametersJSON Schema

Name	Required	Description	Default
`issueIdOrKey`	Yes	The issue ID or key of the ticket

TDQS

A4/5.0

Behavior4/5

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

The description indicates a read operation ('Return'), but with no annotations, it could be more explicit about being non-destructive. Still, it clearly conveys the action is safe.

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?

A single focused sentence that front-loads the verb and specifies the result scope. No wasted 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?

For a simple tool with one parameter and no output schema, the description adequately explains what is returned. Could mention error behavior or that summary is the same as name, but overall sufficient.

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%, and the description adds no extra meaning to the parameter beyond the schema's description. Baseline 3 is appropriate.

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 returns 'only summary and plain-text description' for an issue, which is specific and distinguishes it from siblings like get_ticket that likely return more fields.

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

Usage Guidelines3/5

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

The name and description imply it's for when only summary and description are needed, but no explicit guidance on when to use this vs siblings like get_ticket or read_ticket.

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

get_taskB

Same as get_ticket — returns full issue JSON (alias for task-type issues).

ParametersJSON Schema

Name	Required	Description	Default
`issueIdOrKey`	Yes	The issue ID or key of the ticket

TDQS

B3.2/5.0

Behavior2/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 'returns full issue JSON' but does not disclose whether the operation is read-only, requires permissions, or has any side effects. Basic behavioral traits are missing.

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 a single, concise sentence with no extraneous information. It efficiently conveys the core purpose.

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 the simplicity of the tool (one parameter, no output schema), the description is fairly complete. It references get_ticket which presumably has detailed documentation. However, it does not explain what 'full issue JSON' entails or mention error handling.

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% with a single parameter described as 'The issue ID or key of the ticket.' The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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

Purpose4/5

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

The description clearly states it as an alias for get_ticket, returning full issue JSON for task-type issues. The verb 'get' and resource 'task' are specific. However, it does not differentiate from get_ticket beyond being an alias, and the mention of 'task-type issues' is somewhat ambiguous.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives like get_ticket, read_task, or read_ticket. The description implies it is an alias, but does not explain scenarios where one should be preferred over the other.

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

get_ticketA

Get full issue JSON from Jira. Uses JIRA_REST_API_PREFIX (e.g. /rest/api/2 or /rest/api/3). If you see 401, set JIRA_PAT or run jira_login once.

ParametersJSON Schema

Name	Required	Description	Default
`issueIdOrKey`	Yes	The issue ID or key of the ticket

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries the burden of behavioral disclosure. It mentions the API prefix and a common error, but lacks details about idempotency, rate limits, auth requirements beyond a token, or any side 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?

Two concise sentences: the first defines the purpose, the second adds practical troubleshooting. No wasted words.

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 one parameter and no output schema, the description covers the basic purpose and a common error. However, it does not differentiate from sibling tools like 'read_ticket' or describe the response structure, leaving gaps for an agent.

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%, and the schema already explains 'issueIdOrKey' clearly. The description adds no extra parameter meaning beyond the schema, so baseline 3 is appropriate.

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'), resource ('full issue JSON'), and source ('from Jira'). It differentiates from sibling 'get_only_ticket_name_and_description' by implying a complete response.

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

Usage Guidelines3/5

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

The description hints when to use (for full JSON) and provides a troubleshooting step for 401 errors, but does not explicitly state when not to use or compare with alternatives like 'read_ticket' or 'get_task'.

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

jira_loginA

SSO login in a browser (Playwright); saves cookies for REST. If IdP redirects or automation block a session, use JIRA_PAT + PREFER_SSO_COOKIES=0 in mcp.json or delete the reported cookie file. When JIRA_PAT is set, REST prefers it unless PREFER_SSO_COOKIES and cookies override.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so description carries full burden. It discloses browser automation (Playwright) and cookie storage, but lacks details on side effects (e.g., requires user interaction for SSO, modifies local files) or whether it is a one-time setup. More behavioral context 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?

Two sentences with core functionality first, followed by troubleshooting advice. No wasted words, information is front-loaded.

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 zero parameters and no output schema, description covers authentication purpose and failure handling. However, it does not explicitly state the tool's return value or that it should be called before other JIRA tools, which would be helpful for context among sibling tools.

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?

No parameters exist, so baseline score of 4 applies. The description adds no additional parameter-level meaning since there are none to document, but provides context about the tool's behavior.

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 it performs SSO login via Playwright and saves cookies for REST. It is distinct from sibling tools which are task-specific JIRA operations.

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 guidance on when to use (SSO login) and alternatives if automation fails (use JIRA_PAT and delete cookie file). Also mentions configuration options for PREFER_SSO_COOKIES.

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

list_boardsA

List Jira Software boards (GET /rest/agile/1.0/board). Use names/ids with create_ticket when project is ambiguous. Returns 404 if Agile is disabled or your site has no Software boards—in that case pass project or JIRA_DEFAULT_PROJECT.

ParametersJSON Schema

Name	Required	Description	Default
`maxResults`	No	Maximum boards (default 50, max 50).

TDQS

A4.4/5.0

Behavior4/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 discloses the HTTP method (GET), the specific endpoint, and the error condition (404) with a workaround. It also mentions the maxResults parameter behavior (default 50, max 50). However, it does not discuss authentication, rate limits, or other potential side effects, but for a read-only list operation, 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.

Conciseness5/5

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

The description is two efficient sentences. The first sentence states purpose and endpoint. The second sentence gives usage guidance and error handling. No wasted 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 the tool has only one optional parameter and no output schema, the description covers the key points: purpose, endpoint, usage with alternatives, and error handling. It does not explain the return format, but that is less critical for a simple list tool. It is nearly complete.

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% for the single parameter (maxResults), which has a clear description in the schema. The description does not add extra semantics beyond what the schema already provides, so baseline 3 is appropriate. The overall description provides context about error handling but not parameter-specific details.

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 'List Jira Software boards' with the specific REST endpoint. It distinguishes from sibling tools by focusing on Agile boards, with a note about using names/ids with create_ticket when project is ambiguous.

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?

The description provides explicit guidance on when to use the tool (for listing boards) and when to use alternatives ('Use names/ids with create_ticket when project is ambiguous'). It also gives error handling advice for 404 responses.

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

list_projectsA

List Jira projects. Uses /project/search on REST v3; on REST v2 uses GET /project (v2 has no project search endpoint).

ParametersJSON Schema

Name	Required	Description	Default
`maxResults`	No	Maximum number of projects (default 50, max 100).

TDQS

A4/5.0

Behavior4/5

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

Discloses version-dependent endpoint selection (v3 uses /project/search, v2 uses GET /project), which is a behavioral trait not in annotations. Missing details like pagination or idempotency.

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 concise sentences with no superfluous information, efficiently conveying purpose and technical detail.

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?

Adequately covers the simple list operation with one parameter. Lacks mention of return format but that is often implied.

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% with a description for maxResults. The tool description adds no further parameter details 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 'List Jira projects' and provides specific API endpoint details for v2 and v3, distinguishing itself from sibling tools like list_boards.

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

Usage Guidelines3/5

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

No explicit guidance on when to use or avoid this tool versus alternatives. The description implies use for listing projects, but lacks when-not or comparisons.

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

query_assignableB

List users assignable for a project.

ParametersJSON Schema

Name	Required	Description	Default
`project_key`	Yes	Project key to query assignable users for

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It only says 'List users assignable for a project' but does not mention output format, pagination, permissions needed, or whether the list includes only available users or all potential assignees. This leaves significant ambiguity for a read operation.

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 extremely concise at 5 words, with no filler. However, it sacrifices some completeness for brevity. For such a simple tool, this level of conciseness is acceptable but could be slightly more informative without losing efficiency.

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?

Given the tool's simplicity (1 param, no output schema, no annotations), the description fails to clarify what 'assignable' means in the project context. It does not connect to related tools like assign_ticket, leaving the agent without full context to understand the tool's use case.

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% and the schema description of project_key is clear. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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 function: listing assignable users for a project. It uses a specific verb (List) and resource (users assignable for a project), and is distinct from sibling tools which focus on ticket operations rather than user queries.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It lacks any indication of prerequisites, context for when it is appropriate, or exclusions. The agent has no basis to decide between this and similar tools like assign_ticket.

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

read_taskC

Same as read_ticket — compact issue view (alias for task-type issues).

ParametersJSON Schema

Name	Required	Description	Default
`issueIdOrKey`	Yes	The issue ID or key of the ticket

TDQS

C2.5/5.0

Behavior2/5

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

No annotations provided. Description mentions 'compact issue view' but does not explain what fields or behavior entails. Minimal disclosure beyond alias.

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?

One sentence, very concise. However, it achieves conciseness at the expense of clarity, relying on external reference.

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?

Simple tool with one param and no output schema. Description is incomplete, referencing another tool without explaining its own behavior or return format.

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?

Input schema has 100% coverage with one parameter (issueIdOrKey) clearly described. Description adds no additional meaning beyond schema.

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

Purpose2/5

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

The description states it is 'same as read_ticket — compact issue view (alias for task-type issues).' It does not explicitly define what the tool does, relying on an alias to another tool. Vague purpose.

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

Usage Guidelines3/5

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

Implies use for task-type issues versus ticket-type, providing some differentiation among siblings. However, it does not explicitly state when to use or alternatives.

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

read_ticketC

Read a ticket as a compact object (summary, plain-text description, status, assignee, etc.).

ParametersJSON Schema

Name	Required	Description	Default
`issueIdOrKey`	Yes	The issue ID or key of the ticket

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden. It only mentions the output is a compact object with certain fields, but lacks details on permissions, side effects, or limitations. For a read operation, minimal transparency is provided.

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 sentence with no unnecessary words. It effectively communicates the core purpose, though it could include more detail without sacrificing conciseness.

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?

The tool has one parameter and no output schema. The description covers basic return fields but does not specify whether all fields are always present or if additional data like comments are included. It is adequate for a simple read but leaves some gaps.

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% for the single parameter 'issueIdOrKey', which is self-explanatory. The description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate.

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

Purpose4/5

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

The description clearly states it reads a ticket and returns a compact object with specific fields (summary, description, status, assignee, etc.). It provides a verb and resource, and hints at a lighter version compared to siblings like 'get_ticket' or 'get_only_ticket_name_and_description', but does not explicitly differentiate.

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

Usage Guidelines2/5

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 alternatives. Siblings like 'get_ticket' and 'get_only_ticket_name_and_description' exist but the description offers no comparison or selection criteria.

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.

17 tool updatesv0.1.5Jun 29, 2026
- First observedadd_attachment_from_confluence
- First observedadd_attachment_from_public_url
- First observedassign_ticket
- First observedcreate_ticket
- First observeddelete_ticket
- First observededit_ticket
- First observedexecute_jql
- First observedget_all_statuses
- First observedget_only_ticket_name_and_description
- First observedget_task
- First observedget_ticket
- First observedjira_login
- First observedlist_boards
- First observedlist_projects
- First observedquery_assignable
- First observedread_task
- First observedread_ticket

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

B3/5.0

Scored 2026-06-29 03:05 across 17 tools

Disambiguation2/5

Multiple aliases (get_task/get_ticket, read_task/read_ticket) create redundancy and confusion. Agents may struggle to choose the correct tool for retrieving issue data. The two attachment tools are similar but distinct in source.

Naming Consistency3/5

Most tools follow verb_noun pattern (e.g., create_ticket, list_boards), but inconsistencies exist: jira_login instead of login_jira, and usage of both 'get' and 'read' for similar retrieval functions. The lengthy get_only_ticket_name_and_description breaks the pattern.

Tool Count3/5

17 tools is slightly above the well-scoped range (3-15). While the number covers Jira operations, the presence of duplicate aliases (4 tools for ticket retrieval) inflates the count without adding value.

Completeness3/5

Core operations like CRUD for issues, JQL search, and project/board listing are present. However, critical gaps exist: no tool for transitioning issue status (workflow), and no direct way to manage issue types or sprints. Alias tools further reduce effective coverage.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
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
ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297
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

Related MCP Servers

Personal JIRA MCP
Project Management App Automation
yuezheng2006
A
license
C
quality
C
maintenance
An MCP server that enables AI assistants to interact with JIRA, allowing for querying issue details, creating and updating work items, and managing attachments through a standardized interface.
Updated a year ago (2025-05-20 17:01 UTC)
12
4
MIT
MCP Atlassian
Project Management Workplace & Productivity Developer Tools
crew-of-one
A
license
Not graded
quality
C
maintenance
An MCP server that enables AI assistants to interact with Atlassian Jira and Confluence across Cloud and Server/Data Center environments. It supports tasks like searching and summarizing documentation, managing Jira issues, and creating content through natural language.
Updated 8 days ago (2026-09-07 11:52 UTC)
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)
-
mcp-atlassian
Project Management Content Management Systems Search
matutezam
A
license
Not graded
quality
B
maintenance
MCP server for Atlassian Confluence and Jira, enabling AI assistants to search, create, and update issues and pages via natural language.
Updated 13 days ago (2026-09-02 00:28 UTC)
MIT

Project	Purpose
Confluence MCP	confluence-mcp-oauth — Confluence REST + SSO (`confluence-sso-mcp` on npm). Same cookie design as this server.
GitHub Enterprise launcher	mcp-github-enterprise-launcher — npm stdio wrapper around a `github-mcp-server` binary (optional `vendor/` bundle).
SonarQube launcher	mcp-sonarqube-launcher — npm stdio wrapper around a SonarQube MCP `.jar` (optional `vendor/` bundle).

Jira MCP OAuth gateway

See also (sibling projects)

What this project is

Why use it

How it fits in your workflow

MCP tools (reference)

Authentication

Search and read

Create, update, delete

Projects, people, workflow

Attachments

Prerequisites

How to use it

Option A — Published package (npx)

Option B — Clone this repository

Configure Cursor (mcp.json)

First-time SSO

Using tools from the assistant

Environment variables

Required

Optional (Jira)

Optional (Confluence attachment helper)

Where to set them

Configuration reference (files & precedence)

Defaults (when omitted)

Authentication (summary)

Validation

Local tarball sanity check

Security

Troubleshooting

Repository and npm metadata

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Option A — Published package (`npx`)

Configure Cursor (`mcp.json`)