What changed on Robinhood Chain

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

Annotations only declare readOnly and openWorld; the description adds real behavioral context beyond them: result ordering (newest first by first arrival), the cursor-persistence contract for sync, and the retraction semantics ('a retraction means HEY no longer makes that claim'). It does not cover rate limits, page-size defaults beyond what the schema states, or the cost of a broad unfiltered call, which keeps it below 5.

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?

Front-loaded with the purpose question, then filters, then ordering/sync mechanics — a sensible order with no filler sentences. It is dense but slightly overpacked, and the closing tagline 'Facts, never causes' is punchy but of marginal operational value.

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 10-parameter, zero-required, open-world read tool with an output schema covering return values, the description supplies the unstated essentials: default ordering, sync protocol, and retraction handling. The main residual gap is that the 35-value type enum is neither sampled nor guided, leaving the agent to infer the taxonomy from the schema alone.

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?

Schema coverage is 70%, so baseline is near 3, but the description earns credit by disambiguating the two cursor-like parameters: detectedSince for 'today' (record-time) versus after as a resumable cursor to be retained. It also hints project/contract filtering via 'or for one project or contract.' The type enum taxonomy and limit behavior are left entirely to the schema.

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?

Opens with a concrete question and names the resource precisely: 'The change ledger: releases, ships, status moves, contract deploys and upgrades, verification, sources, unlocks.' An agent knows this is a chronological event feed and can distinguish it from snapshot/timeline siblings by the explicit 'one event per change' framing. It never names a sibling it is not, so 5 is not warranted.

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?

Gives clear situational routing: 'Newest first by first arrival; for today pass detectedSince; to sync, pass after=c1.0 and keep each cursor.' That is actionable context for two distinct call patterns. However, no exclusions or alternatives are named — nothing tells the agent when to prefer get_project_timeline, get_project_snapshot, or project_diff instead.

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