Replace the text of an existing comment to correct errors or update information.
Replace the text of an existing comment.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Replacement comment body. | |
| task_id | Yes | Task id. | |
| comment_id | Yes | Comment to edit. | |
| project_id | Yes | Project the task belongs to. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Replace,' which implies mutation, but it does not mention whether the operation is destructive to the original text, whether any permissions are required, what the response looks like, or whether the change is reversible. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant phrasing. Every word contributes to communicating the core action, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The flat 4-parameter schema with 100% coverage makes the tool fairly simple to invoke, and the description clarifies the core operation. However, because there is no output schema and no annotations, the description does not explain what the tool returns or any side effects. It is minimally sufficient but not richly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented in the schema. The description confirms that 'text' is the replacement body and that the target is an 'existing comment,' but it does not add any meaning beyond what the schema properties already provide. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Replace the text of an existing comment.' It clearly identifies the action and object, and the word 'existing' distinguishes it from sibling tools like post_comment, which create new comments. This is a precise, non-tautological statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when you want to overwrite the text of an already-created comment—but it does not explicitly name alternatives or exclusion criteria. An agent can infer the use case, but there is no direct guidance such as 'use post_comment for new comments'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.