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

No annotations exist, so the description carries the full burden. It does disclose the exact fee formula and root-solver inequality, which is genuinely useful behavioral context for trusting the output. However, it never says the tool is a pure side-effect-free calculation, never describes the return shape, and never discloses that it operates in two distinct modes (fee lookup vs. counterpart-price solve) — a real gap for a 5-param tool with zero required fields.

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

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

Two sentences, front-loaded with the purpose before the formula. The formula is dense but earns its place as the tool's defining behavior. Minor cost: the LaTeX-style notation is harder to parse than plain prose would be.

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 5 optional parameters, two operating modes, and no output schema, the description should explain which parameter combination triggers which computation and roughly what comes back. It explains the math but not the invocation contract, leaving an agent to guess at mode selection.

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

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

Schema description coverage is 100%, so the schema already carries parameter meaning and the baseline is 3. The description reinforces the math behind price/primary_price but adds no interaction semantics — specifically, it does not say that price+contracts selects fee mode while primary_price+target_roi_pct selects the arbitrage solve mode.

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

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

The description names a specific verb+resource pair: solving Kalshi quadratic taker fees and maximum counterpart contract prices. The purpose is unambiguous for an agent reading it, though it never contrasts itself with siblings like scan_arbitrage_opportunities, which it plainly complements rather than duplicates.

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 clause 'for guaranteed positive EV cross-venue arbitrage' implies the scenario, but the description never states when to call this versus scan_arbitrage_opportunities, nor does it say what inputs are required for which mode. Usage must be inferred from the parameter names.

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

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

With no annotations, the description carries the full disclosure burden. It signals a read-only retrieval and enumerates return fields (bids, asks, mid, spread bps, OBI), but does not cover error behavior for unknown markets, whether the book can be empty, data freshness/realtime status, or rate limits.

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

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

Two sentences with zero filler: the first establishes what is retrieved and from where, the second enumerates outputs. It is front-loaded and appropriately sized for the tool's scope.

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?

Since there is no output schema, the description usefully enumerates the return fields, which is the key missing structured information. It falls short only on edge cases like empty or invalid markets and data freshness, which matter for a market-data tool.

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

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

Schema coverage is 100%, so all three parameters (including depth bounds and the venue enum) are already documented in structured fields. The description adds little semantic detail beyond the venue list, which duplicates the enum, so the baseline 3 is appropriate.

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

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

The description gives a specific verb and resource ('Retrieve normalized Level 2 orderbook depth') and enumerates the supported venues, so an agent immediately knows this is the orderbook data tool. It does not explicitly contrast itself with siblings like search_prediction_markets or scan_arbitrage_opportunities, but the resource is distinct enough to avoid confusion.

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

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

There is no statement of when to use this tool versus the alternatives; the sibling set includes market search, arbitrage scanning, and fee calculation, but none are mentioned. The agent must infer that this is for reading depth data rather than discovering markets or opportunities.

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

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

No annotations are provided, so the description carries the burden. It makes clear this is a read/query operation returning wallet addresses, sizes, prices, and transaction hashes, but it omits rate limits, authentication needs, pagination behavior, and a precise definition of 'recent'.

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

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

The description is a single front-loaded sentence with no wasted language. It immediately states the action, resource, returned data, and venue scope.

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 description gives enough context for a read query: it names the resource, returned fields, and venue coverage. It is slightly incomplete because 'recent' is undefined and the venue list names only three of the schema's supported venues, but the schema fills those gaps.

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

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

Schema coverage is 100%, so the parameter documentation is already handled by the input schema. The description adds useful domain context like block trades and whale orderflow, but does not add parameter-specific meaning beyond what the schema provides for limit, venue, market_id, or min_size_usd.

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

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

The description uses a specific verb and resource: query recent block trades and institutional whale orderflow, including the data fields returned and supported venues. The tool is clearly distinct from siblings like orderbook and arbitrage scanners, though it does not explicitly contrast itself with 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 implies the tool is for whale/block trade queries but gives no explicit when-to-use guidance, no exclusions, and no alternatives among the sibling tools. An agent must infer the use case from the purpose statement alone.

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

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

With no annotations, the description carries the full burden. It usefully discloses that results are net of exchange taker fees and gas and that oracle risk is reported, which is real behavioral context. But it leaves out the operational profile: whether it queries venues live or from cache, scan latency/cost, data freshness, and whether results are ranked. For a potentially expensive cross-venue scan, that is a meaningful gap.

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

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

Two dense sentences, zero filler, with the core action and the returned metrics both front-loaded. Every clause carries information an agent can use.

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

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

No output schema exists, so the description's enumeration of returned metrics (net ROI, gross edge cents, combined costs, annualized yield, oracle risk) does real work in explaining the return value. What is missing is scope of coverage — whether all venues are scanned or only the exemplified pairs — and freshness, which matters for an arbitrage 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 100% with defaults, ranges and an enum on 'risk', so the schema already documents all four parameters well. The description's mention of net ROI is consistent with min_net_roi_pct but adds no syntax or interpretation beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Find cross-venue matched prediction market arbitrage opportunities') and concretizes it with named venue pairs (Polymarket YES vs Kalshi NO). It also enumerates the metrics computed, so an agent knows this is an analysis/scan tool rather than a raw data fetch. It does not explicitly distinguish itself from siblings like search_prediction_markets or get_market_orderbook, but the arbitrage framing makes the difference inferable.

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

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

Usage is implied by the examples and by the fee-adjusted ROI framing, which signals a screening/opportunity-discovery use case. However, there is no explicit when-to-use vs when-not, no statement of prerequisites (does it need a prior search? does it hit live orderbooks?), and no routing to the sibling tools an agent would need afterwards to inspect an opportunity.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the return payload (live quotes, volume, liquidity) and implies a read-only search over active markets, but it says nothing about rate limits, pagination/caps, whether results are ranked, or what happens with zero matches. For an unannotated tool this is decent but incomplete.

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

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

Two sentences, zero waste, front-loaded with the resource and venue scope before the filter and output details. 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?

With five well-documented parameters and no output schema, the description covers venues, filters, and the shape of results, which is nearly everything needed to call it. Minor gaps remain around result ordering and empty-result behavior, but nothing blocking.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description mirrors the filter set (keyword, category, status, venue) but adds no semantics beyond the schema — it doesn't explain the limit cap, the 'ALL' venue/status interaction, or whether query can be broadened with empty strings.

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 ('Search') plus resource ('active prediction markets') with the exact scope spelled out: seven named venues and the four filter dimensions. An agent can immediately distinguish this discovery tool from siblings like get_market_orderbook or scan_arbitrage_opportunities without opening any schema.

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

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

The description implies the use case ('filter ... to view live quotes, volume, and liquidity'), which tells the agent this is the market-discovery entry point. However, it never explicitly routes against the siblings — nothing says when to prefer this over get_market_orderbook or get_whale_trades, and there are no exclusions or prerequisites.

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