steve-guard

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses non-custodial operation, the embedded fee, the Guard safety check, the unsigned return value, and that the agent performs signing/sending. It stops short of explaining failure modes or guard rejection behavior, so it is not perfect.

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 tight sentences, front-loads the most important distinction (non-custodial, unsigned), and every clause adds unique value: fee, guard, custody, and signing responsibility. There is no filler.

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 the absence of an output schema, the description tells the agent what the tool returns (unsigned transaction) and who signs. It also conveys the fee and guard behavior. It is reasonably complete, though it could clarify what happens if the Guard check fails or how fees are deducted from the swap.

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 only 50%: amount and user_pubkey are documented, but input_mint and output_mint are bare strings. The description does not compensate by explaining mint address format or how the Guard check affects the output_mint parameter. Parameters are mostly left to inference.

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 states a specific verb ('Build'), a precise resource ('NON-CUSTODIAL Solana swap transaction via Jupiter'), and distinguishing details (embedded 0.20% fee, Guard safety check, unsigned transaction). This clearly separates it from the sibling check/verify/guard tools.

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 when to use the tool by emphasizing that the agent signs and sends with its own wallet and that keys/funds are never held. However, it does not explicitly mention when not to use it or directly compare it with any alternative tool.

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 provided, the description carries the full burden and does so well by disclosing the check outputs, the safety-screen caveat, and the 10/day free tier followed by paid checks. It makes clear that this is a safety screen, not an investment guarantee, which is useful behavioral context beyond the schema. The only minor gap is that it does not specify the exact response shape or define 'fresh' precisely.

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 dense sentences front-load the core function and output categories, then add the safety caveat and pricing note. Every clause earns its place, and there is no redundant restatement of the schema.

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 single-parameter tool with no output schema and no annotations, the description provides sufficient context for correct invocation: what it checks, what categories it returns, and how to interpret it. It also points to relevant sibling tools for track-record verification and pricing, making the surrounding workflow clear.

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 already documents the single 'mint' parameter as a base58 Solana mint address with 100% schema description coverage. The tool description adds extra selection-relevant meaning by narrowing the intended input to a fresh mint with a pump.fun focus, helping the agent understand what kind of address to pass. This exceeds the baseline for fully documented params.

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 states a specific verb-plus-resource action: 'Trap check for a fresh Solana mint' with a pump.fun focus, and enumerates concrete outputs such as rug-check verdict, dev first-buy SOL, reserves, and liveness. It also disambiguates itself as a safety screen rather than a profit claim, which clearly separates it from score_mint and related tools.

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?

It explicitly frames when to use the tool: as a safety screen for a fresh mint, and when not to rely on it, since it is 'not a profit claim' and directs verification via track_record. It also points to guard_pricing for the free quota and paid checks, giving the agent actionable routing guidance.

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 it does so strongly: it discloses the GoPlus safety checks, wallet-distribution metrics, the net-USD footprint methodology, the score/verdict output, and the daily quota/billing behavior. This gives the agent a clear picture of what the tool does and what to expect.

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 the chain and use case, and every sentence contributes meaning. It is slightly promotional and jargon-heavy, but it remains compact and informative.

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 one input parameter and no output schema, the description covers the important calling context: what checks are run, what output is produced, and how the verdict is derived. It could add score-direction interpretation, but the existing detail is sufficient for a capable 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?

Schema coverage is 100% for the single parameter, with the format already defined in the schema, so the baseline is 3. The description adds chain context but does not need to elaborate further on the parameter semantics.

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 identifies the resource (Robinhood Chain tokens) and the combined safety/wallet-distribution analysis, ending in a 0-100 score and verdict. It does not explicitly differentiate from sibling check_robinhood_honeypot, though the 'One call' bundling implies broader scope.

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 clear use context: pre-buy intelligence for Robinhood Chain, with a single call covering multiple checks. It also states the free-usage quota and paid path via guard_pricing. It lacks explicit when-not-to-use guidance or named alternatives, so it stops short of a 5.

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 provided, the description carries full behavioral burden and succeeds: it reveals the simulation mechanism, explicitly states 'no funds spent', lists the honeypot types detected, and discloses the free/paid quota. This gives an agent a strong safety and side-effect profile without needing additional metadata.

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?

Every sentence earns its place: mechanism, detection scope, verdict output, and quota/pricing. It is dense but well-organized, front-loading what the tool does and why it matters before practical constraints.

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 one simple parameter, no output schema, and a moderately complex behavior, the description is complete enough for correct selection and invocation. It covers chain identity, operation mechanism, safety profile, result format, and usage limits, so an agent has what it needs to call the tool correctly.

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 already provides 100% coverage of the single token parameter, including address format and chain. The description does not add much parameter-level detail beyond reinforcing that the token is on Robinhood Chain, so the schema-description-coverage 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?

States a specific verb and resource: a Robinhood Chain token honeypot check via on-chain buy+sell simulation. It clearly distinguishes itself from static-analysis tools by noting what it detects that they miss, and lists concrete verdicts (SAFE / HONEYPOT / CANT_BUY). The purpose is unmistakable even among siblings like check_mint and check_robinhood.

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?

Describes itself as a pre-trade safety check for autonomous agents trading Robinhood Chain crypto, which gives clear context for when to use it. It does not explicitly name sibling alternatives or provide when-not-to-use guidance, but the positioning against static analysis and the pre-trade framing provide strong usage direction.

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 it does a solid job: it discloses that track records are real, that the EV is under live validation rather than proven, that each signal includes a Guard safety check and execution hint, and that the tool is non-custodial. It could go further on data freshness or what 'live Guard safety check' entails, but the honesty caveat notably mitigates overclaiming.

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?

Three sentences, each earning its place: they identify the output, add the essential honesty caveat, and note the non-custodial nature. Information is front-loaded and the language is direct with no filler or redundant restatement of the tool name.

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 description covers what signals include and the risk framing, which is useful given no output schema. However, it omits any explanation of the limit parameter and doesn't describe the shape or format of the results beyond high-level content, leaving some implementation details unspecified for accurate invocation.

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 only one parameter, limit, with zero schema description coverage, and the description never mentions limit or its meaning. The agent is left to guess whether limit caps the number of signals or some other quantity, making this a clear gap that the description fails to fill.

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 returns recent buys from wallets with proven on-chain PnL, adding supplementary data like win-rate, SOL profit, a Guard safety check, and an execution hint. It names the resource and the nature of the output, though it doesn't use an explicit verb like 'list' or 'retrieve'—the intent is still clear.

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 this is for viewing copy-trading signals, but provides no explicit when-to-use guidance or comparison with sibling tools like track_record, verify_claim, or guard_pricing. There are no exclusions or alternative routing suggestions, leaving the agent to infer the appropriate 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 behavioral disclosure burden. It mentions that the payment is on-chain verified with instant redeem, and the phrasing implies the tool is informational (providing instructions rather than executing a payment). However, it does not explicitly state that calling the tool is side-effect-free or describe output behavior.

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?

A single sentence front-loads the core purpose—pricing and payment instructions—and the parenthetical adds high-value specifics without waste. Every element earns its place.

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 zero-parameter tool, the description is mostly adequate but omits what the returned instructions look like and when the agent should call it (e.g., before using a protected tool). No output schema exists, so a bit more context about the return value would be warranted.

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 zero parameters, so there is nothing for the description to clarify. Baseline for 0 params is 4.

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 states the tool provides pricing and x402-style payment instructions, specifying USDC on Solana with on-chain verified instant redeem. This clearly differentiates it from sibling tools about swaps, mint checks, and claims, though it lacks an explicit verb and leaves 'guard' undefined.

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 offers no guidance on when to call this tool versus alternatives, and no context about where it fits in an agent's workflow. There is no mention of prerequisites or exclusions.

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 behavioral disclosure burden. It usefully discloses that the tool is a live stream and that historical access is paid, but it does not mention whether the operation is read-only, what the response contains, or any rate limits or auth requirements.

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 with no fluff; the description is front-loaded with the tool's purpose. The cryptic 'K3 event stream' costs some clarity, but overall the wording is compact and efficient.

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 simple event-feed tool with no output schema and no annotations, the description gives the essential purpose and a pricing constraint. However, `since` remains ambiguous, the return shape is not described, and the 'K3' reference is unexplained, leaving notable gaps an agent may need to resolve.

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 documents `types` but leaves `since` undocumented. The description adds meaning to `since` by implying recency controls the free/paid boundary, but it does not specify units or expected format. It partially compensates for the 50% schema coverage but not fully.

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 identifies a live feed resource and names specific contents: fresh launches, graduations, whale big-buys. It conveys that this is an event stream rather than a validation or scoring tool, but it does not explicitly distinguish itself from sibling tools.

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 free 30-minute window and paid historical access imply when this tool is appropriate: use it for recent events without cost. However, it does not state when to avoid it or which sibling tools should be used instead, so the practical routing guidance is only implied.

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 behavioral burden. It discloses that only validated signals are reported, that the output is descriptive rather than predictive, and it gives concrete examples of the validation thresholds. This is strong behavioral context, though some terms like 'OR 0.35' are left unexplained.

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 compact and front-loaded with the most important constraint: it reports ONLY validated signals. The second sentence provides a crucial limitation about not being a price prediction. The parenthetical thresholds add specificity but are dense and could be easier to parse.

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 single-parameter tool with no output schema and no annotations, the description gives a reasonable sense of scope and limitations but omits return shape, interpretation, and error behavior. It is adequate for choosing the tool, but an agent still lacks detail on what the actual score output looks like.

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 has 0% description coverage and only says the parameter is a string named 'mint'. The description adds contextual meaning by connecting the mint to mcap, reserve, and graduation signals, but it never explicitly defines the expected input format or what a valid mint looks like. It partially compensates for the gap but does not fully document 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 clearly states the tool reports signals that passed locked-holdout validation for a given mint, which is specific and distinct from a generic scoring tool. It also clarifies it is a descriptive base-rate shift, not a price prediction, which helps differentiate it from prediction-like tools. However, it does not explicitly name or contrast a sibling tool, so it stops short of a 5.

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 this tool should be used when a validated, non-predictive base-rate score is needed, and it warns against treating it as a price prediction. It does not explicitly state when not to use it or point to alternatives such as check_mint or verify_claim, so usage guidance is mostly implicit.

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 the full burden of behavioral disclosure. It discloses that the underlying record is append-only, that many signals are still pending/unmeasured, and that the counts in the description are approximate and should be replaced by actual response values. This goes well beyond a simple 'returns a summary' statement.

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 dense sentence with no filler. The core idea 'track record summary' is front-loaded, and the parenthetical adds only essential caveats about scale and measured outcomes.

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 zero-parameter tool with no output schema, the description covers the purpose, the scale, the outcome-status split, and the important caveat to read the actual counts from the response. It could be slightly more explicit about the response structure, but nothing critical appears missing.

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 tool has zero parameters and schema coverage is 100%, so there are no parameter semantics for the description to clarify. The description appropriately focuses on what the returned summary means rather than on inputs.

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 identifies the resource (signal track record) and the kind of output (a machine-readable summary), including the archive size and outcome breakdown. It is distinguishable from siblings like recent_events or score_mint, though it lacks an explicit action verb and does not directly name an alternative.

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 the tool is used to get track-record statistics, but it gives no explicit guidance about when to use it versus sibling tools. There are no stated conditions, exclusions, or alternative tool names, so the agent must infer suitability from the name and content.

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 behavioral burden and does it reasonably well: it discloses the analytical nature of the tool, the specific verification dimensions considered, and the output shape ('flags + verdict'). It does not detail side effects, auth, or exact flag semantics, but the tool appears to be a read-oriented verification service, and the disclosure is meaningful beyond the tool name.

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 dense sentence with the core action front-loaded, followed by a compact checklist of quality dimensions and the return summary. Every phrase adds useful information, with no filler or repeated schema content.

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 4-parameter tool with no schema descriptions and no output schema, the description covers the tool's purpose and general output but leaves important invocation details unclear: how sample and win_rate are used, whether inputs are optional, and what the verdict/flags values look like. It 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?

Schema description coverage is 0%, so the description must compensate for the 4 undocumented parameters. It only implicitly hints at 'n' via 'small-n' and mentions 'claim', but 'sample' and 'win_rate' are never explained, and no parameter mapping or usage examples are provided. This is a clear gap for an agent trying to construct a valid invocation.

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 phrase, 'Adversarial red-team of a trading claim/backtest', and names the exact resource being acted on. It adds a concrete list of verification dimensions and reports that it returns flags plus a verdict, clearly distinguishing it from the crypto/swap/mint-focused sibling tools.

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 clear context for when the tool is appropriate: when a trading claim or backtest needs adversarial verification/red-teaming. It does not explicitly name alternatives or exclusion conditions, but the purpose is specific enough that an agent can infer the intended use.

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