Provides tools for interacting with Jira Cloud REST API v3, including field discovery, issue creation/update, user resolution, comments, transitions, and bulk operations.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jira-api-mcp-wrapper find the customfield ID for 'Epic Link'"
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.
An MCP server (stdio) that talks directly to Jira Cloud REST API v3 using static credentials (no OAuth flow) and exposes a small set of deterministic tools for:
discovering customfield_* IDs
resolving accountId for user picker fields
updating issue fields (including ADF JSON)
Unit and Contract Tests (default, no network):
npm testThis runs all unit tests and contract tests without making any network calls. These tests use mocked HTTP clients and are deterministic.
Integration Tests (requires Jira credentials):
Integration tests make real HTTP calls to Jira Cloud. They are split into read-only (smoke) and write tests.
Read-only smoke tests:
npm run test:integration:smokeRequires:
JIRA_BASE_URL (or JIRA_URL)
JIRA_EMAIL and JIRA_API_TOKEN, OR JIRA_BEARER_TOKEN
Optional variables:
JIRA_TEST_USER_QUERY: User search query
JIRA_TEST_JQL: JQL query for search test
JIRA_TEST_ISSUE_KEY: Issue key for get/transitions tests
Write tests (creates real data):
JIRA_INTEGRATION_WRITE_TESTS=1 npm run test:integration:writeRequires:
All smoke test variables
JIRA_TEST_PROJECT_KEY: Project key for creating test issues
JIRA_TEST_TRANSITION_ID (optional): Transition ID for transition test
⚠️ Warning: Write tests create real issues and comments in your Jira instance. They use the tag [mcp-wrapper-test] in summaries for easy identification and cleanup.
All integration tests:
npm run test:integrationtests/unit/: Unit tests for individual components (no network)
tests/contract/: Contract tests for MCP tool handlers (no network, uses fake Jira client)
tests/integration/smoke.test.js: Read-only integration tests
tests/integration/write.test.js: Write integration tests (guarded by env var)
Related MCP server: jiraxmcp
Set environment variables (pick one auth method):
ga-jira/mcp.jsonJIRA_URL → JIRA_BASE_URL (same value)
JIRA_EMAIL → JIRA_EMAIL
JIRA_API_TOKEN → JIRA_API_TOKEN
JIRA_BASE_URL (example: https://your-domain.atlassian.net)
JIRA_EMAIL (example: you@company.com)
JIRA_API_TOKEN (create in Atlassian account settings)
JIRA_BASE_URL
JIRA_BEARER_TOKEN
Add to your Cursor MCP config (typically ~/.cursor/mcp.json):
{
"mcpServers": {
"jira-api-mcp-wrapper": {
"command": "node",
"args": [
"/path/to/jira-api-mcp-wrapper/dist/index.js"
],
"env": {
"JIRA_BASE_URL": "https://your-domain.atlassian.net",
"JIRA_EMAIL": "you@company.com",
"JIRA_API_TOKEN": "your_api_token"
}
}
}
}jira_list_fieldsLists Jira fields (including customfield_*) via /rest/api/3/field.
jira_search_issues_jqlSearch issues using JQL via /rest/api/3/search.
jira_create_issueCreate an issue via /rest/api/3/issue (provide fields including project + issuetype + summary, plus any customfield_*).
jira_search_usersSearches users and returns accountId candidates via /rest/api/3/user/search.
jira_resolve_user_account_idResolves a best-match user and returns the chosen accountId (useful for user picker custom fields).
jira_get_issueFetches an issue via /rest/api/3/issue/{key}.
jira_update_issue_fieldsUpdates issue fields via /rest/api/3/issue/{key} PUT.
Supports customfield_* updates
Supports sending raw ADF JSON for ADF-backed fields (e.g., description and some multi-line custom fields)
Includes optional flags:
notifyUsers
overrideScreenSecurity
overrideEditableFlag
validateAdf (default true)
jira_add_commentAdd a comment via /rest/api/3/issue/{key}/comment (wrapper accepts plain text or ADF doc).
jira_get_transitionsList available transitions via /rest/api/3/issue/{key}/transitions.
jira_transition_issueApply a transition via /rest/api/3/issue/{key}/transitions (use jira_get_transitions to find transitionId).
jira_bulk_create_issuesBulk create issues via POST /rest/api/3/issue/bulk.
Input is an array of issueUpdates entries, each with:
fields: issue creation fields (must include project, issuetype, summary, etc.)
update (optional): Jira update object
jira_bulk_get_editable_fieldsGet the bulk-editable field IDs for a set of issues via GET /rest/api/3/bulk/issues/fields.
Use the returned field IDs as selectedActions for jira_bulk_edit_issues.
jira_bulk_edit_issuesBulk edit issues via POST /rest/api/3/bulk/issues/fields.
Requires:
selectedIssueIdsOrKeys: issue IDs or keys to edit
selectedActions: field IDs to edit (use jira_bulk_get_editable_fields)
editedFieldsInput: object containing values to apply (must align with selectedActions)
customfield_10246)Resolve accountId:
call jira_resolve_user_account_id with query="you@company.com"
Update the issue:
call jira_update_issue_fields with:
issueKey="WOR-2367"
fields={ "customfield_10246": { "accountId": "<accountId>" } }
If your local record already stores ADF JSON, send it directly as the field value (must include type:"doc", version, and content).
Jira Cloud frequently does not expose email addresses in API responses depending on org privacy settings. This wrapper supports resolving by display name as a fallback.
For many “people picker” fields, Jira Cloud expects accountId (not email).
Add a comment to an issue via /rest/api/3/issue/{key}/comment. Body may be plain string or ADF doc object.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Comment body: plain text string or ADF doc object | |
| issueKey | Yes | Issue key, e.g. WOR-2367 | |
| validateAdf | No | If true and body is object-like, validate it as an ADF doc |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description only mentions body formats and API endpoint. It fails to disclose return value, error cases, permissions, or idempotency. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. Efficiently conveys core purpose and key detail about body format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers basic operation and parameter formats but lacks usage guidance and behavioral details. For a simple tool, it's minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so schema already documents parameters. Description adds marginal value by restating body options but no new insights beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'add', resource 'comment to an issue', includes API endpoint, and distinguishes from sibling tools like jira_create_issue or jira_update_issue_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives. The description implies usage for adding comments but lacks context on when not to use or comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk create issues via POST /rest/api/3/issue/bulk. Provide issueUpdates entries containing fields (and optional update).
| Name | Required | Description | Default |
|---|---|---|---|
| validateAdf | No | If true, validates any ADF-like objects inside each issue fields object | |
| issueUpdates | Yes | Issues to create (Jira Cloud limit is typically 50 per request) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions HTTP POST (mutating) and bulk creation, but omits details on error handling, partial failures, rate limits, or required authentication. The schema includes a max limit of 50, but this is not 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loaded with the action. It is efficient but could benefit from additional context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of bulk creation (nested objects, up to 50 issues), the description is too minimal. It fails to explain required fields, error behavior, or return values. The input schema provides some detail, but the description adds little context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description restates the input structure ('issueUpdates entries containing fields and optional update') without adding new meaning or explaining object formats like valid fields or ADF validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: 'Bulk create issues via POST /rest/api/3/issue/bulk'. The verb 'create' and resource 'issues' are specific, and the sibling tool 'jira_create_issue' for single creation makes the bulk nature distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for bulk creation but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, e.g., using 'jira_create_issue' for single issues or 'jira_bulk_edit_issues' for editing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk edit issues via POST /rest/api/3/bulk/issues/fields. You must provide selectedIssueIdsOrKeys, selectedActions (field IDs), and editedFieldsInput.
| Name | Required | Description | Default |
|---|---|---|---|
| validateAdf | No | If true, validates any ADF-like objects inside editedFieldsInput | |
| selectedActions | Yes | Field IDs to be bulk edited (use jira_bulk_get_editable_fields to discover field IDs for your selected issues) | |
| editedFieldsInput | Yes | Object containing the new field values (must align to selectedActions) | |
| sendBulkNotification | No | Whether Jira should send a bulk change notification email | |
| selectedIssueIdsOrKeys | Yes | Issue IDs or keys to bulk edit (Jira limit is typically 1000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'bulk edit' without disclosing side effects, limits (though schema shows max 1000 items), or whether the operation is destructive. It fails to warn about notification behavior or validation, which are exposed in schema but not highlighted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and endpoint, and includes the most critical required parameters. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal given the tool's complexity (5 params, nested objects, no output schema). It does not explain return values, error conditions, or how the bulk operation behaves (e.g., partial success). With no annotations, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds value by recommending jira_bulk_get_editable_fields to discover field IDs, which is not in the schema. This extra guidance improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('bulk edit issues'), the HTTP method and endpoint, and explicitly lists the three required parameters. It distinguishes from siblings like jira_bulk_create_issues and jira_update_issue_fields by indicating this is a bulk operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions required inputs but does not provide explicit guidance on when to use this tool versus single-issue editing or other bulk operations. It implies usage by stating 'bulk edit', but lacks direct comparison or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get bulk-editable field IDs for a set of issues via GET /rest/api/3/bulk/issues/fields. Use the returned field IDs in selectedActions for jira_bulk_edit_issues.
| Name | Required | Description | Default |
|---|---|---|---|
| searchText | No | Optional search text filter | |
| endingBefore | No | Pagination cursor | |
| startingAfter | No | Pagination cursor | |
| issueIdsOrKeys | Yes | Issue IDs or keys to calculate bulk-editable fields for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions the endpoint and that it returns field IDs, but it does not disclose whether the operation is read-only, required permissions, rate limits, error handling, or any side effects. The description is too minimal for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences with no wasted words. It front-loads the action and resource, and then provides a clear link to the next step. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema, no annotations), the description is lacking. It does not explain the return structure, specify that it is a read-only operation, or provide enough context for an agent to decide when to use this tool confidently over alternatives. The description is functional but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description does not add additional meaning beyond what the schema provides (e.g., explaining searchText or pagination cursors). It only implicitly references the required parameter 'issueIdsOrKeys' via context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('bulk-editable field IDs for a set of issues'). It also references the HTTP endpoint and mentions the complementary tool (jira_bulk_edit_issues), which helps contextualize the purpose. However, it does not explicitly differentiate from siblings like jira_update_issue_fields or jira_list_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates that this tool should be used to obtain field IDs for bulk editing, and its output is intended for jira_bulk_edit_issues. However, it does not provide explicit when-not-to-use guidance or mention alternatives (e.g., for single issue editing). The usage context is implied but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an issue via /rest/api/3/issue. Supply fields including project + issuetype and any customfield_* values (including ADF docs).
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Issue fields for creation (must include project and issuetype) | |
| validateAdf | No | If true, validates any ADF-like objects contain type/version/content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations. Description discloses API endpoint and support for ADF docs but no behavioral traits like rate limits, auth requirements, or side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and endpoint. Concise but could be structured with separate sentences for required vs optional info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output schema, no explanation of return values (e.g., issue key/ID). Does not elaborate on validateAdf or error handling. Adequate but incomplete for a complex creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by specifying required fields (project, issuetype) and custom field support, including ADF format. Schema already describes both parameters but this clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action (create) and resource (Jira issue). Mentions required fields (project, issuetype) and optional custom fields/ADF. However, does not distinguish from bulk creation or update siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives like bulk_create or update. No prerequisites or context provided. Only mentions which fields to supply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a Jira issue by key using /rest/api/3/issue/{key}. You can request specific fields/expand to reduce payload.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Optional expand list, e.g. ["names","schema","renderedFields","operations"] | |
| fields | No | Optional list of fields (names or IDs) to include | |
| issueKey | Yes | Issue key, e.g. WOR-2367 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description discloses it's a read-only fetch with optional payload reduction via fields/expand. No contradictions. Could mention return format but adequate for a get operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key action and endpoint, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool, description covers essential: fetch by key, optional field selection. Lacks mention of default return behavior but not critical for a get operation. No output schema, but not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by explaining purpose of fields/expand parameters ('to reduce payload'), which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a Jira issue by key', specifying the exact endpoint and verb. It distinguishes from sibling 'jira_search_issues_jql' which searches rather than fetches by key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you have an issue key. But no explicit guidance on when not to use (e.g., searching) or comparison to alternatives like jira_search_issues_jql.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available transitions for an issue via /rest/api/3/issue/{key}/transitions.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Optional expand list | |
| issueKey | Yes | Issue key, e.g. WOR-2367 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only mentions the API endpoint without clarifying permissions, error handling, or side effects (though it's read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded, but it could benefit from a bit more structure, such as listing the return type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with full schema coverage and no output schema, the description is minimally adequate but lacks information about the output structure (e.g., array of transitions with statuses).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it repeats the API path but does not elaborate on parameter syntax or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'available transitions for an issue', which is specific and distinguishes it from siblings like 'jira_transition_issue' that performs transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'jira_get_issue' or 'jira_transition_issue'. The description is minimal and implies usage only by naming the endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Jira fields (including customfield_*) from /rest/api/3/field. Use this to map friendly names to field IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional case-insensitive substring filter applied to field name and id | |
| includeSchema | No | Include schema metadata if present |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, potential size of output, or rate limits. For a listing tool, stating it is non-destructive would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first sentence states the core functionality and API endpoint; the second provides a concrete use case. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a simple list tool with good schema coverage and no output schema, the description is mostly complete. It covers purpose, resource, and use case. It could mention that the output contains all fields (limited by filter) and that it's read-only.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters well (case-insensitive filter, optional schema metadata). The description adds overarching context ('including customfield_*') but does not enhance meaning of individual parameters beyond what the schema provides. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('Jira fields including customfield_* from /rest/api/3/field'). It provides a specific use case ('map friendly names to field IDs'). While it doesn't explicitly differentiate from siblings, the sibling tools are mostly issue/comment operations, so it's reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case ('use this to map friendly names to field IDs'), which guides the agent. However, it does not mention when not to use it (e.g., if you need field details by project) or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a single best-match Jira user and return accountId (for setting user picker custom fields). Uses /rest/api/3/user/search and selects the best candidate.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Email or name to resolve | |
| includeInactive | No | If true, allow inactive users | |
| requireEmailMatch | No | If true, prefers exact email match when emailAddress is present |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions using the /rest/api/3/user/search API and selecting the best candidate, which gives some insight but lacks details on matching logic, error handling, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 24 words, front-loading the key action ('Resolve a single best-match Jira user and return accountId') and providing only essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the main purpose and key parameters, it lacks output schema and does not explain failure behavior (e.g., no match found) or return format beyond 'accountId.' For a simple resolver, this is somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described in the schema. The description does not add additional meaning beyond the schema; it merely restates the purpose. Thus, score at baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a single best-match Jira user and returns an accountId, specifically for setting user picker custom fields. It mentions the API endpoint used and that it selects the best candidate, which differentiates it from sibling tools like jira_search_users that return multiple users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool ('for setting user picker custom fields') and implies it's for a single best match, contrasting with search tools. However, it does not explicitly name alternative tools or state 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.
Search issues using JQL via /rest/api/3/search. Returns a page of issues with selected fields.
| Name | Required | Description | Default |
|---|---|---|---|
| jql | Yes | JQL query (e.g. project=WOR AND key=WOR-2367) | |
| expand | No | Optional expand list | |
| fields | No | Optional list of fields (names or IDs) to include | |
| startAt | No | Pagination start offset | |
| maxResults | No | Max results (1-100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries behavioral disclosure. It mentions the endpoint path and that it returns a page with selected fields, but lacks details on error handling, authentication needs, or rate limits. Basic transparency but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and endpoint, no fluff. Every sentence adds value. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (5 parameters, no output schema), the description is minimal. It explains return type (page of issues with selected fields) but not pagination details or error scenarios. Adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. The description adds no additional meaning beyond what the schema already provides for parameters. It briefly mentions 'selected fields' which relates to the fields parameter, but no deeper explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action 'search', resource 'issues', and method 'using JQL'. It distinguishes from sibling tools like jira_get_issue by specifying JQL-based search and returning a page of issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for searching issues with JQL but does not explicitly differentiate from alternatives like jira_get_issue or provide when-not-to-use guidance. Given the clear purpose, this is adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search users (returns accountId) using /rest/api/3/user/search. Use this to map email/displayName → accountId for user picker fields.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (email or name) | |
| maxResults | No | Max results (1-50) | |
| includeInactive | No | If true, do not filter out inactive users client-side |
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 the API endpoint and that it returns accountId, but does not disclose other behaviors like query matching behavior, pagination, rate limits, or authentication requirements. The schema covers parameters, so the description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with no wasted words. It front-loads the purpose and use case, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 parameters, no output schema, no nested objects), the description is adequate but could be improved by mentioning the output format (e.g., list of users with accountId and displayName). It does cover the key return value (accountId) and the use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so baseline is 3. The description does not add any additional meaning beyond what is already in the schema for the parameters. It does not elaborate on the query format beyond what is in the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches users and returns accountId, and provides a specific use case (mapping email/displayName to accountId for user picker fields). It implicitly distinguishes from sibling 'jira_resolve_user_account_id' which likely operates on a known accountId.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to map email/displayName → accountId for user picker fields', providing a clear when-to-use scenario. It does not explicitly mention when not to use, but the context of siblings and the specific use case give enough guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transition an issue via /rest/api/3/issue/{key}/transitions. Provide a transition id (use jira_get_transitions first).
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Optional fields to set during transition | |
| update | No | Optional update object to apply during transition | |
| issueKey | Yes | Issue key, e.g. WOR-2367 | |
| transitionId | Yes | Transition id to apply |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning whether the transition is destructive, what side effects occur, or any required permissions. This is insufficient for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the core action and prerequisite. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the core purpose is clear and the schema covers parameters, the description lacks information about return values, error handling, or state changes. For a mutation tool without output schema, this is a notable gap, but the essential context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description adds minimal value by mentioning the transition ID requirement, but does not elaborate on the 'fields' or 'update' objects. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'transition' and identifies the resource 'issue'. It explicitly mentions the API endpoint and provides a direct link to the sibling tool jira_get_transitions, clearly distinguishing this tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool: to transition an issue. It provides explicit guidance to use jira_get_transitions first to obtain the transition ID, which is essential for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update Jira issue fields via /rest/api/3/issue/{key} PUT. Supports customfield_* and ADF docs. You must send correct field IDs and value shapes (e.g. user picker needs accountId).
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Fields object to set (e.g. { "customfield_10246": { accountId: "..." } }) | |
| update | No | Optional Jira "update" object for advanced updates | |
| issueKey | Yes | Issue key, e.g. WOR-2367 | |
| notifyUsers | No | Whether to notify users (Jira notifyUsers query param) | |
| validateAdf | No | If true, validates any ADF-like objects contain type/version/content | |
| overrideEditableFlag | No | Attempt to override editable flag (if permitted) | |
| overrideScreenSecurity | No | Attempt to override screen security (if permitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It confirms the tool mutates data ('Update') and mentions requirements for field IDs and value shapes, but lacks details on idempotency, validation, error handling, permissions, or response behavior. The caution about user picker requiring accountId adds some transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences. The first states the core action, the second lists supported features, and the third gives critical usage advice. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, no output schema), the description is somewhat incomplete. It does not explain return values or whether the tool returns the updated issue, nor does it mention prerequisites like issue existence or authorization needs. It covers the main action but lacks broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description enhances parameter semantics by providing a concrete example ('user picker needs accountId') and warning about correct field IDs and ADF docs. This adds value beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'Jira issue fields'. It mentions the specific API endpoint and supported field types (customfield_*, ADF docs), which distinguishes it from siblings like jira_create_issue or jira_get_issue. However, it does not contrast with jira_bulk_edit_issues, but the singular focus is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating single issue fields but does not explicitly state when to use this tool versus alternatives like jira_bulk_edit_issues. It provides cautionary guidance about correct field IDs and value shapes, but no explicit when-to-use/when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0jira_add_commentjira_bulk_create_issuesjira_bulk_edit_issuesjira_bulk_get_editable_fieldsjira_create_issuejira_get_issuejira_get_transitionsjira_list_fieldsjira_resolve_user_account_idjira_search_issues_jqljira_search_usersjira_transition_issuejira_update_issue_fieldsEach tool targets a distinct action on Jira resources. Single and bulk operations are clearly separated, and user-related tools (search_users vs resolve_user_account_id) have distinct purposes. No two tools appear to do the same thing.
All tools follow a consistent 'jira_verb_noun' pattern using snake_case. Verbs are uniform (add, bulk_create, bulk_edit, create, get, list, resolve, search, transition, update), and bulk operations are prefixed with 'bulk_'. The naming is predictable and easy to understand.
With 13 tools, the server covers core Jira issue operations without being overwhelming. The number is well within the ideal range (3-15) and each tool addresses a specific need, from CRUD to searching and user resolution.
The tool surface covers creation (single and bulk), reading, updating, commenting, searching, and transitions. Missing delete functionality is a notable gap, but the set is sufficient for most issue management workflows. Overall, it is well-scoped for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
MCP Server for JFrog, providing tools for development and artifact management.
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jarekbird/jira-api-mcp-wrapper'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
