Skip to main content
Glama
vish288

mcp-atlassian-extended

by vish288
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Jira Create Issue

jira_create_issue

Create Jira issues with standard or custom fields, including epics. Specify project, summary, issue type, and custom field IDs to capture all required data.

Instructions

Create a Jira issue with standard and custom fields.

Pass issue_type="Epic" to create an epic; set your instance's Epic Name custom field through custom_fields (e.g. {"customfield_10009": "My Epic"}).

custom_fields example: {"customfield_10004": 5, "customfield_12345": {"value": "MyTeam"}}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
labelsNoLabels to set
summaryYesIssue title/summary
priorityNoPriority name
issue_typeNoIssue type nameStory
descriptionNoIssue description
project_keyYesProject key (e.g. PROJ)
custom_fieldsNoCustom fields dict — keys are customfield_NNNNN IDs. Use jira_list_fields to discover IDs for your instance.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.15.1
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null
  2. First observedv0.6.13

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the write/open-world nature is covered. The description adds genuinely useful behavior beyond that: epics need an instance-specific Epic Name custom field, and custom_fields takes typed values like {"value": "MyTeam"}. It omits any statement about side effects (notifications, watchers) or what is returned, so it goes beyond annotations but not far.

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?

Three short lines, front-loaded with the core action and followed by the two highest-value edge cases, using inline code for exact syntax. Nothing is padded, though the Epic paragraph and custom_fields example are somewhat tersely juxtaposed without a clear connective.

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

Completeness3/5

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

No output schema exists, yet the description never says what a successful create returns (presumably an issue key/ID), which an agent needs to chain follow-up calls like jira_update_issue. Parameter coverage is otherwise solid, so the gap is narrow but real for a mutation tool.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining non-obvious semantics the schema cannot: the special issue_type="Epic" branch requires an Epic Name custom field, and custom_fields entries can be scalars or nested {"value": ...} objects. It also points at jira_list_fields for discovering IDs, which is real added meaning.

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?

States a specific verb and resource ("Create a Jira issue") and scopes it to standard and custom fields, which distinguishes it naturally from jira_update_issue and jira_create_version. It stops short of explicitly naming a sibling or clarifying boundaries, so it is clear but not maximally differentiating.

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 Epic note is really the only usage guidance: use issue_type="Epic" and set the Epic Name via custom_fields. There is no statement of when to prefer this tool over alternatives, no prerequisites (project access, required fields per issue type), and no sizing or rate-limit context; usage is implied rather than prescribed.

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

Deploy Server

Other Tools