Skip to main content
Glama

add_jira_comment

Add a comment to a Jira issue by specifying the issue key and comment text, enabling efficient issue tracking and collaboration through the Jira MCP Server.

Instructions

Add a comment to a Jira issue

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commentYesThe comment text
issue_keyYesThe issue key (e.g., PROJECT-123)

Implementation Reference

  • The main handler function that executes the 'add_jira_comment' tool logic. It uses the JiraV3APIClient to add a comment to the specified issue and processes the response.
    async def add_jira_comment(self, issue_key: str, comment: str) -> Dict[str, Any]:
        """Add a comment to an issue using v3 REST API"""
        logger.info("Starting add_jira_comment...")
    
        try:
            # Use v3 API client
            v3_client = self._get_v3_api_client()
            comment_result = await v3_client.add_comment(
                issue_id_or_key=issue_key,
                comment=comment,
            )
    
            # Extract useful information from the v3 API response
            response_data = {
                "id": comment_result.get("id"),
                "body": comment_result.get("body", {}),
                "created": comment_result.get("created"),
                "updated": comment_result.get("updated"),
            }
    
            # Extract author information if available
            if "author" in comment_result:
                author = comment_result["author"]
                response_data["author"] = author.get("displayName", "Unknown")
            else:
                response_data["author"] = "Unknown"
    
            logger.info(f"Successfully added comment to issue {issue_key}")
            return response_data
    
        except Exception as e:
            error_msg = (
                f"Failed to add comment to {issue_key}: {type(e).__name__}: {str(e)}"
            )
            logger.error(error_msg, exc_info=True)
            print(error_msg)
            raise ValueError(error_msg)
  • The input schema definition for the 'add_jira_comment' tool, specifying required parameters: issue_key and comment.
    Tool(
        name=JiraTools.ADD_COMMENT.value,
        description="Add a comment to a Jira issue",
        inputSchema={
            "type": "object",
            "properties": {
                "issue_key": {
                    "type": "string",
                    "description": "The issue key (e.g., PROJECT-123)",
                },
                "comment": {
                    "type": "string",
                    "description": "The comment text",
                },
            },
            "required": ["issue_key", "comment"],
        },
    ),
  • The registration and dispatch logic in the call_tool handler that routes calls to 'add_jira_comment' to the appropriate method.
    case JiraTools.ADD_COMMENT.value:
        logger.info("About to AWAIT jira_server.add_jira_comment...")
        issue_key = arguments.get("issue_key")
        comment_text = arguments.get("comment") or arguments.get("body")
        if not issue_key or not comment_text:
            raise ValueError(
                "Missing required arguments: issue_key and comment (or body)"
            )
        result = await jira_server.add_jira_comment(issue_key, comment_text)
        logger.info("COMPLETED await jira_server.add_jira_comment.")
  • Low-level helper function in JiraV3APIClient that makes the actual HTTP POST request to Jira's v3 REST API to add a comment, formatting the comment in ADF and handling the response.
    async def add_comment(
        self,
        issue_id_or_key: str,
        comment: str,
        visibility: Optional[Dict[str, str]] = None,
        properties: Optional[list] = None,
    ) -> Dict[str, Any]:
        """
        Add a comment to an issue using the v3 REST API.
    
        Args:
            issue_id_or_key: Issue ID or key (required)
            comment: Comment text to add (required)
            visibility: Optional visibility settings (e.g., {"type": "role", "value": "Administrators"})
            properties: Optional list of properties to set
    
        Returns:
            Dict containing comment details:
            - id: Comment ID
            - body: Comment body in ADF format
            - author: Author information
            - created: Creation timestamp
            - updated: Last update timestamp
            - etc.
    
        Raises:
            ValueError: If required parameters are missing or comment creation fails
        """
        if not issue_id_or_key:
            raise ValueError("issue_id_or_key is required")
    
        if not comment:
            raise ValueError("comment is required")
    
        # Build the request payload with ADF format
        payload = {
            "body": {
                "type": "doc",
                "version": 1,
                "content": [
                    {
                        "type": "paragraph",
                        "content": [{"type": "text", "text": comment}],
                    }
                ],
            }
        }
    
        # Add optional visibility
        if visibility:
            payload["visibility"] = visibility
    
        # Add optional properties
        if properties:
            payload["properties"] = properties
    
        endpoint = f"/issue/{issue_id_or_key}/comment"
        logger.debug(f"Adding comment to issue {issue_id_or_key} with v3 API endpoint: {endpoint}")
        response_data = await self._make_v3_api_request("POST", endpoint, data=payload)
        logger.debug(f"Add comment API response: {json.dumps(response_data, indent=2)}")
        return response_data
  • Enum definition that registers the tool name 'add_jira_comment' as ADD_COMMENT.
    class JiraTools(str, Enum):
        GET_PROJECTS = "get_jira_projects"
        GET_ISSUE = "get_jira_issue"
        SEARCH_ISSUES = "search_jira_issues"
        CREATE_ISSUE = "create_jira_issue"
        CREATE_ISSUES = "create_jira_issues"
        ADD_COMMENT = "add_jira_comment"
        GET_TRANSITIONS = "get_jira_transitions"
        TRANSITION_ISSUE = "transition_jira_issue"
        CREATE_PROJECT = "create_jira_project"
        GET_PROJECT_ISSUE_TYPES = "get_jira_project_issue_types"
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. While 'Add a comment' implies a write operation, it doesn't specify permission requirements, whether comments are editable/deletable, rate limits, or what happens on success/failure. This leaves significant behavioral gaps for a mutation tool.

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, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for a simple tool and front-loads the essential information.

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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral constraints. While the schema covers parameters well, the overall context for using this tool remains incomplete.

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 has 100% description coverage, with both parameters clearly documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema (e.g., no format examples beyond 'PROJECT-123', no character limits, no mention of optional fields). Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Add a comment') and target resource ('to a Jira issue'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'create_jira_issue' or 'transition_jira_issue' beyond the obvious comment-focused functionality.

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 about when to use this tool versus alternatives. There's no mention of prerequisites (like needing an existing issue), when not to use it, or how it relates to sibling tools such as 'create_jira_issue' for initial issue creation or 'transition_jira_issue' for status changes.

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

Related 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/InfinitIQ-Tech/mcp-jira'

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