Tokenrip

List outputs

output_list

Read-onlyIdempotent

List what went out from a workspace, newest first: filter by job (a name), agent (a handle from workspace_load agents), kind, labels (all of them), task, status (sending, sent, failed), since and until. Each output carries its target, ref, task, job, approval (who approved it, or null) and the agent that recorded it. A page may hold fewer than limit outputs when they are large; while nextCursor is not null, call again with cursor: nextCursor (and the same filters) for older ones.

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>"
    },
    "name": "output_list"
  }
}

Input Schema

Name	Required	Description
`job`	No	Only outputs of this job, by name.
`kind`	No	Only outputs of this kind.
`task`	No	Only this task's outputs.
`agent`	No	Only outputs this agent recorded: its handle from workspace_load agents (or agent:<handle>).
`limit`	No	Page size, 1–100 (default 50).
`since`	No	Only what happened since: an ISO 8601 timestamp, or a number of days back (7 = the last week).
`until`	No	Only what was recorded up to then: an ISO 8601 timestamp, or a number of days back.
`cursor`	No	nextCursor of the previous page, with the same filters: older outputs.
`labels`	No	Only outputs with all of these labels: a comma list of at most 20 (client:acme,campaign.q4).
`status`	No	Only outputs with this status: sending (claimed, not settled), sent or failed.
`workspaceId`	Yes	The workspace (its id or its slug).

Output Schema

Name	Required	Description
`outputs`	Yes
`partial`	Yes	true while nextCursor is not null: more outputs follow.
`nextCursor`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description goes beyond them usefully by disclosing newest-first ordering and the caveat that "a page may hold fewer than limit outputs when they are large", plus a summary of what each output carries (target, ref, task, job, approval including null, recording agent) — but details like an explicit rate or consistency guarantee are absent. With a full output schema present, this is solid but not exceptional.

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?

Two sentences, front-loaded with the operation and scope, followed by filters, return shape and the pagination loop. It is dense but each clause carries information; the return-field enumeration is the only part that partly overlaps the output schema.

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

Completeness4/5

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

For an 11-parameter filtered list with an output schema, the description covers the operation, filter semantics, ordering, partial pages and cursor continuation — enough for correct invocation. The required workspaceId (id or slug) is left entirely to the schema, and no sibling alternative is named, so it is complete but not exhaustive.

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 description coverage is 100%, so the baseline is 3; the description adds a little on top by restating the filter list in one place, tying agent to "a handle from workspace_load agents" and spelling out the status vocabulary. It mostly mirrors the schema (e.g. labels "all of them" duplicates the schema's AND semantics) rather than adding new meaning.

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 ("List what went out from a workspace, newest first") and enumerates every filter dimension, so an agent can immediately distinguish it from the write-side siblings output_record and output_update 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit procedural guidance: "while nextCursor is not null, call again with cursor: nextCursor (and the same filters) for older ones", which tells the agent exactly how to continue paging. It also points to workspace_load for obtaining an agent handle, but never states when to prefer this over sibling listing tools or when it would be the wrong call.

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.