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 this is the only on-chain step, that it costs gas, that it should happen once, that empty balances cause payment refusal, and what the return values are. This is far beyond a bare 'deposit' statement.

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 efficiently structured: clear purpose paragraph, workflow guidance, prerequisite, and a returns summary. Every sentence adds useful information and nothing feels like filler or tautology.

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 3-parameter tool with no output schema, the description is complete: it explains the purpose, the workflow position, gas implications, the private key requirement, parameter nuances, and the exact return fields including units. An agent has enough to invoke it correctly and interpret the result.

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 schema already documents amount, rpc_url, and at_least with units and defaults. The description reinforces the decimal-string format and USDC smallest-unit convention, but mostly repeats what the schema already provides. 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 opens with a specific verb and resource: 'Deposit USDC into Circle Gateway on Arc', and immediately states the downstream purpose (paying for proofs via nanopayments). This clearly distinguishes it from the sibling tools like gateway_balance and generate_proof, which serve different steps in the workflow.

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 when-to-use guidance: 'Do this ONCE, not per proof' and explains why, including gas cost and refusal of payments against an empty balance. It also notes the PAYMENT_PRIVATE_KEY requirement. It does not explicitly name an alternative sibling, but the situational guidance is concrete enough to route an agent correctly.

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 burden and does meaningful work: it discloses that the operation reads a current balance, specifies USDC base units, and states the required private key. It does not explicitly say the call is read-only, but the wording strongly implies a non-mutating balance lookup.

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 compact sentences with no filler: the first states the tool's purpose and its relationship to nanopayments, and the second packs in unit semantics and an authentication requirement. Every sentence earns its 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 one-optional-parameter read tool, the description covers purpose, units, and auth. However, because there is no output schema, it does not specify the exact response shape or field name, and it does not address edge cases like an invalid key or missing gateway balance.

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 only parameter, rpc_url, is fully documented in the schema with its type and default value, so schema coverage is 100%. The description adds no parameter-specific detail, which aligns with the baseline score for high schema coverage.

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

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

The description clearly identifies the tool as reporting the buyer's current balance inside Circle Gateway on Arc and notes this is the balance nanopayments draw against. It distinguishes itself from deposit_to_gateway and proof-flow siblings, though it lacks an explicit imperative verb like 'get' or 'fetch'.

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: call this when you need the current balance that nanopayments draw against. It also states a prerequisite (PAYMENT_PRIVATE_KEY), but it never explicitly says when to use this instead of deposit_to_gateway or other alternatives, nor provides exclusions.

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

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

No annotations are provided, so the description carries the full burden. It discloses the one-call bundling behavior, per-circuit requirements, optional EIP-712 action binding, and the fact that the proof carries the action's hash. It does not detail failure modes or rate limiting, but the behavioral disclosure is strong.

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 long but appropriately structured with a summary, routing guidance, a circuit section, and a returns section. Every paragraph earns its place given the complexity of 11 parameters and five circuits; there is no filler.

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?

Despite having no output schema or annotations, the description covers the operation, when to use it, all circuits, payment/chain nuances, EIP-712 action semantics, nanopayments, and return type. It is unusually complete for a complex tool and leaves little for an agent to infer.

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 substantial value by linking parameters to circuits: country_list and is_included for coinbase_country, jwt and scope for oidc_domain, and optional/rejected action for arc_eligibility and giwa_attestation. It also explains defaults for pay_on and pay_with, materially improving correct invocation.

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 'All-in-one ZK proof generation' and explicitly says it handles prepare inputs, request challenge, and submit proof in a single call, clearly distinguishing it from the individual sibling tools. It then enumerates five distinct circuits with their exact guarantees, making the tool's operation unmistakable.

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 states 'Use this when you want the simplest path to a proof. For fine-grained control over each step, use prepare_inputs, request_challenge, and submit_proof individually', providing explicit when-to-use guidance and named alternatives. It also routes verification to verify_proof separately and tells the caller to use request_challenge to see what a service offers.

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 provided, so description must disclose behavior. It mentions no parameters required but does not state if it's read-only or any side effects. Minimal behavioral info, but acceptable for a simple listing 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?

Two sentences, no wasted words. Efficiently conveys purpose, output contents, and usage order.

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 the tool has zero parameters and no output schema, the description adequately covers purpose and guidance. Could mention output format or safety of repeated calls, but it's mostly complete.

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

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

No parameters defined; description adds value by explicitly stating 'No parameters required,' which reassures the agent. Baseline 4 for zero-parameter tools with coverage.

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?

Clearly states the tool lists all ZK circuits with specific details (verifier addresses and authorized signers). Distinguishes from siblings by being a discovery step before proof generation.

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 'Call this first to discover available circuits before starting proof generation,' which guides when to use it. Could be improved by specifying when not to use it or naming alternatives, but it's clear for a discovery 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses signing behavior for Arc/GIWA versus Coinbase, the EAS query, Merkle proof construction, private output contents, and a security warning about never exposing inputs to the dApp, model, or logs. It could say more about side effects or failure behavior, but it is substantially transparent.

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 six sentences long, and every sentence carries distinct information: step identity, signing behavior, EAS/proof/output behavior, security handling, call ordering, and circuit-specific parameter guidance. It is front-loaded with the core purpose and contains no filler.

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 there is no output schema, the description reasonably names the returned artifacts ('private witness inputs including the Arc domain_separator and action_hash') and covers sequencing, security, and circuit variants. It does not fully enumerate all outputs or edge cases, but for a preparation step it is largely complete.

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

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

Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds cross-parameter guidance beyond the schema: jwt/scope replace Coinbase-specific parameters for oidc_domain, and the action signing behavior differs by signer. This is meaningful value over the schema alone.

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 and resource: 'Prepare all circuit inputs', and grounds it in concrete behavior ('Queries EAS, builds the Merkle proof, and returns private witness inputs'). It positions itself as 'Step 1 of the step-by-step flow', which distinguishes it from later siblings like generate_proof and request_challenge.

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 sequencing: 'Call this BEFORE request_challenge'. It also provides circuit-specific routing: 'For oidc_domain circuit, provide jwt and scope instead of Coinbase-specific parameters', which tells the agent exactly when to use which parameter set.

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. It discloses security-relevant behavior: that the tool does not sign payments or encrypt inputs, and that '{}' prevents transmission of private witness data. It also highlights the server-side nonce issuance and its necessity for subsequent steps.

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 concise yet information-dense, with critical points front-loaded: step indication, the recommendation to use '{}', and the nonce requirement. Every sentence earns its place, covering purpose, usage, and security implications without 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?

Given the tool's moderate complexity (2 params, no output schema), the description provides comprehensive guidance on what the tool does, when to use it, how to use it safely, and what to do with the result (pass nonce to submit_proof). It also covers the alternative for paid/encrypted use, making it self-sufficient 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?

Even though schema coverage is 100%, the description adds crucial meaning: it explains that '{}' is sufficient for anonymous discovery, warns that providing witness data sends it to the prover and must be kept out of context/logs, and clarifies the circuit enum's purpose. This goes well beyond the schema's minimal descriptions.

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

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

The description clearly states it is 'Step 2 of the step-by-step flow: Request a challenge from the server' and specifies the resource and action. It distinguishes itself from siblings like submit_proof by explaining its role and the critical dependency on the returned nonce.

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 recommends passing '{}' to avoid transmitting private data, warns against using submit_proof for signing, and directs to generate_proof or the SDK for paid/encrypted flows. This provides clear when-to-use and when-not-to-use guidance with specific alternatives.

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?

Discloses substantial runtime behavior: the server runs the Noir circuit, builds Prover.toml from inputs, returns UltraHonk proof, and takes 30-90 seconds. It also warns about 402 challenge responses when nonce is omitted, providing a concrete failure mode. With no annotations, the description carries the burden and does so well, though it doesn't describe the exact success/error response envelope.

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?

Description is compact and front-loaded: purpose, server behavior, latency, and nonce warning in four sentences. The only slightly extra detail is the internal endpoint path, but it reinforces the nonce requirement.

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?

Grounds the tool in a step-by-step flow, specifies runtime duration, and warns about the one critical mistake. For a 3-param synchronous tool with no output schema, this is nearly complete; it could add an explicit success/error response format or a note that proof should be passed to verify_proof.

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?

Input schema covers all 3 params with complete descriptions, so the high-coverage baseline applies. The description adds workflow provenance (nonce from request_challenge, inputs from prepare_inputs) and notes Prover.toml construction, but most of this repeats schema descriptions and does not substantially deepen parameter meaning.

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 ('Submit prepared inputs to generate the ZK proof') and identifies position as 'Step 3' in the flow, with the TEE server running the Noir circuit. However, it never distinguishes itself from the sibling 'generate_proof', which could plausibly perform the same action.

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?

Positions itself clearly as Step 3 and states the requirement to pass the nonce from request_challenge, giving an agent a precondition to check before calling. It doesn't explicitly say when to prefer this over generate_proof or mention exclusions, but the step context and nonce dependency are clear.

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 must disclose all behavioral traits. It states the tool verifies on-chain and returns a success object, but does not mention potential gas costs, network dependencies, failure responses, or side effects.

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 three sentences with no wasted words. It front-loads the purpose and incrementally adds context on how to use the tool and what to expect.

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 the nested object parameter and lack of output schema, the description effectively covers the main use case and expected return for a valid proof. However, it omits error handling, edge cases, and a full return structure description.

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 input schema has 100% coverage with descriptions for all properties. The description adds value by explaining to pass the result object directly, but it reinforces usage rather than adding new semantic meaning 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 clearly states the tool's action ('Verify a ZK proof on-chain'), the specific resource ('against the deployed verifier contract'), and its place in a workflow ('Step 4 (optional)'). It distinguishes itself from siblings like generate_proof and submit_proof.

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 instructs users to 'Pass the full generate_proof result object directly,' providing clear how-to guidance. It frames the tool as an optional step after proof generation, but lacks explicit when-not-to-use or mention of alternatives.

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