coinrebate

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the output theme (cost and savings vs standard fees) but no deeper behavioral context such as data sources or rate limits. No contradiction with 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?

Two focused sentences with no filler. The action and purpose are front-loaded, and every clause adds either the calculation target or the comparison basis.

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 is a simple read-only calculator with full schema coverage and an output schema, so the description does not need to explain return values. It is adequate for selection and basic invocation, though it could be slightly stronger if it explicitly routed between sibling fee tools.

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 exchange, volume, type, and country. The description only mentions trade volume and adds no extra parameter nuance, 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?

The description states a specific verb ('Calculate') and a specific resource ('actual trading cost and savings') tied to CoinRebate referral codes. It also signals the comparison against standard fees, which helps distinguish this tool from 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?

The description gives clear context: use this tool when you need the real cost and savings from referral codes for a given trade volume. It does not explicitly exclude alternatives or name when to prefer compare_fees, so it falls short of full routing 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?

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 readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds meaningful behavior: returns ranked exchanges, applies CoinRebate discount, and supports optional compliance filtering by country.

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 no fluff: the main action and ranking logic are front-loaded, and the optional country parameter is placed second. Every word 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?

Given the simple read-only nature, full schema coverage (100%), annotations indicating safety, and an existing output schema, the description provides enough for an agent to invoke correctly: purpose required, country optional, and ranking criterion clear.

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% already documents both parameters, including the country's purpose. The description's mention of 'Pass country code for compliance-filtered results' largely echoes the schema, adding no significant new semantics beyond the required purpose enum.

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

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

The description uses a specific verb 'Compare' with clear resource 'trading fees across all exchanges' and scopes to spot or futures. It also states the output is ranked by lowest fee after rebate, which distinguishes it from sibling tools like get_exchange_fees or get_compliant_exchanges.

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?

Clear context: the tool is for comparing fees across all exchanges for spot/futures, with an optional country for compliance filtering. It doesn't explicitly name alternatives or when-not-to-use, but the 'all exchanges' scope and ranking behavior make its use case evident.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that the tool optimizes for maximum discount and verifies compliance via country, but it does not disclose additional behavioral details such as live vs cached data or external network behavior. No contradiction with 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?

Two sentences with no wasted words. The core purpose is front-loaded, outputs are explicitly listed, and a practical instruction about the country parameter is included. 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?

For a low-complexity, read-only tool with full schema coverage and an output schema, this description is largely complete. It could have explicitly contrasted itself with sibling tools like check_referral_link or inspect_exchange_link, but that omission is minor and does not block 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%, so the input schema already explains both parameters, including the ISO country code for compliance and the allowed exchange names. The description adds little beyond restating the compliance purpose of the country parameter, so the baseline 3 is appropriate.

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

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

The description names a specific operation ('get the best referral/signup link'), a clear target ('a specific exchange'), and a selection criterion ('maximum fee discount'), while also listing the concrete outputs. This makes it easy to distinguish from sibling tools like check_referral_link or 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 context is clear: this tool is for retrieving the highest-discount referral link for an exchange, with country passed for compliance. It does not explicitly state when not to use it or name alternatives, but the intended use case is evident enough for an agent to select it correctly.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds that results are filtered by the CoinRebate compliance matrix, which is a behavioral detail beyond the safety profile. However, it does not disclose return format, pagination, or error behavior.

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

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

The description is a single, concise sentence that front-loads the core function. Every word is useful, and there is 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 is simple and read-only, with an output schema present (covering return format). The description covers the main function and the compliance filter. The optional purpose filter is not mentioned in the description, but it is fully documented in the schema, so the overall context is adequate.

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 (country with ISO 3166-1 alpha-2 and purpose enum) are fully documented in the schema. The description adds no extra meaning to the parameters, 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 clearly states a specific verb ('Get') and resource ('exchanges available in a specific country, filtered by the CoinRebate compliance matrix'), which immediately distinguishes it from sibling tools focused on fees, referrals, and news. The purpose is unambiguous and contextually relevant.

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 regulatory compliance queries but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusion criteria or alternative tools are mentioned, so guidance is only implied.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, so the safety profile is established. The description adds useful context by clarifying that the data is real-time, spans multiple exchanges, and includes post-discount fees, with no contradiction.

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 sentence with the core action front-loaded. Every clause contributes either the exchange scope, the fee categories, or the CoinRebate discount context, with no filler.

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

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

For a zero-parameter, read-only tool with an output schema and rich annotations, the description fully conveys what will be returned and at what scope. No critical operational detail 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 has zero parameters and 100% schema coverage, so there is no parameter meaning for the description to add. Baseline 4 applies because no undocumented inputs 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 verb ('Get') and resource ('real-time trading fees'), scopes it to six named major exchanges, and specifies the fee types returned. It is clear, though it does not explicitly differentiate itself from siblings like compare_fees or calculate_trading_cost.

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

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

The description implies when to use the tool: when the agent needs current spot/futures fee rates and CoinRebate-discounted values. It does not state exclusions or name alternative tools, so it stops short of fully explicit routing 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 it returns recent article titles and links, which is useful but doesn't disclose details like pagination behavior or whether 'latest' is time-windowed.

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, focused sentence that front-loads the main purpose and includes the return value. No wasted words.

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

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

For a simple read-only tool with one optional parameter and an output schema, the description is nearly complete. It could mention that results are limited to CoinRebate's published articles, but that's already implied by the source name.

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 limit parameter is fully documented in the schema. The description doesn't add extra meaning beyond what the schema provides, which is acceptable given the high 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 retrieves crypto news and market insights from CoinRebate, returning article titles and links. It distinguishes itself from sibling tools like calculate_trading_cost or compare_fees, though it doesn't explicitly name a sibling alternative.

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 fetching recent news, and the sibling list shows no other news-related tool, so the context is clear. However, it doesn't explicitly state when to use this tool versus alternatives or mention any exclusions.

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

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

Annotations already declare 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?

Beyond the readOnly/idempotent annotations, the description discloses conditional behavior: it returns a verdict with assumptions and non-modelled caveats, abstains with a neutral table when data is unreliable or venues are tied, and changes behavior in high-regulation jurisdictions by omitting signup links. This significantly enriches the annotations and sets correct expectations.

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 with the core purpose, then efficiently lists the verdict contents, abstention triggers, and jurisdiction-specific behavior. Every sentence adds decision-relevant information with no 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 tool with five parameters, rich annotations, and an output schema, the description is complete: it covers purpose, inputs in context, return contents, uncertainty handling, and legal/jurisdiction behavior. An agent has enough guidance to invoke the tool correctly without relying solely on structured fields.

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 all five parameters and their meanings. The description adds minimal parameter-level insight beyond requiring a user country and implying a personalized verdict, which matches the baseline rather than exceeding it.

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

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

The description opens with a specific verb ('Decide') and a specific resource ('which covered exchange has the lowest effective trading fee for a specific user') and explicitly contrasts itself with 'returning a table.' This clearly distinguishes it from table-returning sibling tools 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?

The description gives clear usage context: it is for deciding a verdict for a specific user, requires a country, and abstains under defined conditions. It does not explicitly name sibling alternatives, so it stops short of a 5, but the 'instead of returning a table' contrast and abstention criteria provide solid 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 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.