Skip to main content
Glama

Reply Comment

reply_comment

Reply to an existing comment in a code review thread, with support for multi-level nested responses. When the thread reaches 100 comments, use a status update instead.

Instructions

Reply to an existing comment (supports multi-level nesting via parent_id).

DISCUSSION CAP: threads hold at most 100 comments total (posts + replies). Replying into a full thread is rejected — conclude with set_status instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesthe reply text.
authorYeswho is replying — your own tool name.
comment_idYesthe comment being replied to.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the burden. It discloses a non-obvious domain rule (100-comment cap) and the rejection behavior, plus a workflow alternative. It does not cover auth or side effects, but the key mutation constraint is stated.

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?

Two short paragraphs, front-loaded with the core action and then the constraint. Every sentence adds information; no filler.

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?

The description covers purpose, the critical cap, and the fallback tool. However, the phantom 'parent_id' reference creates a real invocation hazard, and there is no mention of error behavior for invalid comment_id, so it is not fully complete.

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 coverage is 100%, so baseline is 3, but the description references 'parent_id' which is not present in the input schema (additionalProperties: false). This can mislead an agent into passing an invalid parameter, so the description actually detracts from parameter clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('Reply to an existing comment') and resource ('existing comment'), and the parenthetical about multi-level nesting clarifies capability. It is distinguishable from siblings like post_comment by the word 'existing' and from set_status by mentioning the alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says replying into a full thread is rejected and directs the agent to 'conclude with set_status instead.' The phrase 'existing comment' implies it is not for top-level posts, giving clear selection context.

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