Still Roach token check

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the bar is lower; the description still adds ordering (oldest first, not newest), the pagination contract, and the plan/cost requirement. It does not disclose rate limits or what an empty/expired cursor returns.

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 the resource and ordering front-loaded, then the paging and auth facts. Every clause carries information; the trailing 'Free.' is terse but still adds cost context.

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?

With no output schema, the description does at least name the alert type and version so the agent knows what comes back, and it covers paging and access requirements. It omits the shape of an alert object and what limit controls, which is a modest remaining gap.

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 50%: cursor is documented inline, limit is not. The description reinforces cursor semantics ('pass next_cursor back to page') but says nothing about limit's default of 50 or its 200 ceiling, leaving the undocumented half unaddressed.

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 ('Alerts ... across your watched coins and wallets'), plus the schema identifier bagwatch.alert.v1 and ordering (oldest first). That is enough to separate it from the token-check and report siblings, though it never explicitly contrasts with watch_report.

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?

Gives concrete operational context: pass next_cursor to page, omit for the start, and a Watch plan key is required. It stops short of naming when to prefer this over watch_report or the token-check siblings, so there is no explicit alternative routing.

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?

Annotations cover read-only/no-destruct safely, and the description adds genuinely non-obvious behaviour: credit consumption, cache-reuse for free, and an API key prerequisite. It also flags the output is 'not financial advice', which matters for downstream use. No contradiction with idempotentHint=false, though the schema-level idempotency_key behaviour is left for the schema to explain.

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 paragraph, front-loaded with the verdict/output inventory, then cost, then auth, then disclaimer. No wasted clauses; the parenthetical enum list (never sold / sold / churn / fresh) earns its space by pre-announcing output values.

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?

With no output schema, the description must convey return content, and it does list the major sections (verdict, shell/rug, holder behaviour, bundles, callers). It stops short of describing the shape or ordering of that payload, but an agent knows what it will get.

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 mint, idempotency_key, and max_data_age_seconds are already documented. The description's mention of max_data_age_seconds caching reinforces the schema rather than adding new semantics. Baseline 3 is appropriate when the schema carries the parameter burden.

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+resource ('Full Bag Check') and enumerates the concrete outputs: verdict with reasons, shell/rug checks, top-holder behaviour categories, bundles, callers. The word 'Full' implicitly separates it from check_solana_token_basic and check_solana_token_lite, though neither sibling is named outright.

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 real context — API key required, 1 credit for a fresh scan, 0 if a cached scan is newer than max_data_age_seconds — but nothing states when to pick this over the lite or basic siblings. An agent can infer 'full/deep analysis' but must guess at the cost-tier tradeoff that actually separates the three 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?

Annotations already cover read-only, idempotent, non-destructive and open-world. The description adds genuinely new behavioral context: the tool is free, needs no key, serves only cached data from the last hour, and degrades to status=not_cached instead of erroring. That caching/failure behavior is exactly the kind of thing an agent cannot get from the annotations or schema.

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 short sentences, well front-loaded: price tier first, then the payload, then the failure mode and auth note. No filler. Marginally terse on jargon ('shell check') but structurally tight.

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?

With no output schema, the description carries the burden of explaining returns; it names the payload sections but not their structure or the possible verdict values, and 'shell check' and 'token facts' go undefined. Combined with its silence on sibling selection, it is adequate but leaves clear gaps for a tool whose output is the whole point.

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?

One required parameter with 100% schema description coverage ('Solana token mint address (base58)'), plus a base58 pattern constraint. The description adds nothing beyond the schema, so the baseline of 3 applies.

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 concretely what comes back for a Solana mint: verdict, token facts, shell check, holder summary, plus the not_cached fallback. That is a specific verb+resource with a clear scope. It does not name the sibling it differs from (check_solana_token_lite, analyze_solana_token), so an agent must infer the distinction from the word 'Free' and the one-hour cache rule.

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' label and the 'if it was scanned in the last hour' condition imply the intended use case and one exclusion (cache miss returns status=not_cached). But the description never says to use analyze_solana_token for a fresh/full scan or check_solana_token_lite for an intermediate tier, leaving the sibling choice 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?

Annotations already declare readOnly, non-destructive and open-world, so the safety profile is covered; the description adds what annotations cannot: an API key is required, fresh reads are metered (3/day free then 1 credit), and cached reads are free. It does not disclose failure behavior for an invalid or unknown mint, nor latency, which is the main remaining gap.

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 front-loaded sentence pairs the operation with its return fields, followed by a short cost/auth sentence; nothing is padding. The 'bagcheck.lite.v1' version tag and 'Not financial advice' boilerplate are mildly wasteful but defensible as provenance and disclaimer.

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?

With no output schema, the description correctly carries the return-field inventory, plus auth and billing constraints an agent needs before calling. What is missing is minor for a lite read: error/edge behavior for a bad or unknown mint, and whether a fresh read is forced when max_data_age_seconds=0.

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%, so baseline is 3; the description earns the extra point by explaining that cached reads are free, which is the practical reason an agent would raise max_data_age_seconds toward its 600s default or 3600s ceiling. It does not restate the base58 mint format, but the schema handles that 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?

States a specific verb and resource ('Lite read' of a Solana token) and enumerates exactly what the payload contains: verdict, top-10 holder %, dev stake, launch buy / dev sold, KOL wallets holding, basic flags. It does not explicitly distinguish itself from sibling check_solana_token_basic or analyze_solana_token, so the agent must infer that 'lite' means a shallower, cheaper tier.

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 'Lite' label and the credit pricing imply this is the cheap first-pass screening call, but there is no explicit when-to-use or when-to-escalate guidance relative to check_solana_token_basic or analyze_solana_token. The quota sentence ('Free for 3 fresh reads per day, then 1 credit') hints at a cost-tier decision but never states the alternative.

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?

Annotations already cover readOnly/idempotent/non-destructive, but the description adds meaningful context beyond them: 'Free, no key' discloses the auth model, 'Solana only, no cards' scopes payment rails, and 'never moves funds' plus 'Ask the user before any payment' clarifies that this is informational only despite discussing payments. Return-format/pagination detail is absent, but not critical for a zero-param pricing read.

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?

It is a single front-loaded sentence with the key facts (free, no key, what it returns) up front, and the safety note trailing. It is dense with pricing figures that arguably belong in the response payload rather than the definition, which keeps it just short of a 5.

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?

With no output schema, the description must convey what comes back, and it does so concretely (pack prices, accepted currencies, x402 lite/full and cached rates). Annotations plus 'never moves funds' cover the safety profile. The only gap is not describing the response shape or units for the cached/fresh distinction.

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?

Zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly implies no input is needed by emphasizing 'Free, no key'.

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 makes clear this returns credit pack pricing (100 credits for 0.05 SOL / 5 USDC / $STILL) plus x402 per-call rates, and that it requires no key. It is distinguishable from siblings like get_quota (balance) and the check_* tools (token safety), though the purpose is conveyed through content rather than an explicit verb like 'Returns pricing for...'.

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 rather than stated: an agent infers it should call this when a user asks about buying credits or per-call costs. The one explicit guideline is 'Ask the user before any payment,' but no alternative is named (e.g., get_quota for remaining balance), so routing between siblings 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?

Annotations already declare this as a read-only, idempotent, non-destructive call, so the description doesn't need to re-litigate safety. It does add real context beyond the annotations: the 30-day cycle, that pool_resets_at is the next refill, the per-key daily cap, the tier origin of credits, and that the call is free.

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, front-loaded with the core answer (credits left) and followed by the supporting details. The parenthetical and the trailing 'Free.' are slightly telegraphic but nothing is wasted.

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?

With no parameters and no output schema, the description carries the return-value burden, and it covers the main fields an agent needs (remaining credits, reset time, tier source, daily cap, zero cost). It stops short of stating format/units or whether caps are per-key vs per-account in a way an agent could act on without a sample response.

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?

There are zero parameters, so the baseline is 4. The description goes further by naming return fields (pool_resets_at, tier, daily cap), which is the only place that information exists given there is no output schema.

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 (remaining API credits) plus the extra data returned: reset timestamp, credit source/tier, and per-key daily cap. It's clear what the call yields, though it never explicitly contrasts itself with the sibling get_credit_packs, so differentiation is only implicit.

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 (check how many credits you have left before spending them), and 'Free' signals it costs nothing to call. There is no explicit when-to-use/when-not or pointer to get_credit_packs for topping up, so the agent must infer the boundary.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is fully covered. The description adds genuinely useful context beyond that — API-key/Watch-plan auth requirement, free pricing, and the versioned payload tag — but stays silent on snapshot recency, alert window, and rate limits.

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 short sentences with the payload scope front-loaded and the gating requirement immediately after; nothing is padded. The one-word 'Free.' fragment is efficient but slightly clipped for a standalone sentence.

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?

With one parameter, rich annotations and no output schema, the essentials are present, and naming 'snapshot and recent alerts' gives a rough shape of the return. What's missing is the alert window/recency semantics and any sense of response size or pagination — things an agent should know before calling.

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% with a single required 'mint' documented as a base58 Solana token mint address, so the schema carries the full load. The description adds no meaning about the mint beyond what the pattern and property description already say, which is the baseline case.

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 retrieval: a current Bag Watch snapshot plus recent alerts for one coin, tagged with the response version (bagwatch.report.v1). The resource and scope are clear, though 'recent alerts' invites confusion with the sibling alerts_since, which the description never addresses.

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 supplies a precondition ('Requires a key for a wallet with an active Watch plan') and a cost note ('Free'), which implicitly frames eligibility. However, it never says when to choose this over alerts_since or the other check_* siblings, so the agent must infer routing from names alone.

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