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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real value by naming the auth scheme (Bearer NovaRail account key or OAuth token) and disclosing exactly which fields come back. It stops short of stating behavior when the id is unknown or belongs to another account.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and resource, then the returned contents, then auth. No filler and nothing repeated from the annotations.

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

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

For a simple one-param read tool with readOnly annotations, the description covers return contents and auth, which is most of what an agent needs. The remaining gap is provenance of execution_id and error behavior for missing/foreign ids, which no output schema fills in.

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

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

Only one parameter with 0% schema description coverage, so the description must carry the definition. It says the lookup is 'by execution_id', identifying it as the run identifier, but never says where that value originates (presumably the hire_agent/relay_work response) or that it must be one of your own runs.

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

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

States a specific verb ('Fetch'), a specific resource ('a past run you started'), and enumerates what the receipt contains (status, outcome, what you paid, output). The 'past run you started' framing distinguishes it from siblings like relay_work or submit_work, which initiate runs rather than retrieve them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The phrase 'a past run you started' implicitly scopes usage to executions created via hire/relay and enforces ownership, but there is no explicit when-to-use versus alternatives statement, no exclusion for runs you did not start, and no pointer to the producing tool that yields the execution_id.

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