Skip to main content
Glama

update_jira_issue

Modify existing JIRA issues by updating fields like summary, description, assignee, and issue type through the MCP JIRA Server.

Instructions

Updates an existing JIRA issue. Only provided fields will be updated.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
issue_keyYes
summaryNo
descriptionNo
issue_typeNo
site_aliasNo
assigneeNo
additional_fieldsNo

Implementation Reference

  • MCP tool handler: update_jira_issue_tool - the main execution function for the tool, including error handling and response formatting. Calls the core business logic.
    @mcp_server.tool(
        name="update_jira_issue",
        description="Updates an existing JIRA issue. Only provided fields will be updated.",
    )
    def update_jira_issue_tool(
        issue_key: str,  # Required - which issue to update
        summary: str = None,
        description: str = None,  # This will be Markdown input
        issue_type: str = None,
        site_alias: str = None,
        assignee: str = None,
        additional_fields: Dict[str, Any] = None  # For future flexibility
    ) -> types.TextContent:
        """
        Update an existing JIRA issue with markdown description converted to ADF.
        Only provided (non-None) fields will be updated.
        """
        logger.debug(
            f"update_jira_issue_tool received: issue_key={issue_key}, summary={summary is not None}, "
            f"description={description is not None}, issue_type={issue_type}, site_alias={site_alias}, "
            f"assignee={assignee}, additional_fields_present={additional_fields is not None}"
        )
        try:
            # Call the business logic function directly
            result = jira_tools.update_jira_issue(
                issue_key=issue_key,
                summary=summary,
                description=description,
                issue_type=issue_type,
                site_alias=site_alias,
                assignee=assignee,
                additional_fields=additional_fields,
                server_config=config
            )
            
            logger.info(f"JIRA issue update result: {result}")
    
            issue_key_result = result.get('key')
            updated_fields = result.get('updated_fields', [])
            browse_url = result.get('url', "N/A")
    
            return types.TextContent(
                type="text",
                text=f"Successfully updated JIRA issue: {issue_key_result}. Updated fields: {', '.join(updated_fields)}. URL: {browse_url}",
                format="text/plain"
            )
        except JiraServiceError as e:
            logger.error(f"JiraServiceError in update_jira_issue_tool: {e}", exc_info=True)
            return types.TextContent(
                type="text",
                text=f"Error updating JIRA issue: {e}",
                format="text/plain"
            )
        except Exception as e:
            logger.error(f"Unexpected error in update_jira_issue_tool: {e}", exc_info=True)
            return types.TextContent(
                type="text",
                text=f"An unexpected error occurred: {e}",
                format="text/plain"
            )
  • Registration of the 'update_jira_issue' tool with the MCP server using the @mcp_server.tool decorator.
    @mcp_server.tool(
        name="update_jira_issue",
        description="Updates an existing JIRA issue. Only provided fields will be updated.",
    )
  • Core helper function implementing the JIRA issue update logic using JiraClient, called by the MCP handler.
    def update_jira_issue(
        issue_key: str,
        summary: Optional[str] = None,
        description: Optional[str] = None, 
        issue_type: Optional[str] = None,
        site_alias: Optional[str] = None,
        assignee: Optional[str] = None,
        additional_fields: Optional[Dict[str, Any]] = None,
        server_config: Optional[ServerConfig] = None
    ) -> Dict[str, Any]:
        """
        Update an existing JIRA issue. Only provided fields will be updated.
        
        Args:
            issue_key: The issue key to update (e.g., 'ABC-123')
            summary: Optional new summary
            description: Optional new description in markdown format
            issue_type: Optional new issue type
            site_alias: Optional site alias for multi-site configurations
            assignee: Optional new assignee email address
            additional_fields: Optional dict of additional JIRA fields to update
            server_config: Server configuration object
            
        Returns:
            Dict containing updated issue information (key, updated_fields, url)
            
        Raises:
            JiraServiceError: If issue update fails
        """
        try:
            # Get active JIRA site configuration
            active_site_config = get_active_jira_config(alias=site_alias, server_config=server_config)
            
            # Create JiraClient instance
            jira_client = JiraClient(site_config=active_site_config)
            
            # Update the issue
            result = jira_client.update_issue(
                issue_key=issue_key,
                summary=summary,
                description=description,  # Will be converted to ADF by JiraClient if provided
                issue_type=issue_type,
                assignee=assignee,
                **(additional_fields or {})
            )
            
            return result
            
        except JiraServiceError:
            # Re-raise JiraServiceError as-is
            raise
        except Exception as e:
            # Wrap unexpected errors
            raise JiraServiceError(f"Unexpected error updating JIRA issue: {e}")
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Only provided fields will be updated,' which adds useful context about partial updates. However, it lacks critical behavioral details: it doesn't specify if this is a mutation requiring permissions, what happens on success/failure, rate limits, or authentication needs. For a mutation tool with 7 parameters, this is a significant gap.

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 extremely concise with two sentences that are front-loaded and waste-free. Every word earns its place by stating the core action and a key behavioral constraint. No unnecessary details or redundancy are present.

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 high complexity (7 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It lacks details on return values, error handling, permissions, and parameter meanings. For a mutation tool with significant schema complexity, this minimal description leaves too many gaps for effective agent use.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only vaguely references 'fields' without explaining what fields are updatable or their semantics (e.g., 'issue_key' as identifier, 'additional_fields' for custom fields). This adds minimal value beyond the schema's property names, failing to adequately address the coverage gap.

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 verb ('Updates') and resource ('an existing JIRA issue'), making the purpose immediately understandable. It distinguishes from 'create_jira_issue' by specifying 'existing' issue. However, it doesn't explicitly differentiate from potential sibling tools like 'search_jira_issues' in terms of update vs. read operations.

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 like 'create_jira_issue' or 'search_jira_issues'. There's no mention of prerequisites (e.g., needing an existing issue key), appropriate contexts, or when not to use it. The only implied usage is updating fields, but no explicit alternatives or exclusions are stated.

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/codingthefuturewithai/mcp_jira'

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