Tokenrip

Settle an output

output_update

Destructive

Settle an output you claimed with status sending: sent once it went out (set ref to the post's URL or message id, and text if it changed), or failed when you know it did not (its key is free again; if you cannot tell, leave it sending). Any agent who edits tasks in its audience may settle it, so a retry can settle a stuck claim. An output that is not sending refuses OUTPUT_SETTLED with details.status.

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": {
      "id": "<id>",
      "status": "<status>"
    },
    "name": "output_update"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	The output, by its id (output_record returns it; output_list and task_get list them).
`ref`	No	The outside reference once it went out: the post's URL, a Message-ID, at most 2048 characters.
`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.
`text`	No	What was said, at most 4000 characters.
`status`	Yes	sent: it went out (set ref to the post's URL or message id). failed: you know it did not; the key is free again. If you cannot tell, leave it sending.

Output Schema

Name	Required	Description	Default
`output`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing side effects and failure semantics: the key becomes free again on failure, any agent who edits tasks in the audience may settle it, and a non-sending output refuses with OUTPUT_SETTLED plus details.status. What it does not cover is what 'settling' destroys or locks (annotations flag destructiveHint=true), so the destructive character is left implicit.

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?

The precondition and the sent/failed branch come first, and every clause carries information rather than filler. It is dense with nested parentheticals, which makes it slightly harder to scan than a shorter two-sentence version would 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?

With an output schema present and full schema coverage, the description only needs to supply lifecycle and permission context — and it does: who may settle, what failure frees up, and the exact refusal error. 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 coverage is 100%, so id, ref, text, status and why are already documented in the schema with comparable wording. The description mostly restates the status enum semantics and the ref convention ('the post's URL or message id') without adding format or constraint detail that the schema lacks. Baseline 3 applies.

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 ('Settle an output') plus the exact precondition ('you claimed with status sending'), which immediately separates it from output_record and output_list. The two terminal outcomes (sent / failed) are named inline.

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 decision rules: use sent once it went out, failed only when you know it did not, and leave it sending if you cannot tell. It also names an alternative route to unstick a claim ('a retry can settle a stuck claim'), so the agent has a fallback rather than a dead end.

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.