loophole-tape

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

With no annotations provided, the description carries the behavioral disclosure burden. It adds useful context such as 'look-ahead-safe' and the specific data windows, plus the $0.02 cost. However, it does not explicitly state that the tool is read-only or describe how the stats are computed.

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 compact sentence that front-loads the core concept and cost, then uses a scannable list of data categories. Every phrase earns its place with no redundant wording.

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 lists the main data areas and is adequate for a simple one-parameter lookup. However, without an output schema or annotations, it does not explain return value structure, address format, or how this tool differs from sibling tools, so it is not fully 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%, and the only parameter, 'address', has no description beyond its title. The tool description never mentions the address parameter or its expected format, leaving the agent to infer it from the tool name.

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 identifies the resource as creator reputation and enumerates the data ranges it covers, making the tool's purpose clear. It lacks an explicit verb and does not differentiate it from sibling tools such as wallet_profile, so it is clear but not maximally precise.

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?

There is no guidance on when to use this tool versus alternatives. Sibling tools like wallet_profile, mint_risk_card, and recent_launches are not mentioned, and no when-not-to-use conditions are provided.

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 transparency burden. It names the metrics but does not disclose whether this is a read-only snapshot, what freshness or limitations apply, whether any auth or connection is needed, or what the output shape is. 'Free' adds minor context but not enough behavioral detail.

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?

One dense sentence with no wasted words; every listed metric adds meaningful signal. The leading 'Free:' is slightly off-mission but does not make the description bloated.

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-input market meter with no output schema, the description provides enough context by listing the metrics the agent can expect. It does not describe output formatting or update cadence, but those are minor gaps given the tool's simplicity.

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 100% schema coverage, so input semantics are trivially complete and the description does not need to compensate. This matches the baseline for a no-parameter tool.

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 market-wide pump.fun regime meter and enumerates its metrics (launch rate, mayhem share, buy/sell flow, fail share, migrations vs true graduations, rug flags). It lacks an explicit verb, but the 'meter' framing makes the purpose clear and distinguishes it from per-mint or per-wallet 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?

Usage is implied: use this to assess overall pump.fun market conditions rather than individual tokens or wallets. However, there is no explicit when-to-use guidance, exclusions, or mention of alternatives, so the agent must infer selection from the sibling tool names.

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?

Without annotations, the description carries the behavioral disclosure burden and does well: it reveals the graduation threshold, look-ahead-safe behavior, warm-launch labeling, rug/close flags, exit signals, and historical coverage. It does not mention auth, rate limits, or error behavior, but the disclosed behavior is substantial and specific.

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 yet efficient, front-loading price and scope before listing key risk-card contents. The single run-on sentence is slightly compressed, but every element earns its place and no filler is present.

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 or annotations, the description is reasonably complete: it explains cost, scope, key metrics, edge-case handling for older mints, and the presence of flags and exit signals. It does not describe exact JSON output structure, but the enumerated categories give an agent enough context to use the tool effectively.

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 0%, but the description compensates by defining 'mint' as a pump.fun mint and indicating the tool analyzes exactly one mint. This adds meaning beyond the bare string property in the schema, though it does not specify address format or validation expectations.

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 defines the tool as a live risk card for a single pump.fun mint and enumerates the risk dimensions it covers. It is distinguishable from sibling tools like wallet_profile or creator_reputation by being mint-scoped, though it does not explicitly name those 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?

The description implies when to use it: for one-off mint-level risk analysis, including older mints via the 'Historical record' note. However, it does not give explicit when-to-use versus alternatives guidance or exclusions, so usage context is present but not fully articulated.

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 takes on the full burden and does disclose the cost ($0.02), the classification scheme (true-graduation vs low/fake), and the exact threshold used (curve witnessed >= 84 SOL). It does not cover ordering, pagination, or rate limits, but for a read-only list tool the key behavioral traits are 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 a single compact sentence with no filler; the threshold and classification are packed efficiently. The '$0.02' prefix is off-topic from purpose but still useful and does not bloat the definition.

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, no annotations, and the description does not explain what fields are returned, what 'curve' or 'close pools' mean, or how limit/window_s shape results. An agent can call it with defaults, but cannot confidently reason about output or parameter effects.

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%, and the description does not mention 'limit' or 'window_s' at all. The parameter names are mildly self-explanatory, but no meaning or constraints are added to compensate for the missing schema descriptions.

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?

Although it lacks an explicit verb, the description identifies the resource ('migrations') and the distinguishing output ('labelled true-graduation ... vs low/fake close pools') with a concrete threshold (>= 84 SOL). This separates it from siblings recent_launches and recent_rugs by domain and classification.

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?

No explicit when/when-not guidance or alternative tools are named. The phrase 'recent migrations labelled true-graduation ... vs low/fake close pools' implies the tool is appropriate when the agent needs graduation/migration classifications rather than launches or rugs, but this is left to 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does add useful behavior: the default time window (last hour), mayhem exclusion, and the specific compact labels returned. However, it does not disclose read-only behavior, sorting, pagination, error cases, or the meaning of '$0.01' (possibly a cost per call), leaving notable gaps.

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 dense sentence packs in cost, resource, default window, filtering, and output fields with no filler. The leading '$0.01' is cryptic but not wasteful, and the colon-separated label list is efficient. Slightly better ordering might put the resource first, but the description remains highly concise.

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 list-like tool with no output schema and no annotations, the description does state what kind of data is returned and highlights two important defaults. Yet it omits parameter semantics for limit, min_rs, and only_alive; does not specify return format or ordering; and does not differentiate among sibling tools. It is adequate for a simple call but incomplete for reliable agent selection and parameter tuning.

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 explain all five parameters. It only touches max_age_s ('default last hour') and exclude_mayhem ('mayhem excluded'), both of which already have clear defaults in the schema. It gives no explanation for limit, min_rs, or only_alive, and the output label list does not clarify these ambiguous parameter names.

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 ('recent pump.fun launches') and the tool's output nature ('with compact labels: creator prior, dev buy, bundle/insider share, unique buyers, rug flags'). It also sets it apart from sibling tools like recent_graduations and recent_rugs by specifying pump.fun launches and the mayhem exclusion, though it does not explicitly name those 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?

The description implies the tool is for browsing recent launches, especially within the last hour with mayhem excluded. However, it offers no explicit guidance on when to choose this tool over siblings, no exclusions, and no alternative tool references. An agent cannot tell from the text whether to prefer recent_launches over recent_graduations or recent_rugs for a particular query.

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 it does disclose content-level behavior: returned flags come with a fixed taxonomy of six mechanism labels, which tells the agent what categories exist and hints at detection logic. It also embeds a '$0.02' cost hint. It does not describe output shape, ordering, or read-only status, but the label taxonomy is genuine behavioral context beyond what the tool name conveys.

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 compact sentence, and the mechanism-label enumeration is high-value information that earns its place. However, the leading '$0.02' is unexplained and could be misread as a parameter, cost, or version token — it adds noise without earning its position.

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 annotations, no output schema, and 0% parameter coverage, the description omits how rug events relate to the recent_graduations/recent_launches siblings and what the response looks like. The label taxonomy is genuinely helpful, but an agent would still be guessing about result shape, default behavior, and when this tool is the right choice.

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 undocumented limit and window_s parameters, but it never mentions either. 'Recent' loosely implies a time window and the schema defaults (50, 3600) carry the actual meaning, yet the description itself adds zero parameter-level 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?

States a specific resource — recent rug/close flags — and enumerates the six mechanism labels returned (creator_sold, bundle_dumped, curve_drained, pool_drained, curve_closed_low, migrate_below_grad), giving an agent a concrete picture of the result set. It is distinguishable from sibling tools like recent_launches and recent_graduations via the 'rug' framing, though it never names a sibling explicitly. The '$0.02' prefix is cryptic noise but does not obscure the core purpose.

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?

No guidance on when to use this tool versus the sibling recent_graduations or recent_launches; an agent must infer that 'rug' events are a distinct post-launch category. There are no prerequisites, no exclusions, and no mention of alternative tools for graduated or launched tokens.

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 burden. It discloses that the tool is free, delayed, and constrained to one mint aged >= 300 seconds. However, it does not explicitly state side effects, permissions, or whether any state changes occur, leaving some behavioral ambiguity.

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 efficient sentence, front-loading the key value proposition ('Free') and the core purpose. There is no redundant wording.

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 sample tool, the description is sufficient: it explains what the output is for, the free nature, the delay, and the relationship to the paid sibling. No output schema or additional context is strictly necessary.

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, so the baseline is 4. The description adds relevant contextual detail about the sample criteria (one mint, age threshold, delayed), even though it is not describing a 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 that this tool provides a free full risk-card sample for one mint and explicitly frames it as a way to preview the paid mint_risk_card shape. This distinguishes it from the sibling mint_risk_card tool.

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 gives clear context for when to use the tool: when you want to preview the paid mint_risk_card output without paying. It does not explicitly state when NOT to use it or compare with other siblings, but the intent is clear enough.

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 is the only source of behavioral context. It does disclose that the tool reports leaderboard-derived wallet classes, holdings, and conditional creator stats, and the '$0.02' prefix hints at a cost, but it never explicitly states that the operation is read-only or describes error/freshness behavior. The name 'profile' and the passive data language make a read-only lookup the reasonable inference.

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 one compact sentence that packs in the core output categories and the classification labels without redundancy. The leading '$0.02:' is slightly cryptic and competes with the main purpose for attention, but the rest is efficiently structured and front-loaded with the key result.

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 lookup with no output schema, the description gives a reasonable high-level picture of the response: wallet class, holdings, and creator stats. It does not cover the input format, exact return shape, or relationship to sibling tools, but the tool is simple enough that an agent can likely invoke it correctly with the address parameter alone.

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 'address' parameter. It only does so implicitly through 'wallet class' and 'wallet profile', making it clear that address refers to a wallet identifier, but it does not specify format, chain, or examples. For a single self-descriptive parameter this is adequate but minimal.

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 identifies a specific resource (wallet profile) and the concrete output: wallet class (insider/sniper/skilled/crowd), holdings among recent mints, and creator stats. It does not use an explicit verb like 'retrieve' or 'returns', and it does not name a sibling tool, so it stops short of full differentiation.

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 single required 'address' parameter and the phrase 'wallet class from our rolling PnL leaderboard' imply the tool is for analyzing a wallet address, which is enough to infer a basic use case. However, the description gives no explicit when-to-use guidance, exclusions, or comparisons to siblings such as creator_reputation or market_regime.

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