Checkpoint402

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely new behavioral context: a paid x402 model at $0.03 USDC per successful call, with the explicit assurance that errors are not charged. That is important pre-invocation knowledge an agent cannot get from the annotations. It does not cover latency, rate limits, or supported failure modes, keeping it short of a 5.

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 tight sentences with no filler; the pricing constraint is front-loaded and the capability list is compact. Slightly dense in the second sentence, but every clause maps to a real output element.

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 return-value burden and does so well, enumerating the decoded fields an agent receives. Combined with the disclosed payment model and the read-only annotation, an agent has everything needed to decide and call 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?

Schema description coverage is 100%: the hash format and the base/ethereum enum with its default are fully documented in the schema. The description adds no parameter-level detail beyond that, so the baseline 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 a specific verb (explains) and resource (any Base or Ethereum transaction) and then enumerates exactly what the output contains: sender/recipient, token/NFT movements, function called, status and fee. An agent can distinguish this from all listed siblings, which cover yields, services, token safety, sanctions and filings.

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 (supply a transaction hash to get a plain-English explanation), but there is no explicit when-to-use statement or routing advice. Since the sibling set contains no overlapping transaction-decoding tool, the absence of alternatives is less costly, but the description still leaves the trigger condition 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 only declare readOnlyHint and openWorldHint; the description adds material behavioral facts the annotations do not cover — an x402 payment of $0.05 USDC per successful call, and explicitly that errors are not charged. It also discloses the risk-tier heuristics (outlier APY, thin TVL, reward-heavy, IL exposure). Missing only rate limits 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?

Four dense sentences with no filler, though the lead position is given to the pricing notice rather than the tool's core purpose, which is arguably the more important orientation for an agent. Everything after that is information-bearing.

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?

No output schema exists, so the description carries more burden, and it covers cost, filter axes, risk semantics and provenance. It stops short of describing the shape of a returned pool row (APY field, TVL, tier label) or data freshness, which for a paid query tool would close the 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 description coverage is 100%, so the baseline is 3, and the description earns above it by explaining what the risk tiers actually mean (outlier APY, thin TVL, reward-heavy, IL exposure) — semantics the enum in the schema does not convey. It also confirms the filter axes match the parameters.

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 (find top DeFi yields) with concrete scope: 16k+ pools, filtered by asset, chain, minimum TVL and risk. No sibling tool overlaps this domain, so differentiation is unnecessary, and the data source (DefiLlama) pins down exactly what is returned.

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 establishes context (finding yields for a given asset/chain/risk) but never says when to reach for this tool versus another, nor any preconditions or exclusions. Usage is implied rather than stated, which is the definition of a 3.

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 establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context by disclosing cost ('Free') and describing the shape of what comes back, including payment mechanics — useful behavioral detail beyond the annotations, though it omits any rate-limit or auth notes.

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 most decision-relevant fact ('Free.') front-loaded, followed by the content inventory. No filler or 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 no-param, read-only catalog tool with no output schema, the description usefully enumerates the returned fields and states the cost, which is exactly the gap the absent output schema leaves. Complete enough to call confidently; only the follow-up relationship to the data tools is left implicit.

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 by the rubric baseline is 4. There is nothing parameter-level the description could usefully add, and it does not clutter itself pretending otherwise.

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 gives a specific verb and resource ('Lists every Checkpoint402 data service') and enumerates the returned fields (price, inputs, example output link, payment mechanics). It is unmistakably distinct from siblings like explain_transaction or ofac_sanctions_screen, though it never names an alternative to route against.

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?

Leading with 'Free.' implies this is the no-cost discovery entry point before paid calls, but the description never states when to call it versus the sibling tools or what to do with the results. Usage is implied rather than instructed.

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/openWorld, and the description adds value beyond them: the $0.10 USDC x402 charge per successful call, the explicit no-charge-on-error rule, and the upstream sources (GeckoTerminal + GoPlus). It does not disclose freshness/latency of the 'newly launched' window, which is the main remaining behavioral 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?

Two dense sentences with no filler; pricing is front-loaded, which is defensible for a pay-per-call tool but pushes the actual purpose into the second sentence instead of leading with it.

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 describe the return shape (pools plus score and red flags) and the cost model, which is what an agent needs. It stops short of clarifying how recent the launches are or result ordering.

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 chain, limit and minScore including enums, ranges and defaults. The description only echoes the chain set and the 0-100 score range, adding no syntax or format detail beyond the 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 (newly launched token pools) across named chains, plus exactly what each result carries (0-100 safety score and named red flags). No sibling tool in the set overlaps with a new-token feed, so an agent can select this unambiguously.

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 conveys the domain (freshly launched pools for safety screening) and the billing condition, but never says when to prefer this over alternatives or what the exclusions are. Usage is implied by the resource rather than stated.

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?

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the x402 pricing model ($0.05 USDC), that errors are not charged, the twice-daily refresh cadence, and that the extended-remarks file (where most sanctioned crypto addresses live) is included. These are exactly the operational facts an agent needs before paying for a call.

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 with the cost model front-loaded, followed by coverage and freshness details. No filler, no repetition of the title, and every clause carries decision-relevant information.

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, and it does not describe what a screening result contains (match/no-match, score, matched entry). Coverage, pricing, and freshness are all well handled, so the single remaining gap is the response shape.

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 name, limit, address, and threshold. The description usefully characterizes the name matching as 'fuzzy, alias-aware', which contextualizes the threshold parameter, but adds nothing for limit or address formats beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: screens a person/company name and/or crypto wallet address against the US Treasury OFAC SDN list. It also differentiates itself from every sibling (explain_transaction, find_defi_yields, list_services, etc.), none of which perform sanctions screening.

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 'and/or' phrasing implies at least one of name/address must be supplied, which is a usage hint, but the description never states when to use this tool versus alternatives or when it is inappropriate. Given the siblings are unrelated domains, the omission is minor but the guidance remains implicit 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?

Annotations cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower, and the description still adds real operational context: per-call pricing via x402 with no charge on errors, and near-real-time availability ('within minutes of filing'). It does not mention rate limits, freshness guarantees, or error/empty-result behavior, so it is good 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?

A single dense sentence front-loaded with the pricing constraint, then resource, scope, and enrichment. Every clause carries information, though the run-on structure makes it slightly harder to scan than a split sentence would be.

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 the work of explaining what comes back (translated item codes, high-impact flags, AI summaries of filing text), which is the key missing piece for this tool. Pagination and limit semantics live in the schema, so the only gap is edge-case behavior such as empty results.

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 the baseline is 3, but the description adds meaning the schema lacks: that omitting ticker yields the market-wide latest feed and that the high-impact flag maps to concrete event types (earnings, CEO changes, M&A, bankruptcy, cyber incidents). This clarifies what highImpactOnly and the ticker omission actually select.

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 (latest SEC 8-K filings) with explicit scope variants (market-wide within minutes, or a single ticker) and names the enrichment applied (item code translation, high-impact flags, AI summaries). An agent knows exactly what this returns without opening the schema, and the sibling tools are unrelated domains so no further disambiguation is needed.

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 choosing between modes: market-wide versus one ticker, and when high-impact-only is appropriate ('high-impact events flagged (earnings, CEO changes, M&A, bankruptcy, cyber incidents)'). It does not state exclusions or prerequisites beyond the pricing note, so it falls short of a full when/when-not statement.

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 readOnly/openWorld, but the description adds real behavioral context: it is paid ($0.02 USDC per successful call, not charged on errors) and names its data sources (GoPlus + DexScreener). It does not discuss latency or rate limits, but the pay-per-call nuance is valuable beyond annotations.

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 pricing note and the purpose are front-loaded, and the return contents are enumerated compactly. Slightly dense in the single long sentence but every element carries useful information.

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?

No output schema exists, yet the description fully enumerates the return shape (score, verdict, red flags with examples, good signs, plain-English summary), which is exactly what the agent needs to interpret results and complete the picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents the address format and the chain enum with a default. The description reinforces which chains are supported but adds no format or syntax details beyond what the schema provides; baseline 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 a specific verb and resource: 'Checks any token on Base, Ethereum or BSC' and returns a safety score, verdict, red flags and summary. The 'Is this token a scam?' framing plus the enumerated chains make it immediately distinguishable from siblings like new_token_safety_feed.

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 scam-question framing implies when to use it, but there is no explicit guidance on when to use it versus new_token_safety_feed or other siblings. No prerequisites or exclusions are stated beyond the implicit chain scope.

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