Hive Dispute

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

With no annotations, the description carries the full burden. It discloses data sources (subgraphs, RPC fallback, Etherscan scans) and explicitly states Hive does not judge, freeze, or enforce. This goes beyond the bare minimum, though details on response shape or rate limits are absent.

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 core purpose, followed by a compact list of sources and a key safety caveat. No redundant or filler content, every sentence earns its place.

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?

Despite no output schema, the description lists the types of data returned (dispute history, active cases, flags) and mentions the underlying data sources. It is adequate for a read-only check tool, but could be more explicit about response structure or error scenarios.

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 description coverage is 100% for both parameters: chain includes the allowed values and address specifies format. The tool description does not add additional parameter semantics beyond re-stating 'counterparty address + chain', so the baseline of 3 applies.

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 a specific action: 'return public dispute history, active arbitration cases, and on-chain reversal-pattern flags' given an address and chain. It identifies the resource (counterparty dispute data) and clearly distinguishes from siblings like dispute_today by focusing on a specific counterparty.

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 description clearly implies when to use: when you need dispute history for a counterparty on a supported chain. It adds a behavioral caveat ('Observational only') that helps avoid misuse, but it does not explicitly name alternatives or state when not to use, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden. It does add meaningful context by specifying the types of data returned and clarifying that Hive is excluded from this listing. However, it does not disclose any potential side effects, authentication requirements, or other behavioral nuances beyond the 'List' operation.

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?

The description is concise, front-loaded with the primary action, and every sentence adds value. The first sentence states the core purpose, and the second sentence adds an important caveat about Hive, with no wasted words.

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?

The description is largely complete for a simple listing tool with no parameters and no output schema. It names the providers, the data returned, and an important exclusion. A minor gap is the lack of explicit mention of the response format, but the listed details are sufficient for basic understanding.

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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain any parameters, and the empty input schema is fully self-evident.

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 clearly states the tool lists third-party arbitration protocols with specific data points (case load, intake URLs, jurisdiction model), using the verb 'List' and a clear resource. It distinguishes itself from siblings by naming the exact protocols and explicitly excluding Hive, which separates it from other dispute-related tools.

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 description gives clear context for what the tool provides, but does not explicitly state when to use it versus the sibling tools (dispute_check, dispute_route, dispute_today). The 'Hive is not one of them' note provides a partial exclusion but no direct guidance on alternatives.

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

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

With no annotations, the description carries the full burden. It discloses key non-obvious behavior: "NO automatic filing — Hive returns options + intake URLs only. The disputing party files directly with the chosen provider." This explains what the tool does NOT do, which is critical for correct usage.

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?

The description is two sentences: the first states purpose and inputs, the second clarifies the critical non-filing behavior. No wasted words.

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 tool with 3 params and no output schema, this description is complete. It explains what is returned (ranked options + intake URLs) and what is not done (filing). It fully covers the tool's behavior and inputs.

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 description coverage is 100%, so each parameter is already described. The description adds minimal extra meaning—it mentions "optional jurisdiction preference" but doesn't elaborate beyond the schema. Baseline 3 is appropriate.

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 clearly states the tool's function: "Given a case description, disputed amount in USD, and optional jurisdiction preference, return ranked arbitration provider options." It specifies the action (return ranked options), the resource (arbitration provider options), and the inputs. It also distinguishes from siblings by emphasizing it returns options + intake URLs only, not filing.

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 description clearly implies when to use the tool: when you have a case description, amount, and possibly jurisdiction preference, and want ranked provider options. It does not explicitly mention alternatives or exclusions, but the context is clear.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the tool provides a rollup, implying a read-only aggregation, but does not explicitly confirm it is non-destructive or disclose any permissions, rate limits, or data freshness details. It also does not describe the output structure.

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?

The description is a single, concise sentence that front-loads the key concept '24-hour rollup' and then lists the two data components. It wastes no words and is easy to scan.

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?

Given the tool's simplicity (0 params, no output schema), the description conveys the core content but leaves out the return format and any indication of when to choose this over sibling tools. It is adequate but not fully contextual.

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?

The tool has zero parameters, so the baseline is 4 as per the rubric. The description adds no parameter-specific meaning, but none is required.

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 clearly states what the tool provides: a 24-hour rollup of flagged-counterparty count and top arbitration providers by active case load. It specifies the resource and scope, and the term 'rollup' distinguishes it from the sibling tools, which likely offer individual checks or routing. However, it lacks an explicit action verb like 'returns' or 'lists,' making it slightly less direct than a 5.

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 description provides no guidance on when to use this tool versus the sibling tools (dispute_check, dispute_providers, dispute_route). It does not mention alternatives or exclusions, leaving the agent to infer usage from the name and description alone.

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