cabal-hunter

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

With zero annotations provided, the description carries the full burden, and it delivers: it discloses the freshness/caching behavior (8-hour traces answered in <100ms vs full live trace in 15-20s), the degraded-mode honesty policy ('if we cannot verify something, we say so'), what counts versus what is excluded (real wallets only, LP/locked supply excluded), and the cost model. It even warns about treatment of the UNKNOWN verdict. No important behavioral trait is hidden.

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 evidence layers are well-structured with clear headers and ordered by evidentiary strength, and critical warnings (FIRST_LAUNCH vs UNKNOWN) are front-loaded. However, the description is very long and carries substantial non-functional content: a marketing pitch for the paid tier ('best for 24/7 bots'), detailed pricing arithmetic, and redundant re-explanation of the watch endpoint. These earn their place only partially, dragging the score below what the structure alone merits.

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 tool of this complexity — an external-API interaction with cost, caching, and multiple evidence layers — the description is remarkably complete. It covers the return fields (risk, cabal_score, top_holder_pct, degraded flag), tells the agent it can apply its own risk tolerance, and instructs on the required client timeout. The absence of an output schema is offset by the description listing the key return components explicitly.

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 baseline is 3. The description adds minimal new meaning about the two parameters themselves — it confirms supply comes from getTokenSupply rather than an estimate, but that's about tool behavior, not the parameters. The functional details around pairCreatedAt (speeding up analysis) are already in the schema. Nothing is misleading, but nothing compensates beyond baseline.

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 specific verb-resource pairing ('Pre-trade safety check for any Solana token mint') and frames the exact question it answers ('is a buyer about to be someone's exit liquidity?'). It distinguishes itself from the sibling check_wallet_in_token by focusing on buyer-side risk per mint, and even explains the complementary watch endpoint as a separate HOLD check. An agent can select it unambiguously.

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 explicitly marks this as a BUY check and contrasts it with the watch workflow ('a watch is a HOLD check... GET/DELETE /api/watch manage your own'), giving an agent both when-to-use and when-not-to-use guidance. It also states practical preconditions: free tier limits, no signup required, and the 30s client timeout needed to avoid abandoning a live trace.

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 does so thoroughly. It discloses the dual-source lookup, warns that found_in_scan=false is not a clean bill of health, explains holding.sold_out=true as the strong signal, and cautions that track_record is not a profit signal or recommendation.

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 long but every section earns its place: purpose, behavior, result-interpretation caveats, and access constraints. It front-loads the core question and usage case, then structures critical warnings in a clear, readable way.

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?

Despite having no output schema and no annotations, the description covers what an agent needs to call and interpret the tool correctly: result meaning, limitations, false-negative risk, rate limiting, and authentication. Nothing essential appears missing for this tool's complexity.

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 schema already documents both parameters adequately. The description adds contextual meaning by framing them as 'specific wallet' and 'specific token,' but does not add meaningful semantic detail beyond what the schema provides.

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 answers whether a specific wallet is involved in a specific Solana token, with a concrete use case. It does not explicitly differentiate itself from the sibling tool check_cabal_risk, so it misses the highest bar for sibling distinction.

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?

Provides explicit when-to-use guidance: when a user names a worried-about wallet or when an agent screens a token against a watchlist. It also mentions the Screen List add-on as an alternative for bulk screening, though it does not discuss exclusions relative to check_cabal_risk.

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