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

Annotations declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, which raises the question of whether a backtest mutates account state or fires real orders; the description is silent on this. It also says nothing about runtime, whether results persist, or whether it needs a live market connection. With non-trivial annotations present, the description adds no behavioral context to disambiguate them.

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-line purpose followed by a compact per-parameter glossary, with the two required paths listed first. Nothing is padded, though the parameter block is a flat list rather than front-loading the required inputs explicitly.

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?

An output schema exists, so return values need not be described. However, for a five-parameter simulation tool whose annotations flag non-read-only, non-idempotent behavior, the description should at minimum say whether account or order state is affected. That gap keeps it at minimum-viable rather than complete.

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

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

Schema description coverage is 0%, so the description carries the full burden and largely does: it gives the accepted file formats for data_path, shows a dotted-path example for strategy_path, and identifies balance as USD. The gaps are the units/meaning of spread and depth (it calls them 'synthetic order book' values but gives no scale or defaults) which the schema's bare types do not fill in.

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: run a backtest against historical price data. The purpose is unmistakable and no sibling tool overlaps with it. It stops short of saying what the backtest yields or how it relates to the live trading tools (buy/sell/place_limit_order), so it lacks sibling differentiation beyond the obvious name.

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 at all. The description never says whether this simulates trades without touching the account or whether it is a prerequisite for anything, and it never contrasts itself with the live-order siblings. An agent gets no routing information from the text.

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

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description goes beyond them by disclosing execution semantics: it buys at best available prices and explains that 'fok' is all-or-nothing while 'fak' permits partial fills. It does not mention slippage or funding requirements, but the added execution detail is genuinely useful.

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 lines, front-loaded with the verb and resource, and each sentence carries information. Formatting is slightly awkward with mid-thought line breaks, but there is no filler.

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

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

An output schema exists, so return-value explanation is not required. Still, for a real-money mutation that is non-idempotent, the description omits prerequisites such as account selection (the 'account' param), slug vs id format, and any balance or minimum-order constraints.

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 fully explains the order_type enum values and conceptually covers amount_usd, but leaves slug_or_id, outcome, and account entirely undefined — and 'outcome' (which side/token of the market) is a required parameter whose meaning an agent could easily get wrong.

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

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

States a specific verb and resource ('Buy shares in a Polymarket outcome') and identifies the exchange (Polymarket). It is distinguishable from 'sell', but does not explicitly differentiate itself from 'place_limit_order', which is the closest 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?

Usage context is implied: this is a market buy that spends amount_usd at best available prices. However, there is no explicit routing guidance such as 'use place_limit_order for limit orders' or stated prerequisites (funded account, minimum size), leaving the agent to infer when to choose this over its siblings.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds no behavioral context beyond the name — nothing about irreversibility, blast radius, whether it spans accounts, or whether it blocks new orders. For a destructive bulk operation this is thin.

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

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

A single front-loaded sentence with no filler. It is efficient, though the brevity comes at the cost of the operational detail this destructive tool needs.

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

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

An output schema exists so return values need not be explained, but for a destructive bulk-cancel tool the definition omits account scoping, prerequisites, and post-cancellation behavior. An agent lacks enough context to call it safely and predictably.

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 never mentions the single 'account' parameter or its 'default' value. The phrase 'all pending limit orders' actually implies global scope without clarifying that it can be scoped by account, leaving the one parameter 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 (cancel) and resource (all pending limit orders) with clear scope ('at once'), which distinguishes it from the singular cancel_order sibling. However, it never names that sibling explicitly, so the differentiation 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?

There is no guidance on when to use this versus cancel_order, place_limit_order, or list_orders/check_orders, and no preconditions (e.g., auth or account state) are given. Usage is only implied by the verb.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is carried by structured data. The description adds one useful behavioral constraint, that only pending limit orders are cancellable, but says nothing about failure modes (order already filled, unknown ID) or the effect of cancelling.

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

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

A single tight sentence with the action front-loaded and no filler. It is efficient, though the brevity is arguably part of the specification gap rather than pure economy.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. Still, for a destructive mutation with one fully undocumented parameter and no stated precondition failures, the description leaves real gaps an agent would want filled.

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 bears the full burden. 'By ID' loosely maps to order_id, but the 'account' parameter (default 'default') is explained nowhere, and neither parameter's format or constraints are clarified.

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 pending limit order') and the qualifier 'pending limit' narrows scope enough to separate it from cancel_all_orders. It stops short of explicitly naming that sibling, so an agent must infer the division of labor.

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

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

The description gives no when-to-use or when-not-to-use guidance and never mentions cancel_all_orders, which is the obvious alternative for bulk cancellation. The only usable signal is the implicit 'pending limit order' scope, which the agent must decode on its own.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the agent knows this mutates state and depends on external market data. The description adds the mechanism (pending orders matched against live prices become fills) and implies repeat-call safety, but says nothing about authentication, rate limits, or what happens to partially filled or rejected orders.

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 before the invocation guidance. The second sentence partially restates the first, but it adds the periodicity cue, so it roughly 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?

An output schema exists, so return values need not be described. Given the tool mutates state and takes an undocumented scoping parameter, the description is complete enough to invoke safely but leaves the account-scoping and failure-mode questions unanswered.

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

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

The single parameter "account" has 0% schema description coverage (only a "default" value), so the description is the only place its meaning could be established — and it never mentions the parameter. It does not say whether omitting it defaults to the "default" account or whether evaluation can be scoped to one account.

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+resource: it checks pending limit orders against live prices and executes fills. That is clearly distinct from sibling tools like place_limit_order, list_orders, and cancel_order, even though those siblings are never named.

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?

"Call this periodically to trigger limit order evaluation" gives explicit invocation context (a polling/cadence trigger), which is genuinely useful for an agent deciding when to call it. However, it offers no exclusions or alternatives (e.g., whether to call per-account or whether it is safe to call after cancel_all_orders).

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds some value by breaking down the payload (reserved vs available cash, P&L) but says nothing about freshness, pagination, or whether positions are included by default.

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

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

One sentence, front-loaded with the core action and no filler. It could be slightly tighter since part of the content list duplicates what the output schema already exposes.

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?

An output schema exists, so return structure need not be explained, and the operation is a simple read with no required parameters. However, the definition omits any routing guidance among the many sibling read tools and leaves the sole parameter undocumented.

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 single 'account' parameter with its 'default' value is never mentioned in the description. The word 'account balance' hints at account scoping but does not explain what values are accepted or what 'default' resolves to.

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

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

States a specific verb and resource ('Get current account balance') and enumerates the returned content (cash, reserved/available cash, positions value, P&L). It does not distinguish itself from plausible siblings like 'portfolio' or 'history', which may also surface balance-like 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?

There is no guidance on when to call this versus alternatives such as portfolio, history, or stats, and no mention of prerequisites. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds only the conceptual definition of an event; it says nothing about pagination, nesting of child markets, or lookup failures, so it does not meaningfully exceed the annotation baseline.

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 compact sentence with the purpose front-loaded and the clarifying appositive kept short. Nothing is wasted, though it omits any routing or parameter detail that would make the sentence more load-bearing.

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?

An output schema exists, so return-shape explanation is not needed, and annotations cover the safety semantics. The remaining gap is the undocumented required slug argument and the absence of any routing hint among many market-related siblings, leaving the definition merely adequate for a simple read 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% and the single required parameter 'slug' is undocumented in both schema and description. The description never explains that the slug identifies the event (vs. a market slug), nor gives format examples, so it fails to compensate for the coverage gap.

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

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

Specific verb+resource ('Get event details') with a useful gloss ('a group of related markets') that defines the domain object and implicitly distinguishes it from the sibling get_market, which returns a single market. It does not explicitly name get_market as the alternative, so it falls short of a 5.

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

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

No guidance on when to use this versus get_market, list_markets, search_markets, or get_markets_by_tag, and no prerequisites stated. The description only says what the tool does, leaving tool selection 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, fully covering the safety profile for this lookup. The description adds nothing beyond that annotation set – no note on what happens with an unknown slug, whether a condition ID behaves differently, or the cost/freshness of the call.

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

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

A single compact sentence, front-loaded with the verb and resource and ending with the discriminator for the input. Zero filler.

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

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

For a one-parameter, read-only getter with a declared output schema, the description need not explain return values or pagination. It is close to complete; the only shortfall is not positioning itself against the related market/event retrieval tools in a crowded sibling list.

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

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

Schema coverage is 0% and the sole property is merely titled 'Slug Or Id', so the description carries real weight by explicitly stating the accepted value types ('by slug or condition ID'). It compensates for the bare schema, though it gives no format nuance (e.g., hex ID vs. slug shape).

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

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

States a specific verb and resource ('Get detailed info for a specific market') plus the lookup key (slug or condition ID). This implicitly separates it from list_markets and search_markets, which return sets rather than a single market, though it never names those siblings or get_event as an alternative.

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

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

Usage is implied rather than stated: an agent infers this is the tool for fetching one market once it already has a slug or condition ID. There is no explicit when-to-use/when-not guidance and no mention of how it differs from search_markets, list_markets, or get_event.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond the name: no pagination behavior, no note on ordering or what happens with an unknown tag slug, so it contributes no extra behavioral context.

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

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

A single short sentence with no filler, which is good, but the brevity reflects under-specification rather than tight information density.

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?

An output schema exists so return values needn't be explained, but with zero schema description coverage the definition leaves the required tag_slug format and the limit semantics undocumented. For a tool in a crowded market-listing family, this is too thin to route the agent confidently.

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 and does not. It alludes to the tag concept but never documents the tag_slug format, whether it must match get_tags output, or what the limit parameter controls.

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 clear verb+resource (list markets) scoped by category/tag, which distinguishes it from the unfiltered list_markets. It does not explicitly name search_markets or get_market as alternatives, so sibling differentiation is implied rather than stated.

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

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

No guidance on when to use this versus search_markets, list_markets, or get_tags. The agent must infer from the name alone that this is the tag-filtered listing 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds useful context by stating the book is 'live' and contains asks and bids, but it does not discuss freshness, throttling, or whether the book can be empty.

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

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

A single front-loaded sentence with no filler, and the key noun 'order book' appears early. It is efficient, though terse relative to the gaps it leaves.

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?

An output schema exists, so return-value explanation is not required, and the description adequately states what the tool fetches. However, with 0% parameter coverage and no usage guidance, an agent still lacks enough information to invoke it confidently across different market identifiers.

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 neither parameter is explained: 'slug_or_id' is undocumented and the 'outcome' parameter's default of 'yes' is not mentioned. The phrase 'market outcome' hints at the outcome parameter but adds no format or allowed-value detail, so the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Get the live order book for a market outcome') and clarifies the content returned ('asks and bids'). It is clearly distinct from siblings like get_market or list_orders, though it does not explicitly name how it differs.

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 indication of when to call this tool versus alternatives such as get_market or buy/sell, and no prerequisites are given. The only inferable guidance is that it is a read operation, which comes from annotations rather than the description.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety and repeatability profile is covered. The description adds only that these are market categories used for filtering; with a rich annotation set and an output schema present, this modest addition is worth a 3.

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

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

One short, front-loaded sentence with no filler. It is efficient, though the budget freed up by that brevity is not spent on any routing or scope detail, which slightly weakens it against the more verbose siblings.

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

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

For a no-parameter, read-only lookup with an output schema and full annotation coverage, the description supplies enough to call it correctly. The only real gap is disambiguation from get_markets_by_tag, which the agent must resolve on its own.

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 are no parameter semantics for the description to clarify. Baseline 4 applies; the description correctly implies an unfiltered, complete retrieval.

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

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

States a concrete verb and resource: 'Get all market categories/tags', and adds the use case ('for filtering'). It does not, however, distinguish itself from the close sibling get_markets_by_tag, which an agent might easily confuse with it.

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

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

The phrase 'for filtering' implies the intended use — retrieving the tag vocabulary so tags can be applied as filters elsewhere. There is no explicit when-to-use versus get_markets_by_tag, nor any exclusions or prerequisites, leaving routing to be inferred.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds essentially nothing beyond that — no meaning for 'recent', no pagination behavior, no indication of whose history the default account 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?

The single sentence is front-loaded and free of padding, which is good, but its brevity comes from under-specification rather than discipline. It is appropriately sized only in the sense that there is nothing to trim.

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?

An output schema exists, so return values need no explanation here. However, with a defaulted account parameter and an undefined recency window, the description leaves an agent unable to call the tool confidently relative to its many data-returning siblings.

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

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

Schema description coverage is 0% for both parameters, and the description never mentions limit or account at all. The agent must open the schema and still finds no prose explaining what values these accept or how 'account: default' resolves.

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

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

States a specific verb and resource ('Get ... trade history'), which is better than a tautology, but it doesn't differentiate itself from siblings that also return trading data such as list_orders, check_orders, and portfolio. An agent cannot tell from this description which one to reach for.

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 at all — no mention of when history applies versus list_orders, check_orders, or portfolio. The word 'recent' hints at a time window but never defines it or explains how to widen 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?

Annotations declare destructiveHint=true and idempotentHint=true, and the description explicitly warns it can reset an existing account – the one genuinely important behavioral fact beyond the hints. It does not detail what reset destroys (orders, history, positions), so it's not a 5.

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

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

Two short lines, purpose first and the destructive reset caveat second. 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?

An output schema exists so return values needn't be explained, and annotations cover safety. What's missing is the overlap with reset_account and the full consequences of the reset path. Adequate but with a clear gap for 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 coverage is 0% and neither parameter has a description. The description only names the balance as USD-denominated, leaving account identity and the currency/range semantics of balance entirely undocumented. It partially compensates but far from fully.

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 clear verb+resource: initialize/reset a paper trading account. The title and description align well. It is distinguishable from reset_account and get_balance, though it doesn't explicitly contrast with the sibling reset_account that presumably does the same thing.

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

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

No guidance on when to use this versus reset_account, which by the description's own wording ('resets an existing one') appears to overlap. No prerequisites or typical invocation context are given.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely useful domain behavior beyond the annotations: Kalshi publishes bids only and asks are derived via a NO bid at p being a YES ask at 1 - p, plus best-levels-first ordering.

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 resource and scope, and the derived-asks nuance follows immediately. No filler.

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

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

Output schema exists so return values need not be described, and annotations cover the safety profile. The only meaningful gap is the undocumented depth parameter and ticker semantics.

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 carry the parameter burden and it does not mention either parameter. Neither 'ticker' (market vs event ticker) nor 'depth' (number of book levels, default 10) is explained anywhere, leaving both ambiguous for the caller.

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

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

States a specific verb and resource with scope: 'Get the live YES order book for a Kalshi market'. It is clear what the tool returns, but it never distinguishes itself from the sibling get_order_book, leaving the agent to guess whether this is the Kalshi-specific variant or a duplicate.

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

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

There is no when-to-use guidance and no named alternative, despite siblings get_order_book, kalshi_market, and kalshi_markets competing for overlap. The agent gets domain context (Kalshi market) but no routing rule.

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

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

The only behavioral claim ('read-only') merely restates the readOnlyHint annotation, so it adds no value beyond structured data. With annotations already covering readOnly, idempotent, destructive, and openWorld, the description contributes nothing new such as error behavior for an unknown ticker.

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

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

A single front-loaded sentence with zero filler, placing the identifier (ticker) before the parenthetical qualifier. Nothing is redundant or padded.

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

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

The output schema means return values need not be explained, and the operation is simple. Still, in a sibling set crowded with market-listing and market-fetching tools, the absence of any disambiguation makes the definition only minimally complete.

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

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

Schema description coverage is 0%, so the description must carry the ticker parameter's meaning. Saying 'by ticker' does identify the key as a market identifier, which is minimal but real compensation; it gives no format or example, so it only partly fills the gap.

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

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

States a specific verb and resource ('Get one Kalshi market by ticker'), so the operation is unambiguous. However, it does nothing to distinguish itself from near-identical siblings such as get_market, kalshi_markets, and list_markets, leaving the agent to guess which one to call.

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 indication of when to use this over get_market, kalshi_markets, or list_markets, which overlap heavily in this sibling set. No prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the 'read-only' remark is largely redundant. The useful additions are the status enumeration and the note that slug equals the Kalshi ticker, but return/pagination behavior is not addressed.

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

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

Two compact sentences, front-loaded with the scope constraint; little waste, though the format is terse enough that the ticker-filter sentence reads as a fragment.

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?

An output schema exists so return values need not be explained, and the read-only/list framing covers the safety side. The only shortfall is the undocumented limit parameter, minor for a low-complexity list tool.

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

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

Schema coverage is 0%, so the description must compensate; it does for three of four params, defining status values (open/closed/settled) and explaining that series_ticker/event_ticker narrow the list. The limit parameter is left undocumented, a small gap.

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

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

States a specific verb and resource ('List Kalshi markets') and clarifies scope with 'read-only; trading stays on Polymarket'. The singular sibling kalshi_market exists, and while the plural/singular distinction is inferable, the description never explicitly routes between them.

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

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

It hints at narrowing via series_ticker/event_ticker and status, which implies when to use the filters, but gives no explicit when-to-use versus siblings like kalshi_market or get_markets_by_tag, and no exclusions.

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

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

Annotations already cover readOnly/idempotent/openWorld/destructive, so the bar is low, but the description adds real context: the 10+ trade qualification threshold, ROI% ranking, and where data is read from (~/.pm-trader locally vs the caller's directory in remote mode). This tells the agent what will be scanned and what qualifies.

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 primary outcome, then the qualification rule, then the parameter condition, then the data-root detail. No filler, though the line breaks make it slightly more sprawling than necessary.

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 an output schema present, return values need not be described. Combined with the annotation coverage, threshold, ranking basis, scope, and parameter semantics, an agent has enough to invoke it correctly; only sibling differentiation is missing.

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

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

Schema description coverage is 0%, so the description must carry the parameter. It does: 'comma-separated', include-only-those-accounts when supplied, otherwise scan everything. Format and default behavior are both conveyed, compensating well for 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 specific verb and resource: 'Generate a Top 10 leaderboard card', and clarifies the source is 'all local accounts'. It does not explicitly distinguish itself from the sibling leaderboard_entry, so it stops short of a 5.

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

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

It explains the filter mechanics of the accounts parameter but never says when to use this tool versus leaderboard_entry or stats_card. There is no when/when-not guidance or named alternative, only procedural scope.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds the fair-comparison intent and enumerates metrics, but those return values are also carried by the output schema, so the net new behavioral insight is modest.

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

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

Front-loaded with the core purpose in the first sentence and kept to three short lines. There is mild redundancy between the metric list and the 'includes starting balance, total trades, and account age' sentence, but overall it earns its space.

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?

An output schema exists so return values needn't be re-explained, and the annotations cover the safety profile. The remaining deficits are the unexplained 'account' parameter and absent usage routing against its many sibling cards/stats tools.

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

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

Schema description coverage is 0% and the single 'account' parameter (default 'default') is never explained in the description. An agent gets no guidance on what an account identifier means here or how multiple accounts behave.

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

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

States a specific verb and resource ('Generate a verifiable leaderboard entry for ranking and PK'), so the agent knows this produces a ranking artifact. However, it does not distinguish itself from close siblings like stats, stats_card, leaderboard_card, or pk_card, leaving overlap ambiguity.

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

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

The phrase 'for ranking and PK' implies a purpose but gives no when-to-use condition, prerequisites, or named alternatives. With five similar stats/card siblings present, the absence of routing guidance is a real gap.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds one behavioral qualifier, that only active markets are returned, which is useful filtering context, but says nothing about result size, truncation, or ordering behavior beyond the sort 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?

A single front-loaded sentence with zero padding. It is efficient, though arguably underpadded given the schema leaves both parameters undocumented.

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?

An output schema exists so return values need not be explained, and annotations cover safety. However with 0% parameter schema coverage and no usage routing, the definition is only minimally complete for a tool sitting among several overlapping market-listing siblings.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies that sort_by accepts volume or liquidity (values absent from the schema) but never explains 'limit' or its default. Partial compensation for the coverage gap.

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

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

Clear verb (List) plus resource (active Polymarket markets) and a scope qualifier (active only), which distinguishes it somewhat from the more flexible search_markets sibling. It does not explicitly name or contrast with that sibling, so it stops short of a 5.

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

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

No guidance on when to use this versus search_markets, get_market, get_markets_by_tag, or get_tags. The word 'active' implies a filter but the reader gets no condition or exclusion criteria for choosing this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral fact that only pending limit orders are returned (not filled/cancelled ones), but says nothing about scoping to an account or the default account 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?

One short sentence, front-loaded with the verb and resource, and the 'pending' qualifier placed where it filters the result set. No 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Still missing is why this tool exists alongside check_orders and how the account parameter affects the listing, leaving the agent to guess on the two points that actually require description.

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 single 'account' parameter is documented only by its schema key and a 'default' value. The description never explains what the account parameter does, whether results are scoped to it, or what happens with the default.

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

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

States a specific verb ('List') and resource ('limit orders') with an added scope qualifier ('pending'). It does not distinguish itself from the sibling check_orders, which plausibly covers overlapping order-status ground, so sibling differentiation is missing.

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

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

There is no guidance on when to call this versus check_orders, cancel_order, or place_limit_order, and no mention of prerequisites such as account selection. The 'pending' qualifier implies a filter but never states what disqualifies an order from the result.

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

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

Annotations already declare it is a non-read-only, open-world, non-idempotent, non-destructive operation, so the bar is lower. The description adds real behavioral context: both strategies start from the same balance, run independently, and results are compared with a winner announced. It still doesn't say whether the run mutates account balance/state or is simulated.

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 mechanics, then parameter notes. No wasted sentences, though the trailing parameter glosses could be folded more cleanly into the prose.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Combined with the mechanics description this is nearly complete; the missing balance parameter semantics is the only notable gap.

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

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

Schema description coverage is 0%, so the description must compensate, and it does explain strategy_a/b (dotted Python path with an example) and name_a/b (display names). But the 'balance' parameter is never mentioned, leaving one of five parameters undocumented in both schema and description.

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: running two strategies head-to-head and comparing them with a PK card. However, it never differentiates itself from the sibling 'backtest' tool, which an agent could plausibly confuse it with for strategy evaluation.

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 usage context is implied (use it when you want to compare two strategies), but there is no explicit when-to-use/when-not guidance and no mention of how it relates to alternatives like backtest or a single-strategy run.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds useful output context ('tweet-ready card with winner announcement') but says nothing about how missing/invalid accounts are handled or what the defaults ('default', 'aggressive') imply.

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 and the compared metrics in the first two sentences. The final sentence ('Great for rivalry and sharing') is light marketing copy that doesn't earn much of its place.

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

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

With an output schema present, return-format detail isn't required, and the annotations cover safety. The description covers purpose, compared dimensions, and output nature; the only real gap is the unexplained default account values.

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 both parameters, so the description must carry the load. It does convey that the two inputs are the two accounts being compared head-to-head, which maps to account_a/account_b, but it adds no format, value, or default semantics beyond the names themselves.

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 ('Generate a head-to-head PK comparison card between two accounts') and enumerates the compared metrics (ROI, Sharpe, win rate, trades, tier). It is clear what the tool produces but never distinguishes it from the sibling pk_battle, which an agent would reasonably confuse it with.

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

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

The closing line 'Great for rivalry and sharing' implies the social/competitive context in which to reach for this tool, giving implied usage. However, it offers no when-not guidance and never mentions pk_battle or the other card tools (stats_card, leaderboard_card) as alternatives.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the mutation/non-destructive profile is covered. The description usefully adds that the order persists until filled/expired and clarifies the gtc vs gtd lifecycle, but does not mention permissions, fund-holding/reservation, resolution behavior, or failure modes.

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 parameter notes are front-loaded and compact, but the list is bare and presentational rather than structured prose, and the split between the main sentence and the annotations is a bit disjointed. Nothing is wasted, but the format is not optimally organized.

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 presence of an output schema means return values need not be explained, and annotations cover safety. Still, for a non-idempotent order-placement tool with 8 params and 0% schema coverage, the description omits the meaning of core parameters and the effect of the order on the account.

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 documents side, limit_price range (0–1), order_type semantics, and the gtd/expires_at dependency. However three required parameters (slug_or_id, outcome, amount) and the optional account parameter receive no explanation, leaving a substantial gap against the eight-parameter 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 ('Place a limit order') and defines the lifecycle ('stays open until filled or cancelled/expired'), which differentiates it from the sibling market-order tools buy/sell. It does not explicitly name those siblings, but the limit-order concept is clear.

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

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

No guidance on when to use this instead of buy, sell, or a market order, and no prerequisites or account context. The reader must infer that a limit order differs from the adjacent buy/sell tools.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds that prices are live and P&L unrealized, hinting at real-time computation cost, but says nothing about latency, rate limits, or what happens when there are no open positions.

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

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

One sentence, front-loaded with the verb and resource, with the valuable qualifier about live pricing following immediately. 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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile. The gaps are the undocumented account parameter and the absence of any fleet-routing context among the balance/history siblings, leaving the definition merely adequate.

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

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

The single 'account' parameter has 0% schema description coverage and a 'default' value, yet the description never mentions it. An agent cannot tell from the description whether omitting it is safe or what a named account selects, so the description does not compensate for the coverage gap.

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

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

States a specific verb (get) and resource (open positions) and clarifies the payload with 'live prices and unrealized P&L', which separates it in spirit from get_balance and history. It stops short of explicitly naming those siblings, so an agent must infer the boundary between positions, balance, and trade history.

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, nor any mention of alternatives such as get_balance or history. The purpose implies a portfolio snapshot, but routing among the many read siblings 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds concrete value beyond that by enumerating exactly what is destroyed (trades, positions, balance), which the annotations do not specify. It stops short of noting irreversibility or confirmation requirements.

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

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

One short, front-loaded sentence with no filler; the destructive consequence is stated immediately. It is arguably too terse given the omission of the account parameter, 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?

The output schema exists, so return values need not be explained, and annotations carry the safety profile. However, for a destructive reset the description omits which account is reset and any irreversibility note, leaving a meaningful gap for correct invocation.

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

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

The single 'account' parameter has 0% schema description coverage and the description never mentions it, so its meaning, the effect of the 'default' value, or how targeting a non-default account behaves is left entirely to the raw schema. With coverage this low, the description should have compensated and does not.

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 ('reset') plus an explicit, enumerated scope of what is affected: all trades, positions, and balance. This tells an agent exactly what the operation does and how its blast radius compares to sibling tools like buy, sell, or portfolio, though it never names a sibling to sharpen the contrast.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of the natural counterpart init_account. An agent gets no signal about prerequisites, sequencing, or alternative tools for clearing data.

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

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

Annotations already disclose that this is a mutation (readOnlyHint=false), open-world, idempotent, and non-destructive, so the agent knows repeated calls are safe. The description adds the payout semantics (winning shares redeem at $1), which is useful beyond the annotations, but says nothing about permissions, what happens to losing positions, or whether the action can be reversed.

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

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

A single tight sentence with the verb and the payout consequence front-loaded and no wasted filler. It is arguably under-specified rather than verbose, but as prose it is efficient.

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

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

An output schema exists, so return values need not be described, but the definition is still thin for a state-mutating financial tool: undocumented parameters (0% schema coverage), no guidance on the resolve vs resolve_all choice, and no precondition that the market be resolvable. Too much is left to inference.

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 both parameters, so the description must carry the load and it does not. Neither 'slug_or_id' (which identifier format is accepted) nor 'account' (and its 'default' value / multi-account semantics) is explained anywhere.

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

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

States a specific verb (resolve) and resource (a market's positions) plus the payout rule ($1/share for winning outcome), which is more informative than the title. However it never distinguishes itself from the sibling tool resolve_all, leaving the agent to guess which scope applies.

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

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

There is no when-to-use guidance at all: no prerequisite that a market be closed/expired, no mention of when to prefer resolve over the sibling resolve_all, and no note on ordering relative to buy/sell or cancel_order. Only the implied purpose conveys any usage context.

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

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

Annotations already declare this is a mutation (readOnlyHint=false) that is idempotent and non-destructive. The description adds essentially no behavioral context beyond that - it does not state what happens to the resolved positions, whether it affects all accounts, or what permissions are needed.

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 sentence, front-loaded with the verb and scope, with no wasted words. It is efficient, though the brevity contributes to the ambiguity noted elsewhere.

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?

An output schema exists so return values need not be explained, but for a bulk mutation tool with zero annotation-independent guidance and an undocumented parameter, the description is too thin to let an agent invoke it confidently.

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

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

There is one parameter ('account', default 'default') with 0% schema description coverage, and the description never mentions it or explains what account scoping means. The single sentence provides no compensating meaning for the undocumented 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 gives a verb (resolve) and a resource (all open positions in closed/resolved markets), which is more specific than the title. However, it does not distinguish itself from the sibling tool 'resolve', and the title ('Resolve all closed positions') conflicts with the description's 'open positions', leaving scope ambiguous.

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

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

There is no guidance on when to use this bulk operation versus the singular 'resolve' sibling, nor any stated preconditions (e.g., that markets must already be closed/resolved). Usage must be inferred entirely from the description text.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that: no ranking/relevance behavior, no pagination or limit semantics, no note that search is against live Polymarket data.

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 the action and resource front-loaded and zero filler. It is efficient, though the brevity is partly under-specification rather than disciplined concision.

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?

An output schema exists, so return values need not be explained, but with 0% schema coverage and no sibling routing the agent is left guessing how 'limit' behaves and when this beats list_markets. For a two-parameter search tool in a 29-tool family, the definition is thinner than it needs to be.

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 carries the full burden for two parameters. It clarifies that 'query' is a string match, but says nothing about the 'limit' parameter (default 10) or whether the query supports keywords, phrases, or fuzzy matching.

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 ('search') and resource ('markets') plus the domain (Polymarket), and 'matching a query string' signals this is a filtered lookup rather than an enumeration. It implicitly distinguishes itself from list_markets and get_market, though it never names them explicitly.

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

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

No guidance on when to use this instead of list_markets, get_market, or get_markets_by_tag, despite three plausible siblings existing. The only hint is the presence of a 'query' parameter.

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

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

Annotations already declare this as a non-idempotent, non-read-only write, and the description adds real behavioral context by defining the order execution modes ('fok' kills the whole order, 'fak' allows partial fills). That is meaningful disclosure beyond the structured fields, though execution guarantees and failure behavior are not fully described.

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 lines with the core purpose front-loaded and no filler. The stray quoting/line break around the order_type sentence is slightly untidy but does not waste space.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. However, for a 5-parameter trade tool, key inputs (how to identify the outcome, what 'account' selects) are never addressed, leaving gaps an agent would need to guess at.

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

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

Schema description coverage is 0%, so the description must carry the burden, yet it only explains one of five parameters (order_type). The meanings of slug_or_id, outcome, shares, and account are left entirely undocumented in both schema and description.

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 ('Sell shares in a Polymarket outcome') and the execution style ('at best available prices'). This distinguishes it implicitly from the sibling 'buy' and from 'place_limit_order', but neither alternative is named, so sibling differentiation 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?

Usage is implied rather than stated: 'best available prices' signals a market-order sell as opposed to a limit order, but there is no explicit when-to-use, when-not, or pointer to 'place_limit_order'/'buy'. An agent can infer the context but gets no routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety and idempotency profile is covered and 'generate' is consistent with a read-only operation. The description adds that output includes hashtags and an install CTA, which is genuinely useful output-shape context beyond the annotations but is the only behavioral addition.

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 one-line purpose followed by tight, skimmable enumerations of the two enum-like parameters, then a single closing sentence on output. No filler sentences; every line 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. The description fills the critical 0%-coverage parameter gap with value enumerations; the remaining gaps are the undocumented 'account' parameter and lack of sibling differentiation, which are minor for a low-complexity, zero-required-parameter 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%, so the description carries the full burden and it delivers: it enumerates the valid platform values (twitter/X, telegram, discord, plain) and template values (performance, milestone, daily) with a gloss for each template. Only the 'account' parameter is left undefined, keeping it 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+resource ('Generate shareable content') and scopes it by platform and template, which is clear on its own. It does not distinguish itself from siblings like stats_card, pk_card, or leaderboard_card, which also produce shareable artifacts, so an agent can't route between them from the description alone.

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

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

The description never states when to use this tool versus the card/leaderboard siblings, nor when not to use it. The platform and template lists read as parameter documentation rather than usage guidance, leaving the selection decision to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful detail about the metrics returned (win rate, ROI, profit, max drawdown) but does not disclose account scoping, time range, or whether the data is live or cached.

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 that lists the key metrics with no wasted words. It is appropriately sized for a simple read 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?

An output schema exists, so return values need not be detailed, and annotations cover the safety profile. However, the description is incomplete regarding the account parameter and usage context, which are not covered elsewhere.

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 mention the single 'account' parameter at all. It neither explains the parameter's purpose nor notes the default value, leaving the agent without any semantic guidance for that input.

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 (Get) and resource (performance analytics) and enumerates the exact metrics returned, making the purpose clear. However, it does not distinguish this tool from close siblings like stats_card, portfolio, or history, so an agent could still confuse which stats tool to call.

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

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

There is no guidance on when to use this tool versus alternatives such as stats_card, history, or portfolio. The description simply states what it retrieves without any context, prerequisites, or exclusions.

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

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds the social-sharing intent and output framing, but says nothing about account resolution behavior (e.g., what happens with an unknown account) or any rate limits on generated cards.

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 lines: what it is, what it returns, and the format options. No filler sentences, and the shareable-card purpose is stated before the details.

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?

An output schema exists, so the return values need not be re-explained, and the description still usefully summarizes them. The main gap is the undocumented `account` parameter, which is the only element an agent could get wrong.

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 carry the load. It does compensate well for `format` by enumerating tweet/markdown/plain, which the schema lacks (no enum, no description, only a default of markdown). But the `account` parameter is never mentioned anywhere, leaving half the inputs undocumented.

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

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

States a specific verb and resource ('Get a shareable stats card') and enumerates the payload it returns (ROI, Sharpe, win rate, P&L). That content signature distinguishes it from siblings such as `stats` (raw data), `pk_card`, and `leaderboard_card` without needing to open 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?

The 'ready to post on X, Telegram, Discord' framing implies the use case (sharing a performance summary) and the format parameter routes the agent to the right output style. However, it never states when to prefer this over the sibling `stats` tool or when it should not be used, so usage is implied 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?

Annotations already establish readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that prices are 'live' and that they are 'midpoint' prices, which is real behavioral context, but it stays silent on whether this starts a subscription/stream, how often values update, or whether the call blocks. With annotations carrying the safety burden, a 3 is appropriate.

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

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

Front-loaded with the core purpose in the first sentence, followed by a compact two-line parameter note. Every line earns its place and there is no filler. Slightly more structure (e.g. listing parameter semantics inline as bullets) could be tighter, but it is well sized for a 2-parameter 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?

An output schema exists, so return values need not be explained, and the low parameter count keeps the surface small. What is missing is behavioral completeness around the streaming semantics implied by 'watch' — update cadence, subscription lifetime, and cancellation — plus any usage scaffolding versus siblings, leaving the definition merely adequate.

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 carries full responsibility, and it largely delivers: slugs is clarified as 'comma-separated market slugs or condition IDs' and outcomes as 'comma-separated outcomes (default: "yes")', giving format and default for both parameters. It does not enumerate valid outcome tokens (e.g. whether 'no' is accepted), which keeps it from a 5, but the format guidance clearly exceeds 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?

States a specific verb+resource combination: 'Watch live midpoint prices for one or more markets.' The word 'live' and the streaming verb 'watch' imply continuous/ongoing observation, which meaningfully distinguishes it from the one-shot lookup siblings like get_market, get_order_book, or search_markets. However, it never explicitly names those siblings or codifies the streaming-vs-snapshot distinction, so it stops short of a 5.

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

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

There is no when-to-use guidance at all. Given a crowded sibling set (get_market, get_order_book, search_markets, buy, sell), an agent gets no signal about when to watch prices versus doing a one-shot fetch, nor any exclusions or prerequisites. The description only restates what the tool does, not when it should be chosen.

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