Dinero en la Mesa — Perp DEX costs & funding

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds facts annotations cannot carry: the tool is unavailable, it is priced at 29 USD/month for 3 pairs or 79 USD unlimited via USDC on x402, and invoking it is a no-op status check rather than a subscription action. That is meaningful context beyond the structured fields, though it omits what the status payload contains.

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 single most decision-relevant fact ('COMING SOON') before any pricing or capability detail. Nothing is redundant with the title. The pricing parenthetical is dense but earns its place, since cost is the main reason an agent would skip this tool.

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

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

For a zero-parameter, read-only stub with no output schema, the description covers the three things an agent needs: this is not yet functional, what it will eventually do, and what a call returns today. There is no complexity left unaddressed.

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 input schema has zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The description is consistent with that — no behavior implies hidden arguments such as a threshold value or webhook URL.

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 what the tool is meant to do (push a webhook when a net funding gap or a cost crosses a user-set threshold) and, critically, what it does today (returns its status plus the free tool to use in the meantime). That is specific and distinguishes it from siblings like funding_rates or trading_cost, which return data rather than notify. It loses a point because the active behavior is described only loosely — 'returns its status' — and no specific free tool is named.

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

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

It tells the agent it can call this now and that the response will point at a free alternative, which is genuine usage context. But it never names that alternative among the 14 siblings (best_venue, trading_cost, funding_rates would be the obvious candidates), and it gives no explicit when-not-to-use guidance. The guidance is implied rather than actionable.

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 only declare readOnlyHint and openWorldHint, so the description must carry most of the behavioral load. It does add meaningful context beyond annotations: the live order book basis for slippage, the 28-venue scope, and that every figure carries a timestamp and source, which signals data freshness and provenance. It stops short of describing the response shape or how ties/ranking are presented.

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 core purpose is front-loaded in a single dense sentence followed by a short scope/provenance clause. It is efficient with no filler, though the parenthetical venue list is slightly long for the value it adds.

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 enough for a low-complexity read tool: it explains the computation, the venue universe, and that figures are timestamped and sourced. What is missing is whether the response is a single winner or a ranked comparison across venues.

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 all three parameters are already documented in the schema, giving a baseline of 3. The description reinforces that size is a market-order notional and implies fee-tier sensitivity, but adds no parameter-level detail beyond the schema (e.g., how monthly_volume_usd changes the ranking).

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 precise verb+resource question ("Which decentralised perpetual exchange is cheapest right now to open and close a market order of a given size") and enumerates the cost components (taker fees on both legs plus real slippage) and coverage (28 perp DEXs, named examples). This clearly separates it from siblings like trading_cost, cost_per_point, and execution_plan.

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 "cheapest right now" for a market order of a given size, which tells the agent this is a live cost-comparison lookup. However, it never states when to prefer it over siblings such as trading_cost or execution_plan, nor any exclusions or prerequisites.

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

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

Annotations already establish a safe read-only, closed-world operation. The description adds useful behavior beyond that: scope is limited to tracked airdrops, results cover dates/rules/rewards, the window is recent, and ordering is newest first; it does not describe pagination or result volume.

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

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

One front-loaded sentence with no filler; every phrase (tracked airdrops, changed fields, time window, ordering) contributes.

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

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

For a single optional-parameter read tool with no output schema, the description supplies the essential scope, time range, content categories, and ordering. Minor gaps are pagination/result-shape details and explicit sibling routing.

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 only parameter is fully documented in the schema (integer 1–7, default 1). The description restates the 1–7 day range but adds no syntax or edge-case meaning beyond the schema.

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

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

States the resource (changes in tracked airdrops), the changed attributes (dates, rules, rewards), the look-back window, and ordering. It is specific enough to separate this from a live listing, though it does not explicitly name live_airdrops or history.

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

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

Implies use for recent airdrop changes via the 1–7 day window, but gives no explicit when-not or alternative tool guidance (e.g., live_airdrops for current status or history for older changes).

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 and openWorldHint=false, so safety is covered. The description adds meaningful context beyond them by flagging the result as 'a theoretical maximum' and scoping it to 'this week', but it never explains where 'your volume' comes from given zero input parameters, which is a notable behavioral 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 short sentences, front-loaded with the applicability scope before the computed result. The trailing fragment 'A theoretical maximum, said so' is slightly informal and clipped, but it carries real information rather than 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?

With no output schema, the description must convey what comes back; it does describe the outputs (points and fee cost) but not their shape, granularity, or per-venue breakdown. Combined with the unaddressed question of how user volume is determined without parameters, the definition is adequate but leaves gaps for a zero-input analytical 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?

The tool takes zero parameters, so there is no schema semantics to compensate for; baseline 4 applies. The description's statement that volume is implicitly 'yours' is consistent with the empty schema but does not add further parameter meaning.

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

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

The description names a specific computation: points earned this week per dollar of fees spent, restricted to perp DEXs with a published weekly points pool. That is concrete enough for an agent to distinguish it from siblings like trading_cost (fees only) or live_airdrops (airdrop listings), although it never names those siblings 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 phrase 'For perp DEXs with a published weekly points pool' establishes an applicability condition, which is real guidance. However, it does not say when to prefer this over live_airdrops or farming_route, nor does it state any exclusions or prerequisites, leaving the routing decision to inference.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description does add real value beyond that: it discloses that costs for opening and closing both legs are netted in, that free-tier readings can be up to 15 minutes stale, and that rates change hourly so the result is a snapshot. It stops short of describing what the response contains (venues, fee breakdown, net rate) or any rate limits on call frequency.

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

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

Three short sentences, front-loaded with the core promise and then the cost model and the freshness caveat. No repeated title text or filler; every sentence adds a distinct fact.

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, three-parameter screening tool with full schema coverage and no output schema, the description covers the two things an agent cannot infer: costs are netted and the result may be stale. The remaining gap is the unresolved overlap with delta_neutral_scanner and the absence of any hint about what the ranked result looks like, which prevents a fully confident 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 pair, days, and size_usd_per_leg are already documented with defaults and bounds. The description adds only indirect meaning – 'net of opening and closing both legs at market' implies position size materially affects the answer – but says nothing about how holding days or size change the ranking. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific outcome: the best long/short pair across perp DEXs to collect the funding difference, computed net of opening and closing both legs at market. That is a clear verb+resource (find/rank a funding pair). It does not, however, distinguish itself from the near-identical sibling delta_neutral_scanner, so an agent still has to guess which of the two to call.

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

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

There is no explicit when-to-use guidance and no named alternative among siblings such as delta_neutral_scanner, best_venue, or execution_plan. The only guidance is implicit – that this is a screening snapshot rather than a forecast – which tells the agent how to read the result, not when to select this tool.

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

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

Annotations already declare readOnlyHint and closed-world scope, and the description adds real substance: per-scan pricing via x402 in USDC, per-minute cadence, fee-inclusive calculation on real books, and gap-duration output. The one behavior it omits is the exact current status payload, though it does say a status object is returned.

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?

Availability and price are correctly front-loaded before the capability pitch, and the final sentence states the present-day behavior. Phrasing like 'every pair and every venue couple, every minute' is promotional but still conveys cadence and coverage.

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

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

With no parameters and no output schema, the description carries the full burden and mostly succeeds: it covers availability, cost, scope, and what a call returns today. The missing piece is the specific free alternative to use in the interim.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline applies. Nothing in the text misleads about inputs.

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

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

Identifies the resource and computation precisely: a delta-neutral opportunity scanner across every pair and venue, measured net of opening and closing both legs. It does not name the sibling it overlaps with (delta_neutral), so sibling differentiation is only implied.

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 tells the agent the tool is not yet available and that calling it now yields status plus an alternative free tool, which is useful routing context. However, it never names that free tool, leaving the agent to guess among delta_neutral, best_venue, or farming_route.

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 and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by defining the exact depth bands (0.5% and 1% of mid) and the spread unit (bps), and by stating coverage is 'every live perp DEX'. It does not say whether illiquid/empty books are omitted or how venue identity appears in results.

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 no filler, and the most distinguishing detail (the metric definitions) is front-loaded. It is terse to the point of being slightly telegraphic, but nothing is wasted.

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

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

With one required parameter and no output schema, the description usefully carries the return-value burden by enumerating the fields the agent will get back and the fact that results span all venues. Only venue-level granularity and handling of missing books remain unstated.

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

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

Schema coverage is 100% with a single enum-constrained 'pair' parameter already documented as the base asset. The description adds nothing about the pair parameter, so the schema does all the work — the baseline 3 applies.

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

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

The description names the concrete metrics returned — best bid/ask, spread in bps, and USD resting within 0.5% and 1% of mid — and scopes them to every live perp DEX order book. That is specific enough to distinguish it from siblings like best_venue or trading_cost, though it is a noun phrase rather than a verb-led statement of action.

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

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

There is no when-to-use guidance at all: no mention of when to reach for this versus best_venue (single best price), trading_cost, or execution_plan (which presumably consumes depth). The agent must infer the selection criteria from sibling names 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?

The annotations only declare readOnlyHint=true and openWorldHint=false. The description adds important behavior beyond that: the tool is coming soon, costs 0.05 USD per plan via USDC x402, and currently returns status plus a fallback recommendation. It does not detail the payment/auth flow, but it discloses enough for an agent to understand current limitations.

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 three front-loaded sentences with no major repetition. Pricing, the future capability, and current fallback behavior each earn their place. The phrasing is slightly promotional, but still efficient.

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

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

Given the empty input schema and no output schema, the description must carry availability, cost, and return behavior, which it does. The main remaining gap is that the free fallback tool is not named and payment mechanics are only lightly described.

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

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

There are zero parameters, so the baseline is 4. The description appropriately does not spend space explaining nonexistent parameters.

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

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

The description specifies the future capability: splitting a large order across venues so each book absorbs only what it can, reducing slippage. That is more specific than a tautology. It does not explicitly distinguish itself from sibling tools such as best_venue, depth, or trading_cost, so it falls short of a 5.

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

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

It states that calling the tool now returns its status and the free tool to use meanwhile, which implies the tool is not yet usable for its main purpose. However, it does not name the free fallback tool or explicitly say when to choose this over siblings like best_venue or trading_cost.

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 only say readOnlyHint=true and openWorldHint=false; the description adds material context beyond that: the tool is not yet available, it will be Pro-priced at 0.25 USD per route paid in USDC via x402, and a call today returns status rather than a route. It stops short of saying whether a call incurs any charge or what the status payload looks like.

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 availability and price, then purpose, then the current-call behavior — a sensible order for a placeholder. Slight waste in the marketing-flavored phrase about 'avoiding what each campaign penalises', but nothing is substantially redundant.

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

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

For a zero-parameter, no-output-schema stub, the description covers the essentials an agent needs: it is not live, what it will cost, and that calling it is safe and returns status. The one real hole is the unnamed free alternative, which leaves the agent without a concrete next step.

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

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

The schema has zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter meaning is missing or misdescribed.

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 intent: recommend where and how to trade to maximize airdrop points per dollar of fees, given capital and horizon, while avoiding campaign penalties. That is distinguishable from siblings like cost_per_point or best_venue, though it describes a future capability rather than a currently callable action, and never says plainly 'this tool is a placeholder that returns status'.

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 tells the agent that calling now yields status plus the free tool to use in the meantime, which is real when-to/not-to guidance for a not-yet-live capability. However, the fallback tool is never named, so the agent must guess among siblings such as cost_per_point, best_venue, or trading_cost.

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 (readOnlyHint, openWorldHint), and the description adds meaningful context beyond them: the normalisation basis (8 hours), the annualisation, and the conditional availability of open interest and volume ('when published'). It does not state whether values are live snapshots or cached, which keeps it short of a 5.

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

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

Two compact sentences with no filler; the returned-data specification is front-loaded and the use-case hint is deferred to the end. Every clause carries information an agent would otherwise have to guess.

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 one required parameter and no output schema, the description compensates well by enumerating what comes back (normalised and annualised rate, open interest, 24h volume). It stops short of describing the response shape — e.g. that results are per-venue — which leaves a small gap for an agent planning downstream use.

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% and the single 'pair' parameter is a fully enumerated base asset with an example, so the schema carries the semantics. The description adds only the implication that the pair is queried across all venues rather than one, which is a modest gain.

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 (current funding rate of a perpetual) and its scope (each perp DEX), plus the derived metrics returned (8h-normalised, annualised, open interest, 24h volume). This distinguishes it from siblings like delta_neutral_scanner or cost_per_point, 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?

The trailing clause 'Useful for delta-neutral funding trades' gives an implied use case, but there is no explicit when-to-use vs when-not guidance and no routing to the closely related delta_neutral, delta_neutral_scanner, or best_venue tools. An agent must infer the selection criteria.

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 only declare readOnlyHint and openWorldHint; the description adds real context beyond them: pricing (0.05 USD per series, paid in USDC via x402) and the fact that calls today return a status payload rather than data. Not disclosing the exact status response shape keeps it from a 5, though with no output schema a hint would help.

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?

"COMING SOON" is front-loaded so the agent cannot miss the availability caveat, and both sentences carry distinct information (what it will do, what it does now, cost). Minor awkwardness in "as we read them" costs a point but nothing is padding.

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

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

For a zero-parameter, no-output-schema placeholder, the definition covers availability, cost, intended purpose, and present-day return behavior. The only substantive omission is naming the specific free alternative to route to.

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 and the baseline applies. It correctly implies no inputs are required for the current status-check behavior.

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 the resource (historical funding, costs, and order books, venue by venue) and its intended use (backtesting a strategy), and explicitly distinguishes the current placeholder behavior from the eventual paid product. It is clear about what the tool is for, though the eventual output shape stays abstract.

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?

"Calling it now returns its status and the free tool to use meanwhile" tells the agent this is not yet a data source and that it should fall back to a free sibling. The gap is that it never names which sibling (funding_rates, trading_cost, depth, cost_per_point are all plausible), leaving the agent to guess.

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 and openWorldHint=false, so safety is covered. The description adds genuinely useful provenance — fees are entry-tier and were verified against each venue's own docs on a recorded date — which tells the agent how much to trust the numbers. It says nothing about ordering, pagination, or result size, but for a static zero-param list that is a minor omission.

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

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

A single sentence, front-loaded with the resource and then the returned fields. It is dense but every element listed is meaningful output information, with no filler or hedging.

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 describing the return shape, and it does so by enumerating the four per-venue attributes. What is missing is the differentiation an agent needs to choose this over siblings, not the call mechanics.

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

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

The tool takes no parameters (0 count, 100% coverage), so there is nothing for the description to disambiguate; baseline 4 applies.

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

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

'The perp DEXs we cover' names the exact resource set and, by listing the per-venue attributes (order book type, maker/taker fees, verification date, signup link), makes clear this is an enumeration of covered venues. It does not state a verb or contrast with siblings such as best_venue or trading_cost, so it falls short of a 5.

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

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

There is no when-to-use guidance at all — nothing tells the agent to call this before trading_cost, best_venue, or signup_link, nor that it is the right entry point when the user asks which venues exist. The relationship to the closely related signup_link sibling is left entirely implicit.

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 and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond that: results are ordered by the next hard date, dates come from each project's own docs, and each entry carries a signup link. It does not disclose freshness/update cadence or whether closed campaigns are included, 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 front-loaded sentence with no filler; the ordering rule and provenance of dates are placed where they are most useful. It reads slightly as a run-on clause stack, but every element (resource, ordering, source, link) earns its place.

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

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

With no parameters and no output schema, the description carries the burden of explaining what comes back, and it does describe the key fields and sort order. It stops short of stating whether only open/active campaigns are returned, how fresh the data is, or how many results to expect, which leaves real ambiguity for a discovery 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify about inputs. It does not wrongly imply filters or options that do not exist.

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

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

The description names a specific resource (airdrop and points campaigns) and states it is a listing of 'the campaigns we track,' which is a concrete scope an agent can act on. It does not explicitly contrast with siblings such as signup_link or alerts, but the resource is distinct enough to be recognizable.

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 alternatives like signup_link (which likely retrieves a single link) or alerts (which likely covers notifications). Usage is only implied by the word 'tracked' — the agent must infer that this is the discovery/browse entry point.

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 and openWorldHint=false, so the safety profile is carried structurally. The description adds genuinely useful behavior beyond that: the returned link embeds a referral code when one exists, which is a conditional output property not visible in schema or annotations.

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

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

One short sentence, front-loaded with the resource and ending with the conditional referral qualifier. Nothing is redundant or padded.

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

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

For a one-parameter, read-only tool this is close to sufficient, but with no output schema the description never states what shape the response takes (a bare URL string vs. a link object) or what happens when no referral exists or the venue is unsupported.

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 venue parameter already documents its source ('Venue id from list_venues, e.g. hyperliquid'). The description adds no further meaning about valid venues, failure on unknown venues, or fallback behavior, so the baseline 3 applies.

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

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

States a concrete resource and outcome: a link to open an account on a perp DEX, with the referral applied conditionally. The verb is implicit (returns/generates a link) rather than explicit, and the description never contrasts itself with siblings like list_venues or best_venue, but the resource 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?

Usage is only implied – an agent can infer it should call this when a user wants to open a venue account – but there is no explicit when/when-not guidance, no mention of prerequisites (e.g. that venue ids come from list_venues, which only appears in the schema), and no alternative tools named.

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 read-only and open-world safety, so the description's job is return-content disclosure, which it does well: it describes the cost decomposition (fees plus live-book slippage), fee tier, book time, and critically that some venues return no figure with an explanation. That last clause prepares the agent for partial results, which is real behavioral value. It does not mention rate limits, data freshness, or ordering in detail.

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 core output (round-trip cost ranking) before the supporting fields. Every clause carries information and nothing is redundant with the title, though the parenthetical and trailing list make it slightly harder to scan than a two-sentence split 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 and a simple three-parameter input, the description carries the return-value burden and does so by naming the output fields and the partial-coverage case. What's missing is how the ranking is ordered or expressed (bps, absolute USD) and how quickly live book data goes stale, which matters for a real-time slippage estimate.

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%, including the enum of supported pairs, the minimum order size, and the monthly_volume_usd fee-tier mechanism. The description's mention of 'fee tier' and 'book time' aligns with the schema but adds no format, units, or default detail beyond it. 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 resource and action: a full ranking of round-trip cost (fees + slippage on the live book) of a market order across perp DEXes. This is clearly a cost-comparison tool rather than depth, funding, or execution planning. It stops short of naming siblings like best_venue or execution_plan to sharpen the boundary, so 4 rather than 5.

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

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

The phrase 'Full ranking ... on each perp DEX' implies the use case of comparing venues before trading, but there is no explicit when-to-use, when-not-to-use, or pointer to the obvious alternative best_venue for a single recommendation. Usage is inferred rather than stated.

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