apex-arc

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

The description discloses that quotes are live, measured per source chain, refreshed every 10 minutes, and includes the X1 bridge minimum of 11 USDC. It also notes a CCTP mention. With no annotations provided, the description carries the burden and does a good job of setting expectations about data freshness and constraints, though it doesn't detail the exact output format or failure modes.

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, information-dense sentence that front-loads the core purpose (USDC onto Arc) and then adds specifics. It's slightly long but every clause adds value: source chains, LI.FI, what's measured, refresh rate, X1 minimum, and CCTP note. The usage guidance at the end is a bit tacked on but not redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with no output schema, the description covers the key context: what it does, how it works (LI.FI), what data it provides (cost, time, what arrives), freshness (10 minutes), and a usage scenario. It doesn't explain how to interpret the quote or what 'claim at the faucet' entails, but those are likely covered by sibling tools (arc_faucet_claim).

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 description doesn't need to explain parameter semantics. The baseline for 0 params is 4, and the description adds context about what the tool measures and returns, which is sufficient.

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

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

The description clearly states the tool's purpose: it provides live USDC bridge quotes to Arc (eip155:5042) from multiple source chains via LI.FI, including cost, time, and what arrives. It also mentions the X1 path and CCTP note, distinguishing it from generic bridge tools like bridge_assets or get_onto_x1.

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 'Use it to bring an agent or a person to Arc from wherever they are, then claim at the faucet,' giving clear context for when to use it. It doesn't explicitly state when not to use it or name alternatives, but the sibling list includes bridge_assets and get_onto_x1, and the description's specificity about Arc and USDC implies the alternative scenarios.

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 well. It discloses that the check is a simulation ('nothing spent'), details the return values (sell success, cost, depth, flags), and states rate limits ('ten a minute'). This is thorough behavioral disclosure for a read-only check tool.

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 but well-structured: purpose first, then method, output, and constraints. Every sentence contributes necessary context, though it is slightly verbose. It earns a 4.

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 explains what the tool returns, the method used, and rate limits, making it sufficient for an agent to decide whether to call it. It does not mention error cases or prerequisites, but for a free single-token check with no output schema, this is reasonably complete. A 4 reflects minor missing edge-case 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 coverage is 100% for both parameters, so the schema already documents the input formats. The description adds no extra parameter-level detail beyond restating the token/pool ID format and test size. 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?

The description states a specific verb (check exit) and resource (token/pool on Arc), and clearly explains the simulated round-trip check. It distinguishes itself from generic exit_check by specifying 'on Arc' and from arc_exit_check_bulk by implying single-token checks. The purpose is unambiguous and actionable.

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 clarifies the input scope (token address or v4 pool id on Arc) and mentions rate limits, but it does not explicitly mention when not to use this tool or point to alternatives like arc_exit_check_bulk for batch checks or exit_check for other chains. Usage context is clear but exclusionary guidance is missing.

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 well: it discloses the paywall, the 25-item limit, the sorting behavior, and that the return value is x402 payment instructions with accepted payment methods. It could mention error behavior for invalid ids, but the key behavioral traits are covered.

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 lead with the most important constraint (PAYWALLED), then max size, ordering, return value, cost, payment methods, and the free alternative. Every sentence earns its place with no 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?

The input is simple, but there is no output schema, so the description correctly explains what is returned (x402 payment instructions) and how payment is made. It does not detail how the returned instructions should be executed, which is a minor gap for an agent that must complete the payment flow.

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 single 'ids' parameter is already described as 'Up to 25 token addresses or pool ids.' The description mostly restates this limit and adds the Arc token context, but does not add meaningful semantic 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?

The description states a specific action: bulk Arc token/pool exit checks for up to 25 ids, with a defined ordering ('worst first'). It is clearly distinguished from the sibling arc_exit_check by naming it as the free single-check alternative.

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?

Explicitly says bulk calls are paywalled and cost $1, then routes single-check use cases to the free arc_exit_check sibling. This gives an agent clear conditions for choosing between the bulk and single tools.

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

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

With no annotations provided, the description carries the full burden and handles it very well: it discloses that the operator pays gas, that a contract enforces cooldown/daily limits, that there is no withdraw function, the UTC open windows, and the 8-hour per-connection limit. It even states what a refusal means and names the response fields.

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 but mostly earns its length because it packs a two-step protocol, timing windows, and response fields into a compact paragraph. It is front-loaded with the core action, though a phrase like 'Same claim for everyone' adds only modest 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?

The tool has no output schema, so the description's mention of nextClaimAt and claimNumber fills that gap. Accounting for the two-step signature flow, cooldown behavior, and response contents, nothing needed to use the tool correctly is left 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 coverage is 100%, so the baseline is 3, and the description reinforces the schema's address and signature meanings. It adds useful detail beyond the schema by specifying that the signature must be personal_sign from the address's key and that the first call intentionally omits signature to receive the challenge.

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 action ('Claim real USDC and APEX on Arc') and identifies the resource and target address, so the tool's role is unmistakable. It also includes a two-step protocol that sets it apart from status/metrics siblings like arc_faucet_status and faucet_metrics.

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 step-by-step invocation guidance: call with only {address} first, sign the challenge with EIP-191, then call with {address, signature}. It explains timing and cooldown constraints, but it does not explicitly name alternative tools or say when not to use this one.

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 fully carries the behavioral burden and does so excellently: it discloses live reads from the contract, honest error behavior (failed reported as failed, never zero), cost ('Free'), and the three-part daily release schedule. This is highly transparent for a status tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence earns its place. The description front-loads the core status payload, then adds crucial behavioral details and the chain identifier without any filler. Dense but well organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no annotations, and no output schema, the description is complete: it lists every returned datum, explains the timing semantics, clarifies live vs cached reads, and specifies error and cost behavior. An agent has everything needed to call 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 tool has 0 parameters, so the baseline is 4. The description adds relevant output-context semantics even though no parameters exist to document.

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

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

The description states a specific resource (APEX faucet on Arc) and explicitly enumerates the data points returned: pot, claim amounts, claims left today and right now, release timing, and cooldown. It clearly identifies this as a status read, distinguishing it from the claiming sibling arc_faucet_claim without naming it.

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?

Clear context is provided about what information is available and how to interpret nextReleaseAt with specific UTC release times. However, it does not explicitly state when to prefer this tool over alternatives like arc_faucet_claim or faucet_metrics, so it earns a 4 rather than a 5.

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

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

With no annotations, the description fully carries the behavioral burden. It discloses custody ('from your own key, non-custodially'), swap mechanics ('half is swapped for APEX'), minting ('full-range Uniswap v4 position minted to the caller'), refunds ('leftovers refunded, nothing kept'), and removal actions. This is exceptional transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences with no filler and the core action front-loaded. The first sentence is long and compound, but each clause contributes operational detail; a bit more formatting would make it perfect.

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 is responsible for return-value explanation, and it does: positions, deposit, and value with an address; contract, ABI, and steps without. It also covers the exit path, making the tool self-contained for an agent.

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

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

The schema already covers the address parameter, so a baseline of 3 applies. The description adds functional meaning beyond the schema by explaining exactly how omitting or including the address changes the result, which earns an extra point.

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 action ('Put USDC to work in the APEX/USDC pool') with a precise contract call ('call grow(minApexOut) on the ArcGrow contract'), and distinguishes itself from siblings by describing the LP minting and read variant. This is far from a tautology.

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?

Clearly explains the two invocation modes ('With {address} this returns... without it, the contract, ABI and steps') and even includes removal instructions via PositionManager. It lacks an explicit 'use X instead' exclusion of sibling tools, but the context is strong enough to route an agent.

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 present, so the description carries the full burden. It discloses the data source (PoolManager events), the refresh interval (five minutes), the cost (free), and the exact output fields (first buyer, seconds, sold straight back, USDC depth, flags, leaderboard). This is thorough behavioral disclosure.

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 but front-loaded with the title and a comma-separated list of outputs. It is efficient: each clause adds distinct information, and the data source/frequency sentence is short.

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 enumerates all return fields despite lacking an output schema, and it states the update frequency and cost. Nothing critical is missing for a zero-input monitoring 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?

The tool has zero parameters, so the description has nothing to explain. Baseline 4 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 clearly states the tool's purpose: monitoring new Uniswap v4 pools on Arc, including first buyer details and metrics. It specifically mentions the resource (pools on Arc) and the action (watch), distinguishing it from generic pool 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 provides clear context: it is for pools created in the last 24 hours and updates every five minutes. However, it does not explicitly compare to sibling tools or state when not to use it.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explains the nature of an assay (a reverted buy-and-sell), the contract address, and the fee's destination when creating one. However, it does not disclose the tool's own behavior (e.g., whether it is read-only, pagination, error cases, or output format). The description focuses on the assay concept rather than the tool's execution.

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 informative but slightly dense. It defines the assay concept, provides a contract address, and explains how to create an assay—information that may be tangential for a read tool. However, every sentence adds context, and it is not overly verbose. The core read functionality is stated early, and the later details are supplementary.

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 does not explicitly state the return format. It implies the read returns verdict, round-trip cost, and streak from the assay definition, but it does not confirm the output schema or any potential pagination. Given the tool takes an optional token and has no output schema, the description should clarify what the caller receives. The instruction about creating an assay via contract call is additional context but not directly relevant to the tool's interface.

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 describes the single parameter as 'Optional token address to read assays for.' The description adds meaningful distinction: if a token is provided, you read that token's assay; if omitted, you read all pools. This clarifies the parameter's behavior beyond the schema and directly maps to the two use cases.

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

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

The description clearly states the tool's function: 'Read every pool's last assay and streak, or one token's.' This is a specific verb (read) and resource (assays), and it also defines what an assay is. While it doesn't explicitly name a sibling tool, the unique concept of 'on-chain assays' distinguishes it from the other Arc-related tools like arc_exit_check or arc_pools.

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 says when to use the tool ('Read every pool's... or one token's') but does not provide explicit exclusions or name alternatives. It indirectly suggests that creating an assay is done via a direct contract call ('To make one, call assay(poolKey, 0)...'), implying this tool is for reading, but it never compares to other tools or states when not to use it.

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