Tokenrip

Record an output

output_record

Record something you sent, posted, published or delivered outside Tokenrip (an X post, an email reply, a client report), in one call, with or without a task: kind (x.post, email.reply), target (who received it), ref (the post's URL or message id), text, file (the artifact it was made from), task, job, labels. On a task it takes the task's audience, job and labels, and the task's approved round as its approval. To send once only: first record it with status sending and a key unique to this one send and destination (the task id with the kind, task-id:x.post, or the id of the message you reply to; never an id that recurs, such as a draft's), then send, then settle it with output_update (sent with its ref, or failed only when you know it did not go out, which frees the key). A key an output that is not failed already holds is OUTPUT_EXISTS: details.output names it, so do not send again. Not for files you make in the workspace (artifact_publish) or results of a task (task_complete).

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": {
      "workspaceId": "<workspaceId>",
      "kind": "<kind>"
    },
    "name": "output_record"
  }
}

Input Schema

Name	Required	Description
`job`	No	The job it served, by name (from workspace_load jobs): a live job of this workspace. Defaults to the task's job. Jobs are internal: only internal members name one.
`key`	No	Your once-only key, unique to this one send and destination (the task id with the kind, task-id:x.post; the reply's message id; never an id that recurs, such as a draft's), at most 255 characters: while an output not failed holds it in this workspace, another record with it is OUTPUT_EXISTS naming that output.
`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.
`file`	No	The file it was made from: { artifact, version? }, readable in the output's audience and not in the trash. The version is recorded.
`kind`	Yes	What it was, a free tag Tokenrip never interprets (x.post, email.reply, li.comment, link): lowercase letters, digits, -, _ and ., starting with a letter or a digit, at most 64 characters.
`task`	No	The task it served, by id: any task in this workspace you can edit, whatever its status. The output takes the task's audience, and its job and labels unless you name them; its approval is the task's approved round.
`text`	No	What was said, at most 4000 characters.
`labels`	No	Labels for the output: your own words for grouping work. Defaults to the task's labels. Each label is lowercase letters, digits, -, _, : and ., starting with a letter or a digit, at most 64 characters (client:acme, campaign.q4); at most 20. Labels group work; Tokenrip never interprets them.
`status`	No	sent (the default): it went out. sending: claim it before you send, with a key, then settle it with output_update.
`target`	No	Who or what received it (x:@bob, bob@acme.com, a channel or a URL), at most 255 characters.
`audience`	No	Who in the workspace reads it, for an output with no task (internal by default for an internal member; a guest records shared ones). An output on a task takes the task's audience: naming another is refused.
`workspaceId`	Yes	The workspace (its id or its slug).

Output Schema

Name	Required	Description	Default
`output`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only declare this is a non-read-only, non-destructive, non-idempotent, closed-world write. The description goes further, disclosing the duplicate-prevention contract (OUTPUT_EXISTS, details.output names the existing output, the key is freed only when an output is marked failed), the inheritance behavior from a task (audience, job, labels, approved round as approval), and the refusal when an explicit audience conflicts with the task's. That is substantial context the annotations cannot convey; the only missing piece is what a successful response contains, which the output schema covers.

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 purpose, then the once-only protocol, then the exclusions — a sensible order for a mutating tool. It is dense but nearly every clause carries operational weight; the one cost is mild overlap with the schema descriptions of kind, target, ref and labels.

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 13 parameters, nested objects, enums and an existing output schema, the description covers exactly the parts structured data cannot: the multi-call send/settle workflow, the failure/retry semantics of the key, task-derived defaults, and sibling exclusions. An agent has everything needed to call this correctly and to recover from OUTPUT_EXISTS.

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 100%, so the baseline would be 3, but the description adds cross-parameter meaning rather than restating fields: it defines key validity by example ('the task id with the kind, task-id:x.post, or the id of the message you reply to; never an id that recurs, such as a draft's') and explains how task, job, labels and audience interact when supplied together. Genuine value above the per-field docs, though some of the enumeration of parameter names is redundant with the schema.

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?

Opens with a specific verb ('Record') and an unambiguous resource ('something you sent, posted, published or delivered outside Tokenrip'), then anchors it with concrete examples (an X post, an email reply, a client report). It also distinguishes itself from the two nearest siblings, artifact_publish and task_complete, so an agent can route correctly 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?

Gives explicit when-not guidance ('Not for files you make in the workspace (artifact_publish) or results of a task (task_complete)') and spells out the full when-to-use sequence for the risky path: record with status sending plus a unique key, send, then settle via output_update. Nothing about choosing this tool over an alternative is left to inference.

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.