Vectorial Data Terminal

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

With no annotations, the description carries the full burden and does disclose key constraints (no prior Hyperliquid account), validity (180 days), and signing algorithms (EIP-191 proof, ECDSA P-256 DER base64). However it omits failure modes, whether the wallet must be funded before call 1 or call 3, what happens if the verify list mismatches, and permission requirements, so meaningful behavioral gaps remain for a security-critical mutation.

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

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

Front-loaded with the action, then organized as an ordered call flow with imperative steps. It is dense and parenthetical-heavy (algorithm stacks, canonical JSON) but nearly every clause carries operational information, and the ordering matches how the agent must actually invoke the 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?

Covers the workflow, prerequisites, validity period, and the shape of returned values (payload_b64 plus a verify list to check before signing), which is substantial given a four-parameter, no-output-schema, security-critical tool. Still missing error handling, idempotency/retry guidance, and where to source owner keys, so it is not fully complete for the complexity involved.

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 75%, so baseline is 3, and the description genuinely adds meaning by mapping each parameter to a specific call stage and stating what each signature signs (trading_key_proof over the returned message, owner_signature over payload_b64). It also supplies meaning for the undescribed trading_key_address ('your trading key'). Minor gap: nothing on address format or how to obtain it.

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 ('Authorize the key that signs your LIVE orders') and immediately distinguishes the required key type (a NEW secp256k1 key with no Hyperliquid history). An agent can tell this is the live-trading key authorization flow, not key rotation or agent registration, 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 an explicit three-call sequence with the arguments required at each step (no args → message; trading_key_address + trading_key_proof → payload_b64; add time + owner_signature → done), plus the prerequisite to fund the trading wallet first. Also states the alternative outcomes ('repeat to renew or rotate'), so when-to-use and how-to-sequence are fully covered.

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 supplied, so the description carries the full burden. It does contribute one genuinely useful behavioral fact — that in paper mode cancellation executes immediately — but omits what happens to already-filled orders, whether cancellation is idempotent, required permissions, and any failure modes for a mutation tool.

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

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

Two short sentences, zero filler, with the primary action front-loaded and the paper-mode caveat trailing as a secondary note. Nothing could be removed 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 single-parameter cancel tool with no output schema and no annotations, the description covers purpose and one mode-specific behavior, which is close to adequate. It still leaves the agent guessing about error handling on non-resting orders and what the call returns, gaps that matter more here because no structured field fills them.

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 0% and the lone parameter is bare ('order_id' with no description), so the description must compensate. It does add real meaning by clarifying the id is a ledger id, ruling out a client-supplied order reference, but gives no format or example.

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

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

States a specific verb and resource ('Cancel a resting order') plus the identifier basis ('by ledger id'), which distinguishes it from place_order/submit_order and list_orders among the siblings. It stops short of distinguishing itself from close_position, which could also read as exiting an 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?

The word 'resting' implies the applicable case implicitly, but there is no explicit when-to-use, when-not-to-use (e.g., already-filled or partially-filled orders), or named alternative. An agent must infer the boundary conditions itself.

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

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

With no annotations, the description carries the full burden, and it does add real value by disclosing the paper-vs-live split: paper executes immediately while live returns typed_data for signing. It omits whether the close is irreversible, what permissions or trading-key authorization are needed, and what happens to the position between signing and submission.

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 dense sentence with the core action front-loaded and the paper/live behavioral distinction appended. No filler, no restatement of the tool name.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the description covers the most important behavioral fork (paper vs. live signing) but leaves the market identifier format, authorization requirements, and the shape of typed_data unexplained.

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

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

Schema coverage is 0%, so the description must compensate. It clarifies that omitting size_pct means a full close and that size_pct is a percentage, which is genuinely useful, but the required 'market' parameter is never explained (format, identifier type) and the 1-100 bounds are left to 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 an open position') plus the two modes of operation (full close vs. size_pct), which distinguishes it from siblings like protect_position or cancel_order. It stops short of naming those siblings explicitly, so it is clear but not fully differentiated.

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 'close an open position' — an agent knows this applies to an existing position rather than opening one. However, there is no explicit guidance on when to prefer this over protect_position, cancel_order, or place_order with an opposing side, and no stated prerequisites.

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 supplied, the description carries the full burden and does so well: it discloses the key-ownership model (you hold the private key, our signer is policy-locked to fee destinations), the auth prerequisite ('copy' scope), and the security guarantee that an API key alone can never bind an owner key. This is meaningful behavior beyond the schema, not a restatement of it.

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 critical facts (what it creates, what you send, the two-call flow, the scope requirement) are front-loaded in a logical order. A few clauses lean promotional ('keeps your Hyperliquid trading agent from expiring on you') and could be trimmed without losing decision-relevant 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 3-parameter creation tool with no output schema and no annotations, the description covers the write's security model, its auth requirement, the multi-step handshake, and what the first call returns (a message naming the key fingerprint). Nothing an agent needs in order to invoke 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 coverage is 100%, so the baseline is 3, but the description adds the sequencing semantics the schema only gestures at: owner_public_key alone on call one, then owner_public_key + nonce + signature on call two, with the signature specified as EIP-191 over the returned message. This clarifies the stateful relationship between the three parameters.

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

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

The description opens with a specific verb+resource+scope: 'Create the copy wallet needed for LIVE copying.' This distinguishes it from siblings like get_copy_wallet, create_trading_wallet, and follow_leader without the agent needing to open 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?

It states the precondition ('Requires the copy scope') and gives an explicit two-call procedure, including that the first call takes only owner_public_key and the second adds nonce + signature. It stops short of naming an alternative for agents that already hold a wallet (e.g., get_copy_wallet), so the routing guidance is implicit rather than explicit.

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 so unusually well: it discloses the trust model (owner key never leaves the process), the exact limits of the hosted signer (fees to treasury and builder-fee approval only), and the two-phase signed-challenge flow. This is the kind of context an agent cannot get from any structured field.

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?

Purpose and prerequisite are front-loaded, the security guarantees follow, and the two-call procedure is signposted with 'TWO CALLS' so the sequencing cannot be missed. Dense but no sentence 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 3-parameter, annotation-free mutation tool with no output schema, it covers prerequisites, security semantics, and the call sequence. Minor gaps remain: whether the wallet persists/is one-per-agent, what happens if a wallet already exists, and what the first call's response looks like beyond 'a message naming your key's fingerprint'.

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 would be 3, but the description adds real meaning by explaining that the parameters belong to two distinct invocations and that nonce/signature come from the first call's returned message. It stops short of describing formats (EIP-191 is named, but signature encoding is left to 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 ('Create your trading wallet') and immediately scopes it ('required for LIVE trading'), which distinguishes it from the sibling create_copy_wallet and the read-only get_trading_wallet. An agent knows exactly what entity this tool produces.

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 trigger condition (needed for LIVE trading) and a hard precondition ('your agent wallet must have nothing open'), plus an explicit two-call sequence with the inputs for each call. It does not name an alternative or exclusion (e.g., versus create_copy_wallet), 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?

With no annotations at all, the description carries the full burden and does substantial work: it discloses that the HMAC signing secret is returned only once, gives the exact signature header format, and states at-least-once delivery with dedupe by event id. It leaves out whether registration requires an elevated scope (relevant given the escalate_scope sibling) and what happens on duplicate URLs, so it is strong but not complete.

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 tight paragraph, front-loaded with what the tool does and immediately followed by the irreversible detail (secret shown once). Everything included earns its place, though the signature formula is compressed enough (`t + '.' + body` inside a sentence) that it reads densely on first 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 two-parameter creation tool with no annotations and no output schema, the description covers the critical unknowns: the one-time secret return, delivery guarantees, and signature verification. The remaining gap is authorization/scope requirements and duplicate-registration behavior, which an agent would want before invoking it.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the 'omit = all' behavior for event_types. The description reinforces the public-https constraint and the omit-for-all rule but adds no new syntax or format detail beyond the schema, which is the expected baseline-3 outcome.

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 — 'Register a webhook endpoint' — with the key constraint that it must be public https. It does not name the closely related siblings (list_webhooks, test_webhook, delete_webhook, get_webhook), so the differentiation is left to the create/list/get/delete naming convention rather than made explicit.

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

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

The description implies when to use it (you want event deliveries pushed to your endpoint) and gives one conditional: 'Omit event_types to receive everything.' It never says when not to use it — e.g. that test_webhook should be used to validate an endpoint, or that list_webhooks shows existing registrations before creating a duplicate.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose one real consequence: queued deliveries are dropped. However, it omits whether the removal is permanent/irreversible, what permissions are needed, and what happens if webhook_id does not exist — significant gaps for a destructive operation with zero annotation coverage.

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

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

One sentence, front-loaded with the action and resource, with the side effect compactly bracketed. Nothing is wasted and nothing is 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 one-parameter tool with no output schema and no annotations, the description covers purpose and the key delivery-dropping side effect. It is still thin on irreversibility, auth requirements, and the identifier's expected form, which an agent would need before calling a destructive 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 description coverage is 0% for the single parameter, and the description never mentions webhook_id or its format (ID vs URL). The parameter name is largely self-explanatory, but the description makes no attempt to compensate for the undocumented schema, so it falls below 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?

The description gives a specific verb and resource — 'Remove a webhook endpoint' — which clearly separates it from list_webhooks, get_webhook, create_webhook and test_webhook in the sibling set. It stops short of explicitly naming a sibling to route away from, so it lands at 4 rather than 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?

Usage is only implied: an agent can infer this is the teardown counterpart to create_webhook. There is no explicit when-to-use guidance, no mention of alternatives such as disabling a webhook instead of deleting it, and no prerequisites stated.

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

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

With no annotations, the description carries the full burden and does add real behavioral context: a NEW key is issued, the old key keeps working during a short grace window, and the caller must rewire this server's Authorization header. It omits failure behavior (e.g. rejected/expired signature) and any guardian or approval requirement, which matters for a credential-minting operation.

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 clauses, front-loaded with the flow position ('Step 2'), followed by the required follow-up action and the grace-window caveat. Every clause carries operational information; nothing is 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 and no annotations exist, yet the description covers the return value (a new scoped API key), the transition semantics (grace window), and the mandatory post-call step. The remaining gap is the intent parameter's meaning and error conditions, which leave it just short of fully complete for a credential-issuing 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 description coverage is only 33% — just 'signature' is documented — so the description must compensate. It does tie the signature to get_scope_challenge and implies the nonce comes from the challenge, but the 'intent' enum (enable_copy / enable_withdraw) and how it maps to the granted scope is never explained.

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: submit the signature from get_scope_challenge and receive a NEW api key carrying the scope. It explicitly names the sibling tool that precedes it and the artifact produced, so an agent can distinguish it from rotate_key or get_scope_challenge 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?

Makes the sequence explicit ('Step 2', signature from get_scope_challenge) and tells the agent what to do after the call: store the key and replace the Authorization header of this MCP server. It does not contrast with close alternatives such as rotate_key or state when escalation should not be attempted, so it stops short of 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?

No annotations are provided, so the description carries the full burden, and it does: mirrors start at the NEXT fill, no backfill of past trades, sizing is based on the copy wallet's full value rather than allocation_usd, the $10 minimum bump skews risk for small wallets, and paper mode returns paper_copy_retired. These are non-obvious behaviors an agent could not infer from the 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?

Dense but front-loaded, with the wallet prerequisite and start-point rule leading. The nested parentheticals accumulate (sizing formula, minimum bump, paper retirement) and make it slightly hard to scan, though nearly 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 3-parameter tool with no annotations and no output schema, this covers the critical behaviors: funding prerequisite, sizing semantics, start timing, mode restrictions, and scope. It omits failure behavior if a follow already exists and says nothing about leader_id beyond the schema bounds.

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%; the description adds real meaning by clarifying that allocation_usd is recorded only and does not drive mirror sizing, and by confirming mode='paper' is non-functional. leader_id is left to the schema, which documents its bounds but not its meaning, keeping this just short of a 5.

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: "Start copying a leader with real funds." It is immediately distinguishable from unfollow_leader, list_copy_leaders, and create_copy_wallet, and it names the mode split 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?

Explicitly says what must happen first (create and fund the copy wallet via create_copy_wallet), what mode 'live' does, and that 'paper' is retired. It also names the required 'copy' scope, leaving little to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state whether this is a read-only operation, whether it requires an authorized trading key or scope, whether live balances trigger real network calls, or whether sensitive fields (deposit address, scopes) are redacted in paper mode — all material for a credentials-adjacent account tool.

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

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

A single front-loaded line listing exactly what comes back, with the paper|live enum inlined usefully. It is terse to the point of being a field dump rather than prose, but nothing is wasted.

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

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

With no annotations and no output schema, the description must convey what comes back and what the call entails; the field list does the former adequately but leaves the behavioral and authorization picture entirely unstated. For an account-introspection tool on a trading platform, the missing safety and permission context is a real gap.

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

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

There are zero parameters, so the baseline is 4 and the description adds nothing that could mislead. Minor deduction avoided since calling requires no arguments, though the description could have noted that it takes none.

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 specific resource (agent account) and enumerates the returned fields: status, mode (paper|live), scopes, live balances, deposit address, limits. That is concrete and distinguishable from siblings like get_limits, get_trading_wallet, or get_positions, though it overlaps somewhat with those dedicated tools without saying how they relate.

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

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

The description implies usage as the general-purpose account snapshot, but gives no explicit when-to-use guidance and never mentions the overlapping siblings (get_limits, get_trading_wallet, guardian_status, get_metrics) or when to prefer those instead. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full burden and does real work: it discloses that live-follow data must be read from Hyperliquid directly via clearinghouseState and userNonFundingLedgerUpdates using the address from GET /copy/wallet, and it defines the edge-case return shape for retired paper follows (result: null, retired.code = paper_copy_retired). It stops short of describing the normal success payload, which keeps it off 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?

Every sentence contains substantive information, but the middle sentence is a long run-on that packs the wallet definition, two Hyperliquid info endpoints, and an address source into one clause chain, and the opening is a sentence fragment. It is dense and front-loaded in intent, but readability suffers.

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 annotations and no output schema, the description must cover return behavior, and it only documents the retired-paper-follow case while leaving the shape of a live follow's status undefined. It compensates well on external-dependency context, but an agent still does not know what a normal successful response looks like.

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 goes slightly beyond by explaining where the account address used for downstream reads comes from (GET /copy/wallet), which is useful context even though there is no parameter to clarify.

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 opens with 'What this agent is copying, per leader', which identifies the resource as copy-follow status keyed by leader, and explicitly separates it from get_positions by stating 'get_positions reads your agent wallet, not the copy wallet.' The opening fragment is terse rather than a clean verb+resource statement, but an agent can still tell what the tool returns and how it differs from the nearest 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?

It gives situational context — live follows versus a retired paper follow — and warns that get_positions is not a substitute, which implicitly steers usage. However, it never states plainly when to call this tool (e.g. 'call this to check follow state before/after follow_leader or unfollow_leader'), so the guidance must be inferred from the surrounding narrative.

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 of behavioral disclosure. It hints at return content (address to fund, readiness flag, custody terms) but says nothing about what happens when no copy wallet exists, whether auth/registration is required, or how readiness is determined. For a zero-parameter read this 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?

One tight sentence with no filler, and the most important item (address to fund) is front-loaded. It reads as a label legend rather than a description, but nothing is wasted.

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

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

Against a zero-param read with no output schema, the description covers the three returned facts reasonably well. It is still incomplete for an agent in a 40+ tool wallet/copy-trading surface, because it omits the relationship to create_copy_wallet and get_copy_status and gives no behavioral edge cases.

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 for the description to disambiguate; the baseline for a zero-parameter tool applies. The listed return fields are a small bonus but not parameter semantics.

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 (copy wallet) and enumerates its contents — funding address, live-copy readiness, custody terms — so the agent can infer this is a read of copy-wallet state. However, it is a noun phrase with no verb and no differentiation from siblings like get_copy_status, get_trading_wallet, or create_copy_wallet, leaving the actual operation implicit.

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 (e.g., that create_copy_wallet must run first), and no reference to the closely related get_copy_status tool. The agent must guess the call ordering and which sibling answers which question.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the return format (markdown) and the topical scope, which is useful. However, it says nothing about size/context cost of pulling a 'complete' manual, whether it is paginated or section-addressable, whether auth is required, or whether the content is versioned — all material for an agent deciding whether to fetch it.

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

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

A single sentence, front-loaded with what the resource is, followed by format in parentheses and a compact topic list. No redundancy, no filler, nothing that 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 zero-parameter, no-output-schema tool, the description covers what it returns and in what format, which is the core need. The remaining gap is scale — an agent has no signal about how large the manual payload is or whether a targeted section can be requested instead of the whole document.

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

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

The tool takes zero parameters, so the schema has nothing to explain and the baseline of 4 applies. The description adds no misleading parameter hints, consistent with the empty object 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 names a specific resource (the complete Agent API manual) and its delivery format (markdown), then enumerates the coverage areas: auth, trading, limits, withdrawals, error catalog. That scope list implicitly separates it from every operational sibling (get_limits, get_account, place_order, etc.), which return live data rather than documentation. It stops just short of an explicit verb like 'retrieves', but an agent can still tell what this returns.

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

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

There is no explicit guidance on when to call this versus the many data-returning siblings, no 'call this first' recommendation, and no note on when the manual is unnecessary. Usage is only implied by the content itself — a manual is what an agent consults to learn the API. That implication is strong 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?

No annotations are supplied, so the description carries the disclosure burden, and it does indicate the data categories returned (caps, allowlists, pending loosenings). It never states that the operation is read-only, whether it requires authorization, or how 'pending loosenings' should be interpreted. For a zero-parameter getter the risk is low, so this is a moderate rather than severe 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?

A single short fragment with the substantive content front-loaded in the parenthetical; nothing is wasted. It is arguably too compressed to be self-explanatory, but no sentence is 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?

With no output schema, the description is the only place return shape could be conveyed, and it only names three categories without indicating structure or format. For a zero-param read tool the missing pieces are modest, but the absence of any statement about what the limits apply to or how they relate to update_limits leaves the agent guessing.

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 for the description to disambiguate beyond what the empty schema already shows. Baseline 4 applies for a parameterless tool.

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

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

The parenthetical enumerates the resource content (caps, allowlists, pending loosenings), which tells an agent roughly what comes back, but the framing 'your bounded-autonomy rails' is metaphorical jargon rather than a verb+resource statement. It does not explicitly distinguish itself from siblings like guardian_status or update_limits, leaving the agent to infer that this is the read counterpart to update_limits.

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 stated prerequisites, and no routing to alternatives. With update_limits, guardian_status, and escalate_scope all adjacent in the sibling list, an agent gets no signal about which to pick for inspecting versus changing limits.

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

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

With no annotations, the description carries the full burden, and it does contribute one genuinely useful behavioral fact: the numbers are computed server-side from the authoritative ledger, implying they are trustworthy and not client-derived. It does not state that the call is read-only and non-mutating (relevant given siblings like kill_switch and place_order), nor does it cover defaults, cost, or latency.

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

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

A single front-loaded sentence that lists the payload first and the provenance clause second. No filler, no 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?

The enumerated metrics effectively substitute for the missing output schema, which is a real strength. However, with no annotations and no parameter documentation, an agent still lacks the safety profile (is this read-only?) and the meaning of defaults for mode and window.

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%, so the description should compensate for the two parameters — and it says nothing about mode or window. The enums are largely self-explanatory (paper/live, 7d/30d/90d/all), and with zero required parameters the caller can safely invoke it bare, which keeps this at a baseline 3 rather than lower. Still, it leaves the default scope (which mode, which window) undocumented.

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

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

The description names the concrete artifacts returned — win rate, net PnL, fees, drawdown, Sharpe, equity curve — so an agent can tell this is the performance-analytics tool rather than a state tool like get_account or get_positions. The verb is implicit ('tear-sheet') rather than an explicit 'returns/computes', and no sibling is named for contrast, which keeps it from a 5.

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

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

There is no statement of when to call this versus get_account, get_positions, or get_copy_status, and no guidance on choosing between paper/live or which window to request. The agent must infer usage entirely from the field list.

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

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

With no annotations, the description carries the full burden. It does disclose a valuable behavioral trait: the source of truth differs by account mode, so live positions reflect venue state while paper positions are derived from fills — this warns the agent the numbers may not match local records. It says nothing about freshness, failure modes, or what happens when no positions exist.

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 clause with the resource first and the mode distinction in parentheses. Every word earns its place with zero preamble or 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?

No parameters or annotations means less to cover, but there is also no output schema, so the description is the only place return values could be characterized — and it says nothing about what a position record contains (size, entry price, unrealized PnL, venue). Adequate for identification, thin for interpretation.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. Nothing in the description is needed to compensate for schema gaps.

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

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

States the resource clearly ('Open positions') and adds a meaningful discriminator the name alone doesn't convey: where the data comes from in each mode (live = venue truth, paper = from your fills). It is not explicitly differentiated from siblings like list_orders or get_account, but the mode-based provenance note does real work.

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 alternative is named. An agent deciding between this, list_orders, and get_account gets no routing signal from the description beyond the implied 'look at open positions' reading.

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 does useful work by disclosing what comes back (nonce plus message), the signing standard (EIP-191), and that the signature must come from the agent's own EVM wallet. It omits nonce lifetime, single-use behavior, and error conditions for an invalid or already-registered address, which matter for a step-1 flow.

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

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

One sentence, front-loaded with the workflow position and the returned artifacts, with no redundant phrasing. Nothing could be removed without losing information.

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

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

For a one-parameter read tool with no output schema, describing the returned nonce and signable message plus the signing scheme is nearly sufficient. A brief note on nonce validity or the next step (register_agent) would close the remaining gap.

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

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

Schema coverage is 100% and the single parameter is already documented as the agent wallet address. The description reinforces that it must be the agent's own EVM wallet, but adds no format, validation, or constraint detail beyond what the schema states, so the baseline 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 action (get a nonce+message to sign) and ties it to a concrete workflow position (step 1 of creating an agent account). It is distinguishable from siblings like register_agent or get_scope_challenge, though it never names the follow-up tool explicitly, leaving the sequence to inference.

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

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

Saying it is 'step 1 of creating an agent account' implies when to call it and roughly what comes next, but no alternative is named and no exclusion or precondition (e.g. that the nonce may expire or be single-use) is stated. Usage is implied rather than spelled out.

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

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

With no annotations, the description carries the burden well: it discloses that the tool returns a message to sign with the agent wallet, that new authority requires a wallet signature, and that the challenge is bound to the intent to prevent replay across intents. It does not cover challenge expiry or the exact follow-up submission path, but the critical security behavior is explicit.

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

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

The description is two dense sentences with the operational purpose front-loaded and the security rationale following immediately. Every clause adds useful selection or safety context without 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 one-parameter challenge tool with no output schema, the description covers the return value, the authorization requirement, and the intent-binding security property. It stops short of naming the next submission step explicitly, but it is otherwise sufficient 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 0%, so the description must compensate. It explains the two intent semantics in business terms ('copy' to follow leaders, 'withdraw' to move funds) and ties them to the replay-protection behavior, though it uses shorthand rather than the exact enum values.

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: obtaining a message to sign as step 1 of gaining a new scope. It distinguishes the two scope intents ('copy' to follow leaders, 'withdraw' to move funds) and separates this from key rotation, which can only narrow scopes.

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 clearly frames usage as the first step for gaining new authority and explicitly notes that keys/rotate can only narrow scopes, which helps route the agent away from the wrong tool. It does not exhaustively name every sibling alternative, but the context is strong enough to select this tool correctly.

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

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

With no annotations, the description carries the full behavioral burden, and it does substantial work: it discloses that this wallet is the one live orders execute from, that fees are 0.25% per perps trade collected automatically, and that custody terms apply. It stops short of explicitly declaring the call is read-only with no side effects, and says nothing about authentication or error behavior, which keeps it below 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?

It is a single front-loaded sentence that identifies the resource first and then lists its facets, so the agent gets the core identity immediately. The embedded fee and custody details are relevant but dense, making it slightly overstuffed for one sentence.

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

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

With no output schema, the description compensates by enumerating exactly what the wallet record contains, which is the right call for a zero-parameter read tool. Gaps remain around whether the call requires authorization and what happens if no trading wallet exists yet (versus create_trading_wallet), but the core is covered.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The enumerated return content is effectively the useful semantic payload 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?

The description names a specific resource — the Hyperliquid trading wallet that LIVE orders trade from — and enumerates its contents (address, balances, trading key status, fees, custody terms), which clearly distinguishes it from read-only siblings like get_account or get_copy_wallet. It lacks an explicit verb ("retrieve"/"fetch"), relying on the colon-list to convey what is returned, so it falls just 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?

Usage is only implied: the mention of trading key status "and when to renew it" and "how to fund it" hints at pre-trade checks and key-rotation decisions, but the description never states when to call this versus get_account, get_copy_wallet, or authorize_trading_key. An agent must infer the routing.

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

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

No annotations exist, so the description carries the full disclosure burden. It does valuable work by naming the payload contents (status codes, retries, dead letters) and the fixed 20-attempt window, but it says nothing about behavior on an unknown webhook_id, whether delivery history is retained beyond 20, or whether truncation/pagination applies.

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 the resource first, then the payload, then the disambiguating role. Efficient, though the em-dash clause is slightly compressed jargon compared to plain phrasing.

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 and no annotations, the description adequately covers the return shape (one webhook plus 20 delivery attempts with status/retry/dead-letter detail), which is the main thing an agent needs. Gaps remain around id provenance and error behavior for an unknown id.

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 0% — webhook_id is a bare untyped-context string with no description — so the description must compensate. It implies the parameter selects a single webhook but adds no format, source, or example (e.g. where to obtain the id from list_webhooks/create_webhook).

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: retrieve one webhook plus its last 20 delivery attempts, and the parenthetical enumerates what those attempts contain. The closing phrase 'the delivery debugging surface' distinguishes it from list_webhooks (enumeration), create_webhook/delete_webhook (lifecycle) and test_webhook (synthetic send).

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 'delivery debugging surface', which signals this is the tool for investigating failed deliveries. However it never explicitly says when to prefer this over list_webhooks to find the id, or over test_webhook to validate an endpoint, and there are no stated 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?

With no annotations supplied, the description carries the full burden, and it does disclose the shape of the returned policy (mode plus its three allowed values, strict destinations, guardian link) even though no output schema exists. It omits whether this is purely read-only, whether guardian linking can restrict withdrawals, and how mode values affect behavior, so significant behavioral context is missing.

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 compact sentence with no filler, and the key concept ("Money-out policy") is front-loaded. It is arguably over-compressed into a noun-phrase fragment, which costs a little readability but nothing is wasted.

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

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

With no parameters, no annotations, no output schema and low complexity, the description needs to define what comes back and why an agent would call it. It partially does by naming the three policy components and the mode enum, but leaves the returned structure and the practical implication of each mode unexplained.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify. The enum values listed (disabled|autonomous|human_passkey) are return-value semantics, not parameter semantics, so they do not raise or lower this dimension.

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 is a telegraphic field list ("Money-out policy: mode (disabled|autonomous|human_passkey), strict destinations, guardian link") rather than a verb+resource statement. Combined with the name get_withdrawals_config, an agent can infer it returns withdrawal-policy settings, but the description itself never states that it reads/returns configuration and does nothing to distinguish it from siblings like list_pending_withdrawals or prepare_withdrawal.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as prepare_withdrawal or list_pending_withdrawals. The agent must infer from the name alone that this is the pre-flight check before preparing a withdrawal.

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

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

With no annotations, the description carries the full behavioral burden and does not meet it: it never states that this is a read-only operation, whether authentication or a registered agent is required, or what happens when no guardian is linked. The mode reference is the only behavioral hint offered.

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

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

The description is a single short fragment with no wasted words, which is good, but it is not front-loaded with a verb or a clear statement of what is returned. Brevity here reflects under-specification rather than disciplined conciseness.

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

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

There is no output schema and no annotations, so the description should explain what the call returns (linked/unlinked, guardian identity, mode state) and any preconditions. For a status tool whose entire value is its return shape, this is a significant omission.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the empty schema already conveys. Baseline 4 applies; the description neither adds nor detracts from parameter meaning.

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 identifies a resource (human guardian link state) and scopes it to human_passkey mode, which distinguishes it from siblings like invite_guardian or escalate_scope. However, it is a noun fragment with no verb, so an agent must infer that it is a read/status query rather than a state-changing operation.

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 prerequisites, and no mention of alternatives such as get_account or invite_guardian. The parenthetical '(human_passkey mode)' hints at a conditional context but never states what an agent should do with it.

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

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

With no annotations, the description carries the full burden; it does disclose two important behavioral traits: the invite is single-use and expires in 48h, and it produces an accept_url to deliver out-of-band. It omits who is authorized to mint invites, whether minting supersedes an existing guardian, and what happens on expiry or re-invocation.

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 its key constraints (single-use, 48h), followed by the operational instruction. No wasted wording.

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

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

For a zero-parameter tool with no output schema, the description covers the essential output (accept_url) and the invite's lifetime. Minor gaps remain around guardian lifecycle and error behavior, but nothing that would prevent a correct 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly implies no inputs are needed.

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

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

The description uses a specific verb ('Mint') and a well-defined resource ('single-use invite'), and states the outcome precisely: a human becomes this agent's withdrawal guardian. It does not mention the sibling guardian_status, so the boundary between inviting a guardian and checking guardian state is left to inference.

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

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

It implies the usage context (setting up a withdrawal guardian) and gives a concrete next step, 'Hand them the accept_url.' However, it never states when not to call it, whether it can be called repeatedly, or how it relates to guardian_status or prepare_withdrawal.

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 disclose key behavior: immediate rejection of prepare/submit and the wallet-signature requirement for resume_trading. It does not state whether kill_switch itself requires authentication or whether existing orders/positions are affected, leaving some operational details unstated.

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

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

The description is a single front-loaded sentence with no wasted wording. It communicates the pause effect and the resume dependency efficiently.

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 emergency control, the description covers the core effect and recovery path. It could be more complete by clarifying activation authentication and whether open orders or positions are impacted, but it is largely sufficient given the tool's simplicity.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. The baseline for a zero-parameter tool is 4, and the description does not need to compensate for schema gaps.

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

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

The description states a specific action ("Instant pause") and its concrete effect: every subsequent prepare/submit is rejected until resume_trading. It also names the counterpart tool, making it clearly distinguishable from resume_trading and other trading 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?

The emergency-pause context is clear from "Instant pause" and the rejection behavior, and the resume path is explicitly named. It does not spell out when not to use it or any prerequisites for invoking kill_switch itself, but the intended usage is strongly 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?

With no annotations, the description carries the full burden and does substantial work: it discloses the daily UTC snapshot semantics ('the same object all day'), that returns are time-weighted and net of fees, that they are immune to deposits/withdrawals, and that they are never a return on capital. What it omits is pagination/result limits and any freshness or rate-limit details beyond 'daily'.

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 resource and scope, then the metric caveat. The parenthetical definitions are dense but each clause adds real meaning for interpreting the numbers.

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

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

For a zero-parameter read tool with no output schema and no annotations, the description supplies what structured fields cannot: the metric definitions, the snapshot cadence, and the warning about drawdown versus raw return. Nothing an agent needs to call and interpret it is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The description correctly signals that no filtering arguments exist.

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 the resource precisely: 'Strategies available to copy', with the returned metrics enumerated. An agent can tell this is the discovery/listing step before follow_leader, 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?

It gives interpretation guidance ('Read max_drawdown_pct before ranking by return'), which implies the intended workflow of picking a leader to follow. However, it never says when to use this versus follow_leader or get_copy_status, and no prerequisites or exclusions are stated.

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

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

With no annotations, the description must carry the behavioral load. It does disclose that prices are live and that the response includes sizing constraints like the $10 minimum notional, but it says nothing about auth requirements, rate limits, pagination, or whether all markets are returned unfiltered.

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 dense sentence with the core resource front-loaded and the concrete field names parenthesized at the end. Every clause earns its place, though the sentence fragment lacking an explicit verb makes it read more like a data label than an instruction.

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 listing tool with no output schema, the description successfully conveys the return shape (prices plus precision and minimum-size rules). The remaining gap is operational context such as whether the response is cached, whether prices stream or snapshot, and any auth expectations.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the schema-side burden is nil. The description does not need to explain inputs, and the baseline of 4 applies.

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

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

The description names the resource ('tradeable markets') and enumerates the payload (live prices, size_decimals, min_size, price rules, min notional), so an agent immediately knows what it gets. It stops short of a clear verb and never differentiates itself from sibling list_* tools, though no sibling actually overlaps on market 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?

Usage is only implied: the mention of 'precision metadata needed to size orders' hints this is a prerequisite lookup before place_order/submit_order. There is no explicit when-to-use statement, no exclusions, and no named alternative or prerequisite.

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 supplied, the description carries the full behavioral burden; it discloses pagination via cursors and the presence of paper trigger rows (trigger_tp/trigger_sl), which is genuinely useful context. It does not say whether it is read-only, what the default/read scope is, whether results are ordered or scoped to the authenticated account, or how cursors expire.

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

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

Two short sentences with no filler; the pagination contract and the trigger-row caveat are both front-loaded. The second sentence, while terse, adds real information rather than restating 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?

The tool is simple (3 optional params, no nested objects, no output schema) and the description covers pagination and row types adequately. However, with zero annotations and no output schema, an agent still lacks ordering, default limit, account scoping, and read-only guarantees that would matter before relying on it as an 'authoritative ledger'.

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%: 'before' and 'status' are documented in the schema, but 'limit' has no description and the description adds no meaning to any parameter. It repeats the cursor-pagination concept already stated for 'before' without clarifying default page size or ordering.

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 calls it an 'authoritative order ledger' and 'cursor-paginated', which implies listing orders, but it never states the verb or resource plainly — the tool name carries most of the meaning. It also distinguishes the contents (paper trigger rows as trigger_tp/trigger_sl) but does not differentiate from siblings like get_positions or list_pending_withdrawals.

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 mention of when not to use it, and no named alternative among the many list/get siblings. The only implied usage is retrieving order history via pagination.

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 supplied, the description carries the full burden, and it does disclose meaningful behavior: these are the caller's own intents, approval runs through a human_passkey, and approved intents contain signable actions. It does not state that the operation is read-only, whether results are paginated, how stale or ordered the lifecycle states are, or what happens when no intents exist.

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 core resource is front-loaded. The phrasing 'Your withdraw intents and their approval lifecycle' is slightly elliptical about the fact that this returns a list, but nothing is wasted.

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

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

There is no output schema, so the description must convey what comes back; it sketches the shape (intents, lifecycle states, signable actions on approved ones) but does not enumerate statuses or fields, and it omits the read-only framing a caller would want before invoking. Adequate for a zero-parameter list tool, but with clear gaps.

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

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

The tool takes zero parameters (schema coverage 100%), so the baseline is 4 and there is nothing about inputs the description needs to compensate for. It adds no misleading parameter claims.

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

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

The description names a specific resource ('Your withdraw intents and their approval lifecycle') and adds the key qualifier that approved intents include signable actions, so an agent knows this is a read of withdrawal intents rather than of configurations or balances. It does not explicitly differentiate itself from siblings like get_withdrawals_config or prepare_withdrawal, keeping it below 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 explicit when-to-use statement, no mention of when not to use it, and no reference to the obvious alternatives in the sibling set (prepare_withdrawal for creating an intent, get_withdrawals_config for configuration). The agent must infer the call context from the resource name alone.

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

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

With no annotations, the description carries the burden and does disclose useful behavior: the hard cap of 5 endpoints and the fact that the response bundles the full event-type catalog alongside the endpoints. It does not state read-only semantics explicitly, nor whether failure counters are lifetime or windowed, and it gives no indication of auth or rate-limit behavior.

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

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

Two dense clauses, front-loaded with the resource and its cap, then the field list, then the secondary return value. No filler and nothing important buried at the end.

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

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

For a zero-parameter read tool with no annotations and no output schema, the description adequately previews the return shape and its size limit. A sentence on read-only/non-destructive behavior and the sibling relationship to get_webhook would close the remaining gaps.

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

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

The tool takes zero parameters, so the schema imposes nothing an agent must interpret and the baseline is 4. The description correctly adds no parameter discussion, matching the empty 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 gives a concrete verb-and-resource picture: it lists 'Your webhook endpoints' and enumerates the fields returned (url, event types, status, failure counters) plus the event-type catalog. It is clear what the tool does, though it never names the sibling get_webhook for single-endpoint retrieval, so differentiation is only implicit in the plural phrasing.

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 mention of when to prefer get_webhook or create_webhook, and no stated prerequisites. The agent can infer this is a read/list operation, but the routing decision between this and the other webhook tools 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?

No annotations exist, so the description carries the full burden. It does disclose a genuinely important behavioral trait that no structured field conveys: the entry contributes to a 'future public track record', implying visibility beyond the caller. It does not say whether entries can be edited or deleted, whether logging is mandatory for compliance, or what a successful call returns.

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 purpose and ending with the correlation hint. The parenthetical adds real motivation rather than restating the name, though it leans slightly promotional.

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 three parameters, no annotations, and no output schema, the definition is serviceable but thin. It never covers the undocumented 'model' parameter or explains whether logging is a prerequisite for order execution, which matters for an audit-trail tool in a trading API.

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%, so the description must compensate for all three parameters. It explains what 'reasoning' should contain and why 'order_id' is passed, but 'model' is left entirely undefined in both schema and description, leaving one of three parameters opaque.

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 object ('Log WHY you traded') with the added framing that it is an audit trail, which distinguishes it from execution siblings like place_order and submit_order. It does not explicitly name those siblings, but the read/write intent is unmistakable.

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

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

The only guidance is 'Pass order_id to correlate', which is parameter advice rather than a when-to-use rule. Nothing says whether to log before or after placing an order, whether it is required, or when to skip it.

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

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

No annotations are supplied, so the description carries the full burden and does substantial work: it discloses the auth prerequisite chain for LIVE, the fact that PAPER mode needs no signature, the fee rate and automatic settlement, and a hard minimum notional of $10. Gaps remain around failure behavior, whether the returned typed_data expires, and how reduce_only interacts with brackets.

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

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

Front-loaded with the core action, then stacked parenthetical qualifiers for mode, fees, brackets, and sizing — every clause carries information, with no filler. The dense em-dash chaining makes it slightly harder to scan than a bulleted breakdown would be, but nothing is wasted.

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

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

For an 11-parameter mutation tool with no annotations and no output schema, this covers the essentials: mode semantics, authentication prerequisites, fee and minimum-notional constraints, and both sizing paths. What is missing is the return shape for the PAPER path and any statement about rejection or partial-fill 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 only 36% across 11 parameters, and the description compensates well for sizing — it explains tp/sl as the bracket pair and gives the actual risk-first formula (size = risk / |entry − stop|). However limit_price, reduce_only, type, and side receive no explanation beyond their schemas, leaving several parameters undocumented in both places.

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 ('Place an order') and immediately disambiguates the two execution paths: PAPER simulates a fill against real prices, LIVE produces typed_data to sign and hand to submit_order. An agent can tell precisely what this tool does and how it relates to submit_order, authorize_trading_key, and create_trading_wallet 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?

Explicitly states the prerequisite sequence for LIVE mode (create_trading_wallet + authorize_trading_key first) and the follow-up tool (submit_order), so the agent knows the ordering constraint and what to call next. It also gives two mutually exclusive sizing strategies with the condition that selects each (explicit size vs. risk_usd + stop_price).

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 well: it discloses the return shape (typed_data, or approval_state=pending under human_passkey), the permission prerequisites, and the critical non-custodial guarantee that MCP alone can never move funds. It does not cover whether preparation reserves or locks funds, typed_data expiry, or idempotency of repeated calls.

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 clauses, each earning its place: what it does, what it requires/returns, and the execution boundary. The safety-critical constraint is front-loaded and no sentence 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 two-parameter preparation tool with no annotations and no output schema, the description covers prerequisites, the return contract, and the execution boundary that an agent most needs to avoid overclaiming success. The remaining gap is destination/amount format, which is the one thing an agent could get wrong at call time.

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 0%, so the description must explain both parameters, and it largely does not. "destination" has no stated format (Arbitrum address? wallet id? label?) and "amount_usd" only gains the implicit hint that USD is converted to USDC — no minimums, precision, or rounding semantics are given.

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 ("Prepare a withdrawal"), the asset and chain path (USDC → Arbitrum), and clearly separates itself from the sibling that actually executes (submit_intent). An agent can identify both what it produces and what it does not do 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 prerequisites (withdraw scope + matured allowlist) and names the alternative for the execution step (submit_intent via wallet signature), plus the human_passkey branch that yields approval_state=pending. The when-to-use and when-not-to-expect-execution conditions are both spelled out.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does add two useful facts — the triggers are reduce-only and paper mode executes immediately — but the mode contrast is left dangling (what does live mode do? queue? require confirmation?), and nothing is said about permissions, reversibility, or interaction with existing TP/SL.

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 core action is front-loaded. The second sentence is ambiguous phrasing ('Paper executes immediately') that costs a little clarity for its brevity.

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

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

For a three-parameter trading mutation with no annotations and no output schema, the description is thinner than ideal: no return values, no failure modes, no live-vs-paper semantics. It does convey enough for an agent to know broadly what the tool is for, but not enough to call it safely in all modes.

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 0%, so the description must explain all three parameters and does not. It implies tp and sl are take-profit and stop-loss prices, but nothing confirms units, relationship to entry price, required pairing, and the required `market` parameter is entirely unexplained.

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 (attach) and resource (reduce-only TP/SL triggers on an open position), which reads clearly and distinguishes it from order-placement siblings like place_order or submit_order. It stops short of explicitly naming a sibling it differs from, and 'post-hoc' is doing unstated work about applicability.

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?

'Post-hoc ... to an open position' implies the precondition of an existing position, but there is no explicit when-to-use versus close_position or place_order, no note on prerequisites, and no guidance on what happens if the position already has triggers. An agent must infer all routing decisions.

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

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

With no annotations, the description carries the full load and does so well: it discloses the critical one-time api_key return, the required follow-up action (configure as the Authorization header of this MCP server), and the default account state (paper mode). It omits failure behavior, such as what happens if the address is already registered, and whether the key is unrecoverable.

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, front-loaded sentences with zero waste: the action, the one-time secret and how to use it, then the account default. Each sentence changes what the agent does next.

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 correctly explains the key return value and the post-call configuration step, which is exactly what an agent needs. It is slightly incomplete about error/duplicate-registration paths and about the unexplained label parameter.

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 25% — only 'signature' is documented — so the description must compensate. 'Signed challenge' loosely implies that address, nonce, and signature all derive from the step-1 challenge, but the required 'label' parameter (1-60 chars) is never explained, leaving one of four required inputs without any meaning.

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: register (an agent) using the signed challenge, and identifies itself as 'Step 2' of a flow, which implicitly separates it from get_registration_challenge and rotate_key. It stops short of naming the sibling that produces the challenge, so the distinction is inferred 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?

'Step 2: register with the signed challenge' gives clear triggering context: call this after a challenge has been obtained and signed. It does not name get_registration_challenge explicitly or say when not to call it (e.g., if an api_key already exists, use rotate_key instead).

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

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

With no annotations present, the description carries the full burden and does so well: it discloses the authorization requirement (account wallet signature, EIP-191), that the api key is insufficient, and the two-call challenge/response sequence. It doesn't cover error behavior, nonce expiry, or rate limits, which keeps it below the top score.

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 compact sentences ordered by execution: purpose, precondition, then the two-step procedure. Every clause carries operational information; nothing is 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?

Given there is no output schema, the description usefully specifies what the argument-less first call returns ({ nonce, message }), which is the piece an agent could not infer. Minor gaps remain around post-success state and error recovery, but calling it correctly requires nothing further.

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% (the nonce property has no description), and the description compensates fully by explaining where nonce comes from, that message must be signed with the agent wallet under EIP-191, and that both values are passed on the second call. This is meaning well 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 effect ('Reactivate after kill_switch') and anchors it to the sibling tool that creates the paused state, so an agent immediately knows this is the inverse of kill_switch rather than another trading mutation.

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 trigger condition (after a pause via kill_switch) and an explicit constraint (the api key alone cannot undo a pause), which is exactly the kind of when-to-use guidance an agent needs. It stops short of naming alternatives or failure conditions such as an expired nonce, so not a 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?

With no annotations, the description carries the burden and does well: it discloses that old keys remain valid during a grace window (critical for an agent deciding whether rotation is safe mid-flight) and that scope authority cannot be added. It stops short of saying who is authorized to rotate, whether the old key is revoked after the grace window, or whether the new key is returned only once.

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, front-loaded with the action, then the constraint, then the rationale. The closing clause about a running bot is a justification that actually earns its place by explaining the grace window.

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-optional-parameter tool with no output schema and no annotations, this covers the essential behavior: what it mints, what it cannot do, and the old-key lifetime. Gaps remain around authorization requirements, post-grace-window revocation, and whether the new key value is returned, but these are moderate rather than blocking.

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 states "Subset of your current scopes. Omit to keep the same set," so the baseline is 3. The description adds a meaningful constraint beyond the schema by emphasizing narrowing-only and the inability to add authority, which clarifies the enum's intent.

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 ("Mint a fresh api key") plus the key constraint ("optionally NARROWING its scopes"). It also implicitly separates itself from escalate_scope and get_scope_challenge by naming them as the tools for adding authority.

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 states the negative case ("Cannot add authority") and names the exact alternative path (get_scope_challenge + escalate_scope) for the case this tool does not cover. An agent can route correctly without inference.

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

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

With no annotations supplied, the description carries the whole burden, and it discloses the important behavior that pending trading fees are collected before the transfer, that the destination cannot be redirected, and that a human/owner key signature is required over the payload. It does not cover failure modes such as insufficient balance or what happens to an unsigned first-call payload.

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?

Content is front-loaded with the destination guarantee, then the fee behavior, then the call sequence, then the fallback. The density is high but nearly every clause is operational; a light reordering into clearer steps would improve it without shortening it.

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 unannotated mutation tool with no output schema, the description supplies the return shape of the first call, the signing requirement, and the degraded-path endpoint, which is most of what an agent needs. Missing pieces are error handling and any statement about whether a partial multi-rail signing is acceptable.

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 schema documents amount_usd and owner_signatures but leaves time undocumented; the description compensates by explaining that time belongs to the second call alongside owner_signatures keyed by rail. It also clarifies that amount_usd is exactly what gets signed, reinforcing the schema's note about 2-decimal precision.

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 with explicit scope: 'Move USDC from your trading wallet back to your agent wallet, inside Hyperliquid,' and pins down that the destination is always the caller's own agent wallet. It also distinguishes itself from the outbound case by noting that leaving Hyperliquid is done via withdrawal from the agent wallet rather than 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?

The two-call protocol is spelled out: first call to obtain payload_b64 per rail plus the verify list, then a second call with time and owner_signatures. It also gives an explicit fallback for the no-API-key case (a terminated account) via a direct POST endpoint, and rules out using this tool to exit Hyperliquid. It stops short of naming a concrete sibling tool for the exit path.

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 supplied, so the description carries the full behavioral burden. It usefully discloses the funding prerequisite and cross-references a sibling tool, but for a mode switch that moves real money it says nothing about required permissions/keys, whether open positions or orders survive the switch, or whether switching back to paper is safe. That leaves a significant gap for a high-stakes mutation.

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

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

Two short sentences, operation stated first, precondition second with a pointer to the tool that resolves it. No filler 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?

With no annotations, no output schema and a single enum parameter, the definition covers the what and one prerequisite but omits the safety-relevant effects of switching to live: authorization requirements, impact on existing positions/orders, and reversibility. An agent could invoke it but might do so without understanding the consequences.

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 0% and there is one required parameter, but its enum values ('paper', 'live') are self-explanatory and the description reinforces their meaning while adding the funding condition attached to the live value. Little is lost, though it never explicitly ties the mode values to the enum or says what happens if the wallet is unfunded.

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 verb 'Flip' plus the resource 'paper ↔ live' states the operation concretely: switching the account between paper and live trading modes. It is clearly distinguishable from siblings like resume_trading or kill_switch, though the informal 'flip' relies on the reader inferring that 'paper/live' are account modes.

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 one real precondition ('Fund the wallet before going live') and points to get_account.deposit, which is useful. It does not say when not to switch, whether the account must be flat, or how this relates to authorize_trading_key or resume_trading, so usage is only partially 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?

No annotations are supplied, so the description carries the full behavioral burden. It signals that wallet signatures are required and that this is the execution step, but never says whether submission is irreversible, whether it can be retried or is idempotent, what happens if signatures are insufficient, or whether gas/network submission is involved.

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

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

A single front-loaded sentence with no filler; the verb and object appear immediately. It is arguably too terse rather than padded, so there is no wasted wording to cut.

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 state-changing execution tool with no annotations, no output schema, and zero schema description coverage, which is the case where the description must do the most work. It leaves the agent without return-value expectations, failure behavior, or signature requirements beyond the bare hint that signatures come from the wallet.

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%, so the description must explain both parameters. It only gestures at them: 'prepared intent' hints at intent_id and 'the wallet's signatures' hints at the signatures array, but it gives no format, no expected number of signatures, no statement of which key or wallet must sign, and no error semantics for a bad intent_id.

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

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

States a specific verb ('Execute') and resource ('a prepared intent'), and enumerates the intent kinds (cancel/protect/withdraw), which separates it from the read/list siblings. It does not explicitly contrast with submit_order or prepare_withdrawal, so sibling differentiation is only implied by the word 'prepared'.

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 'prepared intent' implies a prerequisite (an intent must already exist, presumably via prepare_withdrawal or similar), which is useful implied sequencing. There is no explicit when-to-use versus submit_order, no statement of what to do if signing is incomplete, and no exclusion of any case.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that this executes a LIVE order and requires one signature per typed_data in order, which signals real-money impact and a precise signing protocol. It does not disclose reversibility, permission requirements, failure behavior on invalid signatures, or whether execution can be cancelled afterward.

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

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

The description is a single, front-loaded sentence with no wasted wording. Its compactness is effective, though the same brevity contributes to the gaps in usage and behavioral detail.

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 live trading execution tool with no annotations, no output schema, and no parameter descriptions in the schema. The definition omits critical context such as authentication expectations, return behavior, signing failure handling, and routing against sibling tools like place_order and submit_intent, making it insufficient for a high-stakes 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 0%, so the description must compensate. It adds meaningful semantics for signatures by stating they are per typed_data and must be ordered, but it leaves order_id unexplained and does not define the expected signature format or how it relates to the prepared order.

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 object: execute a prepared LIVE order using trading-key signatures. This clearly conveys the tool's role and distinguishes it from read tools like list_orders or get_positions. It does not, however, explicitly distinguish itself from nearby siblings such as place_order or submit_intent.

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 'prepared LIVE order' implies this should be called after an order has been prepared, and the signature requirement implies a trading key is already authorized. However, there is no explicit when-to-use guidance, no exclusion of alternatives like place_order or submit_intent, and no stated prerequisites beyond implication.

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 disclose key traits: the call is synchronous, the payload is signed, and the event is a test rather than a real one, so the agent knows it is a safe-ish diagnostic. It leaves important behavior unstated — whether a failed test mutates webhook state (failure counters, auto-disable), what happens on receiver timeout, and whether auth/permissions are 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?

A single front-loaded sentence with the core action first, then the purpose clause. No wasted words or redundancy.

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

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

For a one-parameter, no-output-schema diagnostic tool the description covers what it does and what it returns at a high level (the receiver's response). The remaining gap is failure-mode behavior, which matters for a tool whose entire point is surfacing failures.

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 0% and the single required parameter webhook_id is never mentioned in the description, so no meaning is added beyond the schema. The name is largely self-explanatory, which keeps this at minimum-viable rather than failing.

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 ('send a synchronous signed test event to a webhook') plus the outcome ('report the receiver's response'), which cleanly separates it from create_webhook, get_webhook, list_webhooks and delete_webhook. An agent can identify the operation 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 a clear usage context — verify endpoint and HMAC handling before relying on real events — which tells the agent this is a pre-flight check, not a delivery mechanism. It stops short of explicit exclusions or naming alternatives for inspecting an existing webhook's config.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses the live "stopping" state, that the engine closes mirrored positions, that fees are settled, and that the copy scope is required. It stops short of describing irreversibility, failure modes, or what happens if no positions are open.

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 action and followed by the key live behavior and scope requirement. There is no redundant or filler wording.

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 mutation with no output schema, the description covers the main side effects and authorization scope. It is only missing parameter semantics for leader_id and guidance on checking post-call status.

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%, and the description does not explain leader_id beyond referring to "a leader." It gives no format, source, or validation meaning for the sole required parameter.

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: "Stop copying a leader." It is clearly the inverse of the sibling follow_leader, so an agent can distinguish the action 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?

Usage is implied by the action itself, and the description adds the prerequisite "Requires the 'copy' scope." However, it does not explicitly say when to use this versus checking status with get_copy_status or starting with follow_leader.

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

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

With no annotations, the description carries the full load, and it does disclose one important trait: loosening has a 24h latency while tightening is immediate. It omits other critical behavior for a safety-critical mutation — whether omitted/null fields are left unchanged, permission or signing requirements for this call, and whether changes can be reverted.

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 behavioral trade-off is front-loaded. The opening word "rails" is too cryptic to serve as a strong lead, but nothing is wasted.

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

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

This is a risk-limit mutation tool with no annotations, no output schema, and 0% parameter coverage, so the description bears the whole burden and covers only latency. Missing are required permissions/signing, partial-update semantics, and what confirmation the caller receives.

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

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

Schema description coverage is 0% across four parameters, yet the description never names or explains any of them. The null-union pattern (likely meaning 'leave unchanged') and the semantics of asset_allowlist are completely undocumented, so the agent must guess at update semantics.

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?

"Adjust rails" is domain jargon that only becomes interpretable when paired with the tool name update_limits; the description never states plainly that it changes trading risk limits. It also doesn't distinguish this from siblings like escalate_scope or get_limits, though the delay semantics hint at the scope.

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

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

It gives a genuine decision rule (tightening is instant, loosening incurs 24h) which implies when the tool is the slow path. However, it points to a docs route (/limits/escalate) rather than naming the sibling tool escalate_scope, so an agent may go looking in documentation instead of calling the alternative tool.

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