MCP tool addCommentToJiraIssue cannot create or update public comments

I’m currently trying to use my agent with Rovo MCP to create issues and post comments on them. Currently, the addCommentToJiraIssue tool has a bug that prevents creating a public comment on issue.

As my agent is one that is interfacing with the MCP server, I’ve asked it to describe the issue. I am pasting the description below.


addCommentToJiraIssue cannot create or update public comments

Summary

The rovo-dsrdsr_addCommentToJiraIssue MCP tool cannot create or update an unrestricted public Jira comment. Its input schema requires commentVisibility, but that field only accepts group or role. Jira represents a public comment by omitting visibility entirely. The tool therefore has no valid input that represents a public comment. The schema also requires commentId, although the tool description says it should be omitted when creating a comment.

Environment

  • Jira Cloud site: dsrdsr.atlassian.net
  • Jira REST API: v3
  • Example issue: DSRCAT-6
  • Tool: rovo-dsrdsr_addCommentToJiraIssue

Relevant schema

{
  "cloudId": "string",
  "issueIdOrKey": "string",
  "commentBody": "string",
  "commentVisibility": {
    "type": "group | role",
    "value": "string"
  },
  "contentFormat": "markdown | adf",
  "responseContentFormat": "markdown | adf",
  "commentId": "string"
}

Both commentVisibility and commentId are marked as required.

Expected behavior

Creating a public comment should allow this request:

{
  "cloudId": "<cloud-id>",
  "issueIdOrKey": "DSRCAT-6",
  "commentBody": "Public comment",
  "contentFormat": "markdown",
  "responseContentFormat": "markdown"
}

The tool should omit Jira’s visibility property when commentVisibility is absent. Updating an existing public comment should also preserve its missing visibility:

{
  "cloudId": "<cloud-id>",
  "issueIdOrKey": "DSRCAT-6",
  "commentId": "482246",
  "commentBody": "Updated public comment",
  "contentFormat": "markdown",
  "responseContentFormat": "markdown"
}

Actual behavior

The tool requires a visibility object. Passing an empty role value:

{
  "commentVisibility": {
    "type": "role",
    "value": ""
  }
}

fails with:

Failed to add comment: Bad Request.
Role with id: does not exist.

The same failure occurs when updating an existing public comment. Using a placeholder such as null, -1, or a guessed role ID causes Jira to look for a role with that ID:

Role with id: null does not exist.
Role with id: -1 does not exist.
Role with id: 10000 does not exist.

Trying group visibility fails when the Jira site disables group-restricted comments:

GROUP_VISIBILITY_SETTING_NOT_ENABLED
Group level visibility has been disabled.

Confirmation that the existing comment is public

Reading comment 482246 from DSRCAT-6 returns:

{
  "id": "482246",
  "jsdPublic": true
}

It contains no visibility field. This confirms that public visibility is represented by the absence of a restriction, which the tool schema cannot express.

Secondary schema problem

commentId is required even though its description says:

ID of an existing comment to update. If omitted, a new comment is added.

A required field cannot be omitted. Callers must currently pass an empty string when creating a comment, which conflicts with the documented contract.

Impact

  • Agents cannot add public Jira comments.
  • Agents cannot update existing public comments while preserving visibility.
  • Sites with group restrictions disabled cannot use a group as a workaround.
  • Callers must guess project-role IDs or create unnecessarily restricted comments.
  • Automated issue triage cannot attach public agent briefs.

Requested fix

  1. Make commentVisibility optional.
  2. When it is absent, omit Jira’s visibility property and create or preserve a public comment.
  3. Make commentId optional.
  4. When commentId is absent, create a new comment.
  5. When commentId is present, update that comment.
  6. Add tests for:
    • Creating a public comment.
    • Updating a public comment.
    • Creating a role-restricted comment.
    • Creating a group-restricted comment where enabled.
    • Rejecting an unknown role or group with a clear error.

Hi @MikoajNowak,

The Jira side imposes none of this, which matters because the fix you want needs no REST API change.

In the v3 platform spec the Comment schema has no required array at all, and visibility is annotated “Optional on create and update”. The Visibility type enum really is only group and role, so absence is the only representation of unrestricted. Update takes the same schema, so preserving a public comment on edit also means omitting the field.

Your confirmation section is the part I’d push back on. jsdPublic doesn’t prove it. Per the spec it defaults to true for comments created through the platform API, including on sites with no Service Desk and projects that aren’t JSM at all. A role-restricted comment reads the same. The line carrying your claim is the next one: no visibility key.

I’d grab the raw inputSchema from your client before filing. What you pasted is your agent’s description of it, and that has no required array in it either.

Different axis, same word: 100592 from May. JSM internal notes need servicedeskapi.