AfterFees

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds real behavioral context beyond that: results are net of fees and slippage and are size-dependent ('at your size'), and the output includes a tier and reasons, which signals non-actionable candidates may also be surfaced. It stops short of explaining what 'tier' or 'reasons' mean or how ranking works.

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

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

A single dense sentence, front-loaded with the trade structures covered and closing with a colon-introduced list of returned metrics, so there is no filler. The run-on construction ('and two same-day futures on different exchanges') is slightly hard to parse and no verb anchors the sentence.

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

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

With no output schema, the description usefully enumerates the returned fields, which is the main gap it needed to fill. But for a five-parameter tool with 60% schema coverage it leaves actionable_only and limit unexplained and does not say whether results are sorted or ranked, so an agent cannot fully predict what it will get back.

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 60%; base, scope, and notional are documented in the schema, and 'at your size' in the description reinforces notional as position size per side. However, actionable_only carries no description in either the schema or the description, and limit is undocumented in both — so the description does not compensate for the coverage gap. 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 specifies the resource precisely: spot/perp vs a dated future held to delivery, including cross-venue and same-day-futures variants, and lists the metrics returned (net to expiry, net APR, basis APR, max size, tier). An agent can tell this is a basis/term-structure screener rather than a generic rates tool. It does not, however, explicitly distinguish itself from near-siblings like boros_futures_basis or term_structure.

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

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

There is no explicit when-to-use, when-not-to-use, or named alternative, despite the sibling list containing boros_futures_basis, fixed_vs_floating, and term_structure that could plausibly overlap. The 'held to delivery' phrasing implies a hold-to-expiry use case, but the agent must infer that from what is essentially a scope-of-coverage sentence rather than 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 cover the safety profile (readOnly, idempotent, non-destructive, not open-world), and the description adds real behavior: results are cost-adjusted at the caller's size (fees + order-book slippage), capacity-limited via max size, and validated by a settled 7-day replay. That goes meaningfully past what the annotations declare.

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

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

A single dense sentence with the ranking concept and cost model front-loaded and zero filler. It is slightly run-on with a long parenthetical list, but every clause contributes a distinct output or constraint.

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 carries the return-value burden and does so by enumerating the ranked fields (net, max size, breakeven, replay, tier, reasons). With 6 optional params and full annotation coverage, remaining gaps (cost of the computation, ordering ties) are minor.

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 83%, so the schema baseline is 3; the description still adds linkage the schema lacks by tying 'at your size' to the notional semantics and by explaining that the replay is settled over 7 days (matching holding_hours=168). Tier naming ('actionable / watch') also implicitly clarifies what actionable_only 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 specific verb+resource (ranked funding-rate arbitrage pairs, long one market / short another) and enumerates the computed outputs: net after taker fees and slippage, max size, breakeven, 7-day replay, tier, reasons. An agent can distinguish this from funding_rates or pair_breakdown by the ranking/fee-adjusted framing, though no sibling is named explicitly.

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

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

The description never says when to reach for this versus alternatives like basis_trades, pair_breakdown, or funding_rates, nor does it state prerequisites or when results are meaningless. Usage must be inferred from the output list and the 'actionable / watch' tier vocabulary.

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 clear. The description adds that the result is net of fees and slippage at the user's size, which is useful behavioral context, but the imperative 'Lock funding' is ambiguous because the tool is read-only and does not actually lock anything.

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 padding. Its main weakness is that the leading action phrase 'Lock funding' is less precise than the comparison actually performed.

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

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

For a simple two-parameter read-only comparison tool, the description covers the core calculation and fee/slippage context. It omits the 'limit' parameter and does not clarify the return format, so it is 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 only 50%, and the description does not explain the 'limit' parameter at all. It vaguely gestures at 'notional' with 'at your size', but that does not fully compensate 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 names the specific comparison: Boros implied APR versus delivery-futures basis APR, including net fees and slippage. It is clear enough to distinguish the tool's analytical purpose, but it does not explicitly differentiate itself from siblings such as basis_trades or boros_lock_calculator.

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 'against a delivery future of the same maturity' implies the usage scenario, so there is some context. However, it gives no explicit when-to-use or when-not-to-use guidance and does not name 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?

The annotations already establish that this is a read-only, idempotent, non-destructive calculator. The description adds useful behavioral context by disclosing that the result accounts for taker and settlement fees, entry cost, and floating-rate comparison, which is more than the annotations provide.

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 dense sentence with little wasted text, and the purpose is front-loaded. However, the long run-on structure makes the relationships between inputs and outputs harder to parse 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 no output schema, the description does list the key outputs: locked net APR, advantage versus floating, and break-even floating rate. But it omits important semantics for the horizon (days) and notional size, and its unit language is imprecise for a tool with several non-percent parameters.

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

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

Schema description coverage is only 13% across eight parameters, so the description must carry most of the parameter meaning. It partially maps rate_pct, floating_pct, side, taker_pct, settle_pct, and entry_usd, but leaves days and notional unexplained and offers the potentially misleading blanket phrase 'Percent inputs' even though several parameters are USD amounts.

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 clearly states that this computes locked net income or cost APR on Pendle Boros after fees, plus advantage over floating and break-even floating rate. It is specific to Boros and distinguishes the calculation from generic APR tools, though it does not explicitly name sibling alternatives.

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

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

There is no explicit guidance on when to use this instead of siblings such as fixed_vs_floating, manual_calculator, or execution_cost. Usage is only implied by the calculation being described.

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 genuine context beyond that: the numbers are computed at your notional and are net of fees, and it signals the return is an analytical breakdown (win rate, capacity, reasons). It says nothing about behavior for an unknown or stale market_id, which is the remaining risk.

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 resource and followed by the returned metrics; the parenthetical id provenance sits in a sensible spot. 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?

There is no output schema, so the description must carry the return contract, and it does by listing the six analytical outputs. What's missing is how side affects the result and what happens if the market_id is unknown — modest gaps for a read-only lookup.

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

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

Schema coverage is only 33% – notional is the sole documented property. The description compensates for the required market_id by tying it to fixed_vs_floating, and "at your size net of fees" implies notional drives the output. The side parameter (short/long) is explained by neither the schema nor the description beyond its enum values, leaving a real 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?

The description names the specific resource (one Boros market) and enumerates what comes back: fixed rate at size net of fees, floating benchmarks, advantage, win rate, capacity, reasons. It also distinguishes itself from the sibling fixed_vs_floating by naming that tool as the source of the id. It is phrased as a noun phrase rather than a verb, but the intent is unambiguous.

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

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

"id from fixed_vs_floating" gives clear provenance and therefore the workflow context: call this after screening markets in the sibling tool. It doesn't state exclusions (e.g., when to prefer best_opportunities or pair_breakdown), so it falls short of a full when/when-not treatment.

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 that this is a read-only, idempotent, non-destructive operation, so the bar is lower. The description adds meaningful context beyond them: the VIP0 tier assumption, the averaging windows, and the inclusion of limits/inventory. It still omits refresh cadence and pagination 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?

A single dense sentence that front-loads the resource and its measurements, with the carry-trade framing at the end. No wasted words, though the trailing jargon ('two halves of a reverse spot-perp carry') may be opaque without domain context.

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

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

With no output schema, the description must communicate what comes back; it does list the key fields (VIP0 rates, averages, limits, inventory, funding). However, it leaves the `limit` parameter and pagination/return shape unexplained, which is a meaningful gap for an agent assembling a call.

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

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

Schema description coverage is only 50%: `base` has a terse 'Coin (optional)' and `limit` has no description at all beyond its default and bounds. The description hints that filtering is per coin by saying 'per coin and exchange,' but never explains how `base` or `limit` work, so it 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?

The description names the exact resource (margin borrow rates) and its dimensions: per coin and exchange, VIP0 tier, current plus 24h/7d averages, limits, inventory, and most-negative perp funding. This is far more specific than the title, though it does not explicitly name the sibling tool (funding_rates) it complements.

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 'the two halves of a reverse spot-perp carry' implies the analysis use case, but there is no explicit guidance on when to use this versus funding_rates, best_opportunities, or pair_breakdown. Usage is implied rather than stated.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description's real contribution is behavioral: it discloses that returns are computed NET after fees and slippage at the caller's size, and that the 7-day sum is settled rather than projected. That materially changes how an agent interprets the numbers. It stops short of describing pagination, errors, or how many exchanges/pairs come back.

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

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

A single front-loaded sentence that leads with the resource ('Funding rate of one coin on every exchange') before the returned-fields parenthetical. Dense but every clause carries information; the parenthetical field list is the only slightly heavy section, though it substitutes for a missing output schema.

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

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

With no output schema, the description carries the return-value burden and does so by enumerating the fields (rate, interval, APR, predicted, OI, volume, settled 7-day sum) plus 'best pairs' net of costs. For a 2-parameter read tool whose annotations are already rich, that is nearly sufficient; what's missing is how 'best pairs' is ranked and roughly what volume of results to expect.

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

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

Schema coverage is 100%, so the baseline would be 3; the description earns an extra point by explaining what `notional` actually does — it drives the fee/slippage deduction, so changing it changes the reported net figures, not just a filter. It also ties `base` to the 'one coin' scope. Minor gaps: no restatement of the default (10000) or the 10–100M bounds, though the schema carries those.

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

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

Names a specific resource-and-scope: funding rate of ONE coin across EVERY exchange, plus best pairs — this is the mirror image of a per-exchange scan and an agent can infer the distinction. However, it never names the sibling it contrasts with (funding_rates, exchange_overview), so the differentiation is inferential rather than explicit.

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

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

Usage is only implied by the content list — the agent must infer you call this when you want one asset's cross-venue funding picture rather than a market-wide scan. There is no statement of when not to use it, no prerequisites, and no named alternative among the 26 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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real value by enumerating the returned metrics, but says nothing about sorting, pagination, or what happens when limit truncates the result set.

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

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

A single front-loaded sentence that leads with the defining filter (two or more exchanges) before listing outputs. Dense but every clause carries information; no boilerplate.

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

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

With no output schema, listing the returned metrics is necessary and done well. However, for a listing tool with a `limit` default of 30, the absence of any guidance on ordering, pagination, or the group filter leaves an agent guessing about result 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% and the description never mentions either parameter. The `group` enum (crypto/equity/commodity/index/fx) and the `limit` bounds (1-500, default 30) are only inferable from the raw schema, 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?

The description names a specific resource and a precise scope: coins with a perp on two or more exchanges, plus the fields returned (exchange count, open interest, funding APR range, best after-fee pair). That distinguishes it from siblings like coin_overview or funding_rates, though it never names an alternative explicitly.

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

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

Usage is only implied: an agent can infer this is the discovery/screener view for multi-venue coverage. There is no statement of when to pick this over coin_overview or funding_rates, and no mention of 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 readOnly, idempotent, non-destructive. The description adds substantial behavioral context beyond them: Pro API token requirement (Authorization: Bearer arb_…), unavailability on the anonymous tier, and the exact cost components netted out (aggregator price impact, swap gas, transfer gas, withdrawal fee). It does not disclose rate limits, pagination, or result 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?

Information density is high and the criteria are front-loaded, but the text is a single run-on sentence with awkward fragments ('status and reasons. Pro.'), where 'Pro' is unclear and duplicates the subsequent auth sentence. It could be restructured without losing content.

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

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

With no output schema, the description does explain what comes back (profit at $1k/$5k/$10k, status and reasons), and it flags the auth prerequisite. The only meaningful gap is the unexplained 'base' parameter, which matters for correct invocation.

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

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

Schema description coverage is only 50%: 'base' is documented merely as 'Token (optional)' and 'limit' has no description at all. The description adds nothing about what 'base' selects (base currency? base token?) or how it interacts with the scan, 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?

The description clearly states a specific verb+resource: a scan for tokens with verified contracts across five named chains whose DEX price is >1% away from the exchange price. The qualifying criteria (net profitability thresholds) make the purpose concrete. It does not, however, name or distinguish itself from plausible siblings like best_opportunities or spread_chart.

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 inclusion criteria (>1% gap, verified contract, listed token) imply when results appear, and the Pro-gating sentence tells the agent it needs a Pro token. But there is no explicit when-to-use guidance versus alternatives such as best_opportunities or execution_cost, and no statement of when to avoid 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 this as read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds which exchange-level metrics are returned, but does not mention data freshness, empty/error behavior, or calculation caveats.

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-loads the scope and lists the included metrics without filler. The compressed phrasing is efficient, though "its best after-fee pairs" is slightly ambiguous.

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 overview tool without an output schema, enumerating the returned metric categories makes the definition largely sufficient. It still omits details about return structure, units, and how "best after-fee pairs" is determined.

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 sole venue parameter is fully described by the schema, including an example ("binance"), so baseline 3 applies. The description only implies a single exchange and adds no syntax, validation, or format guidance beyond the schema.

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

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

The description clearly identifies the resource as a single exchange overview and enumerates the metrics covered: fees, funding, open interest, volume, and after-fee pairs. "One exchange" usefully distinguishes it from a multi-exchange listing, though it lacks an explicit verb and does not name sibling tools.

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

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

There is no guidance on when to use this tool versus alternatives such as exchanges, coin_overview, or pair_breakdown. The phrase "One exchange" implies a single-venue scope, but no conditions, exclusions, or alternatives are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so safety is covered. The description adds genuinely useful disclosure about data quality per venue ('fully calculated or watch-only'), which tells the agent some entries are partial. It does not say how many exchanges are returned, whether results are ordered, or whether the list is static.

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

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

It is short, but it is not front-loaded: it opens with an incomplete clause and buries the fact that this is a listing of supported venues. The field list is a useful payload, but the framing sentence is under-specified rather than tight.

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

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

With no output schema and no parameters, the description is the only place a caller can learn what comes back, and it does enumerate the per-exchange attributes. However, it omits the essentials for a list tool: that it returns a collection, roughly how many venues, and how it relates to 'exchange_overview'.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify. The field enumeration in the description describes outputs rather than inputs, which belongs elsewhere but does no harm here.

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

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

The description conveys that this is the roster of exchanges AfterFees covers, plus the attributes reported for each. But it is a noun-phrase fragment ('Every exchange AfterFees reads: ...') with no verb, and it never distinguishes itself from the sibling 'exchange_overview', which an agent could easily pick instead.

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

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

There is no statement of when to call this versus 'exchange_overview' or any other sibling, and no prerequisites or exclusions. The agent must infer usage purely from the name and the field list.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the metric is composed of taker fee plus order-book slippage, it covers both perps and spot, and results are ranked cheapest first — all things the annotations cannot convey. It omits data freshness/snapshot timing, which keeps it from 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?

One dense sentence with the metric definition and the result ordering front-loaded; every clause (what is summed, what scope, what sort) earns its place and nothing is padded.

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

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

For a 2-parameter read-only computation with no output schema, the description covers what is measured, across which venue types, and how results are ordered. It leaves the return shape (per-venue rows vs. single best) and the default size implicit, a minor gap given the low complexity.

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

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

Schema coverage is only 50% (size_usd has no description), so the description carries weight by clarifying that 'base' is a single coin and that size is a USD notional to be bought or sold. It does not mention the 100k default or the 100–50M bounds, which the schema supplies structurally but without explanation.

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 computed resource (taker fee + order-book slippage) for a specific scope (buy or sell a given USD size of one coin across all perps and spot venues). The 'on every exchange' framing implicitly separates it from venue_execution_cost, but the sibling is never named, so 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?

The phrase 'cheapest first' and 'on every exchange' imply the use case is cross-venue cost comparison before entering a position, but there is no explicit when-to-use, when-not-to-use, or pointer to venue_execution_cost for single-venue queries. Usage is left to inference.

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

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

Annotations already cover the safety profile: readOnly, idempotent, non-destructive, and closed-world. The description adds useful domain context by saying the fixed rate is net of Boros fees and fill at your size, and by explaining what each side locks. It does not describe return structure, pagination, or other behavioral details, so it adds value but does not fully compensate for the missing output schema.

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

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

The definition is compact and avoids filler, with the core comparison stated up front. However, the single dense opening sentence is somewhat cryptic and the side semantics are appended rather than integrated into a clearly front-loaded explanation.

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

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

With no output schema, the description should more fully explain what is returned. It names key metrics such as advantage, win rate, and capacity, but does not describe result structure, base filtering, limit behavior, or defaults beyond the schema. It is adequate but incomplete for an analytics tool with four parameters.

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 50%, with base described only as 'Coin (optional)', limit undocumented, notional partially documented, and side carrying an enum but no schema description. The description compensates for side by explaining short versus long and for notional by implying size-based fill, but it leaves base and limit unexplained.

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

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

The description identifies the Pendle Boros domain and the specific comparison being made: fixed funding rate versus term-matched floating benchmark, plus advantage, win rate, and capacity. It is clear what the tool is for, but it lacks an explicit verb and does not distinguish itself from close siblings such as boros_lock_calculator or boros_market.

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 explains what side=short and side=long mean, but it gives no guidance on when to use this tool versus alternatives like boros_lock_calculator, boros_market, or funding_rates. The agent must infer the use case from the metric list.

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

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

Adds context beyond the annotations: rates are gross/before costs, results are pre-sorted (highest first, or by absolute APR), and the OI filter is a top-N-only constraint. This is meaningful interpretive guidance for a read-only tool whose annotations already cover safety.

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

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

Three tight sentences, front-loaded with what the tool returns followed by the two mode behaviors. The telegraphic 'With/Without' phrasing is dense but wastes nothing.

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

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

With no output schema, the description should say more about what comes back – units of the rate (APR vs per-interval), fields per market, or ordering ties. It covers mode behavior and the gross/before-costs caveat, but leaves the return shape underspecified.

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

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

Schema coverage is 67% with `limit` undocumented; the description compensates by explaining that `base` expands to all exchanges for one coin and that `limit` means N in the top-N mode, and reinforces that `min_oi_usd` only applies without `base`. It doesn't state the sort key units, but adds real meaning over the schema.

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

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

States a specific resource (current perpetual funding rates) and distinguishes its two operating modes by the presence of `base`. An agent can tell this apart from siblings like borrow_rates or basis_trades, though no sibling is named explicitly.

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

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

Gives clear conditional guidance: pass `base` to get one coin across every exchange sorted by rate, omit it to get the top N markets by absolute APR with an OI filter. It lacks explicit exclusions pointing at alternative tools, but the mode-selection rules are unambiguous.

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 that this is a safe, read-only, idempotent operation. The description adds useful behavioral context beyond that: results are net after fees and slippage, use a live pair, and optionally apply user-supplied funding-rate assumptions per leg.

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 efficient sentence with the core calculation and key optional behavior front-loaded. Every clause contributes useful information without repetition.

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 calculation tool with a nested parameter object and no output schema, the description explains the input scenario and holding periods but does not describe the returned result structure or pair_key expectations. It is adequate but leaves some completeness 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 67%, so some description support is needed. The description meaningfully explains assumed_rates_pct as percent per funding period keyed by instrument_id, but it does not clarify pair_key format and only indirectly covers notional via the schema 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?

The description clearly states the calculation: net after fees and slippage for one live pair across specific holding periods. It identifies the resource and scope well, but does not explicitly differentiate itself from related sibling tools such as pair_breakdown or execution_cost.

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 scenario comparison by listing holding periods and optional custom funding rates, but gives no explicit guidance on when to use this versus alternatives. There are no when-not conditions or sibling references.

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, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely new behavioral fact — that it uses no live data — but says nothing about determinism, units of the returned figures, or how the 'funding-halved' case is derived.

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

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

A single front-loaded sentence that leads with the outputs and then the required input shape; there is no filler. The curly-brace shorthand is dense but legible for an agent, though it borders on terse.

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

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

With no output schema and a nearly empty legs schema, the description must carry the return-value burden. It lists the four computed metrics by name but never defines them (annualization basis, units, sign conventions) and leaves two numeric parameters unmentioned, so it is adequate 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 coverage is only 40% and the legs array items are declared as a bare object with no properties at all, so the description's inline leg shape ({side, rate_pct per period, interval_hours, taker_bps, first_in_hours?}) carries the critical semantics that the schema omits entirely. It earns credit above the baseline for rescuing the most important undocumented structure, though leverage and slippage_bps remain unexplained.

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

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

The description names the exact outputs it computes (net, net APR, breakeven, funding-halved case) and the resource (two manually typed-in legs), which clearly separates it from live-data siblings like funding_rates or best_opportunities. It stops short of a crisp verb+resource phrasing but the scope is unmistakable.

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

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

The parenthetical '(no live data)' implies this is the tool for hypotheticals you type in rather than market lookups, which is a real usage cue. However, it never names an alternative tool or states an explicit when-not condition; the routing is left to inference from the sibling 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: it requires a Pro API token (Authorization: Bearer arb_…) and is unavailable on the anonymous tier, which an agent must know before calling. It stops short of describing freshness, caching, or empty-state 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?

The first sentence is well front-loaded and information-dense, but the auth requirement is stated twice in near-identical form ('Needs a Pro account token' then 'Needs a Pro API token (Authorization: Bearer arb_…); not available on the anonymous tier'). That duplication costs space without adding information.

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

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

With no output schema, the description carries the burden of telling the agent what comes back, and it does so by listing the hedge groupings. Auth and key-type constraints are also covered. Missing only peripheral details such as ordering, whether empty results are possible, or whether data is live or cached.

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

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

The tool takes zero parameters, so there is no parameter surface for the description to explain; the baseline for a no-param tool is 4. Nothing in the description misleads about inputs, and it correctly implies no filtering arguments are accepted.

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

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

Names a specific resource (hedged positions across read-only exchange keys) and enumerates the groupings returned: delta drift, distance to liquidation, funding received, issues. That is clear enough for an agent to know what it gets back, though it never contrasts itself with siblings such as basis_trades or best_opportunities (which cover adjacent but different data).

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

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

Usage is implied rather than stated: an agent infers 'call this when you want the user's own positions.' The description adds gating conditions (Pro account, read-only keys only), which is useful, but there is no explicit when-to-use versus when-not-to-use guidance and no named alternative among the 26 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 establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral context beyond annotations: quantity is in the exchange's own unit, links contain no referral parameters, and 'AfterFees never trades.'

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

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

The definition is a single front-loaded sentence and avoids repetition, with every clause contributing either output detail or a relevant caveat. It is dense but not wasteful; the run-on structure slightly reduces readability.

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

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

With no output schema, the description usefully enumerates the expected order fields and caveats, which is enough to set expectations for this simple two-parameter tool. Some details, such as exact response ordering or how notional changes the checklist, remain implicit.

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 two parameters are already documented in the schema. The description mentions notional and pair scope only indirectly and does not add syntax or sourcing detail beyond what the schema provides, making 3 the appropriate baseline.

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

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

The description clearly states this produces a two-order manual checklist for one pair and lists the exact fields in each order, so the resource is easy to identify. It does not explicitly distinguish itself from siblings such as manual_calculator or pair_breakdown, which keeps it below a 5.

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

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

Usage is only implied by 'to place by hand': the agent can infer this is for manual order execution, but there is no explicit when-to-use guidance, no exclusions, and no named alternative sibling 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 cover readOnly/idempotent/non-destructive, and the description still adds genuinely new operational context: a required Authorization: Bearer arb_… Pro token and the fact that the anonymous tier has no access. It also discloses the analytical scope (including rate-sensitivity and capacity), so cost and auth expectations are set before 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?

Three sentences, front-loaded with what gets computed, then the key's origin, then the auth gate — no filler. The first sentence is a dense comma-list of outputs, which is information-rich but slightly hard to scan; bullets or grouping would improve it marginally.

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

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

With no output schema, the description carries the return-value burden and does so by enumerating every computed figure, plus prerequisites and auth. Remaining gaps are minor: units/shape of the response, latency or rate limits, and what "settled 7/30-day replay" concretely returns are left implicit.

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 schema already documents notional, pair_key and holding_hours, establishing a baseline of 3. The description adds provenance beyond the schema's vague "pair_key from another tool" by naming the two tools that produce a valid key, which is the parameter detail most likely to cause a failed call.

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

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

The description opens with a specific verb+resource ("Full calculation of one pair") and then enumerates the exact outputs — funding per leg, settlement count, taker fees, VWAP/slippage, carry, net, halved-rate net, breakeven, capacity, 7/30-day replay. That enumeration is far more specific than any sibling (pair_history, execution_cost, holding_scenarios) and lets an agent tell them apart without opening the schema.

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

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

It gives a real workflow prerequisite: pair_key must come from best_opportunities or coin_overview, which routes the agent to the correct upstream tool. It also states an eligibility gate (Pro API token required, unavailable on anonymous tier). It stops short of naming an alternative for simpler cost questions (execution_cost, manual_calculator), so not a full when/when-not.

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 and closed-world, so safety is covered. The description adds real context beyond that: the computation basis (settled funding applied to today's orientation at your size), the four cost deductions, and the Pro entitlement gate for ranges past 7 days. It does not mention latency, caching, or error behavior, which keeps it below a 5.

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

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

A single dense sentence front-loads what is measured, then enumerates the returned metrics and ends with the gating rule. No filler, though the stacked clauses make it slower to parse than a short bulleted framing 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 no output schema, the description correctly spends its budget enumerating what comes back: net after four costs, max drawdown, negative days, daily sign flips, and per-exchange history depth. Remaining ambiguity is minor, mainly what 'today's orientation' assumes about direction and whether notional is per side.

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

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

Schema coverage is 67%, so the schema already carries most of the parameter burden. The description echoes the range set and the 'at your size' notion of notional but adds no format, unit, or constraint detail, and leaves pair_key provenance vague ('from another tool') without naming the tool that supplies it.

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

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

States a specific operation on a specific resource: replay historically settled funding on both legs for one pair, at a given size and range. That is clearly distinct from siblings like funding_rates or pair_breakdown, though no sibling is named explicitly, so 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?

The one concrete guideline is the paywall boundary: 'Ranges beyond 7 days need Pro,' which usefully tells the agent when the call will not be available. There is no guidance on when to pick this over pair_breakdown or funding_rates, so usage context is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is settled. The description adds scope detail beyond that — that it covers per-feed outage state and lookback windows of 1/7/30/90 days — but says nothing about freshness of the status itself, caching, or granularity of the 'down' determination.

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 that front-loads the most actionable information (is data live right now). It is a sentence fragment rather than a full clause, which is a small stylistic cost, but nothing is padded or repeated.

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

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

For a zero-parameter, no-output-schema tool, the description covers the essentials: what questions it answers and the time ranges involved. An agent could call it correctly. It stops short of describing the response shape, which matters here because there is no output schema to fall back on.

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

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

With zero parameters and 100% schema coverage the baseline is 4, but the description explains none of the fixed dimensions it returns (liveness vs. feed outages vs. historical windows) as parameters or selectors — notably whether the 1/7/30/90-day windows are all returned at once. Minor deduction for an all-defaults tool whose output shape is only vaguely sketched.

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

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

The description names the concrete resource and what aspect of it is reported: current liveness, which exchange feeds are down, and availability over four time windows. It is a noun phrase rather than a verb+resource ('check service status'), but it is specific enough that an agent can tell this apart from the market-data siblings like exchanges or exchange_overview.

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

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

There is no statement of when to call this versus alternatives — no mention of calling it before other tools, no preconditions, no exclusions. The only implied usage is 'if you need to know whether data is live,' which the agent must infer from the noun phrase.

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

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

Annotations already cover the read-only, idempotent, non-destructive profile, and the description adds genuinely new behavior: the price source is book mids where stored and falls back to marks otherwise, plus explicit plan-based limits on granularity and history depth. It stops short of anything about response shape or failure modes when an instrument lacks stored mids.

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, front-loaded with the definition and followed by the constraint that most affects tool choice. Every clause carries information; nothing is redundant with the title or schema.

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

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

For a read-only two-leg series tool with no output schema, the description covers what is computed, from what data, and under what tier limits. The one material gap is the undocumented `executable` flag, which changes what the spread actually measures.

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?

With only 40% schema description coverage, the description must carry weight: it does effectively document the `candle` and `days` constraints (granularity tiers, max history) and the (A − B) / B formula implies the roles of leg_a and leg_b. However, `executable` (default false) is never mentioned anywhere and its effect on the computed spread is completely opaque.

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

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

States a specific output (candles) and a precise mathematical definition ((A − B) / B) over two instruments, which uniquely identifies the operation. It does not name or contrast with any sibling such as pair_history or basis_trades, so an agent must infer whether a spread chart or a basis series is wanted.

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 tier-based constraints (Free: 1h+, ≤7 days; Pro: 1m+, ≤365 days), which is useful gating information, but it never says when to reach for this tool rather than a sibling or what prerequisites (valid instrument ids, entitlement) apply beyond the tier note.

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, non-destructive, and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context by specifying that basis is annualised and that coverage is limited to exchanges the service covers. It does not describe return ordering, units, or how perp funding is expressed, which leaves gaps.

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 dense sentence, front-loaded with the primary output (annualised basis) and the secondary metric (perp funding). Every clause carries information and there is 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 simple read-only single-parameter tool this is close to sufficient, but with no output schema the description should say more about the shape of the response — currency/units of the basis, whether perp funding is annualised or raw, and how results are ordered across exchanges. As written the agent knows the concept but not the return layout.

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

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

Schema coverage is 100% and the single 'base' parameter is documented with examples (BTC, ETH, SOL), so the schema carries the load. The description's 'one coin' reinforces the semantic mapping but adds nothing beyond the schema, which is the baseline 3 for a fully documented single 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?

States a specific resource (annualised basis of every delivery future plus perp funding) scoped to one coin across covered exchanges, which an agent can distinguish from siblings such as basis_trades or funding_rates. It doesn't explicitly name a sibling it replaces, but the verb+resource combination is concrete.

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 choose this over basis_trades, boros_futures_basis, pair_breakdown, or funding_rates, and no prerequisites or exclusions are given. The agent must infer the use case from the purpose sentence alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: the comparison is predicted net versus net realised from *settled* funding over the hold, which tells the agent the numbers are historical and settlement-based rather than projected. It does not disclose the evaluation window, sample size, or caching/refresh behaviour.

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

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

A single front-loaded sentence that names the subject first and then lists the returned metrics, with no filler. It is dense and slightly jargon-heavy ('predicted net vs net realised from settled funding over the hold'), but every clause carries information.

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

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

With no output schema and no parameters, the description carries the full burden of explaining what comes back, and it does list the metric families. However, it omits the time window covered, how many picks are included, and whether results are aggregated or per-pick, which an agent needs to interpret or cite the output correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The description correctly implies no input is needed to retrieve the record.

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

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

The description states a specific resource — the realised performance record of AfterFees' daily top picks — and enumerates the metrics returned (predicted vs realised net, hit rate, mean error, latest picks). It is clearly a read-only reporting tool, but it does not name or contrast any sibling such as best_opportunities or my_positions, so the agent must infer the boundary.

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

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

Usage is only implied: an agent can deduce this is the place to verify past pick accuracy rather than to find new opportunities. There is no explicit when-to-use statement, no exclusion, and no pointer to best_opportunities for current picks, which is the obvious alternative an agent would weigh.

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, closed-world, so the safety profile is fully covered structurally. The description adds useful behavioral context beyond that: it states the outputs produced (real-transfer net, prefunded net, break-even premium) and the units for fee inputs. It does not say whether the trade path is modeled as a single round-trip or whether 'prefunded' assumes capital already parked on B, which is a meaningful modeling assumption.

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 trade sequence before the computed outputs, with zero filler. The density borders on cryptic ('usdt_back', 'break-even premium') but nothing needs trimming.

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

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

No output schema exists, and with 8 parameters at 0% schema coverage the description would need to carry more weight than it does. It names the three result figures it returns, which is genuinely helpful, but leaves the semantics of the amount, trips, and usdt_back inputs undefined for a calculation whose correctness depends on them.

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

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

Schema description coverage is 0% across 8 parameters and there is no enum. The description only clarifies units for two of them (fees in percent, withdrawal fee in coins); 'trips', 'amount', and especially 'usdt_back' remain completely unexplained, and 'buy'/'sell' as price inputs is only implied by 'at prices you give'.

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 concrete multi-step operation: buy on exchange A, withdraw, sell on exchange B, and compute real-transfer/prefunded net plus break-even premium. That is a specific verb+resource and clearly separates it from sibling calculators like manual_calculator or execution_cost. It stops short of naming an alternative outright, but the purpose is unambiguous.

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

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

There is no explicit when-to-use guidance and no mention of the many sibling tools that overlap in domain (transfer_routes, execution_cost, manual_calculator, venue_execution_cost). The agent must infer that this is the pricing-input arbitrage calculator rather than route discovery or cost aggregation.

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 readOnly/idempotent/non-destructive/closed-world, so the bar is lower, and the description still adds real context: network matching is by chain and contract and never by ticker, and results carry status plus reasons. It does not disclose pagination/limit behavior or the free-tier constraint (that appears only in the schema), which keeps it from 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?

One dense sentence plus one supporting sentence, front-loaded with the core trade mechanic and followed by the outputs and the traps view. It is information-dense with essentially no filler, though the comma-laden output enumeration reads as a feature dump rather than a prioritized list.

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

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

There is no output schema, so the description carries the return-value burden and does so by enumerating net-after-fees, pre-funded net, capacity thresholds, arrival estimate, hedge cost, status and reasons. What it omits is modest: default behavior (status defaults to executable, limit 10) and what a 'trap' record contains.

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?

With only 33% schema description coverage, the description does substantial compensating work: it defines view=traps, ties 'at your size' to notional, implies include_hedge via 'hedge cost on a perp', and explains that status values carry reasons. Only limit and the precise status enum semantics (executable/near/closed/unverified) remain unaddressed by either source.

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

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

The description names a specific resource and mechanism: buy on one exchange, withdraw on a shared network, sell on another, with net economics after fees, slippage and withdrawal cost. That is far more than a restatement of the name and lets an agent distinguish it from basis or funding tools. It never explicitly names a sibling (e.g. transfer_calculator or basis_trades) to complete the differentiation, 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?

Usage is implied through the mechanics and there is one genuine routing hint: 'view=traps lists spreads that exist only because deposits or withdrawals are closed.' However, there is no explicit when-to-use-this-vs-alternatives guidance against the large sibling set (transfer_calculator, execution_cost, basis_trades), and no statement of prerequisites such as Pro tier for custom notional.

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, closed-world behavior, so the safety profile is covered. The description adds genuine value by decomposing the metric (fee + slippage), fixing the notional tiers, and stating the output unit in bps. It doesn't say whether quotes are live or cached, but that is a minor gap given annotation coverage.

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

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

A single dense sentence with the metric front-loaded and the unit trailing; every clause (fee, slippage, sizes, direction, venue scope) carries information.

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

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

For a two-parameter read-only tool with no output schema, the description covers what is computed, at what sizes, and in what units. The only real omission is the meaning of `limit` and the granularity of the returned markets.

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 50%: `venue` is documented in the schema, but `limit` has no description anywhere. 'biggest markets' hints that limit controls how many markets are scanned, yet the description never states it, so it only partially compensates 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 names a concrete computation (taker fee plus order-book slippage), the scope (one exchange's biggest markets), the sizes ($10k/$100k/$1M), direction (long and short), and the unit (basis points). The 'on one exchange' qualifier separates it from the sibling `execution_cost`, though that sibling is never named explicitly.

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

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

Usage is only implied: an agent can infer this is for measuring per-venue round-trip cost, but there is no statement of when to prefer it over `execution_cost` or `best_opportunities`, and no prerequisites or exclusions.

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