Rokha

Trace Get

trace_get

Read-onlyIdempotent

READ one trace in full (input, result, status, timing) by id, or a whole run by run_id (status, steps with their trace ids, output, every trace). Signed in (Authorization: Bearer ): your own traces. No token: a PUBLIC rig's run is readable by anyone holding its trace id or run id — the runner's identity is stripped. Anything else answers not-found. REST twins: GET /api/traces/ · GET /api/rigs/runs/<run_id>.

Input Schema

Name	Required	Description	Default
`id`	No	A trace UUID (every trace row shows it).
`run_id`	No	A run UUID — the id rig_run / POST /api/rigs/run hand back. Pass this OR id.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

Changed4 schema fields changedSep 29, 2026

changedInput schema / properties / id / description

Previous value: -"UUID of the trace (the id shown on every trace row)"New value: +"A trace UUID (every trace row shows it)."

changedInput schema / properties / run_id / description

Previous value: -"UUID of a whole run — every trace it wrote. Pass this OR id."New value: +"A run UUID — the id rig_run / POST /api/rigs/run hand back. Pass this OR id."

removedInput schema / properties / wallet_address

Removed value: -{
-  "description": "Wallet address that owns the trace",
-  "type": "string"
-}

removedInput schema / required

Removed value: -[
-  "wallet_address"
-]

Changed3 schema fields changedSep 29, 2026

changedInput schema / properties / id / description

Previous value: -"UUID of the trace"New value: +"UUID of the trace (the id shown on every trace row)"

addedInput schema / properties / run_id

Added value: +{
+  "description": "UUID of a whole run — every trace it wrote. Pass this OR id.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "wallet_address",
-  "id"
-]New value: +[
+  "wallet_address"
+]

First observedSep 26, 2026

TDQS

A4.1/5.0

Behavior5/5

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

With readOnlyHint/idempotentHint already covering safety, the description still adds substantial behavioral context: signed-in callers see only their own traces, unauthenticated callers can read a PUBLIC rig's run only if they hold the id, runner identity is stripped, and everything else returns not-found. That is exactly the kind of access-control and failure-mode detail annotations cannot express.

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 scope, then the auth rules and REST twins, so an agent can stop reading early. It is dense but occasionally redundant, and the embedded extra spacing/line breaks make it slightly harder to parse than a clean sentence flow.

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?

An output schema exists, so return contents needn't be enumerated, and the description still spells out what each mode yields (input/result/status/timing vs status/steps/output/every trace) plus auth and REST equivalents. Nothing needed to invoke it 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% and both parameters are already documented as UUIDs with 'Pass this OR id' in the run_id field. The description restates the id/run_id choice without adding format, precedence, or default behavior when neither is supplied (required count is 0), so it stays at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource plus the two access modes: 'READ one trace in full (input, result, status, timing) by `id`, or a whole run by `run_id`'. That's concrete enough to separate it from trace_search behaviorally, though it never names trace_search as the lookup alternative, so an agent must infer which sibling finds the ids.

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?

Explains when each mode applies: single trace by id vs an entire run by run_id, plus the auth branching (signed in = your traces, no token = public rig). It does not state prerequisites for obtaining the ids or point to trace_search for discovery, so guidance is clear but not complete.

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

All Rokha tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.