Skip to main content
Glama

update_issue

Modify existing Jira issues by updating fields like summary, description, priority, assignee, labels, and custom fields to reflect current status or requirements.

Instructions

Update fields of an existing Jira issue. TIP: Use get_create_metadata to discover available custom fields and their allowed values for the project.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
issueKeyYesThe issue key to update (e.g., PROJ-123)
summaryNoNew summary/title - optional
descriptionNoNew description in ADF format or plain string - optional
priorityNoNew priority name - optional
assigneeNoNew assignee account ID or email (will auto-lookup account ID from email) - optional
labelsNoNew labels array - optional
customFieldsNoCustom fields as key-value pairs (e.g., {"customfield_10000": "value"}) - optional. Use get_create_metadata to discover available fields.

Implementation Reference

  • Core implementation of the `update_issue` tool handler. Parses arguments, validates required `issueKey`, builds update payload handling ADF description conversion, assignee resolution via userHandlers, labels, custom fields; performs API PUT request and returns formatted success or error response.
    async handleUpdateIssue(args: any) {
      try {
        const { issueKey, summary, description, priority, assignee, labels, customFields } = args;
    
        if (!issueKey) {
          throw new Error('issueKey is required');
        }
    
        const updateData: any = { fields: {} };
    
        if (summary) updateData.fields.summary = summary;
    
        // Handle description - convert to ADF format if it's plain text
        if (description) {
          if (typeof description === 'string') {
            // Convert plain text to Atlassian Document Format
            updateData.fields.description = {
              type: 'doc',
              version: 1,
              content: [
                {
                  type: 'paragraph',
                  content: [
                    {
                      type: 'text',
                      text: description,
                    },
                  ],
                },
              ],
            };
          } else {
            // Already in ADF format
            updateData.fields.description = description;
          }
        }
    
        if (priority) updateData.fields.priority = { name: priority };
    
        if (assignee) {
          // Auto-resolve email to account ID if needed
          const accountId = await this.userHandlers.resolveUserToAccountId(assignee);
          updateData.fields.assignee = { id: accountId };
        }
    
        if (labels) updateData.fields.labels = labels;
    
        // Merge custom fields
        if (customFields && typeof customFields === 'object') {
          Object.assign(updateData.fields, customFields);
        }
    
        if (Object.keys(updateData.fields).length === 0) {
          throw new Error('At least one field to update must be provided');
        }
    
        await this.apiClient.put(`/issue/${issueKey}`, updateData);
    
        return {
          content: [
            {
              type: 'text',
              text: `✅ Issue ${issueKey} updated successfully!`,
            },
          ],
        };
      } catch (error: any) {
        return {
          content: [
            {
              type: 'text',
              text: JiraFormatters.formatError(error),
            },
          ],
          isError: true,
        };
      }
    }
  • Input schema definition for the `update_issue` tool, specifying properties like issueKey (required), optional fields for summary, description, priority, assignee, labels, customFields, with descriptions.
      name: 'update_issue',
      description: 'Update fields of an existing Jira issue. TIP: Use get_create_metadata to discover available custom fields and their allowed values for the project.',
      inputSchema: {
        type: 'object',
        properties: {
          issueKey: {
            type: 'string',
            description: 'The issue key to update (e.g., PROJ-123)',
          },
          summary: {
            type: 'string',
            description: 'New summary/title - optional',
          },
          description: {
            description: 'New description in ADF format or plain string - optional',
          },
          priority: {
            type: 'string',
            description: 'New priority name - optional',
          },
          assignee: {
            type: 'string',
            description: 'New assignee account ID or email (will auto-lookup account ID from email) - optional',
          },
          labels: {
            type: 'array',
            items: { type: 'string' },
            description: 'New labels array - optional',
          },
          customFields: {
            type: 'object',
            description: 'Custom fields as key-value pairs (e.g., {"customfield_10000": "value"}) - optional. Use get_create_metadata to discover available fields.',
          },
        },
        required: ['issueKey'],
      },
    },
  • src/index.ts:102-103 (registration)
    Registration of the `update_issue` tool in the MCP server's CallToolRequestSchema handler switch statement, dispatching to `issueHandlers.handleUpdateIssue`.
    case 'update_issue':
      return this.issueHandlers.handleUpdateIssue(request.params.arguments);
  • src/index.ts:90-92 (registration)
    Registration for listing tools via ListToolsRequestSchema, which includes the `update_issue` tool from `toolDefinitions`.
    this.server.setRequestHandler(ListToolsRequestSchema, async () => ({
      tools: toolDefinitions,
    }));
  • src/index.ts:70-71 (registration)
    Instantiation of IssueHandlers (containing handleUpdateIssue) in the JiraMCPServer constructor, passing apiClient and userHandlers dependencies.
    this.userHandlers = new UserHandlers(this.apiClient);
    this.issueHandlers = new IssueHandlers(this.apiClient, this.userHandlers);
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While it correctly identifies this as an update operation, it doesn't mention important behavioral aspects like what permissions are required, whether the update is atomic or partial, what happens to unspecified fields, or error conditions. The tip about custom fields adds some context but doesn't compensate for the lack of mutation-specific behavioral information.

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 appropriately brief with two sentences, both of which add value. The first sentence states the core purpose, and the second provides a practical tip. There's no wasted verbiage, though it could be slightly more structured with clearer separation between purpose and guidance.

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?

For a mutation tool with 7 parameters, no annotations, and no output schema, the description is minimally adequate. It identifies the operation type and provides one helpful tip, but doesn't address important contextual aspects like what the tool returns, error handling, or how it differs from similar mutation tools in the sibling set. The lack of output information is particularly notable given there's no output schema.

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?

The schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'fields' generally and provides a tip about custom fields, but doesn't explain parameter interactions, constraints, or provide additional semantic context that isn't already in the parameter descriptions.

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 ('Update fields') and resource ('existing Jira issue'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from similar siblings like 'assign_issue' or 'transition_issue' which also modify issues, missing the highest level of sibling distinction.

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 provides a helpful tip about using 'get_create_metadata' to discover custom fields, which gives some context about when this tool might be needed. However, it doesn't explicitly state when to use this tool versus alternatives like 'assign_issue' or 'transition_issue' for specific modifications, nor does it mention prerequisites or exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pdogra1299/jira-mcp-server'

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