GDEX Trading

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond the annotations – no mention of auth requirements, what gets stored, rate limits, or validation, which is a real gap for a write 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?

The single sentence is front-loaded and waste-free, but it is undersized for a 6-parameter mutation tool. Conciseness is achieved at the cost of substance.

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 write tool with low schema coverage and no output schema, the description is inadequate: it does not explain how to identify the target (tokenAddress + chain), what the message constraints are, 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 coverage is only 17% (just accountRef documented), so the description must compensate, and it does not. It says nothing about tokenAddress, chain, message, data, or userId, leaving five of six parameters undocumented anywhere.

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 (post) and resource (comment) with an object (token), so the agent can tell it is a write of a comment. There is no explicit differentiation from the sibling get_comments, but the purpose is otherwise unambiguous.

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 (e.g. auth via accountRef), and does not route the agent versus alternatives like get_comments. Only the bare object 'on a token' is conveyed.

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?

Annotations already declare this is a non-read-only, open-world, non-destructive mutation. The description adds meaningful behavior: the email is extracted server-side from a verified Google idToken and is not sent by the client, and the operation must precede oauth_login. It does not cover response behavior or idempotency, but the annotations reduce the burden.

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 front-loaded with the core action and then gives the precondition, error condition, data-flow constraint, and build requirement. Every sentence carries operational value with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter mutation with annotations and full schema coverage, the description covers purpose, timing, data source, and required payload construction. It does not describe the success response or post-call state, which is a minor gap given there is no output schema.

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 schema already documents both idToken and computedData, including server-side email extraction and the buildAssociateEmailComputedData helper. The description reinforces the security detail that the email is not client-provided, but largely repeats schema semantics, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: linking the email claim from a Google ID token to the caller's wallet. It distinguishes this from oauth_login by explaining the precondition and the error condition that triggers this tool.

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?

It explicitly states when to use the tool: before oauth_login when the wallet has no associated email yet, with the concrete symptom that oauth-login returns 404/code 108. It also names the required helper buildAssociateEmailComputedData, leaving little ambiguity about invocation 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?

Annotations only mark this as non-read-only and non-destructive; the description adds the crucial behavioral fact that the call mutates session-wide state by installing a Bearer token for all later requests. It omits token lifetime/expiry and failure behavior, but the key side effect is disclosed.

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 filler; the action is front-loaded and the consequence follows immediately.

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 login tool with a fully documented schema and no output schema, the description covers what the agent needs to call it and why. The remaining gap is disambiguation from the other sign-in tools in the sibling list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 100% schema description coverage ("GDEX API key (UUID format)"), so the schema carries the semantics. The description adds nothing about the key beyond what the schema already says, which matches the baseline of 3 for high coverage.

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 (authenticate) and the credential type (GDEX API key), so the agent knows exactly what this does. It does not, however, differentiate itself from sibling auth tools such as oauth_login, managed_sign_in, or generate_session_keypair.

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?

"Sets the Bearer token for all subsequent requests" implies this must be called before other tools, which is useful sequencing guidance. But it never states when to prefer it over oauth_login or managed_sign_in, nor what happens if called again with a different key.

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?

The description is consistent with readOnlyHint=true and openWorldHint=false — it only assembles an encrypted payload locally rather than performing sign-in. Beyond that it adds little: no statement about side effects, determinism, or that the wallet signature must already exist before calling. With annotations carrying the safety profile, a 3 fits.

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, both earning their place: the first defines the operation, the second routes the result to the consumer tool. Purpose is front-loaded with zero padding.

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 exists, yet the description says only "Returns the payload" without characterizing the computedData object an agent must pass to managed_sign_in. For a 6-parameter builder feeding a downstream call, that return-value gap and the missing provenance of nonce/signature leave it only minimally sufficient.

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 (five required) are documented in the schema itself. The description's phrase "from raw credentials" only gestures at the input set and adds no format or dependency detail beyond what the schema provides — 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 and artifact: "Build the encrypted sign-in computedData payload from raw credentials." The second sentence disambiguates it from its close sibling managed_sign_in by positioning this tool as the payload producer, not the sign-in executor.

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" gives clear flow guidance — build first, then submit with managed_sign_in. It stops short of naming where nonce/signature/sessionKey come from (e.g. generate_session_keypair) or when an alternative auth path (auth_login, oauth_login) applies, so no explicit exclusions.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a side-effect-free computation. The description adds that the output is an encrypted computedData payload composed from credentials, but is silent on secret handling and on how the payload is subsequently consumed. Note: 'raw credentials' sits in mild tension with the accountRef schema note that no secret is passed in chat, though this is a schema annotation, not an annotation contradiction.

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 verb and the output artifact front-loaded and no filler. It is appropriately sized for a one-line builder, though a brief pointer to the next step could have been added without bloat.

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 8-parameter builder with no output schema, the description should explain what the computedData payload is and how to use it (e.g., feed it into an execute tool). It names the artifact but leaves its shape and downstream usage unspecified, which is a meaningful gap given there is no output schema to fall back on.

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 8 parameters (action enum, nonce, amount, tokenAddress, apiKey, accountRef, etc.) are already documented in the schema. The description adds no syntax, format, or constraint detail beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (Build) and a specific resource (an encrypted managed-custody trade computedData payload) plus the input nature (raw credentials). An agent can distinguish it from execution siblings like gdex_execute_trade, 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?

There is no when-to-use or when-not-to-use guidance, and no mention of the likely downstream step (executing the payload) or of alternatives such as gdex_execute_trade. The builder-vs-executor relationship is left entirely 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 destructiveHint=true and openWorldHint=true already declared, the description still adds real value: it discloses the async request/confirm pattern via requestId and wait_for_trade, and that the wallet is managed/session-signed rather than a raw key. It does not state that native funds are irreversibly spent on a DEX route or what happens on a failed fill, which for a destructive trade tool is a notable omission.

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 sentences, front-loaded with the action and mechanism, then chains, then the follow-up step and the alternative. The chain list is long but functional; almost 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 12-parameter destructive trade tool with no output schema, the description covers the essential operating picture: supported chains, wallet model, async completion path, and the USDC alternative. Remaining gaps (failure/refund behavior, prerequisite connection via accountRef) are modest given how much the schema and annotations already carry.

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 parameter documentation is already carried by the schema (including the dex/referrer rejection notes and slippage constraints). The description adds only the inputToken restriction implicitly ('with the chain's native token'), so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Buy a token') plus the payment asset ('with the chain's native token') and the wallet/mechanism ('managed GDEX wallet, session-signed purchase_v2'). It enumerates supported chains and explicitly disambiguates from usdc_buy, so an agent can tell it apart from its buy siblings without reading 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 a clear routing rule ('To pay with USDC use usdc_buy') and a mandated next step ('Returns a requestId; follow it with wait_for_trade'). However, it says nothing about when to prefer limit_buy, managed_purchase, or execute_spot over this tool, so the broader alternative landscape 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?

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered. Beyond that the description adds nothing: it does not say the cancellation is irreversible, which account's orders are affected, whether it spans all markets, or what the agent gets back. No contradiction with annotations.

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; the destructive scope ('all open perp orders') appears immediately. Nothing to trim, nothing buried.

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?

Minimally adequate for a destructive bulk-cancel: the schema carries 100% parameter documentation and annotations carry the safety profile, and no output schema exists to explain. However, with zero required parameters declared, the description should have clarified the auth/account binding (accountRef vs walletAddress) and the blast radius of 'all'.

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 description adds no parameter detail (nothing about accountRef, walletAddress, apiKey, or sessionPrivateKey). Baseline 3 applies: the schema fully documents the parameters, so the description neither helps nor hurts here.

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 (Cancel), resource (open perp orders), scope (all), and venue (HyperLiquid) in one sentence. The 'all' explicitly separates it from the sibling cancel_perp_order, so an agent can route between the bulk and single-order tools 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?

No when-to-use framing at all: nothing says when to prefer this over cancel_perp_order, close_all_positions, or direct_cancel_order, and no prerequisite (e.g. needing a connected account or active session) is mentioned. The only guidance is implicit in the word 'all'.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the destructive write profile is covered structurally. The description adds only the word 'open' and says nothing about irreversibility, partial failure, whether an unknown orderId errors or no-ops, or the auth/session requirements implied by the four credential parameters.

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 waste; nothing is buried or redundant. It is efficient, though its brevity is partly under-specification rather than tight editing.

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 destructive, open-world mutation with six parameters including four credential fields and no output schema. The description omits how credentials are supplied, what a successful cancellation returns, and how errors or already-filled orders are handled — significant gaps for a cancel 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%, including the accountRef/credential parameters, so the schema does the heavy lifting. The description contributes no additional meaning about coin formatting, orderId provenance, or how credential parameters combine — 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 (cancel) and resource (a single open perp order) scoped to HyperLiquid, which separates it from cancel_all_perp_orders and update_order by name alone. It does not explicitly name any sibling, so the differentiation is inferable 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 when-to-use, when-not-to-use, or alternative routing is given. An agent must infer on its own that this is for a single order while cancel_all_perp_orders handles bulk, and that the order must still be open.

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?

Annotations already declare this is a non-read-only, non-destructive, open-world mutation, so the safety profile is covered. The description usefully adds that operations run through managed custody and need a pre-built payload, but says nothing about auth requirements, error behavior when removing a token not on the list, or whether the change is idempotent.

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 with the operation front-loaded and the prerequisite second; nothing is redundant. It is arguably under-specified rather than over-long, which is the better failure mode here.

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 output schema and a mandatory encrypted payload, the definition never tells the agent how to obtain the pre-built computedData (no pointer to a build/skill/guide sibling). Combined with no return-value or error context, this leaves a real gap for correct invocation, though the annotations cover the safety dimension.

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 computedData and the optional chainId are documented in the schema. The description only adds the qualifier "pre-built" for computedData, which is a marginal gain over "Encrypted computedData payload" and gives no guidance on how that payload is produced.

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 pair (add/remove) and the exact resource (the user's watchlist), so the agent knows this is a watchlist mutation tool. It stops short of naming the read-only sibling get_watchlist as the alternative, so differentiation relies on the agent inferring from the verb.

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?

"Requires pre-built encrypted computedData" gives one real prerequisite, which is more than most definitions offer. However, there is no explicit statement of when to prefer this over get_watchlist or other token tools (import_token, get_token_details), leaving the choice implied.

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?

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot convey: the backend frequently fails with TIMEOUT or 400/JSON parse errors. It does not say whether partial closes can occur or whether retries are safe.

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, purpose first, then the caveat and the alternative. Nothing is wasted and the critical warning is not buried.

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-close operation with no output schema, it covers purpose, reliability risk, and the safer alternative. An agent would still want to know execution semantics (market order? partial failure behavior?) but the essential information for choosing and invoking it is present.

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 four parameters (apiKey, accountRef, walletAddress, sessionPrivateKey) are already documented. The description adds nothing about them, which is acceptable at full coverage but is baseline, not value-add.

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 ('Close all open perpetual positions on HyperLiquid') and makes the all-vs-single distinction explicit by naming close_perp_position. An agent can immediately tell it apart from its siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent to the alternative ('Prefer close_perp_position per coin'), which is strong guidance. It stops short of saying when, if ever, this tool should be used instead, leaving the agent to infer that it is a bulk fallback only.

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

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

Annotations already flag destructive=true and openWorld=true, but the description adds real substance: the order type (reduce-only market), that the side is derived from the live HL position rather than supplied, and the three rejection cases. It omits auth/session prerequisites, though the schema's accountRef/apiKey fields cover that.

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 tight sentences, front-loaded with what the tool does, then the side-derivation rule, then failure conditions. Nothing is padded or 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 destructive, 10-parameter mutation tool with no output schema, the description covers the operation, the side logic, and the failure modes; the remaining gaps (fill/return details, session requirements) are largely carried by the annotations and the 100%-covered schema.

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 does clarify a genuinely tricky parameter interaction (a bare coin open on several builder DEXes is rejected, and a partial size must not exceed the live position), which is marginally useful but not syntax-level guidance 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 ('Close ... one perp position') plus the exact mechanism ('reduce-only market order'), which cleanly separates it from open_perp_position and close_all_positions in the sibling list.

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 concrete rejection conditions (flat/missing position, size exceeding it, bare coin across multiple builder DEXes) that tell the agent when this call will fail, and 'fully or partially' scopes it to a single position. It never names an explicit alternative such as close_all_positions, so it falls short of a 5.

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

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

Annotations already flag readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the safety profile is covered. The description adds the meaningful behavioral fact that this sets up continuous auto-mirroring of another trader's buys/sells, but it never discloses that real funds are committed, that loss/profit thresholds stop the mirroring, or that an authenticated account is required.

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, the core action front-loaded and the platform constraint immediately after. Nothing is wasted or buried.

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 destructive, open-world mutation with 14 parameters (7 required) and no output schema; the description is far too thin for that weight. It omits the authentication path (accountRef/gdex_connect), the implication that live trading starts immediately, and any mention of how the required risk parameters govern behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 14 parameters are documented in the schema itself. The description adds no extra meaning about buy modes, stop-loss/take-profit interaction, or how accountRef replaces raw secrets, 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 ('Create a new copy trade') plus its effect ('auto-mirror a Solana trader's buys/sells'), and the 'Solana only' clause implicitly separates it from the sibling create_hl_copy_trade. It's clear, though the sibling differentiation is by inference rather than by naming the alternative.

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' constraint tells the agent when this tool applies versus the HL equivalents, but there is no explicit guidance on prerequisites (gdex_connect/accountRef, chainId 622112261), no named alternatives, and no when-not-to-use conditions. Usage is 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?

Annotations already declare destructiveHint=true and openWorldHint=true, so the risk profile is known. The description adds no behavioral context beyond them: it does not say that this begins live copying and commits funds, that credentials (accountRef/apiKey/sessionPrivateKey) are required, or whether the trade can be edited afterward. For a destructive mutation with 11 parameters, that is a meaningful 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 resource. The second sentence is mildly redundant with 'copy trade' in the name but does add the long/short perpetual qualifier, so it earns most of 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, open-world creation tool with 11 parameters, no output schema, and auth-via-accountRef flow, the description omits the setup path (gdex_connect / sign-in), confirmation semantics, and what happens after creation. It names the operation but leaves an agent under-informed about safe invocation of a high-consequence call.

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 including copyMode, lossPercent, profitPercent, oppositeCopy, and accountRef are documented in the schema itself. The description adds only the general notion of long/short copying, which loosely maps to oppositeCopy but explains nothing about mode semantics or risk percentages. Baseline 3 is appropriate 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 clarifies with 'Copies a trader's long/short perpetual positions,' which distinguishes it from the spot-oriented create_copy_trade sibling by naming the HL perp domain. It does not explicitly say how it differs from create_copy_trade or update_hl_copy_trade, leaving the agent to infer scope from the 'HL perp' qualifier.

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 versus create_copy_trade, update_hl_copy_trade, or the related pause/resume tools, and no prerequisites are stated. The agent must discover on its own that this is the creation path for a new perp copy-trade subscription rather than a modification of an existing one.

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?

Annotations already declare destructiveHint=true, but the description goes well beyond that: it states irreversibility ('Cannot be undone') and, critically, enumerates the side effects that do NOT occur (positions not sold, TP/SL orders not cancelled). That non-effect disclosure is genuinely load-bearing information an agent cannot infer from the annotation.

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 tight sentences, front-loaded with the irreversible nature and the verb in caps. Every sentence carries distinct information: scope, side-effect boundary, reversibility, and alternative.

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 single-required-parameter destructive tool with full schema coverage and annotations, this covers the gaps that matter: permanence, what survives the delete, and the safer alternative. No output schema is needed since there is no meaningful return to explain.

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 the copyTradeId provenance ('from get_copy_trade_list') and the accountRef session mechanism are already documented in the schema. The description adds no parameter-level detail, which is acceptable given full schema coverage but earns only the baseline.

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 (PERMANENTLY delete) and a precisely scoped resource (a Solana copy trade configuration), and immediately disambiguates what is NOT touched (positions, TP/SL orders). An agent can distinguish this from pause_copy_trade or delete_hl_copy_trade without reading further.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the alternative for the 'stop copying' intent (pause_copy_trade instead) and states that positions and TP/SL orders must be managed separately, which is a real exclusion condition. Usage routing is fully specified.

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?

Annotations only say destructive=true; the description adds the critical blast radius — positions stay open, TP/SL orders are not cancelled, and the action is irreversible. This is exactly the behavioral detail an agent needs before calling a destructive delete.

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-loads PERMANENTLY, then separates consequences (positions/orders) from irreversibility and the alternative in distinct, waste-free sentences. Every sentence carries unique 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 destructive delete with no output schema, the description covers purpose, irreversibility, side-effect boundaries, and the alternative. Nothing an agent needs for a correct call 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%, so all five parameters are already documented (copyTradeId even cites get_hl_copy_trade_list). The description adds no further parameter syntax or meaning, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (delete) and resource (HL perp copy trade configuration) with explicit permanence emphasis. The distinction from pause_hl_copy_trade is named, so an agent can route without opening a sibling 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 explicit when-to-use routing: delete for permanent removal, pause_hl_copy_trade for temporary stop. Also directs the agent to the perp tools for closing positions/orders, covering the follow-up action.

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?

The annotations already declare the operation destructive, non-read-only, and open-world. The description adds useful auth context by saying the cancellation is performed directly with a private key on HyperLiquid, but it does not explain irreversibility, failure behavior, or why one would use privateKey versus accountRef.

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 definition is a single front-loaded sentence with no redundant words. Its brevity is appropriate, and any missing detail is a completeness issue rather than verbosity.

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 trading mutation, the description gives the essential action, venue, and auth method. However, it omits important operational context such as when to use accountRef instead of privateKey, what kind of open order is meant, and what the agent should expect after cancellation.

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 coin, orderId, accountRef, and privateKey. The description only reinforces the private-key path and adds no syntax, constraints, or meaning 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?

The description states a specific verb (cancel), resource (open order), platform (HyperLiquid), and auth method (private key), so the tool's basic purpose is clear. It does not explicitly differentiate itself from sibling cancellation tools such as cancel_perp_order, cancel_all_perp_orders, or hl_cancel_outcome_order.

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 explicit when-to-use guidance, no when-not-to-use guidance, and no named alternatives. The word 'directly' hints at a direct private-key signing path, but the agent must infer when to choose this over managed or session-based cancellation tools.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so 'without executing' largely restates the safety profile. It does add useful return context (estimated output, provider, time) in the absence of an output schema, but says nothing about quote staleness, rate limits, or fees beyond the headline fields.

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, followed by return shape. No filler or redundant restatement of the 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 simple three-parameter read tool with no output schema, the description covers purpose and return fields adequately. Minor gaps remain around quote validity/expiry and whether execution must follow promptly, which matter for a bridge quote workflow.

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% (amount in raw units, source/destination chain IDs), so the schema does the parameter work. The description adds no unit conventions or constraints of its own, making 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 a cross-chain bridge quote') on a specific resource, and immediately scopes it as non-executing. The phrase 'without executing' implicitly separates it from the execute_bridge sibling, so an agent can pick between quote and execution without inspecting 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?

Gives a clear condition for use: fetching a quote when no execution is desired. The counterpart (executing a bridge) is implied rather than named, and no prerequisites or exclusions (e.g., quote expiry, minimum amounts) are stated, so it is clear but not fully routing-grade.

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?

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds the managed-custody auth prerequisite, which is genuine extra context, but omits what funds movement is irreversible, failure/rollback behavior, and how the session-key vs apiKey paths differ.

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, action first, prerequisite second. No waste whatsoever.

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, open-world, 7-parameter transaction with no output schema, the description is thin: no mention of required ordering with gdex_connect, no fee/slippage or irreversible-funds warning, and no guidance on the auth variants implied by apiKey/sessionPrivateKey. Schema and annotations cover the rest, so it 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 coverage is 100% (7 params, all documented), so the schema itself carries the heavy lifting — including accountRef's explanation of how it supplies session key and API key without passing secrets in chat. The description adds no parameter meaning beyond the schema, so baseline 3 is correct.

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 ('Execute a cross-chain bridge transaction'), which is clearly a mutating action. However it does not distinguish itself from near-identical siblings such as usdc_execute_bridge or estimate_bridge, so an agent must open the schema to route correctly.

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?

'Requires managed-custody auth' gives a precondition, which is more than most mutating tools provide. But it never says when to use this bridge versus estimate_bridge (preview) or usdc_execute_bridge, nor what to do first (e.g. gdex_connect).

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?

Annotations already declare destructive=true, openWorld=true, and readOnly=false, so the safety profile is covered. The description adds useful context about custody mode (private key, no managed custody) and feature support (TP/SL, builder fees), but does not cover risk, reversibility, or auth flow details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action and followed by key features. No wasted words, though the second sentence is a brief feature list rather than deeper guidance.

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 trade tool with 15 parameters and no output schema, the description is somewhat sparse. The schema covers parameter details, but the description does not clarify the relationship between privateKey and accountRef, nor what execution returns, leaving minor 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 93%, so the schema already documents nearly all parameters. The description mentions TP/SL and builder fees but adds no syntax or format guidance beyond what the schema provides; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Execute a cross-margin perpetual trade') and distinguishes itself from sibling execute_isolated_perp via 'cross-margin' and from managed tools via 'directly with a private key (no managed custody)'.

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?

Provides a usage condition (private key, no managed custody) but does not explicitly say when to choose this over alternatives like execute_isolated_perp, open_perp_position, or managed tools. 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is known. The description adds the auth mechanism ('with a private key'), which is useful, but it omits critical trade behavior: irreversibility, funds at risk, how reduceOnly/stopLoss/takeProfit interact, and that accountRef is an alternative to passing a secret. Worse, saying it requires a private key conflicts with the schema, where privateKey is optional and accountRef can supply credentials instead.

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 short and front-loads the action, which is good. But for a 15-parameter destructive trading tool it is under-specified rather than truly concise, and the second sentence duplicates information already present in the 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?

This is a complex, destructive, open-world trading tool with 15 parameters and no output schema. The description omits risk warnings, credential handling (privateKey vs accountRef from gdex_connect), order-type semantics (isMarket vs price), and any indication of what happens on success or failure, leaving the agent materially under-informed for a high-stakes call.

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 47% across 15 parameters, so the description is expected to compensate. Instead, its only parameter-related statement ('Requires explicit leverage') merely repeats the schema's own leverage description and says nothing about coin, isLong, price, positionSize, reduceOnly, stop-loss/take-profit, builder fee fields, or the privateKey-versus-accountRef choice.

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 ('Execute an isolated-margin perpetual trade'), and the 'isolated-margin' qualifier distinguishes it from execute_cross_perp. It does not, however, clarify how it relates to similarly named siblings such as open_perp_position, place_perp_order, or gdex_execute_trade, leaving ambiguity about which perp entry point to choose.

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?

'Directly with a private key' and 'Requires explicit leverage' imply some preconditions, but there is no explicit guidance on when to use this tool versus execute_cross_perp, open_perp_position, or place_perp_order. The agent is left to infer the selection criteria 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?

Annotations already declare destructiveHint=true and openWorldHint=true, so the description's useful additions are limited to the fact that execution is direct/on-venue and requires a private key. It says nothing about irreversibility, fee handling (builderFeeRate), slippage or failure behavior, which matter for a destructive trade 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. It is efficient, though the terseness borders on under-specification for a destructive trading 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?

With 9 parameters, two auth paths, no output schema and a destructive annotation, an agent still lacks guidance on order semantics (market vs limit), price handling for market orders, fees, and what the call returns. The description covers only the venue and the key requirement.

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 67% and the description adds no parameter meaning beyond the auth hint. It ignores the important nuance that accountRef is the secret-free alternative to passing privateKey in chat, and does not explain how isMarket (default true) interacts with the required price field or what builderFeeRate/builderFeeAddress do.

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 concrete verb+resource+venue: 'Execute a spot trade directly on HyperLiquid'. This distinguishes it reasonably from execute_cross_perp / execute_isolated_perp, though it never explains how it relates to siblings like gdex_execute_trade, limit_buy or managed_purchase.

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 'directly' hints at a self-custody path, but there is no explicit statement of when to use this instead of gdex_execute_trade, limit_buy/limit_sell, or the managed_* tools. No preconditions (funding, session key, whitelisting) are 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?

The readOnlyHint=true and openWorldHint=false annotations already establish that this is a safe, closed-domain read, so the bar is lower. The description does add value beyond them by disclosing the shape of the return (step-by-step instructions plus code), which matters because there is no output schema. It stops short of stating length, depth, or how it differs from the other guide tools.

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, no filler and nothing redundant. Every clause (end-to-end, step-by-step, with code) adds 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 read-only, single-enum-parameter tool with no output schema, the definition is adequate: safety is covered by annotations, the enum is fully documented, and the return format is hinted at. The missing piece is routing context against the numerous sibling documentation tools, which leaves the agent guessing when to choose this one.

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 single parameter has 100% schema description coverage and a fully enumerated value set, so the schema carries the semantics. The description adds nothing about the enum values or what each workflow explanation contains, 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 ("Explain") and resource ("end-to-end GDEX trading workflow") plus what the output contains (step-by-step instructions and code). It does not, however, distinguish itself from the many adjacent guide/doc siblings such as get_trading_guide, get_copy_trade_guide, get_component_guide, and search_gdex_docs, so an agent cannot tell on description alone which documentation tool to pick.

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 named alternative, despite a crowded sibling space of overlapping guide tools. The eleven workflow enum values imply a scope but the description never says when this is preferable to get_trading_guide or search_gdex_docs.

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?

Annotations already cover the read-only, closed-world safety profile, so the description's added disclosure that 'No secrets are returned' is genuine extra value for an agent handling credentials. It also enumerates what the response contains, which annotations alone would not convey.

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 the return fields in a tight parenthetical. Zero filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully names the key returned fields and rules out secrets. A slightly fuller picture of the return shape (e.g. one vs many accounts, session-age units) would make it 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 no parameters, so there is nothing to document and the baseline for a zero-param tool applies. The description correctly does not waste space on parameter details.

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 accounts connected on this machine', then enumerates the returned fields (accountRef, control wallet, managed wallets, session age). This clearly separates it from sibling read tools like get_wallet_info or gdex_status, 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?

The phrase 'connected on this machine' implicitly scopes usage to local session state (presumably after gdex_connect), but there is no explicit when-to-use, when-not-to-use, or alternative tool named. Usage is inferable but not 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?

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the write/network profile is partially covered. The description adds meaningful context beyond that: it discloses the return payload (accountRef plus public addresses), explains that the credential stays local rather than in the conversation, and implies a persistent credential store. It does not describe failure modes or whether connectivity to the exchange is required at connect time.

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 sentences, zero filler; the security constraint and the three modes are front-loaded before the downstream routing advice. The long middle sentence is dense with necessary branching detail rather than padding.

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 compensates by stating what is returned (accountRef plus public addresses) and how to use it downstream. For a connection/auth tool with full annotation coverage and full schema coverage, nothing an agent needs in order to call it correctly 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 description coverage is 100%, so the baseline is 3. The description goes beyond the schema by tying each parameter to a mutually exclusive intent (keyFile = sign in, create:true = make a new unfunded local wallet, accountRef = refresh an existing session) and by clarifying that accountRef is the token forwarded to all downstream trading tools.

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 (connect a GDEX trading account) and immediately names the three distinct modes of operation, which is enough for an agent to distinguish it from sibling auth tools such as auth_login, managed_sign_in, or generate_session_keypair. The security framing ('without putting any secret in the conversation') further separates it from tools that handle raw keys.

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 when-to-use guidance per parameter branch (keyFile to sign in from a key file, create:true for a new local wallet, accountRef to refresh) plus the routing rule that accountRef should be passed to any trading tool instead of sessionPrivateKey/privateKey. It also states a hard negative ('Never ask the user to paste a private key or seed phrase'). It stops short of explicitly contrasting against sibling connection tools like gdex_accounts or gdex_status.

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?

Annotations already flag destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds genuinely useful context beyond that: the destruction is scoped to local key material, funds are unaffected, and the action is reversible via gdex_connect. It does not cover error cases (e.g. unknown accountRef).

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, with a parenthetical that clarifies scope and a trailing clause that covers safety and recovery. 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 single-parameter destructive tool with annotations covering the safety profile and no output schema, the description supplies the key missing pieces: what is deleted, that funds are safe, and how to undo it. Minor gaps remain around failure behavior for an invalid accountRef.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 100% schema description coverage ('Account to forget'), so the schema carries the semantics. The description adds no format or identifier guidance beyond the schema, 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?

The description states a specific verb ('Forget') and resource ('a connected account on this machine') and immediately clarifies the mechanism (deletes its stored keys). It is easily distinguished from siblings like gdex_connect and gdex_accounts.

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?

It gives clear context: use this to remove a locally stored account, and it names the follow-up path (reconnect later with gdex_connect and the key file). It does not state explicit exclusions or when-not-to-use, which keeps it short of a 5.

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

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

Beyond the destructiveHint/openWorldHint annotations, it discloses non-obvious behavior: it re-quotes first, moved/expired terms return status 'revised' with a new preview instead of trading, and the outcome statuses (denied, revised, submission_unknown). These are real behavioral traits an agent needs to avoid double-submitting.

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?

Dense but front-loaded: the core action and approval condition lead, followed by re-quote behavior and the follow-up/retry rules. Every clause carries information, though the single packed paragraph could be broken up for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so at a high level ('Returns an operation; follow it with gdex_operation') while enumerating the possible statuses. It is nearly complete for a 2-param mutation tool, missing only a fuller account of the success payload.

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 50% (previewId has no schema description), so the description must compensate. It clearly defines userApproved semantics ('only after the user approved THIS preview's terms'), adding meaning beyond the schema, and previewId's meaning is implied by the preview-flow context, though not spelled out.

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 ('Execute a preview') and ties it to the preview-based flow, which distinguishes it from the direct execute_* siblings (execute_spot, execute_cross_perp) and from gdex_preview_trade that creates the preview. An agent can identify the tool's role 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 explicit when-to-use conditions: userApproved=true only after the user approved THIS preview, otherwise the delegated policy must allow it; and explicit follow-up ('follow it with gdex_operation') and a when-not rule ('Never call again for the same intent after submission_unknown'). This is actionable routing 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?

Annotations already declare readOnlyHint=true and the description is consistent with a non-mutating preview ('Returns a preview; execute it with gdex_execute_trade'). It adds real behavioral context beyond the annotations: the preview runs 'against its live state', the close/reduce is reduce-only, and it handles the correct side for both longs and shorts. It does not describe slippage handling or failure conditions.

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 tightly packed sentences with the core purpose front-loaded and the execution handoff at the end. Every clause earns its place, though the density means no clause is elaborated enough to fully document the action branches.

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 9-parameter tool with no output schema, the definition covers the high-level flow and confirms a preview is returned, which is the most important thing an agent needs to know. But it leaves half the parameters (dex, accountRef, slippagePct, amount/tokenAddress pairing) unexplained and gives no detail about the preview payload the agent must inspect before executing.

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 56%, so several parameters (dex, accountRef, slippagePct) are undocumented in both places. The description does map the action semantics (close/reduce -> perp, sell -> spot) which helps interpret the enum, but it adds no syntax or format detail beyond that. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Preview an exit for an existing position') and splits the two supported cases explicitly: close/reduce a perp vs sell a spot token back to USDC. It names the sibling that performs the follow-up action (gdex_execute_trade), so an agent can distinguish it from execution siblings without reading 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?

Clear context: this is the preview step and execution belongs to gdex_execute_trade, giving the agent a workflow. It does not, however, tell the agent when to choose close vs reduce vs sell, nor how it relates to siblings like gdex_preview_trade or close_perp_position, so the routing is only partially resolved.

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?

Adds real behavioral context beyond the readOnly/openWorld annotations: the call blocks up to waitSec, it deliberately looks up the trade instead of resending when a submission is unknown, and it surfaces needs_retry rather than performing the sell itself. This is exactly the kind of disambiguation that prevents an agent from double-submitting, and nothing contradicts readOnlyHint=true.

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-loads the primary action, then layers the recovery semantics compactly in a single dense sentence plus a closing fallback clause. The nested parentheticals make it slightly hard to scan, but no clause is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a stateful polling/reconciliation tool with no output schema and no annotations covering semantics, the description covers both modes, the waiting behavior, and the notable terminal states (funded/filled, submission_unknown, needs_retry). It could still say more about what the listing mode returns, but the critical call-time information is present.

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?

opId has no schema description, and the description compensates by explaining its dual role: with it the call follows/reconciles a specific operation, without it the call lists recent operations. waitSec and accountRef are already documented in the schema at 67% coverage, so the remaining gap is small.

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 ('follow or recover an operation by opId') plus the alternate listing mode when opId is omitted, so the two shapes of the call are distinguishable. It does not, however, contrast itself with the many similar polling siblings (wait_for_trade, usdc_wait_for_trade, managed_trade_status), and the bare name gdex_operation carries no meaning on its own.

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 concrete selection context: use it to follow funding/fill progress, to resolve a submission_unknown result, or to detect a needs_retry state, and use it without opId to list recent operations. It stops short of telling the agent when another polling tool (e.g. wait_for_trade) is the better choice.

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?

Annotations already cover safety (readOnlyHint, openWorldHint), so the description's job is to add non-obvious behavior — and it does: it discloses that each section reports ok or unavailable and that 'unavailable means unknown, not empty', which prevents the agent from misreading partial failures as zero balances. It still omits auth requirements, rate limits, and freshness/caching semantics.

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, front-loaded with the resource contents and ending with the one caveat that changes how results must be interpreted. 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?

With no output schema, the description carries the return-value burden well by enumerating sections and their status semantics, which is the most important thing for an open-world read tool. It falls short only on the required accountRef argument and on any mention of auth or scope of access.

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% for the single required parameter accountRef, and the description never mentions it. The agent cannot tell from either source whether accountRef is a wallet address, an internal account id, or a session-scoped handle — a gap that matters for a tool that reads another account's holdings.

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 the resource precisely and enumerates its parts: unified USDC + gas balances per chain, Hyperliquid positions across every DEX, open orders, and unfinished operations. The aggregation scope ('unified', 'per chain', 'on every DEX') implicitly distinguishes it from narrower siblings such as get_perp_positions, usdc_get_balances, or get_hl_open_orders. An agent can tell what this returns without opening any 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?

There is no when-to-use guidance and no alternative is named, despite many overlapping siblings (get_balances, get_portfolio, get_account_state, get_perp_positions). The agent is left to infer that this is the aggregate snapshot. The second sentence describes output interpretation, not usage selection.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds behavior beyond annotations: a 60-second expiry, the returned previewId, and confirmation that no trade occurs. These are concrete, useful traits for an agent planning a trade.

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 sentences, front-loaded with the core purpose and return value. Dense but every clause contributes needed information. Slightly run-on first sentence, but no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 18 parameters and no output schema, the description covers the return value (previewId) and the most ambiguous parameter choices (kind, notionalUsd vs marginUsd). The schema carries the rest, so the description is sufficiently complete 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?

Schema description coverage is 89%, so the baseline is 3. The description adds critical guidance that isn't fully captured in the schema: it distinguishes notionalUsd (position size) from marginUsd (collateral) for perps and warns 'never guess which,' and clarifies the meaning of kind values (spot uses USDC wallet).

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: 'Turn an explicit trade intent into exact executable terms without trading.' Explicitly distinguishes itself from the execution sibling by noting it returns a previewId for gdex_execute_trade. An agent can immediately tell this is a preview/simulation tool, not an execution tool.

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?

Names the alternative (gdex_execute_trade) and implies the workflow: preview first, then execute. Provides kind options (spot, perp_open, perp_close) and a rule for perps (give notionalUsd or marginUsd, never guess which). Lacks an explicit 'when not to use' exclusion, but the context is clear.

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

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

Annotations already cover safety (readOnlyHint=true) and external reach (openWorldHint=true), so the description only needs to add context. It does: it discloses that account data is returned without secrets, that policy is reported per account, and that pending operations and setup guidance are included. It omits auth/prerequisite or failure-mode notes, keeping it below 5.

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 routing cue 'Start here' followed by a tight enumeration. Every clause carries information and nothing is repeated from structured fields.

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 parameters and no output schema, the description carries the burden of describing what comes back, and it does so field by field. An agent knows what it will receive and why to call it first, so nothing material is missing for a zero-arg read-only status tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so per the rubric the baseline is 4. The description correctly does not invent parameter semantics and instead describes the response content, which is the right use of space here.

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 ('Reports') and enumerates exactly what the status covers: version, connected accounts, API reachability, delegated trading policy, pending operations, supported trade kinds, and the next setup step. The opening 'Start here' positions it as the entry-point diagnostic and cleanly separates it from action siblings like gdex_connect, gdex_accounts, and gdex_execute_trade.

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?

'Start here' gives an explicit trigger for when to call the tool (before doing anything else), and 'the next setup step' hints at the onboarding flow it feeds. It does not name when-not-to-use or a specific alternative diagnostic, so it stops short of the full 5.

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

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

Annotations cover the safety profile (readOnlyHint, openWorldHint=false), and the description adds real behavioral detail: it runs offline with no network call, returns only the address by default, and reveals secrets only when asked. It doesn't state whether the wallet is persisted or discarded, which is the one 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?

Three short sentences, zero waste, with the defining constraint (offline) front-loaded before the alternative and return behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description tells the agent exactly what comes back (address only, or privateKey/mnemonic with revealSecrets) and when to use a sibling instead. Nothing essential is missing 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?

Schema coverage is 100% and the schema already documents revealSecrets including its side effect. The description reinforces the same fact ('Returns only the address unless revealSecrets is true') but adds no new syntax or format detail, 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 ('Generate a new EVM wallet') plus a distinguishing qualifier ('offline (no network call)'). It clearly separates itself from gdex_connect, which is the persistence/trading path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: use this for an offline throwaway wallet, but 'use gdex_connect { create: true } instead' when you need to trade with it. When-to-use and the alternative are both named directly.

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

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

The description says 'Trigger backend PnL generation', an action verb implying server-side state change or job creation, while the annotations declare readOnlyHint=true. That mismatch is exactly the kind of conflict the annotations are meant to rule out, so it reads as an annotation contradiction rather than added context.

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 or repetition. It is efficient, though it is short by omission rather than by disciplined editing.

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 exists, so the description should carry more of the load, yet it omits return shape, whether generation is synchronous or polled, and the meaning of the three optional parameters. For a four-parameter, zero-coverage tool it is not complete enough.

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% for four parameters, and the description only alludes to walletAddress. It says nothing about what chain accepts (the schema allows string or number), whether startTime/endTime are unix seconds or milliseconds, whether they are optional, or what window is used by default.

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?

Names a specific verb (trigger/generate), resource (PnL), and scope (a wallet), so the agent understands it produces a PnL report for one address. It does not distinguish itself from nearby siblings such as hl_list_user_copy_pnl, get_wallet_performance, or get_nof1_analytics, 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 when-to-use guidance, no mention of prerequisites, and no routing to alternatives even though several siblings return PnL/performance data. The agent is left to infer that this is a generation trigger rather than a read of already-computed PnL.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: only the public key is returned by default, and the private key would end up visible in the conversation. A minor gap remains — it never states explicitly that the key is not persisted locally (only implied by contrast with gdex_connect) nor whether the keypair can be reused after the session.

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, and the routing constraint ('Advanced/manual signing only') plus the preferred alternative are front-loaded. Nothing would be lost by 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?

There is no output schema, and the description does state what is returned (public sessionKey, or the private key when opted in), which is the key fact for a caller. It stops short of covering persistence or lifetime of the generated keypair, a small omission for a security-sensitive tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single optional boolean, and the schema already explains that revealing it puts the key in the transcript. The description restates that consequence without adding syntax or format detail, so 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+resource ('generate a secp256k1 session keypair') and immediately scopes it ('Advanced/manual signing only'), which separates it from signing siblings. It also names the sibling it is not (gdex_connect), so an agent can choose 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?

Explicit when-to-use ('Advanced/manual signing only') and an explicit preferred alternative ('Prefer gdex_connect, which signs in and keeps keys on this machine'). The tradeoff that selects the alternative is stated, not implied.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds a genuinely useful trait not present in structured data — 'No auth required' — and, in the absence of an output schema, enumerates what the returned state contains. It does not mention freshness/caching or rate limits, keeping it short of a 5.

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 with zero filler; the resource scope and returned fields lead, and the auth note is relegated to a short trailing clause.

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 low-complexity, single-parameter read tool with no output schema, the description covers both what comes back and the auth posture, which is sufficient to call it correctly. The missing piece is routing versus the many sibling account/state tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 100% schema description coverage, so the schema already explains walletAddress. The description adds no format, chain, or validation detail beyond implying the account belongs to a wallet — baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get full HyperLiquid account state') and enumerates the returned content (positions, margin, balance, withdrawable amount). However, it does not distinguish itself from close siblings such as get_hl_clearinghouse_state, get_hl_spot_state, or get_perp_positions, which plausibly return overlapping data.

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 prefer this over the several sibling state/balance tools (get_hl_clearinghouse_state, get_usdc_balance, get_portfolio). Usage must be inferred from the resource name alone; 'No auth required' is context, not a selection criterion.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful operational fact, 'No auth required', but says nothing about response shape, freshness/staleness of prices, rate limits, or whether assets with no mid price are omitted.

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, and the scope ('all HyperLiquid assets') is front-loaded before the operational note about auth. Nothing could be cut 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 no-parameter read tool with annotations covering safety and no output schema, this covers the core need: what it returns, over what universe, and that no credentials are needed. A brief note on return format or price staleness would make it fully self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the baseline is 4; the schema is an empty object and there is nothing for the description to document. No misleading parameter discussion is present.

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 all current mid prices') plus an explicit scope ('across all HyperLiquid assets'), so an agent knows exactly what the call returns. It stops short of distinguishing itself from the closely named sibling get_mark_price, so an agent comparing the two still has to infer the difference.

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: 'all current' signals a bulk price snapshot, which suggests calling it when you want a market-wide view rather than a single-asset quote. No explicit when-to-use, when-not, or named alternative (e.g. get_mark_price for a single asset) is 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully discloses the shape of the returned data (URL, method, parameters, response format), which goes slightly beyond annotations, but adds nothing about caching, coverage limits, or whether unknown endpoint names error out.

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; the resource and the returned fields come first, and nothing is repeated from 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?

For a read-only lookup with one fully documented parameter and no output schema, the description compensates by naming the return contents (URL, method, parameters, response format), which is roughly what an agent needs to decide to call it. Minor gap: no hint about endpoint-name coverage or failure behavior for unknown keywords.

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 in the schema with concrete examples ("buy_token", "hl_create_order", "deposit", "portfolio"). The description adds no syntax or matching guidance 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 (Get) and resource (GDEX API endpoint details) and enumerates the returned fields (URL, method, parameters, response format). It is clearly distinct from execution tools like execute_spot, though it does not explicitly contrast itself with sibling doc-lookup tools such as 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?

Usage is only implied: an agent infers it should call this when it needs to know how to call a GDEX endpoint. No when-to-use condition, prerequisites, or alternative (e.g., search_gdex_docs, get_skill_file) is named, even though several documentation-style siblings exist.

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