OwlGate

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds real context beyond them: the data source (recent sales), the fallback window ladder (12 h, else 24 h, 48 h, 7 d), result ordering (deepest discount first), and the disclaimer 'Estimate, not advice'. It stops short of saying what happens when no comparable sales exist or how stale data is signalled.

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 core definition, then modes, then the disclaimer; no filler sentences. The second sentence is a long run-on packing three clauses (quote, listing mode, ordering), which slightly hurts scannability.

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 no output schema, the description carries the return-shape burden and does so: a single quote, or a list of listings with fair price, discount vs fair, and a buy link. Field names and the sign convention for 'discount' are not specified, a minor gap for a read-only 4-parameter 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 100%, so baseline would be 3, but the description adds semantics the schema does not: cp, vw and uw together define the rig being priced, and the absence of cp switches the tool into listing mode. It does not clarify what happens if only one of vw/uw is supplied.

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 resource (fair price of TapeOut rigs on BNB Chain) and the exact computation (median BNB price of recent sales matching the same CPU and mining power) with fallback time windows. No siblings exist, and the two operating modes are spelled out, so an agent knows precisely what the tool returns.

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 maps input shapes to behavior: 'cp + vw/uw returns one quote' versus 'no arguments returns rigs listed now'. That is clear when-to-use guidance for both modes, though it gives no guidance on failure cases (e.g. no matching sales) or when the estimate is unreliable.

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