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

No annotations exist, so the description carries the full burden. 'Resting' usefully implies only open/unfilled orders can be cancelled, which is real behavioral signal, but there is no mention of what happens on an already-filled or nonexistent order, whether cancellation is irreversible, or any permission requirements.

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

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

A single sentence with the action and identifier front-loaded and a parenthetical pointer at the end. Nothing is redundant or padded.

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

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

For a two-parameter mutation with no annotations and no output schema, the description covers the happy path adequately — how to find the id and what gets cancelled — but leaves outcome and failure semantics unspecified.

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 strong per-property descriptions (base symbol example 'BTC', 'uint128 order id, decimal string'), so the schema already does the heavy lifting. The description only restates that the order is identified by its id, adding no format or validation detail beyond the schema.

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

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

States a concrete verb (cancel) plus a precise resource (resting perp order) and identifies the keying parameter (order id). The word 'resting' also implicitly separates it from close_position, though it never names that sibling explicitly.

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

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

Gives an actionable workflow pointer — 'see get_account for open orders' — which tells the agent where the orderId comes from. It stops short of stating exclusions or when to prefer close_position over cancel.

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

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

With no annotations, the description carries the burden and does real work: it reveals this is a one-time, non-repeatable mutation, specifies the credit amount, and flags the state precondition (no open positions or orders) that causes failure. It stops short of saying how failure surfaces (error vs. silent no-op) or what the call returns, which matters for a write with no output schema.

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 load-bearing: the first defines the action and reward, the second defines the gate. The most decision-relevant facts (one-time, amount, precondition) are front-loaded 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 zero-parameter mutation with no annotations and no output schema, the description supplies what an agent needs to decide whether to call it: what it grants, that it is single-use, and the blocking state condition. Minor gap: no hint about the result (transaction hash, balance change) or how a rejected claim is reported.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies nothing is passed in — the wallet is fixed as the server wallet — leaving no parameter ambiguity.

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 (claim), the exact resource and amount (one-time 1,000 paper USDso perps credit), the target (server wallet) and environment (testnet play money). No sibling tool performs anything resembling a credit claim, so it is unambiguously separable from list_markets, get_account, place_order, etc.

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

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

Gives an explicit precondition that also functions as a when-not-to-use rule: 'Only works if the wallet holds no perp positions or orders.' No alternative tool is named, but there is no plausible substitute action here, so the guidance is operationally complete.

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

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

With no annotations at all, the description still discloses the meaningful mechanics: it is a market order (so price impact/slippage applies), it is IOC (won't rest on the book), it hits the server wallet specifically, and the size is derived rather than supplied. It does not state required permissions, what happens if the position is zero, or how a residual after partial IOC fill is handled.

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 front-loaded sentence that states scope, mechanism, order type, time-in-force, and sizing rule with zero padding. Nothing to trim and nothing reordered.

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 mutating trading tool with no annotations and no output schema, the description covers the mechanism well but omits failure/no-position behavior, permissions, and what the response contains (fill price/quantity, residual position after a partial IOC fill). Those gaps matter for an agent deciding whether to invoke it.

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

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

Single parameter with 100% schema coverage, so the schema already explains symbol as the base symbol. The description only adds that the symbol identifies the single market whose position is closed, which is minimal but consistent; baseline 3 applies when the schema does the heavy lifting.

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

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

A specific verb and resource ("Close ... entire position in one market") plus the exact mechanism: an opposite-side IOC market order sized to the open position. This distinguishes it from the generic place_order/cancel_order siblings without needing to open their schemas.

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 implied by the name and description — you call it to flatten an existing position rather than to open or partially adjust one. There is no explicit when-to-use vs. place_order guidance and no stated preconditions (e.g. behavior when no position exists), so the agent must infer.

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

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

With no annotations, the description bears the full burden; it usefully discloses the default server-wallet behavior and the categories of data returned. However, it does not explicitly state read-only semantics, permission requirements, freshness, or error behavior.

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

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

It is a single front-loaded sentence that immediately identifies the resource and then enumerates returned data. There is no wasted framing or redundant text.

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 one-parameter read tool with no output schema, the description is nearly complete because it names the returned data categories and the default address behavior. It could be strengthened with explicit read-only or freshness/limit context, but no critical calling information 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?

There is one optional parameter and the schema description coverage is 100%, including the same default-wallet behavior. The description reinforces the default but adds no syntax, formatting, or validation details 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 resource and scope: a full perp account snapshot for an address, defaulting to the server wallet. It clearly distinguishes this from market or order-action siblings by enumerating account-centric contents, though it does not explicitly name sibling tools.

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 implies usage by listing what the snapshot includes, but gives no explicit guidance on when to call this instead of siblings like claim_voucher or list_markets. There are no when-not conditions or alternatives mentioned.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses the kinds of values returned (pool, tick/lot sizes, min quantity, margin, leverage) but does not state read-only behavior, error handling for invalid symbols, or authentication requirements.

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

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

A single front-loaded sentence with zero waste. It states the action, the key parameter, and the useful returned fields compactly.

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 one-parameter read tool with no output schema, the description gives enough detail about what the returned market record contains. Minor gaps around invalid-symbol behavior and exact response shape remain, but the essential 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?

Schema coverage is 100%, so the single symbol parameter is already documented with an example. The description reinforces that it is a base symbol and adds ETH/SOL examples, but does not add format or validation semantics 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: get one perp market by base symbol. The scope 'one' and the listed returned fields distinguish it clearly from list_markets without needing to name the sibling.

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

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

The description makes the usage condition clear: look up a single perp market by base symbol. It does not explicitly say when to use list_markets instead or what happens for unknown symbols, so it stops short of full when/when-not 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?

No annotations are provided, so the description carries the full burden. It does useful work by previewing the payload (pool addresses, margin requirements, order-size rules) in the absence of an output schema, and 'List' implies a safe read. It does not state auth requirements, testnet-only limitations, or whether results are paginated.

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: scope, environment, and payload contents in one pass.

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

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

For a zero-param read tool with no output schema and no annotations, the description supplies the environment context and the shape of the returned data. Only operational details such as pagination or testnet constraints are missing.

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

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

The tool takes zero parameters, so the schema baseline of 4 applies; there is nothing further the description could clarify about inputs.

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

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

States a specific verb and resource ('List all dreamDEX perpetual markets') plus the environment (Somnia Hideki testnet) and the returned fields. The plural 'all markets' implicitly contrasts with the singular sibling get_market, though it never names that 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 scope 'all ... markets' versus get_market's single-market retrieval is implied by naming and the sibling list, but there is no explicit when-to-use guidance, prerequisites, or exclusion. Usage must be inferred.

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

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

With no annotations, the description carries the full burden and does it well: it discloses the execution guards (trading enabled, MAX_ORDER_NOTIONAL_USD notional cap), that quantity/price are silently rounded to the market's lot/tick, and that a getMaxPerpOrderSize pre-check happens before submission. Gaps remain on failure behavior and what is returned on success or rejection.

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 action and target lead the sentence, followed by the guard list as a compact enumeration. Every clause supplies a distinct operational fact — no restatement of the tool name, 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 state-mutating tool with no annotations and no output schema, the description covers environment, signer, preconditions, rounding, and a pre-check. It stops short of describing the result shape or how rejections surface, which is the one thing left unstated for a mutation tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: submitted quantity/price may be adjusted to lot/tick increments and the effective size is bounded by a notional cap. Those facts change what values an agent should pass, which is exactly what parameter prose should 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+resource ('Place a perp order') plus two scoping facts an agent needs: dreamDEX testnet and the server wallet as signer. None of the siblings (list_markets, get_market, get_account, cancel_order, close_position, claim_voucher) can be confused with this action, so differentiation is achieved without naming one.

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 the precondition that selects this tool ('trading must be enabled') and an environmental constraint (testnet, server wallet) that tells the agent who is trading. It does not name alternatives for exiting or unwinding exposure (close_position, cancel_order) or say when not to place an order, 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.