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 full burden. It discloses that the tool measures a rate-of-change and returns signals, and it notes it is leading. However, it does not explicitly state it is a read-only analysis with no side effects, nor does it mention data sources, latency, or limitations. The core behavior is transparent, but additional behavioral details are missing. No contradictions with annotations since none exist.

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 moderately long but well-structured. It front-loads the core concept, explains the signals, and adds the leading-indicator context. Every sentence contributes useful information. It could be slightly tighter by removing the chain mention (already in schema), but overall it is efficient 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 there is no output schema, the description compensates by enumerating all possible signal values (SELL_EXHAUSTION, BUY_CLIMAX, ACCELERATION_UP, ACCELERATION_DOWN, STEADY). It also clarifies the leading nature. The single parameter is well-documented. The main gap is the lack of error conditions or unsupported token formats, but for a simple signal tool, the description is nearly complete. A 4 is justified.

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 documents the token parameter as '0x-address or base58 mint' with 100% coverage. The description mentions 'RH-chain (0x) or Solana (base58)' which essentially repeats the schema's description without adding new semantic depth. It doesn't clarify formatting, validation, or edge cases. Baseline 3 is appropriate when the schema covers the parameter 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 states the tool measures pressure rate-of-change (2nd derivative) and explicitly lists the signal types (SELL_EXHAUSTION, BUY_CLIMAX, etc.). It differentiates from siblings by claiming 'a signal no other tool computes,' giving a specific verb and resource. This makes it easy for an agent to understand what it does and how it differs.

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 for detecting acceleration/exhaustion and is a leading indicator, but it does not explicitly state when to use it versus alternatives like flow_inflection or timing_signal. It gives context (leading, before price reversal) but no exclusions or direct comparison to siblings. Thus, usage guidance is implied rather than explicit.

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 of behavioral disclosure. It discloses what the tool returns: exit_slippage_pct, max exit under 5%/10% slippage, liquidity, thin-volume warning, and verdict categories. It also communicates the nontrivial behavior that a token can be sellable yet still trap a user due to thin liquidity, which adds meaningful context beyond the 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 compact and every sentence serves a purpose: it frames the problem, clarifies what it is not, lists concrete outputs, gives usage timing, and states supported chains. The example 'thin pool: exiting $5k costs 20%+' is illustrative rather than 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 having no output schema, the description compensates by enumerating the key return fields and verdict values, explaining the intended pre-entry use case, and specifying supported address formats. This is sufficient for an agent to understand what the tool does, when to call it, and what to expect back.

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 token and size_usd. The description reinforces that size matters and ties it to slippage, but it does not add meaningful new parameter-level detail beyond what the schema provides. 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 identifies the tool as a size-aware exit-liquidity check that returns slippage estimates and verdicts, not merely a binary 'sellable' check. It distinguishes itself from simple checks by emphasizing position-size dependency, which separates it from sibling tools like check_mint and score_mint.

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 states when to call the tool: 'Call BEFORE entering to size the position to your real exit capacity.' This gives clear timing guidance. It does not name specific alternatives or explicitly say when not to use it, but the context is strong enough for an agent to understand the intended workflow.

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. It explicitly describes the return values (flow_state with five distinct states) and the input format (Robinhood-chain 0x or Solana base58). It implies a read-only query by framing the tool as a signal detector, but it doesn't explicitly state there are no side effects. Given the context, this is adequate.

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 moderately verbose but front-loaded with the core purpose and includes a list of possible return states. It is structured logically, with the usage tip at the end. It earns a high score for efficiency, though it could be tightened.

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, read-only signal tool with no output schema, the description is fairly complete. It explains the return states, the input format, and when to use it. It lacks explicit error handling or edge-case details, but these are minor given the simplicity of the tool.

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 'token' parameter, and the description's mention of formats (Robinhood-chain 0x or Solana base58) exactly matches the schema description, adding no new information. The description does not elaborate beyond what the schema already specifies, so it stays at the baseline for full coverage.

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 detects a temporal money-flow direction flip for a token, enumerates the specific flow_state values, and explicitly contrasts it with a static snapshot. This distinguishes it from siblings like check_mint or score_mint, which serve different purposes.

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 provides a clear usage context: 'Call before an entry to avoid buying a top a static footprint would miss.' This implies when to use it and suggests it complements (rather than replaces) static analysis, but it doesn't name specific alternative tools or state when not to use it.

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 full burden. It discloses the output fields (rank, is_canonical, real contract, famous-name flag, impersonation_risk) and supported chains (Robinhood/Solana). It does not explicitly state that the operation is read-only, though 'check' implies it, nor does it mention error cases or rate limits. Adequate but not exhaustive.

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 that front-load the purpose with a question, then list outputs and input format. No fluff, but it is a bit dense. The structure is logical and efficient, earning a 4 rather than 5 due to slight redundancy in repeating the input format from 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 tool with no output schema, the description lists all return fields, which is essential for an agent to interpret results. It also explains the input format and the purpose. It does not cover edge cases like invalid addresses or token-not-found scenarios, but for a check tool this is acceptable.

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 parameter is fully documented in the schema. The description repeats the input format (0x or base58) but adds no new semantics beyond that. Since the schema already does the heavy lifting, 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 purpose: verifying whether a token contract is the real one for its ticker or a copycat, using a question and scam context. It identifies the resource (token contract) and the action (check). It is specific and distinguishes from generic 'check' tools by focusing on impersonation, though it does not explicitly name sibling alternatives.

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 a clear scenario: when an agent is told to buy a ticker, it needs the legit contract, implying this tool should be used to verify authenticity. It also lists the output fields that aid decision-making. However, it does not explicitly mention when not to use it or name alternatives like check_mint, leaving some inference.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently describes the output categories (ENTER, WAIT_PULLBACK, TAKE_PROFIT, EXIT_NOW, WATCH) and the entry_quality score (0-100), and clarifies the input format (0x for RH-chain, base58 for Solana). It does not explicitly state that the operation is read-only, but the nature of an analysis tool makes that evident. It omits error behavior or potential latency, but the core behavior is well disclosed.

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 well-structured and front-loaded with the core question ('Is NOW a good entry, a wait, or an exit point?') before elaborating on the three axes and output signal values. Every sentence adds relevant context (axes, signal categories, quality score, input formats). It is slightly verbose but efficient given the complexity it covers, and it avoids redundancy.

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, analysis-only tool with no output schema, the description provides a comprehensive picture: it explains the logic behind the signal (combining money flow, price extension, momentum), lists all possible signal values, and describes the entry_quality score. It does not mention edge cases (e.g., invalid token, unsupported chain) or provide interpretation details for the score, but the core usage and output are sufficiently covered.

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 description for the only parameter (token) is already explicit: '0x-address or base58 mint'. The description repeats this same information ('RH-chain (0x) or Solana (base58)') without adding new semantic detail, such as examples, validation rules, or interpretation guidance. With 100% schema coverage, the baseline is 3, and the description does not exceed it.

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 purpose: to assess whether NOW is a good entry, wait, or exit point for a token. It names the specific resource (token) and the action (timing analysis), and explicitly differentiates itself from siblings by claiming it fuses three axes 'no other tool combines' (money-flow direction, price extension, momentum). This distinguishes it from flow_inflection and exit_check.

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 this tool (when a combined timing signal is needed) by stating it fuses three axes that no other tool combines. However, it does not explicitly name alternative tools or give conditional guidance like 'use flow_inflection for flow-only analysis' or 'use exit_check for a single exit signal'. The guidance is implied but not stated as direct usage rules.

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 mostly does: it discloses append-only behavior, that outcomes are paper (simulated), that |return|>500% is excluded as a glitch, and explicitly warns it is 'descriptive, not a profit promise'. That is meaningful context an agent needs for interpreting trustworthiness. It does not discuss refresh cadence or data freshness.

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, front-loaded with the identity of the resource before the structural breakdown and the caveats. The signal-type enumeration adds concrete value rather than filler, though the long parenthetical list is slightly dense.

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?

There is no output schema, so the description must convey return shape, and it does by describing by_signal_type and calibration_slices. For a zero-parameter read tool the picture is nearly complete; only the update cadence and whether the sample is live or historical is left unstated.

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 takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The schema is an empty object with no fields to document.

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 names a specific resource (an append-only signal track record) and enumerates its contents: per-signal sample size, 1h/6h/24h returns, directional accuracy, and calibration_slices. An agent knows exactly what payload it receives. It does not, however, contrast itself with sibling signal tools such as timing_signal or copy_signals.

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?

Usage is only implied by the phrase 'Lets an agent decide how much to trust each signal type', which suggests consulting it before acting on signals. There is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling signal tools.

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.