Skip to main content
Glama
Sign In
atlassian-browser-mcp

atlassian-browser-mcp

by GeiserX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Add Comment

jira_add_comment

Adds Markdown comments to Jira issues, with optional visibility restrictions or JSM customer-facing/internal flags for Service Desk issues.

Instructions

Add a comment to a Jira issue.

Input Schema

NameRequiredDescriptionDefault
bodyYesComment text in Markdown format
publicNo(Optional) For JSM/Service Desk issues only. Set to true for customer-visible comment, false for internal agent-only comment. Posted via the ServiceDesk API as a raw string; Jira Cloud renders it server-side and stores ADF (markdown observed to render on Cloud, without the client-side markdown-to-ADF guarantees of the regular comment path). Cannot be combined with visibility. If the issue's project is listed in JIRA_INTERNAL_ONLY_PROJECTS, only public=false is accepted — public=true or omitting this field is rejected.
issue_keyYesJira issue key (e.g., 'PROJ-123', 'ACV2-642')
visibilityNo(Optional) Comment visibility as JSON string (e.g. '{"type":"group","value":"jira-users"}')

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.4.1
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / issue_key / pattern
      Previous value: -"^[A-Z][A-Z0-9_]+-\\d+$"New value: +"^[A-Z][A-Z0-9_]+-\\d+(?:-\\d+)*$"
    • changedInput schema / properties / public / description
      Previous value: -"(Optional) For JSM/Service Desk issues only. Set to true for customer-visible comment, false for internal agent-only comment. Uses the ServiceDesk API (plain text, not Markdown). Cannot be combined with visibility."New value: +"(Optional) For JSM/Service Desk issues only. Set to true for customer-visible comment, false for internal agent-only comment. Posted via the ServiceDesk API as a raw string; Jira Cloud renders it server-side and stores ADF (markdown observed to render on Cloud, without the client-side markdown-to-ADF guarantees of the regular comment path). Cannot be combined with visibility. If the issue's project is listed in JIRA_INTERNAL_ONLY_PROJECTS, only public=false is accepted — public=true or omitting this field is rejected."
    • removedOutput schema / description
      Removed value: -"Generic wrapper for non-object return types."
  2. Addedv1.0.1

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already disclose that this is a non-read-only, non-idempotent, open-world, non-destructive write operation. The description adds no behavioral context beyond the annotations, such as the JSM public flag semantics, internal-only project rejection rules, or markdown/ADF handling.

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 a single front-loaded sentence with no wasted words. It is efficient, though its extreme brevity leaves important usage context to the schema.

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?

Given the rich schema coverage and existing output schema, the description is minimally adequate for a simple comment-adding call. However, for a tool with meaningful JSM visibility constraints and a sibling edit tool, it omits context that would help an agent choose and invoke it confidently.

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?

Schema description coverage is 100%, so the schema itself fully documents issue_key, body, public, and visibility. The description adds no parameter meaning beyond what the schema already provides, which matches the baseline of 3 for high-coverage schemas.

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 states a specific verb and resource: "Add a comment to a Jira issue." It is clearly distinguishable from Confluence comment tools by naming Jira, but it does not explicitly differentiate from the sibling jira_edit_comment.

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?

There is no guidance on when to use this tool versus jira_edit_comment, nor any mention of prerequisites or the special JSM public/internal comment paths. Usage is only implied by the verb "Add."

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