coinrebate

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds real context: the benchmark is a published fee table entry with a stated date, and the yearly figure is explicitly an extrapolation assuming the volume is monthly — an assumption the annotations cannot convey. It stops short of stating rate limits or failure 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?

Two sentences, with the most consequential scoping guardrail (do not call for advice/orders/fund movement) front-loaded before the capability statement. The exclusion list is long but each item prevents a real misuse, so it earns its space.

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

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

An output schema exists, so return-value enumeration is not required, yet the description still explains the derived yearly figure and the fee-table date. Combined with the explicit scope boundaries and the data source, an agent has everything needed to call this 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?

Schema description coverage is 100% and every parameter (exchange, volume, type, country) is documented in the schema itself, so the baseline is 3. The description clarifies the fee basis used for the volume/exchange inputs but adds no syntax or format detail 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 states a precise verb+resource: 'Estimate the taker-fee cost of a trading volume on one exchange, with and without the CoinRebate referral discount.' The 'one exchange' scope implicitly distinguishes it from the sibling compare_fees, and the named data source (CoinRebate's published fee table) nails down what the estimate is based on.

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 an unusually explicit exclusion list (investment advice, order placement, signing in, moving funds) plus a positive scope statement ('Use it only for questions about exchange trading fees and fee discounts'). The one gap is that it never names the sibling to switch to when the user wants multiple exchanges (compare_fees) or a general fee table (get_exchange_fees), leaving that routing 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?

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior. The description adds valuable behavioral nuance beyond that: allowlisted host restriction and the fact that a link carrying someone else's code is reported as stale_code even though it may be valid. This helps set expectations for an agent interpreting the result.

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 two sentences with no filler. It front-loads the core purpose, adds a crucial behavioral caveat, and ends with a clear pointer to the alternative 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 single-parameter read-only tool with an output schema and annotations covering safety, the description is complete. It explains scope, edge-case behavior, and when to use a different tool, leaving no key decision unclear.

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 only one parameter, url, with 100% description coverage. The description does not add further syntax or format guidance beyond the schema, but that is acceptable because the schema already documents the parameter adequately.

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

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

The description states a specific verb and resource: it checks whether a URL carries CoinRebate's own current referral code, restricted to allowlisted exchange hosts. It also explicitly distinguishes this from the sibling tool inspect_exchange_link by describing this as a self-check rather than a neutral inspection.

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 an explicit alternative with the condition for choosing it: 'For a neutral inspection of any exchange link, use inspect_exchange_link.' This tells the agent exactly when to use this tool versus the sibling.

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 read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds real behavioral value: the return is ranked by taker fee and accounts for the CoinRebate referral discount, and results are compliance-filtered when a country is supplied. It does not cover data freshness or table update cadence, so it stops short of 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?

The negative guardrail list plus the positive scope statements are all substantive and no sentence is filler. It is slightly verbose and leads with prohibitions before stating the purpose, which delays the core function, 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?

For a two-parameter read tool with a full output schema, the description covers scope, exclusions, output ordering, and the compliance-filtering behavior. Nothing an agent needs to select and correctly invoke this tool is missing.

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

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

Schema coverage is 100%, so both parameters (purpose enum, country code) are already documented in the schema, including that country drives compliance filtering. The description largely restates this ('Pass a country code for compliance-filtered results', 'one purpose (spot or futures)') without adding format or edge-case detail, matching the baseline 3.

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 (compare) and resource (benchmark trading fees from CoinRebate's published fee table across covered exchanges), plus the output ordering (ranked by lowest taker fee after referral discount). This implicitly separates it from siblings like get_exchange_fees (single exchange) and recommend_fee_option, so an agent can route without opening schemas.

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?

Explicit when-not list (investment advice, order placement, signing in, moving funds) with the instruction to answer those without calling the tool, and an explicit when-to-use clause: 'Use it only for questions about exchange trading fees and fee discounts.' Both the exclusion and inclusion conditions are stated, not inferred.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: results are governed by CoinRebate's compliance matrix and the tool cannot perform account or fund actions. It does not discuss coverage gaps or freshness of the compliance data, 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?

Compact at three sentences with no filler, and the positive purpose statement follows the exclusions. The leading exclusions are slightly verbose and delay the core purpose statement, but every clause carries real routing value.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Combined with a fully documented schema and clear scope statements, the definition is nearly complete; only minor detail about how the compliance matrix shapes results is absent.

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%: the country parameter documents the ISO 3166-1 alpha-2 format with examples and the purpose parameter enumerates spot/futures/p2p. The description adds no parameter-level meaning beyond that, so the baseline of 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 specific verb and resource ('Get exchanges available in a specific country') plus the scoping mechanism ('filtered by the CoinRebate compliance matrix'). The final sentence pins the tool's domain ('only for questions about which exchanges are available in a country'), which cleanly separates it from the fee, news, and referral siblings.

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 explicit when-not guidance by enumerating the out-of-scope request classes (investment advice, order placement, sign-in, moving funds) and telling the agent to answer those without calling the tool. It also states the positive condition for use, leaving nothing 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 readOnly/idempotent/openWorld/non-destructive, so the bar is lower, yet the description adds genuinely new behavioral context: these are published static rates, not live order-book data, and it disambiguates freshness fields — fees.fee_table_updated is the exchange entry's last update, whereas data_source and fetched_at describe only CoinRebate's refresh check. That distinction is not derivable from the annotations and prevents a serious misinterpretation of staleness.

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?

Roughly 110 words, which is reasonable for a tool carrying this much scope and freshness nuance, and the key 'published rates, not live data' caveat is stated early. It loses a point because the opening do-not-call sentence and the closing 'Use it only for...' sentence partially restate the same scope boundary, creating mild redundancy.

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 tool with an output schema present, the description supplies everything an agent needs to select and call it correctly: coverage (all covered exchanges), tier basis (VIP 0), discount treatment, and the non-live nature of the data. Return structure is left to the output schema, which exists, so nothing material is missing.

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

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

The tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to document; the baseline for a parameterless tool is 4. The description correctly adds no invented argument syntax and instead spends its words on output semantics.

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+scope: 'Get the benchmark trading fees from CoinRebate's published fee table for every covered exchange,' and pinpoints the content (spot and futures maker/taker at VIP 0 base tier, plus post-referral-discount rates). It distinguishes this reference-data tool from adjacent siblings like compare_fees or recommend_fee_option only implicitly, via the closing 'Use it only for questions about exchange trading fees and fee discounts'; 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?

It enumerates four explicit out-of-scope request classes (investment advice, placing orders, signing in, moving funds) and instructs the agent to answer those without calling the tool, then states the positive trigger condition. This is unusually strong when/when-not guidance that directly prevents misuse, even though it routes on task type rather than naming alternative tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description goes beyond that by disclosing that a country value activates CoinRebate's availability records for that country and by enumerating exactly which referral artefacts are returned, which the annotations cannot convey. It stops short of mentioning data freshness or coverage limits.

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

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

The negative guidance is front-loaded, which is the right priority for an agent deciding whether to call it, and the return-value sentence is dense with useful content. The prose is somewhat long and the closing 'use it only for...' sentence partially restates the scope already implied by the negative 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?

With an output schema present the description does not need to spell out return shape, and with annotations covering safety it does not need to restate read-only behaviour. What remains — scope, exclusions, the effect of the optional country parameter, and the boundary against order/advice requests — is fully covered.

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 is 3. The description nonetheless adds meaning the schema lacks: the schema merely says 'for compliance check', while the description explains that passing country applies CoinRebate's stored availability records for that country. The exchange param adds no semantics beyond the schema's enumerated exchange names, so it is not a full 5.

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

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

The description states a precise verb and resource (look up a referral code, fee discount and signup link for one exchange) and enumerates the exact returned fields including maker/taker fees before and after discount. This distinguishes it from siblings like get_exchange_fees, compare_fees and check_referral_link, which do not combine referral data with per-exchange fee tables.

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 an unusually explicit when-not list (investment advice, order placement, exchange sign-in, moving funds) and a positive scope rule ('use it only for questions about an exchange referral code, signup link or fee discount'). The only gap is that it never names a sibling tool as the alternative for the excluded cases, so the routing is stated by task rather than by target 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 the operation is read-only, idempotent, and non-destructive. The description goes further, disclosing that results are newest-first, capped at 5 by default and 20 max, that each item carries title/date/link, and that it signals when the newest article is over three days old – genuinely useful behavioral context not present in 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?

Dense but front-loaded: the exclusions and routing rule come first, then the return semantics. Every clause carries information, though the paragraph runs long enough that the positive purpose is somewhat buried after the negative guidance.

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 read-only annotations, a fully documented parameter, and an existing output schema, the remaining burden is scope and routing – both fully addressed. An agent has everything needed to decide to call it and how to interpret the response, including the staleness signal.

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 'limit' parameter is fully documented in the schema (default 5, min 1, max 20). The description's 'up to five by default, at most 20' merely restates the schema, so it earns the baseline rather than extra credit.

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

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

States a specific verb and resource: 'Get CoinRebate's most recently published English-language articles (market analysis, guides and news)'. It clearly distinguishes itself from sibling tools like compare_fees, get_exchange_fees, and search_guides by scoping to newly published content.

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?

Explicitly enumerates when NOT to use it (investment advice, placing orders, signing in, moving funds) and gives the sole positive condition: 'Use it only when the user asks what CoinRebate has published.' Names the routing rule and the fallback behavior for out-of-scope requests.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the context 'from official Binance klines', which specifies the data source. However, it does not disclose potential rate limits, error behavior, or what happens if the symbol is invalid, but given annotations, a 3 is appropriate.

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

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

The description is a single, concise sentence that front-loads the core action and scope. Every word contributes value, with no redundancy or 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?

The tool has an output schema, so return values are documented separately. The description covers the purpose, data source, and the specific statistics. Given the low complexity (one parameter, no nested objects) and existing schema, the description is nearly complete, missing only explicit usage conditions that are minor for this 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 schema description covers the single parameter 'symbol' with an example and format constraints, achieving 100% coverage. The tool description does not add any additional semantics beyond what the schema already provides, so the baseline of 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 a specific verb ('Gets') and a clear resource: daily, weekly, 30-day, and historical weekly-rank statistics for a Binance TradFi perpetual. It distinguishes from siblings like list_tradfi_perps (listing) and fee-related tools by focusing on statistics derived from official Binance klines.

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

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

The description implies usage for retrieving statistics for a specific perpetual symbol, but it does not explicitly mention when to use this over alternatives like list_tradfi_perps or calculate_trading_cost. It is clear that it is for stats, but no explicit exclusions or alternative routing is provided.

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 read-only, open-world, and idempotent behavior, and the description reinforces these without contradicting them. More importantly, it adds substantial non-obvious behavioral guarantees: 'Unknown items are reported as unknown,' 'never says a link is safe,' 'never probes unrecognized domains,' and 'never suggests a replacement link.' These are high-value behavioral constraints an agent would otherwise have no way to know.

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 focused and front-loaded with the core action, followed by a compact list of the five evidence points and two boundary statements. It is information-dense with no filler. The five-point list is packed into a long, somewhat run-on sentence, which costs a point, but every clause earns its place and nothing is 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 read-only inspection tool with an output schema, the description is remarkably complete. It covers what inputs are used for, what the five categories of output are, how unknowns are handled, what the tool will never do, and its side-effect-free nature. Nothing an agent needs to safely invoke this tool is missing, especially given the annotations and output schema supply the remaining structure.

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%, placing the burden on the description. It compensates by explaining that the input is an exchange sign-up/referral link (the url parameter) and that country-specific listing and rebate evidence depend on 'a given country' (the optional country parameter). It doesn't spell out formats or defaults, but the semantic role of both parameters is clearly inferable from the five evidence points.

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 starts with a specific verb ('Inspects') and resource ('an exchange sign-up or referral link'), then enumerates five concrete evidence points the tool reports. This makes the tool's function unmistakable and inherently distinguishes it from data-lookup siblings like calculate_trading_cost or get_exchange_fees. It even states what it never does, sharpening the boundary further.

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 clear context: use this tool when you need evidence about a sign-up/referral link's domain, reachability, referral code, country listing, and rebate. It also provides implied exclusions ('never says a link is safe, never probes unrecognized domains, never suggests a replacement link') that tell an agent what not to expect. However, it never explicitly names an alternative sibling such as check_referral_link, so it falls short of fully explicit when-to-use/when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that data comes from the official exchangeInfo endpoint, which is useful context but not a behavioral trait beyond that. It does not describe pagination or any other operational detail, so a 3 is appropriate.

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

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

A single, well-structured sentence that front-loads the core action and scope, with no unnecessary words. Every part 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 and only one optional parameter, the description fully captures what the tool does. An agent can confidently call it knowing exactly what to expect in the response and what inputs are allowed.

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 provides 100% coverage of the single 'category' parameter, including an enum and description. The description's mention of US, HK, KR, CN stocks and commodities aligns with the enum values but does not add new semantics beyond what the schema already documents. Baseline 3 is correct.

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 action ('Lists'), the specific resource ('Binance USDⓈ-M perpetuals'), and the scope (US, HK, KR, CN stocks plus commodities). It also cites the official exchangeInfo endpoint, making the purpose unambiguous and distinct from siblings which cover costs, referrals, fees, or news.

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 makes it obvious when to use this tool (to get a list of these perpetuals) and none of the siblings overlap, so there is no confusion. However, it does not explicitly mention any exclusions or alternative tools, but that is not necessary given the clear scope.

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

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

Goes well beyond the readOnly/idempotent annotations: it discloses abstention triggers (missing/unsupported country, unreliable upstream data, genuine ties), the high-regulation path (objective fee table, no signup link), and the output composition including assumptions, non-modelled factors, and a commercial disclosure. This is exactly the behavioral context annotations cannot carry.

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?

Four dense sentences, all functional, with the negative boundary and the core verdict/purpose established early. The opening negative list is long, so the positive definition arrives slightly late, 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 recommendation tool with an output schema, it still summarizes verdict contents, abstention returns, and jurisdiction-dependent output, and it covers the routing boundary. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so all five parameters are already documented, including country's compliance-filtering role and the per-$10,000 volume default. The description reinforces that country is required and drives abstention but adds no format or syntax detail 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 a specific verb+resource+scope: 'Decide which covered exchange has the lowest effective trading fee for a specific user, instead of returning a table.' The contrast 'instead of returning a table' immediately separates it from table-returning siblings like compare_fees and get_exchange_fees.

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?

Explicit when-not list (investment advice, placing orders, signing in, moving funds) with the instruction to answer without calling, plus explicit when ('Use it only for questions about exchange trading fees and fee discounts'). The only minor gap is that sibling tools are not named, but the exclusion set is unusually precise.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by clarifying that results are informational articles, not referral links, and that search works in any language. It doesn't contradict annotations. It could add more about pagination or result ordering, but the core behavioral traits are disclosed.

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 two sentences with no wasted words. It front-loads the core function (searches by keyword), then adds the return format and the key differentiator (not referral links). Every sentence 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?

The tool has an output schema, so return values are documented elsewhere. The description covers the search scope, language support, and the informational nature of results. It doesn't mention pagination or result ordering, but for a simple search tool with an output schema and strong annotations, this is adequate. The only minor gap is not explaining the 'limit' parameter's effect, but the schema covers that.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter semantics. The description mentions keyword search and any language, which maps to the 'query' and 'lang' parameters, but it doesn't explain the 'limit' parameter or provide details on how language filtering works. The schema itself defines the parameters with types, defaults, and constraints, so the description adds some context but doesn't fully compensate for the 0% coverage.

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 tool's function: searching CoinRebate's published guides by keyword and returning matching articles with title, one-line description, and URL. It also distinguishes itself from referral-link tools by explicitly noting results are informational articles, not referral links, which helps differentiate it from siblings like check_referral_link and inspect_exchange_link.

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

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

The description implies when to use this tool: when searching for informational guides by keyword. It explicitly notes the tool is read-only and returns informational articles, not referral links, which helps exclude it from referral-link use cases. However, it doesn't explicitly name alternative tools or state when not to use it, though the sibling list and the 'not referral links' note provide some guidance.

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