GDEX Trading

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

With no annotations, the description carries the full behavioral burden and delivers almost nothing: it does not say whether a userId must be authenticated, whether comments are public, whether they can be edited/deleted, or what happens on duplicate posts. Only the bare 'post' mutation intent is conveyed.

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 with zero filler. Its brevity is appropriate in form, though it reflects under-specification rather than genuine economy.

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 mutation tool with no annotations, no output schema, and 0% schema coverage on 5 params, the definition is far too thin. An agent lacks the auth expectations, return behavior, and parameter meanings needed to call it correctly.

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 0% across 5 parameters (4 required), so the description must compensate, yet it only loosely gestures at tokenAddress and message. The userId, chain, and unexplained 'data' parameter receive no semantic guidance at all.

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?

Clear verb+resource: 'Post a comment on a token' states the action and target precisely, and implicitly contrasts with the sibling get_comments. It does not explicitly name the sibling, but an agent can distinguish write-from-read without opening the schema.

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 when-to-use guidance, no prerequisites, and no mention of the get_comments alternative for reading. The agent must infer everything about invocation context from the name alone.

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 present, the description carries the burden well: it discloses that the email is never sent by the client and is instead extracted server-side from the verified idToken, and that computedData must come from buildAssociateEmailComputedData as a managed-custody payload. It stops short of covering idempotency/repeat-call behavior or what happens if an email is already associated.

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?

Four short sentences, front-loaded with the action and immediately followed by the sequencing rule. Slightly dense with parenthetical metadata (404/code 108, managed-custody), but every clause carries operational information.

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 two-parameter mutation with no annotations or output schema, the description supplies the critical prerequisite chain, the source of the payload, and the reason the email argument is absent. Missing only return-value and error-handling detail, which is a modest gap given no output schema exists.

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 the baseline is 3; the description goes slightly beyond by clarifying the negative case (no email parameter exists — the backend derives it) and by naming the specific builder function that must produce computedData. It does not expand on token format, expiry, or validation failure modes.

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 (link) and resource (the email claim from a Google ID token) tied to a concrete target (the caller's wallet). It is clearly distinguishable from the many trading/query siblings and from oauth_login, which it names directly.

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?

Gives an explicit precondition ('Must be called before oauth_login when the wallet has no associated email yet') and even cites the failure signature (404/code 108) that selects this tool. It also names the alternative flow (oauth_login) and the ordering requirement, leaving nothing to inference.

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 full behavioral burden. It does disclose one meaningful side effect — that a global Bearer token is set for all subsequent requests — which is the key behavior for an auth tool. But it omits token lifetime/persistence, whether repeated calls are safe, and error behavior, so a 3 rather than higher.

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 waste, and the primary action is front-loaded ahead of the side effect. Nothing could be trimmed without losing information.

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 auth tool with no output schema and no annotations, the description covers the action and the global side effect adequately. It would be more complete with a note on token persistence/expiry, but nothing essential to correct invocation is missing.

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 fully documented in the schema ('GDEX API key (UUID format)'). The description adds no format or sourcing guidance beyond that, so the schema does the heavy lifting — baseline 3.

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 ('Authenticate') plus the resource/credential type ('GDEX API key') and its effect. Clear enough to select it over the dozens of trading/getter siblings, but it does not distinguish itself from the other auth-related siblings (oauth_login, managed_sign_in, build_sign_in_payload), so it stops short of 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 clause 'Sets the Bearer token for all subsequent requests' implicitly signals this is a prerequisite called before other tools, which is useful implied usage. However, it never states when to prefer it over oauth_login or managed_sign_in, nor any prerequisites or failure conditions.

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 behavioral burden. 'Build ... from raw credentials' and 'Returns the payload' imply a local, pure construction with no auth or state mutation, which is useful. It stops short of confirming there are no side effects or network calls, and says nothing about failure conditions for invalid credentials.

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 short sentences with no filler; the purpose is front-loaded and the downstream consumer is stated second. Every clause carries information.

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 six parameters, five required, and no output schema, the description does usefully state that the return value is the payload for managed_sign_in. It still omits the input dependency on a generated session keypair and any description of payload shape, so it is adequate but leaves clear gaps.

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 all six parameters (apiKey, userId, sessionKey, nonce, signature, refSourceCode) are already documented in the schema. The description adds only the collective phrase 'raw credentials' and no per-parameter meaning, so the baseline 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 states a specific verb and output ('Build the encrypted sign-in computedData payload from raw credentials'), so the agent knows exactly what is produced. It also ties the result to the sibling managed_sign_in. It does not distinguish this from other sign-in artifacts such as generate_session_keypair, which produce one of its inputs, so the sibling differentiation is only partial.

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?

'Returns the payload to use with managed_sign_in' implies a build-then-submit ordering, which is usable guidance. However, no prerequisites (e.g. that sessionKey comes from generate_session_keypair), no when-not-to-use, and no alternative are named, so usage is only implied rather than stated.

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 behavioral burden. It hints that the payload is 'encrypted' and 'managed-custody', but never discloses whether the tool is a pure local computation or makes network calls, whether it requires prior session/auth setup (implied by sessionPrivateKey and apiKey but unstated), or what happens to credentials.

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 with no filler; the core action and output are stated immediately. It is arguably too terse for a 7-parameter all-required tool, but nothing is wasted.

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 tool with 7 required parameters, no annotations, and no output schema, the description should at minimum explain what the produced payload is consumed by and whether the call has side effects. Neither is addressed, so an agent cannot fully reason about safe or correct invocation.

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 the schema already documents all 7 parameters and their meanings. The description adds no format, ordering, or constraint detail beyond what the schema provides, 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?

States a specific verb ('Build') and a specific resource ('encrypted managed-custody trade computedData payload from raw credentials'), which is more than a tautology. However, it does not differentiate itself from the structurally similar sibling build_sign_in_payload, nor from execution siblings like managed_purchase/managed_sell, leaving the agent to infer the boundary.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as managed_purchase, managed_sell, or build_sign_in_payload. The description gives no signal about where this fits in a managed-custody trade flow.

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 full behavioral burden. It implies market execution via a routing engine, but says nothing about on-chain irreversibility, slippage risk, which credentials are needed (apiKey + sessionPrivateKey imply distinct managed-custody flows), or whether it signs and broadcasts a transaction.

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 verb and resource, with no filler. The chain enumeration is somewhat redundant with the schema's chain description but does signal multi-chain breadth up front.

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 an 11-parameter financial mutation tool with no annotations and no output schema, the description omits the essentials: no return-value or transaction-hash expectations, no custody-mode explanation for the apiKey/sessionPrivateKey parameters, and no failure modes. The safety profile an agent needs before executing a real swap is absent.

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 all 11 parameters are already documented in the schema; the baseline is 3. The description adds only the 'best DEX route' framing, which loosely contextualizes the dex parameter but adds no syntax, format, or interaction detail beyond the schema.

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 and resource ('Buy a token') plus scope ('any supported chain') and mechanism ('best DEX route'), which is enough to distinguish it from read-side siblings. However, it never distinguishes itself from close siblings like limit_buy, execute_spot, or managed_purchase, so an agent still has to guess which buy path applies.

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?

There is no when-to-use statement, no prerequisites, and no exclusions. Nothing tells the agent when to pick this over limit_buy (limit order), managed_purchase, or execute_spot, nor what conditions (wallet/session state) must hold before calling it.

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 zero annotations, the description carries the full burden of behavioral disclosure for a destructive mutation, yet it only restates the action. It says nothing about irreversibility, required auth/permissions, scope (all symbols/dexes?), rate limits, or whether it can be undone.

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 with no wasted words. It is tight and well-structured, though the brevity reflects under-specification rather than deliberate economy.

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 destructive all-cancel operation with no annotations and no output schema, one sentence is insufficient. It omits safety, auth, and scope details an agent needs before invoking it.

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% and all three credentials are documented in the schema, so the baseline is 3. The description adds no parameter meaning beyond what the schema already provides.

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 and resource ('Cancel all open perp orders') with a clear platform scope ('on HyperLiquid'). The word 'all' implicitly distinguishes it from the singular sibling cancel_perp_order, though no sibling is named explicitly.

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 no when-to-use guidance, no prerequisites, and never mentions the alternative cancel_perp_order or close_all_positions. An agent must infer the use case entirely from the name.

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 full behavioral burden and does not meet it. It never states that cancellation is irreversible, that the order must still be open, or that a valid session private key and API key are required to authorize the call.

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 with no filler and the resource and scope stated immediately. It is appropriately sized, though it is brief enough that it omits useful detail rather than wasting 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 destructive mutation with five required auth-carrying parameters, no annotations, and no output schema, the description is too thin. It omits auth/session requirements, failure modes, and what the result confirms, leaving the agent under-informed before an irreversible action.

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% with all five parameters documented in the schema itself, so baseline 3 applies. The description adds no meaning beyond the schema, e.g. order ID format or how coin relates to orderId.

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 and resource ('Cancel a specific open perp order') scoped to HyperLiquid, and the word 'specific' implicitly contrasts with cancel_all_perp_orders. It does not name that sibling or explain how it differs from direct_cancel_order, so an agent still has to infer the boundary.

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 when-to-use guidance, no prerequisites, and no routing to alternatives such as cancel_all_perp_orders or direct_cancel_order. The agent is left to infer that this applies only to open perp orders on HyperLiquid.

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 full behavioral burden. It discloses the managed-custody path and the encrypted payload requirement, but never explains how 'add' versus 'remove' is selected, whether the operation is reversible, or what authorization the user needs.

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 short sentences, front-loaded with the action and the hard prerequisite. No filler or restatement of the tool name.

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 mutation tool with no annotations and no output schema, the description omits critical context: how add/remove is distinguished, what a successful call returns, and what failure modes exist. It is far too thin for a state-changing operation.

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 both parameters (chainId, computedData) are already documented in the schema. The description adds only that computedData must be pre-built and encrypted, which is marginal added meaning over the schema text.

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 (add/remove) and resource (token on the user's watchlist) with a note that it runs through managed custody. The read counterpart get_watchlist exists in the sibling list but is not named, so the description doesn't fully route the agent between them.

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 only guidance is a prerequisite ('Requires pre-built encrypted computedData'), which implies a payload must be built first via something like build_trade_payload, but that sibling is never named. There is no statement of when to use this versus get_watchlist or import_token.

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 behavioral burden. It usefully discloses unreliability ('may be unreliable'), which is real behavioral value, but it omits that this is a destructive/irreversible mutation and says nothing about auth requirements or scope ('all' across what set of coins/dexes).

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 short sentences with zero waste: the action is front-loaded and the reliability caveat follows immediately. 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?

For a destructive bulk-mutation tool with no annotations and no output schema, the description warns about unreliability but leaves gaps: irreversibility, auth expectations (implied only by the required params), and the exact scope of 'all' positions are not addressed.

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 all three parameters (apiKey, walletAddress, sessionPrivateKey) are already documented in the schema. The description adds no parameter meaning beyond that, making the baseline 3 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 and resource with scope: 'Close all open perpetual positions on HyperLiquid.' The 'all' distinguishes it from the singular sibling close_perp_position without opening either schema.

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 note 'prefer closing per-coin' gives an explicit alternative to this tool, which routes the agent toward close_perp_position. However, it states a preference without spelling out the conditions under which this tool is still the right choice, so it falls short of a full when/when-not rule.

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 usefully discloses that the close is executed as a reduce-only market order, implying immediate fill and that the position cannot be flipped — meaningful behavioral context. It omits auth/session requirements (apiKey, sessionPrivateKey are required), irreversibility, and slippage exposure on a market order.

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 action and resource, then the execution mechanism. No filler, nothing an agent must skip past.

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 mutation tool with six required parameters (including credentials), no annotations, and no output schema, the description is thin. It never explains the sign-in/session-key prerequisite or what a successful close returns, leaving the agent to infer the invocation prerequisites from the schema alone.

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% with all six parameters documented, so the schema does the heavy lifting and baseline is 3. The description adds nothing per-parameter, and it creates mild tension by calling the order a 'market order' while the schema documents a required 'price' parameter without clarifying its role in a market execution.

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?

Specific verb+resource: closes a perp position, with the qualifier 'specific' hinting it targets one position rather than all. The 'reduce-only market order' detail further distinguishes it from open_perp_position. However, it never names close_all_positions or place_perp_order as the contrasting siblings, so an agent must infer the boundary.

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 states what the tool does but gives no when-to-use guidance, no preconditions, and no routing to alternatives such as close_all_positions (full portfolio exit) or place_perp_order (partial/custom close). The 'specific' qualifier is the only implicit selection signal.

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 full behavioral burden. It conveys that this is a mutating creation action, but omits critical context: that it requires apiKey/sessionPrivateKey/userId credentials, whether the trade starts mirroring immediately, and what happens on failure. For a 13-param mutation with zero annotation coverage this is a significant gap.

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 short sentences, front-loaded with the action and scope; every clause earns its place and nothing is padded.

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 schema fully documents all 13 parameters and no output schema exists, so return values need not be explained. However, for a complex credential-gated creation tool with no annotations, the description leaves the authentication/session requirements and post-creation behavior unexplained.

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% and each parameter (buyMode, chainId, lossPercent, copyBuyAmount, etc.) is documented inline, so the baseline is 3. The description adds no syntax or format detail beyond what the schema already states.

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+resource ('Create a new copy trade') plus the behavior it enables ('auto-mirror a Solana trader's buys/sells') and a platform scope ('Solana only'). The Solana-only qualifier usefully distinguishes it from the sibling create_hl_copy_trade, though it doesn't name that sibling explicitly.

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 'Solana only' note implies when this tool applies rather than the Hyperliquid variant, but there is no explicit when-to-use/when-not guidance, no mention of prerequisites (sign-in, session key), and no routing to update_copy_trade for modifying an existing trade.

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 full behavioral burden. It implies a write/mutation operation but discloses nothing about authentication needs, permission requirements, reversibility, or side effects of creating a copy trade. Only the schema's parameter descriptions hint at auth via apiKey/sessionPrivateKey.

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 short, front-loaded sentences with no wasted words. The second sentence adds some explanatory value about copy-trade behavior, though it borders on restating the obvious.

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 10-parameter (9 required) creation tool with no annotations and no output schema, the description is thin on behavioral context. The well-documented schema covers parameters, but nothing explains the creation flow, required auth setup, or what happens on success.

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 the schema already documents all 10 parameters thoroughly. The description adds no parameter-level detail, so the baseline 3 applies when 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?

States a specific verb and resource: 'Create a new HL perp copy trade', and adds a clarifying clause about copying a trader's long/short perpetual positions. However, it does not explicitly distinguish this from the sibling create_copy_trade or update_hl_copy_trade, so an agent must infer the difference from the 'HL' prefix alone.

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 no when-to-use guidance, no prerequisites, and no mention of alternatives such as create_copy_trade. It only states what the tool does, leaving the agent to infer the appropriate context.

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 full burden. It discloses that signing happens directly with a private key (a meaningful custody/auth detail), but says nothing about irreversibility, whether the order must still be open/fillable, error behavior for already-filled orders, or rate limits — all essential for a destructive mutation.

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 with no waste. It is arguably too terse for a destructive, key-handling operation, but on pure conciseness and structure it is efficient.

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 destructive, no-annotation tool that takes a raw private key and has no output schema, the description should cover safety, auth expectations, and what a successful/failed cancellation looks like. None of that is present, leaving significant gaps an agent must guess at.

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% (coin, orderId, privateKey all documented in the schema), so the baseline of 3 applies. The description adds no format, range, or domain detail beyond what the schema already provides.

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 and resource ('Cancel an open order') plus the venue and signing method (HyperLiquid, private key). It does not distinguish itself from siblings like cancel_perp_order, cancel_all_perp_orders, hl_cancel_outcome_order, or update_order, so an agent cannot tell from the description alone which cancel variant applies.

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 on when to use this versus the many cancel siblings or the managed/HL copy-trade cancel tools. 'Directly with a private key' hints at a self-custody signing path, but the description never states prerequisites or when this is preferred over cancel_perp_order.

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 usefully discloses that nothing is executed and names the returned fields (estimated output, provider, time), but omits quote expiry, auth/permission requirements, and failure modes for unsupported routes.

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 short sentences, front-loaded with purpose and immediately followed by the return contract. No filler or redundancy.

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 compensates by summarizing the return values (estimated output, provider, time), and the schema fully documents inputs. It stops just short of covering quote validity/expiry and error conditions an agent would need for reliable use.

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 all three parameters (amount in raw units, source/destination chain IDs), so the schema already does the heavy lifting. The description adds no parameter-level detail beyond that, making the baseline 3 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 (get) and resource (cross-chain bridge quote) plus a key scope qualifier: 'without executing'. This implicitly separates it from the sibling execute_bridge, so an agent can pick correctly without opening the schema.

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?

'Without executing' hints that this is a read-only preview step before execute_bridge, but no alternative is named and no condition for choosing it (e.g., when a quote is needed vs. placing an order) is stated. Usage is implied rather than spelled out.

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 full behavioral-disclosure burden. It states the auth requirement but omits critical traits for a fund-moving bridge execution, such as irreversibility, finality, failure modes, and expected side effects.

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 short, front-loaded sentences with no filler. The purpose is stated first and the key prerequisite second, so 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?

For a high-stakes cross-chain execution tool with six required parameters, no annotations, and no output schema, the description is too thin. It covers purpose and auth but omits execution behavior, safety constraints, and return expectations.

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 all six parameters are already clearly documented in the schema. The description adds no additional parameter meaning, which makes the baseline 3 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 (Execute) and resource (cross-chain bridge transaction), so the agent knows exactly what operation is performed. It does not explicitly distinguish this tool from the sibling estimate_bridge, but the execution-vs-estimation distinction is still clear.

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?

Mentions the prerequisite 'Requires managed-custody auth,' which gives some usage context. However, it does not say when to use this versus estimate_bridge, get_bridge_orders, or other bridge-related siblings, leaving the agent to infer the routing.

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 behavioral burden. It usefully discloses the auth model (private key, self-custody) and feature scope (TP/SL and builder fees), but omits notable behaviors such as the leverage auto-update side effect and what the call returns or how failures behave.

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 tight, front-loaded sentences with no filler; the core action leads and the feature scope follows. There is spare room that could have been used for usage guidance without bloat, but nothing here is wasteful.

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?

This is a 14-parameter financial mutation with no annotations and no output schema. The description covers the action and auth model but leaves out routing context against its many siblings and behavioral caveats, so it is under-specified for a tool of this complexity.

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 93%, so the schema already documents nearly all 14 parameters in detail. The description only summarizes 'Supports TP/SL and builder fees,' adding little beyond what the schema provides, 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 states a specific verb and resource ('Execute a cross-margin perpetual trade') and adds the execution model ('directly with a private key, no managed custody'). The 'cross-margin' qualifier implicitly separates it from the sibling execute_isolated_perp, but that differentiation is left implicit rather than stated.

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 explicit when-to-use/when-not conditions or named alternatives appear. The 'cross-margin' framing plus 'no managed custody' only imply when this tool is appropriate versus the isolated or managed siblings, so usage is inferred rather than stated.

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 full behavioral burden. It does add two useful facts (private key signing, leverage mandatory), but omits critical context for a live-funds mutation: irreversibility, that isMarket defaults to true, reduceOnly semantics, and risk/error behavior.

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 tight, front-loaded sentences with no filler, leading with the action and scope. Given the tool's complexity it is arguably too terse, but structurally it is clean and efficient.

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 14-parameter, 6-required mutation tool with no annotations and no output schema, the description is far too thin. It does not cover market/limit behavior, risk params, builder fee fields, or expected outcomes, leaving the agent without enough to call it safely.

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 only 43% across 14 parameters, and the description only restates 'requires explicit leverage' and mentions the private key. It does not clarify undocumented parameters such as stopLossTrigger, takeProfitTrigger, builderFeeRate/Address, reduceOnly, or isMarket, so it fails to compensate for the coverage gap.

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 and resource ('Execute an isolated-margin perpetual trade') and the scoping word 'isolated' implicitly distinguishes it from execute_cross_perp. However it does not differentiate it from other position-opening siblings like open_perp_position or place_perp_order, so an agent cannot fully disambiguate from the description alone.

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 explicit when-to-use guidance and no named alternatives despite many overlapping siblings (execute_cross_perp, open_perp_position, place_perp_order). The only hint is that 'isolated-margin' is the operative condition, which the agent must infer.

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 behavioral burden. It discloses the notable auth requirement (private key) and that execution is direct/irreversible, but omits slippage, the market-vs-limit default, builder-fee behavior, failure/partial-fill handling, and rate limits for a live financial mutation.

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 with zero padding and the venue plus key requirement stated up front. It is efficient, though arguably too terse for an 8-parameter financial execution tool.

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 live spot-order execution with 8 parameters, no annotations, and no output schema, the description is materially incomplete: it never explains the market/limit distinction, fee parameters, or expected outcome. An agent cannot confidently call it correctly from this definition alone.

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 only 63%, and the description mentions just the private key, adding nothing about coin, size, isBuy, price, or the undocumented isMarket default (true), builderFeeRate, and builderFeeAddress. It does not compensate for the schema's gaps.

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 (execute), resource (spot trade), venue (HyperLiquid) and a distinguishing detail (private key). The word 'spot' separates it from the many perp siblings, but it does not clearly distinguish itself from buy_token/sell_token or limit_buy/limit_sell, which are also spot-order paths.

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?

There is no when-to-use guidance and no alternatives named, even though buy_token, sell_token, limit_buy, and limit_sell are obvious overlapping siblings. The agent must guess whether this is the canonical spot entry point or a lower-level fallback.

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 full burden. It does disclose the shape of the output ('step-by-step instructions and code'), which is valuable given there is no output schema, but it says nothing about auth requirements, scope, or how the result is structured.

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 with no wasted words; the key purpose and output form come first. It is slightly under-specified rather than over-long, but structurally efficient.

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 documentation-lookup tool with full enum coverage and no output schema, the description adequately conveys what it returns. It stops short of explaining when to pick it over the closely related guide/doc siblings, which is the main remaining 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 description coverage is 100% and the single 'workflow' parameter is documented with an enum in the schema itself. The description adds no meaning beyond what the schema already provides, 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?

States a specific verb ('Explain') and resource ('end-to-end GDEX trading workflow') and even names the output form (step-by-step instructions and code). However, it does not distinguish itself from very similar documentation siblings such as get_trading_guide, get_copy_trade_guide, get_component_guide, or search_gdex_docs.

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?

There is no when-to-use guidance, no exclusion criteria, and no mention of any alternative. Given that several siblings (get_trading_guide, get_copy_trade_guide, get_component_guide) sound like they serve overlapping documentation needs, this omission is meaningful.

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 full behavioral burden. It usefully discloses that generation is offline and that keys are returned, but it omits important behavioral context such as whether the wallet is persisted anywhere, security handling of the returned privateKey/mnemonic, or auth requirements.

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 tight two-clause sentence that front-loads the core action and adds the return values without waste. No filler or repetition.

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 annotations and no output schema, the description states the action and returned fields, which is minimally sufficient. However it leaves gaps around security handling and persistence of the generated keys that an agent might need to advise users.

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 takes zero parameters, so there is no parameter semantics to document; baseline 4 applies. The description appropriately spends no words on parameters.

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 and resource ('Generate a new EVM wallet') with an added scope qualifier ('offline'). It is easily distinguished from sibling tools, which are mostly trading/query operations, though it doesn't explicitly name a sibling it complements or replaces.

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 '(no network call)' parenthetical implies the tool's usage context (local key creation without connectivity), but there is no explicit when-to-use statement or named alternative. Usage is left to inference.

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 behavioral burden and largely fails. 'Trigger' hints at an async backend job, but it says nothing about idempotency, whether the call blocks until generation completes, what happens if PnL was already generated, or auth requirements for the wallet.

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 short, front-loaded sentence with no filler. It is appropriately sized for its content, though the content itself is thin rather than the phrasing being wasteful.

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 4-parameter mutation/trigger tool with no annotations and no output schema, the description is inadequate: it omits parameter semantics, post-call behavior, and any indication of what the trigger produces or returns.

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 0% across 4 parameters, and the description only implies walletAddress via 'for a wallet.' It adds no meaning for chain, startTime, or endTime, so the agent has no guidance on the time-range or chain semantics those fields require.

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 (trigger/generate) and resource (backend PnL for a wallet), which cleanly separates it from read-only siblings like get_wallet_performance or get_hl_top_traders_by_pnl. It does not name any sibling explicitly, so it stops short of 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?

There is no statement of when to call this versus the many PnL/performance-reading siblings, nor any prerequisites or sequencing guidance. The agent must infer that this is a write-side trigger rather than a data fetch.

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 does meaningfully well: it discloses the algorithm (secp256k1), the custody model (managed-custody), how the keypair is used (trade signing), and the exact return field names. It omits whether keypairs are session-scoped/expiring, whether regeneration invalidates prior signatures, and any auth requirements for the managed flow.

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 tight sentences, purpose first, return values second. No filler and nothing that fails to earn 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?

For a zero-param tool the description covers purpose and outputs, but with no annotations and no output schema the agent still lacks lifecycle details (expiry, reuse across sessions, relation to managed_sign_in/build_sign_in_payload, whether the private key must be stored or used immediately) that this family of tools likely requires.

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?

Zero parameters, so the baseline is 4. The description goes further by naming the two return fields (sessionPrivateKey, sessionKey as compressed public key), which is useful since no output schema exists to declare them.

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?

Specific verb (Generate) plus resource (secp256k1 session keypair) with an explicit purpose clause ('for managed-custody trade signing'). This distinguishes it from the sibling generate_evm_wallet, which serves a different custody context.

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 'for managed-custody trade signing' implies when it is needed (prior to managed_* trade operations), but there is no explicit when-to-use/when-not guidance, no prerequisite chain, and no mention of the alternative generate_evm_wallet or session lifetime.

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 does disclose one genuinely useful trait: 'No auth required,' which tells the agent it can call this without credentials. Beyond that it does not state read-only semantics explicitly, rate limits, error behavior for an unknown address, or freshness of the data — gaps that matter for a tool with zero annotation coverage.

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 short sentences, zero waste, with the resource and its payload front-loaded and the auth constraint trailing as a qualifier. Nothing is repeated from the title or schema.

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 does list the key returned fields, which is the right thing to do for a read tool. It is nearly complete but stops short of distinguishing this from sibling state readers that appear to return comparable data.

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% with a single well-named required parameter (walletAddress), so the baseline is 3. The description adds no format hints (address casing, chain qualification) beyond what the schema already states.

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 and resource ('Get full HyperLiquid account state') and enumerates the returned content (positions, margin, balance, withdrawable amount), so the purpose is unambiguous. However, it offers no differentiation from near-identical siblings such as get_hl_clearinghouse_state, get_balances, get_portfolio, or get_wallet_info, which an agent must disambiguate before calling.

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 no when-to-use guidance and never names an alternative, despite a crowded field of overlapping account/balance readers. The only conditional information is the auth note, which is a prerequisite rather than usage routing.

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 does disclose one real behavioral trait: 'No auth required', which tells the agent this can be called unauthenticated. It says nothing about rate limits, freshness/latency of the mid prices, or the shape of the result, leaving meaningful behavioral 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?

Two short, front-loaded sentences with no filler; the resource and its scope come first and the auth note follows. Every clause 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?

For a zero-parameter read tool with no output schema, the description conveys what is returned (mid prices for all assets) and the auth posture, which is nearly everything an agent needs. A brief note on the return structure or data freshness would make it fully 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 tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly does not invent parameters.

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 ('Get') and resource ('all current mid prices') with an explicit scope ('across all HyperLiquid assets'). It is distinguishable from single-asset siblings like get_mark_price, but does not name them to sharpen the contrast.

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 word 'all' implies bulk retrieval rather than a per-asset lookup, so usage is inferable, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative such as get_mark_price or get_native_prices.

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 behavioral burden. It discloses the return contents (URL, method, params, response format), but says nothing about read-only safety, authentication requirements, or rate limits. Adequate but not rich.

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 states the resource and its return payload with zero filler. Every clause 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?

There is no output schema, but the description explicitly names the return fields (URL, method, parameters, response format), which largely compensates. For a one-parameter lookup tool this is close to complete; only auth and rate-limit context are missing.

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% and the single 'endpoint' parameter is documented with concrete examples in the schema itself. The description adds no syntax, format, or matching guidance beyond what the schema already provides, 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?

States a specific verb (Get) and resource (GDEX API endpoint details) and enumerates exactly what is returned: URL, method, parameters, response format. An agent can distinguish it from data-fetching siblings, though it does not explicitly name related tools like search_gdex_docs or get_sdk_pattern.

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 purpose implies usage (look up the contract for a named endpoint), but the description offers no explicit when-to-use, when-not-to-use, or alternative routing against sibling documentation/SDK tools. Usage is inferable rather than stated.

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 full behavioral burden, and it discloses almost nothing: no auth/permission requirements, no rate limits, no statement about whether zero balances or native tokens are included, and no return format. Only the implicit read-only nature of 'Get' is conveyed.

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 short, front-loaded sentence with no filler. It is efficient, but the brevity reflects under-specification rather than disciplined compression.

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?

No output schema and no annotations exist, so the description is the only source of behavioral context, yet it omits what the response contains (list shape, zero-balance handling) and how errors/permissions behave. Adequate as a minimum-viable read tool but leaves clear gaps.

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 the schema already documents walletAddress, chain, and the optional tokenAddress filter. The description adds no format or syntax detail (e.g., chain identifier format, address normalization) beyond restating the two required parameters.

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 (Get) and resource (token balances) scoped to a wallet and chain. An agent can distinguish it from get_usdc_balance and get_portfolio, though the description never names those siblings or clarifies the boundary (e.g., does it include USDC?).

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 when-to-use guidance, no prerequisites, and no mention of alternatives in a very crowded read-tool family (get_usdc_balance, get_account_state, get_portfolio, get_wallet_info). The agent must infer routing purely from the name.

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 full behavioral burden. It conveys only that this is a recent-activity read feed; it says nothing about how 'large' is thresholded, result ordering, pagination, rate limits, or auth requirements, all of which matter for interpreting a 'big buy' alert.

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 defines the resource and its scope with zero filler. Nothing is repeated or wasted.

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 two-parameter read tool with no output schema, the definition is minimally viable but thin: with no annotations and no output schema, an agent still cannot tell what the threshold for a 'big buy' is, how results are ordered, or what limit does. The essentials for selection are present; the essentials for correct interpretation are not.

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 only 50%: chainId is documented in the schema with an example, but 'limit' has no description anywhere. The description mentions neither parameter, so it fails to compensate for the undocumented limit or to clarify what limit controls (count vs. lookback window).

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 names a specific resource ('Big buy alert feed') and its content ('recent large buy transactions'), scoped to a chain, so an agent can distinguish it from generic read tools like get_trade_history or get_token_trades. However, it never names a sibling or clarifies the boundary with token-level trade feeds, leaving differentiation to inference.

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?

There is no statement of when to use this feed versus get_token_trades, get_trade_history, or get_trending_tokens, and no prerequisites or exclusions. The agent is left to infer that this is for surfacing whale/large-buy activity on a specific chain.

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 behavioral burden. It discloses that session-key auth is required, which is useful, but says nothing about pagination, result ordering, rate limits, or the shape of the returned history—gaps that matter for a history endpoint.

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 short sentences, front-loaded with the core operation and followed by the auth constraint. No filler or redundancy.

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?

There is no output schema or annotations, so the description is the only source of behavioral context, and it covers purpose and auth but not return format, pagination, or scope limits. Adequate for a simple two-parameter read but with clear missing detail.

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%, and the schema already explains both parameters (encrypted session key, control wallet address). The description adds no syntax or format detail beyond the schema, 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?

States a specific verb (Get) and resource (bridge order history) scoped to a user, so the operation is clear. It does not, however, distinguish itself from related siblings such as estimate_bridge or execute_bridge, which an agent comparing bridge tools might need.

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 on when to use this versus alternative bridge or history tools (e.g., get_trade_history, estimate_bridge). The only context offered is the auth requirement, which is a precondition rather than usage selection guidance.

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 at all, the description carries the full behavioral burden, and it does not state that this is a read-only, side-effect-free lookup, nor whether it requires auth or has rate limits. Enumerating the returned data categories is mildly informative but is closer to a return-value summary than behavioral disclosure.

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 lists exactly the four categories of data returned, with zero filler. Nothing could be trimmed without losing information.

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 zero-required-parameter lookup with full schema coverage and no output schema, the description usefully enumerates the return content, which compensates for the missing output schema. It stops short of usage context or a read-only statement, but nothing essential to invoking it correctly is absent.

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% and the single optional 'chain' parameter is fully documented in the schema, including the omit-for-all behavior. The description adds nothing about the filter, so the baseline 3 for schema-covered parameters 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 names a specific verb (Get) and enumerates the exact resource contents (supported chains, chain IDs, DEXes, capabilities), so an agent immediately knows what this returns. It is distinguishable from write-oriented siblings like buy_token and from narrower lookups like get_hl_perp_dexes, though it doesn't explicitly call out those relatives.

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?

There is no when-to-use guidance: it never says this is the discovery/metadata call to run before selecting a chain for buy_token, sell_token, or bridge operations. No alternatives or exclusions are named, leaving the agent to infer the call context.

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 full burden and it does not deliver. It does not say whether the call is read-only (implied by 'get' but unstated), what authorization is needed, whether results are paginated, or what the response contains.

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?

Extremely short and front-loaded, which is structurally fine, but the brevity is achieved through omission rather than efficiency. Still, nothing is wasted or misleading.

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 4-parameter, 2-required query tool with no annotations, no output schema, and 0% schema coverage, the description is incomplete. It should at minimum document the pagination params and chain identifier formats to let an agent invoke it correctly.

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 0% across four parameters (page, chain, limit, tokenAddress). The description only vaguely gestures at a token and adds no semantics for chain formats, pagination behavior, or limit defaults, leaving all four params undocumented.

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 verb+resource ('Get comments') which is clearer than a tautology, but 'for a token' is vague (comments keyed by token address?) and there is no differentiation from the sibling add_comment or from other token-detail tools. An agent gets the gist but not the distinguishing scope.

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 when-to-use guidance, no mention of when to prefer this over alternatives like get_token_details or add_comment, and no prerequisites stated. The agent must infer usage entirely.

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 full behavioral burden, and it discloses almost nothing: not whether results are static reference material or dynamic, not the return format, not whether the lookup is case-sensitive or falls back on partial matches. Only the implicit read-only nature of a 'guide' lookup can be inferred.

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, front-loaded with the verb and resource, with no filler. It is efficient, though the brevity is also part of the under-specification problem rather than pure economy.

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 lookup with full schema coverage and no output schema, the description is minimally adequate: an agent knows what it fetches. It omits when to prefer this over sibling guide tools and what the returned patterns look like, which for a documentation-retrieval tool is a meaningful omission.

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% and the schema's own description supplies rich examples ('SpotTradeForm', 'PositionTable', 'portfolio', 'theming', 'wallet', 'page-layouts'). The prose adds no syntax, casing, or fallback detail beyond that, 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?

States a specific verb and resource: retrieving React UI component patterns for GDEX trading interfaces. The resource is concrete and the domain is named. However, it does nothing to distinguish itself from nearby reference tools such as get_sdk_pattern, get_trading_guide, or search_gdex_docs, so an agent must guess which reference source applies.

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 no when-to-use guidance, no prerequisites, and no mention of alternatives. With six-plus sibling documentation/guide tools in the set, the absence of any routing hint is a real gap.

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 behavioral burden and discloses useful traits: no authentication is required, the result is limited to the top 300 wallets, and data is cached for 2 minutes. It does not describe return fields or error behavior, but the auth and caching details are the most important operational facts for this read endpoint.

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 three short, front-loaded sentences with no wasted words. It states the core result first, then appends only the two operational facts an agent needs.

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 read-only tool with no output schema, the description states the scope, size cap, auth requirement, and cache duration. However, it leaves 'custom' unexplained and provides no alternative routing or detail about the returned wallet fields, so it is only minimally 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 tool takes zero parameters, so the schema has no parameter documentation to compensate for. Per the rubric, zero parameters yields a baseline of 4; there is nothing additional the description could or should document.

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 gives a specific verb and resource: 'Get top 300 wallets ranked by net received.' That is clear enough for an agent to understand the tool's function. However, it does not explain what 'custom' means in the tool name or distinguish it from siblings like get_copy_trade_wallets and get_copy_trade_gems.

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 when-to-use guidance, no when-not-to-use conditions, and no alternatives. 'No auth' and 'Cached 2 min' are operational facts, not usage instructions, so the agent gets no help selecting this tool over related copy-trade wallet endpoints.

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 does disclose two traits: the operation is a read ('List') and requires no authentication. It says nothing about whether results are static, cached, or how many DEXes are returned, leaving meaningful behavioral gaps for a no-annotation 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?

Two compact sentences, front-loaded with the core action and scope, followed by the authentication note. No filler or redundancy.

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?

There is no output schema and no annotations, so the description should ideally say what the returned DEX list looks like (names, IDs, structure). For a simple one-parameter list tool this is adequate but not 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?

Schema description coverage is 100% and even supplies the Solana chain ID value, so the single parameter is already fully documented. The description's examples of DEX names add color but no additional parameter semantics, 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?

Specific verb ('List') plus resource ('supported DEXes') and scope ('for a chain'), with concrete examples (Raydium, Pumpfun on Solana) that make the output tangible. It does not explicitly differentiate itself from the similar-sounding sibling get_hl_perp_dexes, so it falls short of 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 context of use is implied (discover which DEXes are available on a chain before configuring copy trading), and 'No auth' is a useful prerequisite note, but no alternatives or when-not-to-use conditions are stated. The agent must infer that get_hl_perp_dexes covers a different venue.

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 does disclose two useful traits: 'No auth' and 'Cached 20s'. But it omits the return shape (how many tokens, what fields), whether results are ranked, and any rate-limit behavior beyond the cache window.

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?

Three short sentences, zero filler, with the core purpose front-loaded ahead of the auth and caching notes. Every clause 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?

For a zero-param read tool with no output schema, the description covers purpose, auth, and caching, but leaves the return format and ranking logic unspecified and offers no sibling differentiation. Adequate but with clear gaps.

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 takes zero parameters, so the schema has nothing to explain and the baseline of 4 applies. The description adds the relevant 'no inputs needed' implication through its absence of any parameter discussion.

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 and resource ('Get hot new tokens heavily traded by top wallets'), which is more concrete than a bare 'get tokens'. However, it never names or distinguishes itself from close siblings like get_trending_tokens, get_newest_tokens, or get_bigbuys, which an agent must disambiguate from.

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 when-to-use guidance, no exclusions, no named alternatives. The description says what the tool returns but nothing about when an agent should pick it over the many trending/new-token siblings.

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 full behavioral burden. It says nothing about what the guide contains, whether it is static reference text or account-specific, or what the response looks like. 'Get' implies read-only, but that is inference, not disclosure.

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 tight sentence with the resource front-loaded and no filler. It is not bloated, though the brevity is partly the reason other dimensions are thin.

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, no-annotation, no-output-schema guide tool, the description is minimally viable but leaves an agent guessing at what the guide returns and when in the copy-trade workflow it should be fetched.

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 chain enum already documents 'solana (spot copy) or hyperliquid (perp copy)', so the description's mention of Solana spot vs HyperLiquid perp is essentially duplicative. Baseline 3 applies when the schema does the work.

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 (Get) and resource (copy trading guide) and names the two supported platforms, so the agent knows what it retrieves. It does not differentiate itself from near-siblings such as get_trading_guide or get_component_guide, which is the only thing keeping it from 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 gives no when-to-use context: it never says to call this before create_copy_trade or create_hl_copy_trade, nor how it relates to get_trading_guide. Usage can only be inferred from the tool name.

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 load. 'List' implies a non-mutating read, and the session-key auth requirement is real behavioral context beyond the schema. But it omits pagination, return shape, and failure modes for an auth-gated endpoint.

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 short sentences, zero filler, with the purpose stated first and the auth prerequisite second. Nothing can be trimmed without losing information.

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 two-parameter read tool with no output schema, the description plus the fully covered schema gives an agent what it needs to invoke correctly: what it returns (a list of configs), for whom (a user), and under what auth. Only the return-field detail and pagination are absent.

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% – both 'userId' (control wallet address) and 'data' (AES-encrypted session key) are documented in the schema itself. The description adds no format, encoding, or sourcing guidance beyond that, 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?

States a specific verb and resource ('List all copy trade configurations') scoped to a user, which is enough to tell it apart from write siblings like create_copy_trade and update_copy_trade. It does not, however, distinguish itself from the near-identical get_hl_copy_trade_list sibling.

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 read usage and notes the session-key auth prerequisite, which is genuinely useful. It gives no explicit when-to-use vs when-not-to-use guidance and never mentions the close alternatives (get_hl_copy_trade_list, get_copy_trade_tx_list).

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 behavioral burden. It correctly implies a read operation ('List') and discloses the session-key auth requirement, which is genuinely useful, but says nothing about pagination, time-range scope, rate limits, or whether history is unbounded — significant gaps for a history-listing 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?

Two short sentences with zero waste; the core purpose is front-loaded and the auth prerequisite follows immediately. Nothing redundant.

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 history-listing tool with no output schema, no annotations, and only two opaque parameters, the description should say more about what is returned (fields, ordering, time window, pagination). It is too thin to let an agent call it confidently against its many siblings.

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% (both userId and data are documented as control wallet address and AES-encrypted session key), so the baseline is 3. The description's 'Requires session-key auth' reinforces the purpose of the data parameter but adds no format or syntax detail beyond the schema.

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 and resource ('List copy trade transaction history with PnL'), so an agent knows exactly what it retrieves. However, it does not distinguish itself from the near-identical sibling get_hl_copy_trade_tx_list, leaving the agent to guess which variant applies.

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 only guidance is the prerequisite 'Requires session-key auth.' There is no statement of when to use this tool versus get_hl_copy_trade_tx_list, get_copy_trade_list, or get_trade_history, and no exclusions or conditions.

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 full burden. It usefully discloses that no auth is needed and that results are cached for 2 minutes (a staleness constraint), but says nothing about ordering guarantees, return shape, or pagination for the 300-wallet set.

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?

Three short sentences, zero waste, with the core scope statement front-loaded and operational facts (auth, caching) trailing. 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?

For a no-param, no-output-schema read tool, the description covers what is returned (wallets ranked by totalPnl) plus auth and cache behavior. Minor gap: no indication of the per-wallet fields or whether the list can be truncated.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies the call is parameterless by framing the response as fixed at top 300.

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 (Get) and resource (wallets) with precise scope: top 300, ranked by totalPnl, on the Solana spot copy trade leaderboard. This separates it from generic siblings like get_top_traders, get_wallet_performance and the HL variants, though it never names an alternative explicitly.

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 when-to-use or when-not-to-use guidance is given. With sibling tools such as get_top_traders, get_copy_trade_list and get_copy_trade_custom_wallets in the same namespace, the agent must infer selection from the scope phrase alone.

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 full behavioral burden. It implies a read-only list of currently-live token launches, which is a small behavioral signal, but it omits any safety profile, pagination behavior, data freshness, or required permissions.

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 noun phrase with no front-loaded action or structure. It is too terse for a tool that has undocumented parameters and no annotations, leaving key information absent.

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 annotations, no output schema, and 0% parameter coverage, the description does not compensate at all. It fails to explain what is returned, how to page, or how the chain parameter works, making the definition incomplete for correct invocation.

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 three parameters (page, chain, limit) with 0% schema description coverage, and the description adds no meaning for any of them. An agent cannot determine what these parameters filter or control without guesswork.

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 names a specific resource (currently-livestreaming token launches), which is clearer than a tautology and distinguishable from generic token listings. However, it lacks a verb and does not explicitly differentiate from the nearby get_live_status sibling, keeping it from 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?

There is no guidance on when to use this tool, when not to use it, or which alternatives exist. The description is a standalone fragment with no contextual routing.

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 does disclose one behavioral fact: no authentication is required. However it says nothing about rate limits, response shape, pagination, or whether the list is exhaustive, and the read-only nature is only implied by 'Get'.

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 short clauses, zero waste, with the primary purpose and the return payload front-loaded. Nothing needs trimming.

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-param read tool with no output schema, the description covers what is returned (tradeable assets plus max leverage) and the auth posture. Without an output schema it could say a bit more about the returned fields, but nothing essential to invoking it is missing.

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 takes zero parameters, so per the baseline the schema carries no semantic load the description must compensate for. The description correctly describes a no-argument call.

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+resource ('Get all tradeable assets on HyperLiquid') and adds the payload detail (max leverage info). It does not differentiate itself from a close sibling like get_hl_meta_and_asset_ctxs or get_hl_perp_dexes, which an agent could reasonably confuse it with.

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?

Usage is only implied — an agent gathers that this lists assets for discovery. The 'No auth' note gives useful context on callability, but there is no explicit when-to-use vs alternatives guidance, and the near-duplicate siblings are not mentioned.

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 full burden; it discloses that no auth is required and warns that the default query silently omits builder positions, which is a real behavioral gotcha. It stops short of describing the returned shape or any pagination/rate-limit behavior.

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 purpose, then two tight sentences covering the dex caveat. Slight redundancy between 'Builder/HIP-3 positions live under their own dex' and 'default query does NOT show builder positions', but nothing is wasted.

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 two-param read tool with no annotations and no output schema, the description covers auth status, scope, and the silent-empty pitfall that would otherwise cause wrong conclusions. Only the exact contents/format of the returned state are left implicit.

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 the baseline is 3, but the description goes beyond the schema's 'Omit for the default USDC dex' by explaining the consequence of omitting `dex` (builder positions look empty) and giving a concrete example ('xyz:NVDA'). That adds meaning the schema alone doesn't convey.

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 and resource ('Get account state (positions, margin) on a HyperLiquid DEX') and scopes it to the HL DEX, which separates it from the sibling get_account_state and the position-specific get_perp_positions. An agent can pick it out without opening the schema.

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?

Gives clear contextual guidance for the key trap: builder/HIP-3 positions require passing `dex`, and omitting it yields a misleading empty result. It doesn't name alternative tools to use instead, but the usage condition is explicit and actionable.

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