$AI on HyperEVM

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

With no annotations, the description carries the full burden, and it does well by stating that the transaction is unsigned, that only calldata is returned, and that the caller must sign and send it. It also discloses the conditional gas-estimate behavior when `from` is provided. It does not detail error cases or on-chain interaction side effects, but the key behavioral boundary is made clear.

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 compact sentences that front-load the core purpose and output, then add the conditional gas-estimate detail. Every sentence earns its place with no redundant filler.

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 three-parameter tool with no output schema and no annotations, the description covers the essential context: what is built, what is returned, who signs and sends it, and the conditional gas estimate. It is not exhaustive about the exact calldata/return shape, but it is sufficient for an agent to understand the tool's role and primary behavior.

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 input schema already has 100% coverage, describing `from`, `hype`, and `slippage_bps` with types, defaults, and constraints. The description adds no new parameter semantics beyond restating that `from` enables a gas estimate, so the baseline score of 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 uses a specific verb ('Build'), a specific resource ('unsigned buy transaction against the AiCurve contract'), and clearly distinguishes this from the sell-side sibling by saying 'buy'. It also clarifies the output nature ('calldata only'), leaving no ambiguity about the tool's role.

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 conveys the intended use: constructing an unsigned buy transaction that the caller will sign and send. This gives useful context for when to use the tool, though it does not explicitly name alternatives or state when not to use it, such as pointing to ai_quote_buy for quotes.

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, and it delivers by disclosing the conditional approve step, the fact that multiple transactions may be produced, and that it returns calldata only with no on-chain side effects. This is exactly the kind of behavioral context an agent needs to trust and safely invoke the tool.

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?

A single, front-loaded sentence that moves from the main action to the conditional approve behavior to the caller's responsibility. Every phrase earns its place, with no redundant or filler 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 adequately covers purpose, conditional behavior, and return type, which is sufficient for an agent to call the tool correctly. Lacking an output schema, it could be more explicit about the exact return structure (e.g., a single calldata string vs. an array of transaction objects), but this is a minor gap.

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%, and each parameter already has a clear description (e.g., 'from' explicitly states it is required for allowance check and gas estimation). The description does not add parameter-specific meaning beyond the schema, so the baseline score of 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?

States a specific verb ('Build'), a specific resource ('unsigned transaction(s) to sell $AI'), and clearly distinguishes itself from sibling buy/quote tools through the explicit 'sell' focus. The approve-first detail further clarifies the operation without any ambiguity.

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 conveys when to use it: when constructing an unsigned sell transaction, and it notes that the caller must sign and send, implying this is for building rather than quoting or executing. It does not explicitly name alternatives or exclusions, so it stops short of a 5, but the context is unambiguous.

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 explicitly states 'Read-only snapshot', disclosing non-mutating behavior. It also mentions data is 'read live from chain' and includes a 'fee/no-guarantee disclosure', adding useful context about data source and risk. It doesn't discuss rate limits or latency, but for a simple read, this is sufficient.

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?

A single sentence that is front-loaded with the core purpose ('Read-only snapshot') and then efficiently lists the contained data. Every phrase adds information; there is no padding or repetition. The structure is ideal for quick comprehension.

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?

Since there is no output schema, the description must convey what the tool returns. It enumerates all key data points (price, sold, retired, etc.) and the disclosure, giving an agent a clear expectation of the response. For a parameterless read tool, this is 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?

There are 0 parameters, so the baseline is 4. The description correctly avoids inventing parameter details since none exist. It adds value by listing the fields the snapshot contains, which is more relevant than parameter semantics for a parameterless tool.

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 a specific verb ('Read-only snapshot') and resource ('$AI/HYPE AiCurve') and enumerates the exact data fields it returns. This distinguishes it from sibling tools that build transactions or provide quotes, which are obviously different operations.

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 implies usage: it's for reading market state, while siblings are for building/quoting trades. It doesn't explicitly say 'use this when you need current market data, not when constructing transactions', but the contrast with siblings is clear from context. No explicit exclusions, but the read-only framing sets it apart.

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 are provided, so the description carries the burden. 'Before slippage' is a useful behavioral disclosure indicating the quote may differ from execution price. However, it does not mention whether the quote is live, whether fees apply, or that it is a read-only operation (though 'quote' implies this). Some context is added, but the transparency is not comprehensive.

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?

A single, tightly written sentence that front-loads the tool's purpose and adds the key qualifier ('before slippage'). No filler or repetition of schema details. Every word 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?

With one parameter, no output schema, and no annotations, the description is adequate but not fully complete. It implies the return value is the amount of $AI, which is enough for a simple quote. It does not address output format, possible errors, or the meaning of 'right now' (e.g., spot vs mid-market), but these are minor for this tool's simplicity.

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% — the only parameter 'hype' is fully described with format and max value. The description's phrase 'a given amount of HYPE' simply restates the parameter without adding new meaning. Baseline 3 is appropriate since the schema does the heavy lifting.

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 verb ('Quote') and resource ('how much $AI a given amount of HYPE buys'), making the tool's function immediately clear. The word 'buys' semantically distinguishes it from the sibling ai_quote_sell, and 'quote' distinguishes it from ai_build_buy_tx. This meets the bar for a distinct, unambiguous purpose.

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 phrase 'right now, before slippage' implies the tool is for a current, non-executable price estimate, but there is no explicit when-to-use vs alternatives. An agent can infer it should use this over ai_build_buy_tx when only a quote is needed, but the description does not state that directly.

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 a key behavioral trait — the returned amount is net of the on-chain sell fee — and implies a read-only, real-time quote. It does not detail output shape or auth, but that is not required for a simple quote tool.

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?

One sentence, front-loaded with the core purpose, and no filler. Every word adds 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 one-parameter quote tool with no output schema, the description provides the necessary semantic output (HYPE amount net of fee) and context. Minor missing detail like response formatting is not significant for such a simple 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% and the single parameter is clearly documented as an $AI decimal string. The description adds no new parameter detail beyond 'given amount', so the baseline 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 uses a specific verb ('Quote') and names the resource and direction ('$AI returns HYPE'), adding that the result is net of the sell fee. This clearly distinguishes it from sibling tools like ai_quote_buy and ai_build_sell_tx.

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 phrase 'right now' plus the verb 'Quote' conveys that this is an estimation, not a transaction builder, and 'sell' disambiguates from ai_quote_buy. It does not explicitly state when to use it versus ai_build_sell_tx, 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.