RugRadar

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

With no annotations, the description carries the full burden and does substantial work: it discloses that the verdict is rule-based (implying deterministic, non-LLM output), enumerates the verdict values, the 0-100 score range, and the language options. It omits auth needs, rate limits, and any latency/caching behavior, which keeps it out of 5 territory.

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?

Front-loaded with the purpose, then packed with operational detail in a single dense paragraph; nearly every clause carries new information. The nested parentheticals make it slightly harder to parse than ideal, but there is little waste.

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 and no annotations, the description correctly covers the return shape (verdict, risk score, findings, naira value, message red flags) and the input surface. The only real gap is the unexplained `amount_ngn` parameter and the absence of any note on limits or failure modes for unresolvable input.

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 must compensate, and it does for three of four parameters: `text` (accepted input formats), `chain` ("auto" detection plus DexScreener chain ids like ton/sui/tron/hyperevm, 64 networks), and `lang` (en or pcm). `amount_ngn` is only implied by "what you'd get back in naira" and never explicitly tied to the parameter name.

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 crypto token for scam risk before buying) and enumerates the accepted input forms: contract address, DexScreener/pump.fun link, or forwarded message. This is clearly distinguishable from siblings like scan_message or token_history, which serve different scopes.

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

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

Gives a clear usage context ("before buying") and broad input acceptance across 64 networks, but never names an alternative or an exclusion. It doesn't tell the agent when to prefer scan_message or explain_finding over this tool, even though a forwarded message could plausibly go to either.

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?

With no annotations, the description carries the full burden, and it does disclose the nature of the result ('plain-language meaning'), which implies a read-only lookup. However, it says nothing about behavior for an unrecognized code (error vs fallback text), authentication needs, or whether the code list is fixed, leaving real behavioral gaps.

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 examples at the end earn their place by anchoring the expected input format. Nothing could be removed without losing 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 low-complexity lookup with no output schema, the core purpose is covered and return values need not be detailed further. It is still incomplete regarding the 'lang' parameter's accepted values and the error behavior for unknown codes, which an agent would want before calling it.

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 add semantic value for the required 'code' parameter by giving example values (HONEYPOT, LP_UNLOCKED), but it never mentions the 'lang' parameter at all, nor any format/case rules for codes, so compensation is only partial.

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 RugRadar finding code) and the exact output (its plain-language meaning), with concrete examples (HONEYPOT, LP_UNLOCKED) that make the purpose unmistakable. It does not name or contrast any sibling tool, but none of check_token/get_report/scan_message/token_history overlaps enough to create ambiguity.

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?

No when-to-use statement, no prerequisites, and no routing to or from siblings such as get_report or check_token, which are the likely sources of the codes this tool decodes. Usage is only inferable from the purpose sentence itself.

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?

With no annotations, the description carries the behavioral burden and does disclose two non-obvious traits: saved reports expire after 30 days and can be stale, so check_token should be re-run. It omits what happens for an expired/unknown id (error vs empty) and any permission requirements, so it is strong but not exhaustive.

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, no filler: what it fetches, how the id is obtained, retention window, and staleness caveat. The essential identification info is front-loaded.

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 one-parameter read tool with no annotations and no output schema, the description covers purpose, id sourcing, retention, and staleness guidance. It leaves out not-found/expired behavior, which is the main remaining 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 coverage is 0% and the schema only labels the field "Trace Id", so the description must compensate — and it does, explaining the id is the code at the end of a rugradar-dun.vercel.app/r/... link. That tells the agent exactly where to source the value, though no format/validation details are 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 states a specific verb and resource ("Fetch a saved RugRadar check") plus the addressing key (id from a /r/... link). It also implicitly distinguishes itself from check_token, which performs a fresh run. An agent can tell exactly what this returns without opening the schema.

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

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

It states when results are trustworthy ("Saved checks last 30 days") and explicitly names the alternative and condition: "Re-run check_token before relying on an old one: tokens change fast." This is a concrete when-to-use/when-to-switch rule, not an 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?

With no annotations, the description carries the full load and does disclose meaningful behavior: it performs no network calls and strips private data before processing. It still says nothing about the shape or determinism of the result, so it falls short of fully transparent.

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 filler; the core action and its detection scope are front-loaded, and the parenthetical enumeration of tactics earns its space by defining boundaries.

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 and no annotations, so the description should ideally say what a scan produces (findings, scores, flags). It covers what the tool does and its privacy/offline behavior but leaves the return value and the 'lang' input unexplained.

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 for the two parameters. It only implicitly covers 'text' via 'pitch message' and never mentions the 'lang' parameter or its default of 'en', leaving half the input surface 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 (scan) and resource (crypto pitch message) and even enumerates the tactic classes it detects, so the scope is unambiguous. It does not explicitly distinguish itself from siblings like check_token or get_report, which is the only thing keeping it from a 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 phrase 'crypto pitch message' implies the input context in which this tool applies, and 'without touching the network' hints at a safe, offline use case. However, there is no explicit when-to-use/when-not guidance and no alternatives named among check_token, explain_finding, get_report, or token_history.

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?

No annotations are provided, so the description carries the full behavioral burden. It lists some returned fields, but does not state that the operation is read-only, does not explain behavior when no prior check exists, and provides no auth, rate-limit, or freshness guarantees beyond 'how long ago'.

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 compact sentence with no filler, and the parenthetical list makes the return payload easy to scan. It is slightly under-structured as a fragment rather than a direct verb-resource statement.

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 are no annotations, no output schema, and no parameter documentation, so the description must compensate heavily. It partially describes the return contents but omits the meaning of chain/address, when to prefer this tool over check_token, and how missing history is represented.

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 two required parameters (chain and address), and the description never mentions them or their expected formats. The agent receives no semantic help for the inputs it must supply.

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 identifies a specific resource and scope: historical RugRadar data for a token, including verdict, score, pool size, and age. It is clear enough to distinguish from a fresh check, but it never explicitly names or contrasts against the sibling tools such as check_token or get_report.

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 guidance on when to use this tool versus check_token or the other siblings. The phrase 'last time this token was checked' implies a historical lookup, but the agent must infer all usage conditions.

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