BotOrNot

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral value beyond that: it enumerates the verdict values returned and includes the critical caveat that 'no_record is NOT proof of safety', which an agent needs to phrase results correctly.

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, front-loaded with the action and sources, followed by the return-value caveat. No filler; every clause carries information.

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

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

With no output schema, the description helpfully explains the return shape (verdict enum plus source URLs). For a simple single-parameter read tool this is nearly complete, though it says nothing about coverage limits, rate limits, or freshness of the records.

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

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

Schema coverage is 100% and there is only one parameter, so the schema already documents the query fully with examples. The description restates that the query accepts a name or website/domain but adds no syntax or format detail beyond the schema — baseline 3 is appropriate.

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

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

States a specific verb (check) and resource (trading bot name or website/domain) and names the exact data sources it searches (BotOrNot directory, SEC, CFTC, state crypto scam tracker). This clearly distinguishes it from siblings like check_website and search_scams.

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 the tool's function (vetting a bot/domain before trust), but the description never explicitly states when to prefer it over siblings such as check_website or search_scams. No exclusions or routing conditions are given.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), but the description adds real interpretive context: matches carry custody model and incident history, and it explicitly warns that a match is not a safety rating and that 'unknown' is not proof of a scam. That caveat meaningfully shapes how an agent should report results. It does not describe response shape or multi-match behavior, keeping 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?

The action and scope of the lookup are front-loaded in the opening clause, followed by the outcome taxonomy and a short interpretation caveat. Three sentences, none redundant, with no restatement of the tool name.

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

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

There is no output schema, so the description must convey what comes back, and it largely does by defining the result categories and noting that matches include custody model and incident history. It stops short of describing how multiple matches, partial matches, or confidence are represented, which an agent would benefit from for a single free-text lookup.

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

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

Schema description coverage is 100% and the single param already documents accepted forms (@handle, t.me/ link, tg://resolve link), so the description is not required to carry parameter meaning. It adds no syntax, normalization, or constraint detail beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb and resource (check a Telegram @handle / t.me link) and scopes it to the domain concept that matters: whether it is an official handle, a known impersonator, a look-alike, or unlisted. Sibling tools check_bot and check_website address different artifacts, and the description makes the Telegram-specific scope unmistakable.

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

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

The four possible outcomes are enumerated, which tells the agent when this tool is the right lookup and what a given answer means. However, it never explicitly names an alternative (e.g. check_bot for the bot itself, check_website for the site) or states a when-not-to-use condition, so selection guidance rests on 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 only declare readOnlyHint and openWorldHint; the description adds real behavioral context by disclosing the specific external sources consulted (state regulator tracker, public RDAP) and by explicitly warning the output is probabilistic signals rather than a verdict. It omits rate limits, auth needs, and failure behavior for unreachable or unregistered domains.

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

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

A single dense sentence with the core purpose front-loaded, followed by a short caveat. Every clause carries information (distinct signal categories) and there is 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?

With no output schema, the description correctly takes on the job of describing what the tool returns by enumerating the signal categories. It is nearly complete for a two-parameter read tool; only output shape (scored fields vs. raw evidence) and the relationship between url and text remain unstated.

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

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

Schema coverage is 50%: the 'text' property is documented, but 'url' is not. The description compensates partially by explaining that pasted text is scanned for regulator-listed red-flag phrases, which clarifies the optional parameter's intent, but adds no format or constraint detail for the required url parameter.

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

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

States a specific resource (a website) and enumerates the concrete signals returned: regulator scam-tracker matches, look-alike domain detection, RDAP domain age, HTTPS, and red-flag phrases. This is far more informative than a tautology, though it never names the sibling search_scams or explains how it differs from it.

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 clearly enough (an agent knows this is the per-URL scam-signal lookup), and 'Signals, not a verdict' usefully frames how to treat the output. However, there is no explicit when-to-use versus when-not guidance and no routing to alternatives like search_scams or compare_bots.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds genuinely new behavioral context: the output is factual and sourced, and the tool deliberately renders no verdict or ranking. That 'no winner' note is real information an agent cannot get from the 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 short sentences, front-loaded with the core action and output, with no filler. 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 simple two-parameter read tool with no output schema, the description sufficiently characterizes the return (facts plus report cards, no verdict). It stops short of noting ordering or how a/b map positionally, but nothing critical 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 0% and both parameters are opaque single letters ('a', 'b'). The description compensates by stating these are 'two bots by slug', giving the agent the type and identity of each argument, which is meaningful added meaning beyond the schema.

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

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

States a specific verb (compare) and resource (two bots) with the return content (sourced facts and report cards). It is clearly distinguishable from get_bot or get_report_card, though it does not name those siblings explicitly to sharpen the contrast.

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

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

The phrase 'for two bots by slug' implies the comparison use case and 'No winner is picked' clarifies the intent, but there is no explicit guidance on when to choose this over fetching each bot individually or using get_report_card.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description adds real value by enumerating the payload: pricing, markets, custody model, sourced red flags, report card, and impostor scam reports — telling the agent this is a rich dossier rather than a stub.

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

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

A single front-loaded sentence with zero filler; the resource and scoping are stated first and the payload enumeration is dense but 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 read-only single-record lookup with annotations covering safety and no output schema, the description gives an adequate picture of what comes back. It stops short of edge-case behavior (e.g., unknown slug handling), which is minor.

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

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

Only one parameter with 0% schema description coverage, so the description must carry the load. "By slug" identifies the key and ties it to list_bots, but gives no format or validation detail for the slug itself.

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: retrieves a full fact sheet for a single bot identified by slug. Naming list_bots as the source of the slug helps separate it from siblings, though it doesn't contrast against check_bot or compare_bots directly.

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?

"(see list_bots)" implies the slug must first come from another tool, which is useful implied workflow. However it gives no explicit when-to-use-this vs check_bot guidance or exclusions, leaving the agent to infer the choice.

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=true and openWorldHint=false, so the safety profile is covered. The description adds genuine value by enumerating the event categories returned and implying recency ordering ('Recent'), but says nothing about result count behavior, ordering guarantees, or how the feed is assembled.

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, front-loaded with the returned content and closed with the optional filter. Every clause conveys a distinct event category; nothing is wasted or 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 feed with no output schema and 0% schema coverage, the description covers what is returned reasonably well but omits result ordering, pagination/limit behavior, and the shape of a change event. It is adequate but leaves gaps an agent would have to discover empirically.

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 must compensate. It does clarify that `bot` is a slug and that filtering by it is optional, which is real added meaning, but it says nothing about `limit` (default 20, max 100) beyond what the JSON schema keywords already convey.

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

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

The description names a specific resource and enumerates the exact event types returned (regulator cases, scam-tracker reports, bot shutdowns, report-card changes, SEC/CFTC releases), so an agent knows precisely what data this yields. It does not, however, contrast itself against point-lookup siblings like get_report_card or search_scams, which cover overlapping subject matter.

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 only usage cue is 'Optionally filter by bot slug,' which describes a parameter rather than when to choose this tool over alternatives. There is no guidance on when a changes feed is preferable to check_bot, get_report_card, or search_scams.

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 this as a safe read (readOnlyHint=true, closed-world openWorldHint=false), so the bar is lower. The description adds genuine value by scoping the corpus to 'verified' incidents and disclosing the shape of what is returned (date, impact, users affected, loss, refund status, source URLs), which is important given there is no output schema.

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

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

The definition is compact and front-loaded, leading with the resource and its contents before the optional filter. The field enumeration is dense but every item earns its place since there is no output schema to lean on.

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

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

With no output schema, the description carries the burden of explaining return values and does so thoroughly. The main gap is the absence of differentiation from search_scams and any note on result ordering/pagination, but overall it is sufficient to invoke the tool 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 coverage is only 50%: the 'bot' slug parameter is documented in the schema, but 'limit' is undocumented there. The description clarifies that the bot filter is optional but adds no detail on ordering, defaulting, or what limit controls, so it only partially compensates for the coverage gap.

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

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

The description states a specific verb+resource: retrieving verified security incidents (hacks, exploits, key leaks) at trading bots, and enumerates the returned fields. It is clear what the tool returns, though it does not explicitly distinguish itself from the sibling search_scams, which likely covers a related but different (unverified scam) space.

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?

'Optionally filter by bot slug' implies one usage pattern, and 'verified' implies a quality boundary, but there is no explicit when-to-use vs. when-not-to-use guidance. Critically, it never says how this differs from search_scams, leaving the agent to infer the distinction between the two siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds real value beyond that with the data source (on-chain), the TVL threshold, ranking metric, daily refresh cadence, and a caveat about predictive value. It does not describe result count/paging behavior, which limits it to a 4.

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

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

Three short sentences, front-loaded with the resource and scope, then the ranking rule and refresh cadence, then a caveat. No filler; every clause carries information.

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

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

For a single-parameter read-only tool with no output schema, the description supplies the dataset definition, filter, ranking, and freshness, which is most of what an agent needs; only the limit/result-size behavior is left unaddressed.

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

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

There is one parameter (limit, default 10, max 100) with 0% schema description coverage, and the description never mentions it, so the agent learns nothing about how many rows come back or how to change that. With low coverage the description was expected to compensate and does not.

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?

Specific verb+resource: it returns a Hyperliquid vault leaderboard from on-chain data, and it defines the exact filter (open vaults with >= $100k TVL) and ranking (30-day PnL in USD). No sibling tool covers a leaderboard, so no differentiation is needed.

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 the result is relevant via 'Refreshed daily' and the eligibility criteria, but it never states when to call this versus alternatives (e.g., get_report_card for a single entity) or any exclusions. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety and closed-world profile is covered. The description adds useful content scope (what categories of data come back) but says nothing about whether this is a fixed reference snapshot versus live data, or how the embedded bots/report cards relate to the dedicated sibling tools.

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

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

A single dense sentence that front-loads the primary resource (venues) before the secondary payload (bots and report cards). It is appropriately sized for a no-argument reference tool, though the trailing 'plus the documented...' clause is slightly tacked on.

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

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

With no parameters and no output schema, the description carries the burden of explaining return content, and it does so by listing the main categories (venues, CFTC status, sources, bots, report cards). It stops short of clarifying the relationship between the embedded bot/report-card data and the dedicated bot 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter semantics are missing because none 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 the concrete resource (prediction-market venues — Kalshi, Polymarket US, Gemini Predictions) and enumerates the payload (CFTC status, official sources, documented bots, report cards). It is specific enough to distinguish the content, but it does not explicitly contrast the tool with siblings like list_bots or get_report_card, whose output overlaps with the 'bots and report cards' portion.

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

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

There is no when-to-use statement, no prerequisites, and no exclusions despite the obvious overlap with list_bots, get_bot, and get_report_card. The agent must infer that this is a static reference lookup rather than a query tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the verdict is rule-based and deterministic ('payouts never change it'), it returns the exact sourced facts and rule ids behind the verdict, and it explicitly disclaims being a rating or advice.

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

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

Two dense sentences with no filler, front-loading the resource and its verdict taxonomy before the disclaimer. Slightly overloaded with parenthetical enumerations, but every clause carries information.

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

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

With no output schema, the description usefully enumerates the possible verdict values and notes that sourced facts and rule ids are returned, which an agent needs to interpret results. The remaining gap is slug semantics and the absence of routing guidance versus get_bot/check_bot.

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 single parameter 'slug' has 0% schema description coverage, so the description carries the burden. 'For a bot' weakly implies the slug identifies the bot being reported on, but the description never states the format, source, or lookup semantics of the slug, leaving the parameter under-specified.

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: a rule-based BotOrNot report card for a bot, and even enumerates the possible verdicts (Clear record, Caution, Red flags, Closed, Limited data). It does not explicitly contrast with close siblings like get_bot or check_bot, so an agent must infer the boundary, but the resource and output nature are unambiguous.

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

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

There is no when-to-use or when-not-to-use guidance, and no named alternative among siblings such as get_bot or check_bot. The clause 'Not a rating or investment advice' constrains interpretation of the output rather than telling the agent when to select this tool over its neighbors.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe, non-open-world read profile is covered. The description adds the field list (what you get back) but says nothing about pagination, result limits, or whether the bot list is static or live, so it only modestly exceeds the annotation baseline.

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

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

Two compact sentences with no filler; the resource and returned fields are front-loaded before the optional filtering note.

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

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

With no output schema, the description usefully enumerates the returned fields, and annotations cover the safety profile. It is nearly complete for a simple read-only list tool, missing only pagination/volume hints.

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 50%: category has a description but result is only an undescribed enum. The description names both filters ('category or report card result'), which compensates partially, but the enum values (clear, caution, red_flags, closed, limited) and the exact category syntax are left to 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 (List) and resource (documented trading bots) and enumerates the fields returned (slug, name, category, report card, official_url). It does not distinguish itself from siblings like get_bot or check_bot, so it stops short of 5.

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

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

The sentence 'Optionally filter by category or report card result' implies the tool's usage context (browse/filter), but there is no explicit when-to-use guidance or routing to alternatives such as get_bot for a single bot or compare_bots for comparisons.

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 safety (readOnlyHint=true, openWorldHint=false), and the description adds genuinely useful context beyond them: the provenance of records ('Every record has an official source URL') and a data-quality caveat ('allegations until resolved'). It stops short of describing result ordering or pagination, but the added provenance is real value.

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

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

Three short sentences, zero filler, with the search scope and source list front-loaded and the legal caveat saved for last. 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 two-parameter search with no output schema and only hint-level annotations, the description covers sources, query semantics and record provenance well. It could have said something about result volume/limit behavior or truncation, which is the only notable gap.

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. It clarifies that 'query' accepts a name, website or keyword, which is meaningful, but says nothing about the 2–200 character bounds or about 'limit' (default 10, max 50) and how it affects result count.

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 ('Search') and a specific resource ('regulator scam and enforcement records'), and enumerates the underlying sources (SEC, CFTC, state crypto scam tracker). It is clearly distinct from the bot-centric siblings, though it does not distinguish itself from check_website/check_bot, which could plausibly be reached with an overlapping 'name/website' query.

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

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

Usage is only implied: 'by name, website or keyword' hints at query modality, but there is no statement of when to prefer this over check_website or check_bot, nor any exclusion. The closing line about complaints being allegations is a caveat, not routing guidance.

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