PnL Labs — Solana Trust & Risk Checks

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

With no annotations, the description carries full responsibility for behavioral disclosure. It honestly states the tool's scope and limitations, including that behavioral dumps are invisible to all structural checkers and suggests an alternative. It also mentions the output format (verdict levels and stable reason codes) and promises zero noise, which are useful behavioral traits.

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 three sentences, front-loaded with purpose, then scope, then limitations. Every sentence provides valuable information without redundancy or fluff.

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 only one parameter and no output schema, the description fully covers the tool's purpose, output values, and limitations. It is sufficiently complete for an agent to decide when to use it and what to expect from the result.

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 the mint parameter as a Solana token mint address (base58), and the description does not add any additional parameter-specific meaning beyond what the tool does. Schema coverage is 100%, so baseline 3 is appropriate.

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 a structural risk check for a Solana token, listing specific risk factors (holder concentration, sniper bots, honeypot round-trip). It also distinguishes itself from siblings by focusing on token structural risks, not wallet or trade actions.

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 explicit usage guidance: it flags structural red flags, explicitly states what it cannot detect (behavioral dumps), and directs users to check wallets instead for those cases. This covers when to use and when not to use, with an alternative approach.

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 burden and does so well: it discloses that the tool is calibrated with real-world execution overhead (latency, priority fees, drift) rather than textbook AMM math, and it describes the output verdicts. It stops short of side-effect/access/rate-limit disclosure, but for a read-only cost oracle this is sufficient.

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 dense but not wasteful. It front-loads the high-level purpose, then details what is calculated, then gives a strong call-to-action, then lists verdicts. Each phrase contributes value; it is slightly long but justified by the need to communicate the oracle's sophistication.

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 two-parameter tool with no output schema, the description covers the key return information (slippage, round-trip cost, max size, verdict) and even edge-case verdicts (NO_POOL, UNKNOWN). It does not specify exact output format or thresholds, but enough context is provided for an agent to know what to expect and how to act on 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 coverage is 100% and both parameters have clear descriptions (mint address and size_sol with default). The description adds narrative meaning ('for YOUR size', 'main pool') but does not introduce new parameter semantics beyond the schema, so baseline 3 is appropriate.

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, vivid phrase 'Execution cost oracle' and immediately states the tool's core action: estimating real trade cost (slippage, round-trip cost, recommended max size). It is clearly differentiated from sibling tools (safety/forensics) by focusing exclusively on trade execution economics with a set of verdicts.

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?

Explicitly instructs 'Use before EVERY trade,' giving a clear when-to-use directive. It does not mention when not to use the tool or name alternative tools, but the verdict list includes NO_POOL/UNKNOWN, implying the tool itself reports when it cannot be used, which is helpful context.

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. It discloses the exact output categories (CEX_FUNDED, WALLET_FUNDED, UNKNOWN_ORIGIN, UNVERIFIABLE_ORIGIN) and the meaning of fresh_wallet_flag (elevated insider/bundle risk). It implies a read-only tracing operation and even covers an edge case via UNVERIFIABLE_ORIGIN, though it does not discuss potential errors, rate limits, or side effects.

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 front-loaded with a clear definition, followed by a useful contrast, the output list, and an actionable usage tip. Every sentence earns its place, though the second sentence could be tightened slightly without losing meaning.

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 tool with no output schema and no annotations, this description is remarkably self-contained. It explains the purpose, the classification outputs, the freshness flag's interpretation, and how to use the tool in a broader decision workflow. There are no major gaps left for an agent to guess.

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%, with the only parameter already documented as 'Solana wallet address (base58)'. The description reinforces that it operates on a Solana wallet but adds no new parameter-level constraints or format details. The baseline of 3 is appropriate when the schema fully covers the parameter.

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 pair: 'trace a Solana wallet's funding ORIGIN and freshness.' It explicitly distinguishes itself from check_wallet_trust by contrasting 'is this wallet really profitable?' with 'where did its money come from', making the tool's unique purpose unmistakable.

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 explicit guidance: it names the complementary tool (check_wallet_trust), clarifies what each tool is for, and gives a concrete recommendation: 'Use alongside check_wallet_trust before copy-trading.' This satisfies both when-to-use and how-it-relates-to-alternatives.

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 fully discloses behavior: conservative by design, says UNVERIFIABLE instead of guessing, and explains flags like known_sniper_bot. It also notes that 50% of tracked smart money is losing, which sets expectations about the tool's output.

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 three sentences, each carrying meaningful information: what it does, what it returns, and when to use it. No redundant phrases; it is dense and well-organized.

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?

Even without an output schema, the description enumerates the possible verdicts, confidence, reason codes, and flags. It explains the conservative behavior and gives a concrete example (known_sniper_bot). For a single-parameter tool, this is complete and actionable.

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 the only parameter 'address' as a 'Solana wallet address (base58)' with 100% coverage. The description adds no further parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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's function: 'recomputes REALIZED SOL profit/loss on-chain' and returns a specific verdict. It distinguishes itself from 'peak scores' and implicitly from sibling tools by focusing on realized PnL and trust assessment.

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?

Explicitly states when to use: 'Use before copy-trading or trusting any wallet.' This provides clear context and a concrete use case, differentiating it from general wallet analysis or other checks.

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