Trust Onion Scam Check

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds a genuinely new behavioral trait: matching is deterministic and no external LLM is invoked. That is useful for an agent reasoning about reproducibility and latency. It still doesn't mention rate limits or input limits, so not a 5.

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

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

Two sentences, zero padding, with the action and its outputs front-loaded before the determinism caveat. Nothing is redundant with the title.

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 needn't be described, and annotations carry the safety profile. The description adequately frames the tool, with only minor gaps around input sizing and how it relates to sibling lookup 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 0% for the single 'scenario' parameter, so the description must compensate. 'A described call or text' tells the agent the parameter is free-text narrative rather than an ID, which is modest value, but the 5000-char limit and expected level of detail are undocumented.

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 (match) and resource (a described call or text) plus the outputs produced (scam hubs, red flags, recommended verification step). This is far more specific than siblings like get_scam_stats or list_scam_types, though it stops short of explicitly naming which sibling to prefer.

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 phrase 'a described call or text', suggesting it is for case-by-case assessments, but there is no explicit when-to-use or when-not-to-use guidance. It never contrasts itself with search_incidents or explain_scam_type, so an agent must infer that this is the per-incident assessment path.

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 (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely non-obvious semantics: results are editorial/article-backed and the coverage is 'not a verified incident count,' which prevents the agent from misreading the output as incident data. It also discloses the two possible result shapes.

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, front-loaded sentences with no filler; the second is a meaningful caveat rather than padding. Slightly compressed, but every clause carries information about what is returned.

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, return-value detail is unnecessary, and the editorial-vs-verified caveat is valuable. However, for a tool whose only input is an undocumented string, the absence of any value-format guidance leaves a real gap an agent must fill by trial.

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 scamType parameter has 0% schema description coverage, so the description must compensate and largely does not: it never specifies accepted values, valid identifiers, or format. It hints that a valid input may resolve to either an editorial scam pattern or a Trust Onion topic hub, which is modest added meaning but leaves the agent guessing what to pass.

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 clear verb+resource ('Explain a documented editorial scam pattern') and even distinguishes two result modes: an editorial pattern with article evidence, or a Trust Onion topic hub with warning signs. It implicitly separates itself from list_scam_types and get_scam_stats by describing explanation content, though it never names those 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?

There is no explicit when-to-use guidance or routing to alternatives. The reader must infer from the sibling set that this is the 'explain one type in depth' tool versus list_scam_types (enumerate) or get_scam_stats (aggregates). No prerequisites or exclusions are 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful content scope ('including source reporting and prevention analysis'), but discloses nothing about failure behavior for an unknown slug or about how the case study is returned.

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

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

A single sentence with the verb, scope, keying parameter and payload contents front-loaded, and 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?

With an output schema present, the description need not explain return structure, and it correctly notes what the response contains at a high level. For a one-param read lookup this is nearly complete; only the slug format and unknown-slug behavior are 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 a single parameter with 0% schema description coverage, so the description must carry the meaning. 'For one verified incident by slug' tells the agent the slug identifies a verified incident and must map to exactly one, which is genuinely additive, but no format or example of a valid slug is given.

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 a precisely scoped resource ('the full published Trust Onion case study for one verified incident by slug'), which is far more specific than a generic 'get incident'. It implies a distinction from search_incidents by requiring a slug, but never names that sibling explicitly.

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

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

The phrase 'by slug' implies a prerequisite (you must already have an identifier), which hints that this is a lookup rather than a discovery tool. However, it never states when to use this versus search_incidents, nor any exclusions, so usage 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 declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds genuinely non-obvious behavioral context: results are a 'conservative loss classification' aggregate and 'only explicitly-USD losses are summed,' which tells the agent how to interpret the numbers. No coverage of aggregation window recency or result size.

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 tight sentences, no filler, with the resource scope front-loaded and the interpretation caveat second. 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?

An output schema exists, so return-value structure needn't be explained, and annotations cover the safety profile. The description is sufficient to invoke correctly; the only remaining gap is that 'Trust Onion Pulse' is never grounded in plain terms and no aggregation recency/freshness is given.

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 carry the meaning of the single optional integer 'year'. It does: the parenthetical explains that omitting it yields all-time stats and supplying it scopes to one incident year, which is exactly the semantic the bare 1990-2100 range lacks. It doesn't clarify matching rules (incident year vs. report year).

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 (Return) and resource (Trust Onion Pulse summary) with scope qualifiers, which distinguishes it from list_/search_/explain_ siblings. However, 'Trust Onion Pulse' is internal jargon that is not tied back to the tool's actual subject (scam statistics) named in the title, so an agent gets the shape but not an unambiguous restatement of purpose.

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 parenthetical '(all time, or for one incident year)' implicitly tells the agent when to pass the year argument versus omitting it, which is useful routing guidance. It never states when to prefer this tool over search_incidents or get_incident, so usage 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 declare this a safe, read-only, idempotent, non-open-world call, so the safety profile is covered. The description adds that the content is a fixed five-step protocol (static reference material), which is modestly useful, but it discloses nothing about format, length, or how the steps should be applied.

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

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

A single front-loaded sentence with no filler; the verb and resource lead and the applicable scope trails. Nothing is wasted.

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

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

With zero parameters and an output schema present, the description need not explain return values, and it correctly identifies what will be returned. Adequate, though the title/description mismatch ('Three Words Check' vs 'five-step protocol') could mislead about what the payload contains.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. No parameter-related value is expected or missing.

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 ('Return') and resource ('Trust Onion's five-step family verification protocol'), scoped to suspicious calls, texts, and video calls. It is distinguishable from siblings like list_scam_types and assess_call_scenario, though it never explicitly contrasts itself with them. Minor confusion: the title promises 'the Three Words Check' while the description describes a five-step protocol.

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 suspicious calls, texts, and video calls' hints at the domain, but there is no explicit when-to-use instruction and no routing against siblings such as assess_call_scenario or explain_scam_type. An agent must infer the trigger condition on its own.

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, so safety is covered. The description adds provenance context (editorial content vs verified incident statistics) and notes that article links are included, which is useful, but says nothing about volume, pagination, or freshness.

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

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

A single sentence with no filler, front-loading what is listed before the differentiating clause about incident statistics. Every phrase 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 parameters, an output schema present, and read-only annotations, the description supplies what is needed: the content type, its provenance, and how it differs from the statistics tool. Only minor gaps (pagination/volume) remain, and those are covered by the output schema.

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

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

The tool takes zero parameters, so the schema cannot convey argument meaning and the baseline is 4. The description adds that the returned set spans 'current' patterns with published article links, which is the relevant information for a no-arg list call.

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 (List) and resource (editorial scam patterns and published article links), and scopes it against verified incident statistics. It does not explicitly name the closest sibling, explain_scam_type, so an agent must infer whether this list or the explain tool is the right entry point.

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: 'List the current ... patterns' suggests a bulk enumeration, and 'separately from verified incident statistics' hints that get_scam_stats is a different dataset. There is no explicit when-to-use/when-not guidance or routing to explain_scam_type for detail on a single pattern.

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=false, so the safety profile is covered. The description adds real behavioral value beyond that: default sort order (newest first), a total count, and nextCursor-based pagination.

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

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

Three sentences, zero filler, and the filter list is front-loaded before the return-shape and routing notes. 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?

An output schema exists so return values need no explanation, yet the description still summarizes them usefully for an 11-parameter, zero-coverage schema. The only gaps are the undocumented sort options and the limit default/max, which an agent would need to infer.

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%, so the description carries the burden, and it maps most filters clearly (attack type, victim type, country, outcome, incident year, publication date range, keyword) plus cursor pagination via nextCursor. It omits meaningful detail on sort (4 enum values) and limit (max 25), leaving those parameters undocumented.

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 (Search) and resource (verified, published Voice Clone Scam Pulse incidents) and enumerates the filter dimensions, so the agent knows exactly what the tool returns. It also distinguishes itself from the sibling get_incident by noting that search returns compact summaries versus full detail.

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 routes the agent to get_incident 'with a slug for full detail', which is a clear alternative-and-condition pairing. It stops short of stating exclusions (e.g. when search is unnecessary) or prerequisites, but the context is clear.

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