Robinhood Chain overview

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

Annotations already declare readOnlyHint and openWorldHint, and an output schema exists, so the safety profile and return shape are covered. The description adds view-specific behavior: 'days' is the default view, 'weekly-report' can resolve to the latest ISO week, and 'unlocks' includes scheduled HoodLock unlocks with proof. It omits freshness/pagination, but with annotations and an output schema the bar is lower and what it adds is real.

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?

Dense but front-loaded: the scoping question comes first, followed by the per-view semantics. Almost every clause carries information (metrics list, default, latest-week option, proof detail). The terse final clause 'days names no one; other views name projects' is slightly cryptic and costs a small amount of clarity for its brevity.

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?

With an output schema handling return shape and annotations covering read-only/open-world behavior, the description supplies what remains: the meaning of all five view values, the default view, and the variant semantics of days/week parameters per view. An agent can select a view and call it without opening the schema, which is sufficient for a 3-parameter read tool.

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 67%; the schema already documents the days range/defaults and the week pattern. The description adds semantic meaning beyond that: what each view returns (per-day metric breakdown for 'days', 'an ISO week, or the latest' for weekly-report, proof-bearing unlocks, and the build-market juxtaposition), which genuinely helps an agent choose a view. It does not add format hints beyond what the schema gives.

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?

The description states the resource (Robinhood Chain activity metrics) and enumerates the exact metrics returned per day (trades, volume, tokens, transactions, launches, ships) plus the alternate view modes. The question framing 'How active is Robinhood Chain?' is less crisp than a verb-phrase, but the view list removes ambiguity. It is clearly distinguishable from siblings like get_project_snapshot or get_token_market, which are project/token-scoped.

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 five view names with brief parentheticals imply which mode to choose for which data need, and 'days names no one; other views name projects' hints at chain-wide vs project-named output. However, it never states when to pick this tool over siblings such as get_project_snapshot or get_token_market, nor prerequisites. Guidance is implied rather than explicit.

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