Tokenrip

Comment on a task

comment_create

Post a comment on a task you can read (any role, viewers included; an external member on shared tasks only): a question, a requested change or an answer, in markdown. Comments are not a status channel: the task's own state says where the work stands. It lands in the task's timeline (task_get) and the workspace's changes; nobody is emailed. Returns the comment with its id, which comment_update and comment_delete take.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "taskId": "<taskId>",
      "body": "<body>"
    },
    "name": "comment_create"
  }
}

Input Schema

Name	Required	Description
`why`	No	Required for workspace items: one sentence on what the person is trying to accomplish, in their terms, not a description of this edit. Every workspace write takes one; sessions and summaries record themselves from it. At most 300 characters.
`body`	Yes	The comment, markdown, at most 8000 characters: a question, a requested change or an answer. Never a status: the task's own state says where the work stands.
`taskId`	Yes	The task to comment on, by its id.

Output Schema

Name	Required	Description	Default
`comment`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026
- addedOutput schema / properties / comment / properties / author / properties / account / properties / former
```
Added value: +{
+  "const": true,
+  "type": "boolean"
+}
```
AddedOct 29, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare the write/non-destructive/non-idempotent profile; the description adds real context beyond them: it lands in the task timeline visible via task_get, shows in workspace changes, and nobody is emailed. It also states the return payload (comment plus id) used by the sibling edit/delete tools.

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?

Front-loaded with the verb and resource, then access rules, then anti-pattern, then side effects — a logical order with no filler. Density is high; long parenthetical clauses make it harder to scan than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers access requirements, side effects, timeline/change-log visibility, notification behavior and the returned identifier, while an output schema carries the return shape. Nothing an agent needs in order to call this correctly is missing.

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 taskId, body and why are already documented in structured fields, including markdown format and length limits. The description's mention of markdown and "not a status" only echoes the schema and never mentions the required `why` parameter's purpose, so it adds little beyond the baseline.

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 verb and resource ("Post a comment on a task") plus the distinction from status updates, and names the sibling tools that consume the returned id (comment_update, comment_delete). An agent can separate it from task_update/task_propose without opening a schema.

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?

Explicit permission scope for when it applies (any role, viewers included, external member on shared tasks only), an explicit when-not ("Comments are not a status channel: the task's own state says where the work stands"), and a pointer to comment_update/comment_delete for follow-up operations.

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

All Tokenrip tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.