radar

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

Annotations only declare readOnlyHint=true; the description adds the material behavioral fact that the MCP session is anonymous and cannot subscribe anyone, so the tool is purely informational. That is exactly the kind of context annotations cannot convey. It stops short of noting trial/PRO gating mechanics beyond the marketing summary.

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

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

Two sentences, with the useful enumeration of channels/bot/deep link up front and the constraint last. The first sentence is dense with parenthetical detail (RU/EN, extreme events, PRO, 3-day trial) but each item maps to a real capability the user may ask about, so little is wasted.

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

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

For a two-optional-parameter informational tool with an output schema, the description covers what is explained, what is linked, and what the tool cannot do. Return values need not be described given the output schema. Only minor gaps remain, such as how the deep link behaves when coin is omitted.

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

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

Schema description coverage is 100%, with both coin and lang already documented including an example and the enum. The description reinforces the coin parameter's purpose ('opens the bot with the coin already set'), which adds slight framing but no syntax or defaulting detail beyond the schema. 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 states concretely what the tool returns: an explanation of the public Telegram channels (RU/EN, extreme-events, delayed), the personal bot with instant alerts, and a deep link pre-filled with a coin. The closing clause 'this tool only explains and links' makes it clearly not a data-fetching tool, separating it in spirit from data siblings like funding_events, though no sibling 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?

Framing as 'How to get funding alerts from the radar' plus the explicit exclusion of subscribing tells the agent the right situation (user asks about alerts/delivery) and one thing this tool cannot do. Alternatives such as radar_about or funding_events are not referenced, so routing is implied rather than spelled out.

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

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

Annotations only declare readOnlyHint=true, so the description carries the meaningful burden and does so well: it discloses the threshold that defines an 'extreme' event, what fields accompany each event (peaks, receiving sides), the venues covered, the prediction semantics of the rates, and the data staleness bound. That is unusually rich operational context beyond structured fields.

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

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

The key payload (extreme events, threshold, exchanges) is front-loaded in a single dense sentence with no filler. It is slightly overpacked — three distinct facts (coverage, prediction semantics, freshness) are packed into trailing clauses — but every clause earns its place.

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

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

With an output schema present, the description needn't explain return structure, and it supplies everything else an agent needs: data source set, freshness bound, the numeric threshold for inclusion, and the fact that rates are forward-looking predictions. Nothing material is missing 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 100% for both optional params (lang enum with default, limit 1–20 default 10), so the schema already does the work. The description adds nothing about language selection or row limits, making baseline 3 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 names a specific resource (crypto perpetuals funding market) and precisely defines what is returned: open extreme events with |hourly rate| ≥ 0.1%/h, peaks and receiving sides, plus top pairs by hourly funding rate across five named venues. An agent can immediately distinguish it from funding_history (historical) and spread_pairs (spreads).

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 establishes a clear usage context — a real-time snapshot ('right now', 'data age ≤ ~5 min', 'rates are predictions for the next settlement') — which tells the agent this is the live/current-state tool. It does not, however, explicitly name an alternative such as funding_history for past data or state when not to use it.

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

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

It provides significant behavioral detail beyond the schema and annotations by describing how the data is processed ('normalized to %/hour on a common hourly grid'). It clarifies the analytical value of the output, such as distinguishing between 'a hedged pair' and 'a one-off spike'.

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 extremely dense and front-loaded. It manages to convey the core service, the processing logic, the timeframe, and the types of data returned in a few highly impactful sentences.

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 that the output involves financial curves, normalization, and spread analysis, the description is exceptionally complete. It helps the agent understand not just what to call, but what kind of complex financial data it will receive.

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 coverage is 100%, establishing a baseline of 3. The description mentions the scope ('one coin,' 'up to 90 days back'), which aligns with the schema constraints but adds no semantics or meaning that is not already structured in the parameters or their documentation.

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

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

The description is highly specific, stating that it 'Charged funding rates of one coin across all exchanges.' It goes beyond a simple noun-verb match by explaining the normalization (normalized to %/hour) and the result (curves plus median and maximum spread).

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?

While it defines the specific scope (cross-exchange rates), it doesn't explicitly tell the AI whether to use it over `funding_events` or `pair_briefing`. It primarily defines its domain rather than outlining clear decision paths against 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?

readOnlyHint=true already tells the agent this is a safe read operation. The description adds that all data is aggregated into one response, which is useful context, but it does not disclose latency, error behavior for unknown symbols, or whether data is live or cached. With annotations covering the safety profile, a moderate added-value score is appropriate.

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

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

The opening sentence is long but front-loads the tool's value and enumerates only substantive data points; the second sentence covers input flexibility. There is no filler, though the list could be slightly trimmed for 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?

An output schema exists, so the description need not specify return shape, and all three parameters are fully documented in the schema. For a complex aggregate read, the remaining gap is usage routing against siblings, which keeps it at 4 rather than 5.

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

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

Schema description coverage is 100%, so the schema already documents symbol, exchange, and lang with examples and enums. The description restates the symbol flexibility (BTCUSDT vs BTC) but adds no syntax or constraint beyond what the schema provides. Baseline 3 is correct 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?

The description names the resource ('one perpetual pair') and enumerates the exact data returned (funding rate, settlement timing, mark price, OI, orderbook walls, cross-exchange view), making the tool's scope unambiguous. It implies comprehensiveness ('Everything the radar knows... in a single answer') but never explicitly contrasts itself with focused siblings like funding_history or settlement_calendar, so a 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?

There is no explicit when-to-use or when-not-to-use guidance. The phrase 'in a single answer' implies this is the comprehensive alternative to narrower tools, but the agent must infer that routing. No exclusions or prerequisites 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?

Beyond the readOnlyHint annotation, the description adds critical behavioral constraints (the 300-pair limit) and behavioral output details (what is included in each row: receiving side, next settlement, OI, etc.). This provides full operational context.

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

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

The description is dense but highly efficient. It front-loads the core function and constraints immediately, delivering maximum information density without superfluous language.

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 high parameter coverage and explicit siblings, the description is complete. It explains the tool's limitation (the 300 pairs) and its workflow connection to `pair_briefing`, leaving the agent with all necessary context.

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?

While schema coverage is high (88%), the description significantly adds semantic meaning by explaining the filters in plain English ('receiving side'), clarifying the sorting options, and describing the components of the output row.

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 defines the tool's purpose: to discover perpetual pairs. It specifies the resource (perpetual pairs on the radar) and the specific capabilities (filtering by coin, exchange, side, rate, volume, and sorting).

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 provides precise usage guidelines by defining the scope: it filters the 'scanner's 300 strongest pairs.' Crucially, it dictates when NOT to use this tool—by routing users outside the top 300 to the sibling tool, `pair_briefing`.

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 annotation provides high-level safety (readOnlyHint: true), but the description adds crucial context regarding the tool's function—a detailed reference and glossary of terms. This adds significant value beyond the annotation's scope.

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 appropriately detailed given the nature of the tool (an 'About' resource). While lengthy, every sentence serves a crucial function in defining the scope and utility of the tool.

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

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

As a meta-tool, it is exceptionally complete. It covers data freshness, coverage, terminology, and contact info, which are all essential for a user interacting with the 'radar' source.

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?

Since schema coverage is 100% and there is only one parameter, the description primarily restates or elaborate on the parameter's scope without adding new semantic meaning beyond what the input schema already provides. 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 purpose is explicitly stated as a reference to the Funding Radar source itself. It details the content covered (exchanges, glossary, contacts) and distinguishes it from other 'data 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?

The instructions are prescriptive: 'Call this when the user asks what this source is, how to interpret a field, where to follow it, or how to reach the team.' It explicitly dictates the boundaries of usage and exclusion.

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, so the safety profile is covered. The description adds useful behavioral detail beyond annotations: the filtering thresholds, default horizon, time sorting, and the contents of each row including settlement-window statistics.

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 front-loaded and dense with useful detail. Every part earns its place by specifying the filter criteria, sorting behavior, default horizon, and the statistics included in each row.

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 read-only annotation, full schema coverage, and output schema, the description is largely complete for correct invocation. It could be stronger with explicit sibling differentiation, but the filtering and returned-row details cover the main gaps.

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

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

Schema coverage is 100%, so both parameters are already well documented. The description adds only the default horizon of 4 hours, which is already present in the schema, and does not mention the lang parameter or add further semantic nuance.

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 (funding settlements) and scope (upcoming in the next hours), including thresholds, sorting, and returned statistics. It is clear what the tool returns, but it does not explicitly differentiate itself from sibling tools such as funding_events or funding_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?

Usage is implied by 'coming in the next hours' and the notable-filter criteria, which suggest this is for upcoming notable settlements rather than historical or general event browsing. However, there is no explicit when-to-use guidance or named alternative among the sibling tools.

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

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

The readOnlyHint annotation already establishes the safety profile, and the description adds useful behavioral context: it returns the 7-day median spread, duration above the repay-within-a-day threshold, and breakeven hours against four legs of fees. It also notes that assumptions are included in the answer, which helps an agent interpret 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?

The description is compact and front-loads the core purpose: widest funding-rate spread right now. It packs useful output details into a single dense sentence without wasted clauses, though the phrasing is slightly complex.

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 read-only annotation and the presence of an output schema, the description is sufficiently complete: it explains the scan purpose and key returned metrics. It does not cover sibling routing, but the structural fields carry the rest of the needed context.

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

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

Schema description coverage is 100%, so both parameters (lang and limit) are already fully documented in the schema. The description does not add parameter-level meaning beyond what the schema provides, making the baseline 3 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 clearly states the resource: cross-exchange funding-rate spreads, specifically the widest spreads right now and the long/short leg construction. It is specific enough to distinguish from generic funding tools, but it does not explicitly differentiate itself from siblings such as pair_briefing.

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 'where the funding-rate spread between exchanges is widest right now,' giving a clear scenario for selecting this tool. However, it provides no explicit when-to-use, when-not-to-use, or alternative-tool guidance against siblings like pair_briefing or funding_history.

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