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

With no annotations, the description carries the full burden of behavioral disclosure. It fully discloses what the tool computes ('constant-product maths against the pool's live reserves and its own fee'), the possible verdicts (EXITABLE, PARTIAL, COSTLY, TRAPPED, THIN, NO_POOL, UNPRICED), and the semantics of UNPRICED. It also explains what it does NOT do (safety grading), preventing misinterpretation. This is exemplary transparency for a query tool.

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 somewhat long but every sentence earns its place: it establishes the use case, explains the computation, distinguishes from safety grades, and clarifies a potential misinterpretation. It is front-loaded with the core purpose, and the additional context is directly relevant. It is not wasteful, though it could be tightened without losing clarity.

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 there is no output schema, the description fully explains the possible return values (the verdict list) and their meaning, including the nuance that UNPRICED is not a negative judgement. It also explains the concept of 'largest position that exits under 5%' through the notion of calculates against live reserves. For a tool of this complexity, everything an agent needs to understand the tool's behavior is present.

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 schema already describes both parameters well (mint is a base58 address; usd is an optional position size, with omission giving largest clean exit). The description adds meaningful context by explaining how the two parameters interact ('Give a mint and a position size in USD and this returns...') and how the usd parameter affects the output. While the schema covers the mechanics, the description enriches the semantic understanding beyond a simple baseline 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 opens with a clear user goal: 'Before you buy a token, find out whether you can sell it.' It states the exact inputs (mint and USD position) and outputs (amount received, slippage, largest exit under 5%). It explicitly distinguishes itself from safety grades, which are a different concern, so an agent can tell it apart from any safety-related tool without confusion.

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 gives an explicit when-to-use instruction ('Before you buy a token') and a clear exclusion: 'This is deliberately NOT a safety grade.' It explains that safety grades assess contract characteristics while exitability measures liquidity depth, and even provides a concrete counterexample (PROOF). It also pre-empts misinterpretation of the UNPRICED verdict, clarifying it is not a judgement about the token. This is model usage guidance.

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