Hive Auction

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

The description declares the tool as read-only and lists output fields, but lacks detail on behavior like time zone for 'today', data freshness, or any side effects. Given no annotations, the description partially covers transparency but leaves gaps.

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 extremely concise with two short sentences, no redundant information, and front-loaded key details. Every word contributes meaning.

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 zero-parameter tool with no output schema, the description provides the main fields and context (today aggregate, free, read-only). However, it is missing clarifications like what 'opens' and 'closes' represent, time zone, and whether the data is live or static.

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?

No parameters exist, so the description does not need to add parameter meaning. The baseline is 4 due to 100% schema coverage, and the description adds value by naming the output fields.

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 identifies the tool as returning a 'today aggregate' with specific fields (opens, closes, avg_premium_pct, total_usdc), clearly indicating it fetches aggregated auction data. However, it does not explicitly state a verb like 'retrieves' or 'gets', and the purpose could be more precise.

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?

No guidance is provided on when to use this tool versus its siblings (auction_open, auction_subscribe). The mention of 'Tier 0, free, read-only' implies general context but no explicit when-to-use or when-not-to-use information.

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?

No annotations provided, so description carries full burden. It discloses required authentication (HMAC) and return fields (auction id, descent curve, 402 envelope block). Does not mention if operation is idempotent or any side effects, but is adequate for the tool's nature.

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, no wasted words. First sentence covers action and restriction, second sentence lists return values. Perfectly sized for the tool's complexity.

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 no output schema, description compensates by listing return fields. Could mention if opening a new auction automatically closes a previous one for the same shim, but not required for basic usage.

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 100%, baseline 3. Description adds context: 'Curve is anchored on this' for asking_usd and 'Optional caller-bound on descent (capped at MAX_DESCENT_PCT)' for max_descent_pct, enhancing semantic understanding beyond schema type/required info.

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?

Description clearly states the action 'Open a new Dutch auction' and the resource 'scarce shim slot'. It distinguishes from sibling tools (auction_book, auction_subscribe) which have different verbs (book vs open, subscribe vs open).

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?

Explicitly states 'INTERNAL — requires HMAC signature from hivemorph rate-limiter', giving clear context for when to use. Does not explicitly list when not to use, but the restriction implies it's for authorized internal use only.

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 must cover behavioral traits. It identifies the tool as read-only and free, but lacks details on SSE behavior such as reconnection, timeout, or unsubscription.

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 with no filler. It front-loads the core purpose and adds key context concisely.

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 (one parameter, no output schema), the description explains the return value (SSE URL) reasonably well. Minor gaps exist, such as SSE usage details, but it is mostly complete.

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 schema covers the single parameter with 100% description coverage. The description adds clarity by noting the parameter's source ('from /v1/auction/open'), which is helpful but not extensive.

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 (subscribe) and resource (live descent curve for a specific auction). It clearly distinguishes from siblings (auction_book and auction_open) by focusing on real-time streaming.

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 includes 'Tier 0, free, read-only', which provides basic usage context but does not explicitly mention when not to use or alternative tools.

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