cleartrace

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 excels at disclosing non-obvious behavior. It warns that volume columns fall into two different kinds that must not be summed, explains that overlay values can legitimately exceed total volume, and states that data refreshes weekly and is dated to Monday. These details prevent two serious misinterpretation errors.

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 purpose and then delivers dense, high-value caveats in a structured way. The volume-column warning and weekly-refresh note are essential and each sentence earns its place. The formatting with clear paragraph separation keeps the warnings scannable despite the length.

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 the most dangerous data semantics and lists the volume columns, which compensates partly for the missing output schema. However, it remains incomplete on parameter meaning, especially 'project', and does not describe the exact row shape or default filtering behavior. An agent would still need to infer some usage details.

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 parameters. It only hints at 'chain' through 'per chain', while 'project' and 'limit' are never explained. An agent would have to guess what values project accepts and whether limit controls row count in a meaningful way.

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 what the tool reports: which frontend, router, or interface originated on-chain DEX volume, aggregated per contract per chain. It gives a specific resource and scope, but it lacks an explicit action verb like 'get' or 'query' and does not explicitly distinguish itself from the similarly named sibling contract_attribution.

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 to use the tool: when you need to name the venue behind volume that block explorers leave anonymous. It also provides strong data-handling instructions, such as not summing partition and overlay columns and not presenting weekly data as today's volume. However, it never explicitly mentions alternatives or says when not to use this 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, the description carries the behavioral disclosure burden and does so well: it explains the null-label behavior, instructs the agent to report it as 'not identified', and cautions against guessing an operator. It does not cover auth, rate limits, or error behavior, but it discloses the most important data quirks.

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 core purpose and organized into three short paragraphs, each adding a distinct piece of guidance. It is slightly longer than strictly necessary, but the caveats about named contracts and null labels earn their 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 simple two-parameter lookup with no output schema, the description explains the high-level return content and important edge-case semantics. The main gap is chain parameter semantics and the meaning of the four attribution vectors, but an agent has enough context to select and invoke 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 description coverage is 0%, so the description needed to compensate for the undocumented address and chain parameters. It clarifies that the lookup targets one contract or wallet address and mentions per-chain volume, but it never explains the chain parameter's format, allowed values, or what omitting it means.

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 what the tool returns: ClearTrace's attribution data and label for a single contract or wallet address, including per-chain volume splits. It differentiates itself by emphasizing the anonymous-router use case, though it does not explicitly name 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 explicitly says the tool is most useful for anonymous routers and proxies, warns that named protocol contracts may return nothing, and explains that an empty result is not evidence the address is obscure. This gives the agent clear when-to-use and when-not-to-use 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 thoroughly: it discloses that the score is slippage-only, that high scores do not imply overall success, that reverts/MEV are separate, and that cross-chain blending can be misread. These are the behaviors an agent needs to avoid misreporting.

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 core purpose and scale, then uses two short paragraphs for caveats that each earn their place. No filler or repetition of schema fields.

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 two-parameter ranking tool with no output schema, this is complete: it explains what the score means, how to interpret it, which sibling covers adjacent metrics, and how to handle the chain parameter. An agent has enough to call and interpret it 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 schema provides no parameter descriptions (0% coverage), but the description adds real meaning to `chain`, explaining single-chain vs 'all' semantics and the blending pitfall. `limit` is left to its self-evident name and default, which is acceptable for such a generic parameter, though accepted chain values are not enumerated.

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 ('Rank') and resource ('DEXs and aggregators'), defines the exact metric (median slippage vs 1-minute VWAP) and the scale (0-100, higher better). It also distinguishes itself from sibling `revert_rates` by explicitly excluding reverts and MEV exposure, so an agent can tell tools apart.

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 says when not to use this as an overall best-execution ranking and directs the caller to ask `revert_rates` for reverts. It also gives concrete chain usage rules: pass a chain for single-chain, use 'all' for the blended rollup, and warns not to describe the blend as one chain's result.

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 transparency burden and does so well. It discloses per-vector confidence and its interpretation, warns that a fee recipient is indirect and never rated high, states that `estimated_volume_usd` is only an approximation and must not be quoted as settlement, and reveals that `deep=true` costs extra upstream credits. These are non-obvious behavioral details beyond the 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?

The description is front-loaded with the core purpose, then follows with dense but decision-relevant caveats about confidence, pricing, fee formatting, and `deep` cost. Every sentence earns its place; there is no filler or repetition.

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% schema parameter descriptions, this is a strong level of context. It explains the key result dimensions, evidence reliability, the approximate nature of estimated volume, exactness of fee integers, and the `deep` trade-off. It is not fully complete because it omits supported `chain` values and does not position this tool against the sibling attribution tools, but it covers everything essential for typical 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?

Schema description coverage is 0%, so the description must compensate. It adds real meaning to `deep` (credit cost and when to use), `price` (enables `estimated_volume_usd`), and transaction identification. However, the `chain` parameter is not explained at all, including what values are supported, even though the schema only provides a default of `ethereum`.

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 specifies the verb ('Classify'), the resource ('a single transaction'), and the detailed outputs: originating frontend or router, evidence, pools touched, fee recipients, and sandwich status. It is easy to tell what the tool does, but it does not explicitly contrast itself with the similarly named sibling tools `attribution` and `contract_attribution`, 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 description provides useful conditional guidance for the `deep` parameter ('leave it off unless a shallow classification came back unattributed') and qualifies when `price=true` matters. However, it never explicitly says when to choose this tool over the sibling attribution tools, leaving when-not-to-use and alternative selection 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, and it does exceptionally well: it discloses that L2 values exclude L1 data availability fees, explains that costs built from this are lower bounds, and warns against misleading cross-chain comparisons. This is exactly the kind of behavioral nuance an agent needs.

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 core purpose is front-loaded in one sentence, followed by a necessary caveat about L2 pricing semantics. The caveat is somewhat long but earns its place because it materially changes how the result should be interpreted. No wasted filler, though it could be tightened slightly.

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 the tool returns, its source, and its most important interpretive limitation. It does not enumerate supported chains or specify return units/format, but with zero parameters and a simple read-like use case, these are minor gaps. The caveat makes the description sufficiently complete for correct use.

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 no parameters and the schema is complete, so there is no parameter documentation burden. The description adds no parameter-specific meaning because none is needed; the baseline of 4 for zero-parameter tools 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?

The description states a specific verb-resource pair ('Current gas price on each supported chain') and names the data source ('from RPC'). It clearly distinguishes this as a live gas-price lookup tool and is not confused with the sibling tools like attribution or execution_benchmarks.

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 clearly signals it is for current gas prices and gives concrete guidance on how to interpret the value for L2s, warning that it is a lower-bound cost estimate. It does not explicitly name alternatives or when-not-to-use conditions, but the context is clear enough for an agent to select it appropriately.

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 does so well. It discloses that the key affects limits only, all data is public, there is no paid tier, and the key is returned once and cannot be shown again. It also warns against fabricating an email and instructs the agent to surface the key verbatim.

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 core fact is front-loaded: the key multiplies rate limits by 10x. The second paragraph contains necessary operating and safety instructions. Slight redundancy around 'public and identical' and 'no data gated' keeps it from a perfect score, but each sentence carries value.

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 and no annotations, it covers the essential behavior, prerequisites, consent handling, and one-time return behavior. It falls short only in not describing the response shape and in leaving the optional parameters unexplained.

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. It gives useful meaning for email: required, must come from the user, and must not be invented. However, it never explains name, company, or use_case, nor states that they are optional or how they are used, leaving most parameters underspecified.

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 the exact operation — 'Mint a free API key' — and states its concrete effect: multiplying rate limits by 10x. It also clarifies what the key does NOT do (limits only, no gated content), which helps distinguish it from the data-serving 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 primary use case is clear: raise rate limits with a free key. It also gives explicit consent guidance: 'Ask the user before submitting their email; do not invent an address.' It doesn't name alternatives, but no sibling serves this purpose, so the context is sufficient.

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, and it delivers: it explains the structural near-zero revert rates for non-router venues, the spam-sender inflation issue, the filtering behavior of comparable_only, and the row-level fields the agent should quote. This goes well beyond surface-level tool description.

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 a precise definition, then uses bolded warning text for the most critical caveat, and closes with concrete field-level guidance. Every sentence earns its place, and the structure makes the ranking warning impossible to miss.

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 is thorough for a read-only metrics tool: it covers the core metric, the comparability trap, the spam-inflation nuance, and the fields to quote. It does not describe the full return shape or ordering, but the provided field names and defaults give an agent enough context to invoke and interpret 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 description adds meaningful semantics for comparable_only, explaining its default behavior and why it matters. However, chain, project, and limit are left to their titles and defaults; with 0% schema description coverage, the description does not fully explain those parameters, though they are reasonably inferable.

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's purpose: measuring the share of a venue's routing transactions that fail on-chain, per chain. It also distinguishes the metric from slippage by framing reliability and price as different questions, so an agent understands exactly what this tool provides.

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 explicit usage rules: do not rank across execution models, use comparable_only for valid comparisons, prefer user_revert_rate_pct when present, and quote execution_model and revert_comparable flags. It even explains why batch-auction/intent venues would otherwise be misleadingly ranked, leaving little room for misuse.

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