rugcheck-ai

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

No annotations are provided, and the description only says 'read directly from the chain', implying a read-only operation. However, it lacks details on failure modes, response structure, or any limitations. For a tool with no annotations, more behavioral context is needed.

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, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose and key trait (read from chain) in under 15 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?

Given the low complexity (1 parameter, no annotations, and an output schema), the description covers the core purpose. However, it omits details about the tool's behavior (e.g., what constitutes a 'trap') and assumptions about the input mint. The output schema likely fills in return value details, so this is adequate but not complete.

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 input schema has 0% description coverage for the 'mint' parameter, and the description does not elaborate on its format, expected values, or how it is used. The description's mention of 'mint' is minimal and does not compensate for the schema 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 clearly states the verb 'Check' and specifies the resources: 'mint/freeze authority and Token-2022 traps'. It distinguishes the tool from sibling execution tools (execute_safe_swap, simulate_sell) and verification tools (verify_token_safety) by being a read-only check.

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 context (before swap actions) but does not explicitly state when to use or when not to use this tool. No alternatives or prerequisites are mentioned, leaving the agent to infer intent from the name and 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?

With no annotations, the description bears full burden; it discloses that the swap is not broadcast, only built and returned for signing, and mentions safety verification and MEV protection, providing adequate transparency.

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, front-loads the purpose and route in the first sentence, and adds workflow context in the second, with 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?

Given the presence of an output schema, the description sufficiently explains the tool's behavior (building a swap for signing) without needing to detail return values, making it complete for the agent.

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 input schema has 100% coverage with clear descriptions of each parameter; the tool description does not add further semantic value, meeting the baseline expectation.

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 swaps tokens (amount of input_mint to output_mint) through a safety-verified, MEV-protected route, distinguishing it from sibling tools like simulate_sell and verify_token_safety.

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 explains that the server only builds the swap and returns it for signing, but does not explicitly specify when to use this tool versus alternatives or when not to use it.

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 must disclose behavioral traits. It states the tool 'checks' but does not clarify if it is read-only, requires a connection, or has side effects. This leaves ambiguity about whether it simulates a real transaction.

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 no wasted words. It could be slightly expanded to include parameter details without losing conciseness, but it is appropriately brief.

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 that there is an output schema, the description does not need to detail return values, but it should mention what kind of result to expect (e.g., boolean success). It also lacks any context about network requirements or prerequisites, leaving the agent missing key information for effective use.

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 only parameter 'mint' has no description in the schema (0% coverage). The description mentions 'token' but fails to explain that 'mint' is the token address, an obvious and critical detail for the agent.

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 checks if a token can be sold, specifically a honeypot check, which is a distinct purpose. It distinguishes from sibling tools like 'check_authorities' and 'execute_safe_swap' by focusing on sell simulation.

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 explicit guidance on when to use this tool versus alternatives is provided. The description does not mention prerequisites, such as having a token account, nor does it indicate when not to use it.

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 full burden. It discloses that the tool reads the mint directly (a read-only operation) and flags specific authorities and extensions. It does not mention error cases or prerequisites, but the existence of an output schema reduces the need to detail return values. Overall, transparent enough.

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: the first clearly defines the purpose, the second lists key checks. Front-loaded, no fluff, every sentence adds value.

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

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

The tool is simple (one parameter, read-only), and an output schema exists to document return values. The description covers what it does and what it flags, but omits prerequisites (e.g., network connection) and error handling. Still, it is largely complete for its purpose.

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% with no description for the 'mint' parameter. The description implies 'mint' is the token address by stating 'Reads the mint directly' and associating it with a Solana token, but it does not explicitly define the parameter. This is adequate but not rich.

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 performs an on-chain safety audit on a Solana token, specifying the verb 'audit' and the resource 'token'. It distinguishes from siblings by listing specific flags (mint authority, freeze authority, Token-2022 extensions), differentiating it from check_authorities which likely checks only select authorities.

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 advises using the tool 'before trading', providing clear context. However, it does not explicitly state when not to use it or mention alternatives like check_authorities, though siblings are present. The guidance is clear but lacks exclusions.

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