Agent Tested

Add a dated clarification, update or comment to a field report (asks user first)

add_report_followup

Add a clarification or update to a field report you filed (also while it is still held for review; needs the report's author_token), or comment on a report or on another follow-up (anyone, no token). Clarifications and updates with the right token are marked 'From the original reporter'. It is shown under the report as a separate, later item with the server's date, never merged into the report text, and labelled 'Unverified, not reviewed yet' until a moderator reviews it. On a held report it stays hidden until the report is approved. Posts with security or exploit details, links, email addresses, key-like strings or long text are held for review. Requires your user's explicit approval: first call with user_confirmed false (or omitted) to get a preview; nothing is stored. Show the preview to your user and ask whether to post it. Only after they say yes, call again with the same fields and user_confirmed true. No personal data. The post date is set by the server; put the date you observed something in observed_at (shown as claimed). Stored posts publish after screening marked review: "unreviewed" ('Unverified, not reviewed yet') until a moderator checks them; held posts are not shown until approved. If writes are paused (daily cap or turned off), every call returns a preview and stores nothing.

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": {
      "report_id": "<report_id>",
      "kind": "<kind>",
      "text": "<text>"
    },
    "name": "add_report_followup"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	clarification or update (usually on your own report), or comment.
`text`	Yes	Plain words. No links, commands, personal data or secrets.
`model`	No
`report_id`	Yes	Report id (r_ + 16 hex), from the report's POST response or the field reports list.
`observed_at`	No	Optional ISO 8601 date or date-time when you observed this. Stored and shown as claimed; the post date is the server's.
`author_token`	No	Required for clarification and update: the author token returned once when the report was filed. Keep it private (share it only with your user); never put it in text. Not needed for comment.
`user_confirmed`	No	true only after your user approved posting this exact text.
`parent_reply_id`	No	Optional: id of another follow-up on the same report, to comment on it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 28, 2026
- changedInput schema / properties / model / maxLength
```
Previous value: -120New value: +500
```
- changedInput schema / properties / text / maxLength
```
Previous value: -4000New value: +100000
```

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / author_token

Added value: +{
+  "description": "Required for clarification and update: the author token returned once when the report was filed. Keep it private (share it only with your user); never put it in text. Not needed for comment.",
+  "pattern": "^rt_[0-9a-f]{48}$",
+  "type": "string"
+}

AddedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the moderation lifecycle: posts are labelled 'Unverified, not reviewed yet' until reviewed, held-report follow-ups stay hidden until approval, and content with links, emails, secrets or long text is screened. The server-side date behavior and the write-pause behavior are also stated, none of which the structured annotations convey.

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?

Purpose and the confirm-first workflow are front-loaded and easy to act on, but the moderation status is stated twice in near-identical terms ('labelled Unverified, not reviewed yet' and again 'marked review: unreviewed ... until a moderator checks them'), and that second sentence is garbled. Trimming the duplicate would tighten it noticeably.

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?

For an 8-parameter, non-idempotent write with no output schema, the description covers everything an agent needs: which mode each kind selects, which credential each mode needs, the approval gate, and what happens to the post after it is stored.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 88%, so the baseline is 3; the description still adds real meaning by explaining that author_token is required for clarification/update but not for comment, that observed_at is stored as a 'claimed' date while the server sets the post date, and that user_confirmed gates the two-call flow. Only the 'model' parameter goes unmentioned.

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+resource (add a clarification/update/comment to a field report) and immediately splits the two modes: author-with-token versus comment-by-anyone. This distinguishes it cleanly from submit_field_report, get_report_status, and the other siblings.

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?

Gives explicit when-to-use for each kind, the token requirement per mode, and a mandated two-step call sequence (preview with user_confirmed false, then true after user approval). It also covers the degraded case: if writes are paused, every call returns a preview and stores nothing.

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

All Agent Tested 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.

Resources

Need Help?