Real-time Solana sellability check at your size

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

With no annotations provided, the description carries full burden. It discloses it is a live simulation, answers specific metrics (USDC recovered, price impact, tax/friction loss), and importantly states it is paid ($0.01). It does not detail side effects or failure modes, but the simulation nature implies no destructive actions.

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 concise (three sentences) with no wasted words. It front-loads the core action immediately and provides additional context efficiently.

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 no output schema, the description covers key output aspects (USDC recovered, price impact, loss). It also mentions cost. For a tool with two parameters, it is fairly complete, though it could hint at the response format.

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 documents both parameters clearly. The description echoes the parameter meanings but does not add new semantic information beyond the schema, hence baseline score of 3.

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 specific verbs ('Simulate exiting') and clearly states the resource (Solana token via Jupiter round trip). It answers concrete questions ('can I get $X out right now, and at what cost?') and distinguishes from siblings like scan_honeypot by focusing on live simulation at a given size.

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 provides clear context for use (when checking sellability at a specific USD amount) but does not explicitly state when not to use it or compare to alternatives. The mention of catching honeypots could overlap with scan_honeypot, but the live simulation aspect differentiates it.

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