Skip to main content
Glama

Get comments

jira_get_comments
Read-only

Retrieve comments on a Jira issue as Markdown, newest first, with optional site and result limits, so you can review recent discussion and context.

Instructions

Latest comments on an issue, newest first, as Markdown.

Input Schema

NameRequiredDescriptionDefault
siteNoJira site to use when your account has several: cloud id, site name, or URL (e.g. 'acme' or 'acme.atlassian.net'). Omit to use the selected/default site.
issueKeyYesIssue key, e.g. 'THEOS-123'.
maxResultsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnly=true, destructive=false, and openWorld=true, so the safety profile is covered. The description adds useful behavior — newest-first ordering and Markdown formatting — but omits pagination/default count behavior even though a maxResults parameter exists, leaving 'Latest comments' ambiguous in size.

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?

One tight sentence with no filler, and the key attributes (newest first, Markdown) are front-loaded. It borders on under-specified rather than verbose, but by the sizing criterion it is efficient.

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?

No output schema exists, so the description's mention of Markdown format and ordering is valuable. However, it fails to clarify default/maximum result counts or whether paging is required to get all comments, which is a meaningful gap for a read tool with a maxResults cap.

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 coverage is 67%: site and issueKey are well documented, but maxResults has no description in the schema and the description never explains its role in limiting the 'latest' comments. Baseline 3 for middling coverage where the schema does most of the work.

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?

States a specific verb+resource (get comments), plus ordering (newest first) and output format (Markdown), which clearly separates it from the sibling jira_add_comment. It does not name any sibling explicitly, so it stops short of the 5 bar.

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?

Usage is implied: fetch comments for an issue key. There is no explicit when-to-use, no mention of when not to use it, and no pointer to alternatives (e.g., jira_get_issue for full issue detail).

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