Base USDC Receivables Auditor

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds two non-obvious behavioral facts: the balance is per-connection bearer token, and the call itself has zero credit cost — real value beyond the 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?

Two short sentences, front-loaded with the resource and followed immediately by the cost caveat. No filler, no restatement of the title.

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?

An output schema exists, so return values need not be described. What remains absent is any note on failure modes (e.g., expired or missing token), which for a zero-parameter auth-scoped tool would be the only missing piece.

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

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

Zero parameters, which sets the baseline at 4; the description correctly implies no inputs are needed because scope is derived from the connection's token rather than from arguments.

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 (check) plus the exact resource (remaining prepaid credits) and scopes it to the credential in use ('the bearer token configured on this MCP connection'). No sibling tool touches credits, so there is no ambiguity to resolve; an agent knows exactly what this returns.

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 tells the agent this call is free and does not consume credits, which is the key decision input for calling it (e.g., safe to probe before a paid operation). It does not name alternatives or state when-not-to-call, but the sibling set is unrelated, so no routing guidance is required.

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

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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds genuinely useful context beyond that: the credits are purchased with native Base USDC, the operation is free, and the funding transfer is distinct from audited receivables — which steers the agent away from treating this as a payment or reconciliation action.

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 essentially no filler, and the key point (free instructions for buying credits) is front-loaded. The second sentence is a caveat rather than padding, though its phrasing is slightly indirect.

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, read-only tool with an output schema that already documents return values, this is close to complete. The one residual gap is that the description does not explicitly characterize the returned content as instructions rather than transactional data.

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 the baseline of 4 applies; there are no argument semantics for the description to clarify. Nothing in the description contradicts or under-specifies the empty 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 conveys that the tool returns instructions for buying prepaid credits with native Base USDC, which is more than a restatement of the name. However, it never says plainly what is returned (address, quote, step-by-step instructions) or that this is purely informational rather than a payment action. It contrasts obliquely with receivables auditing, so sibling differentiation is only partial.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit statement of when to call this tool versus siblings like get_credit_balance or reconcile_usdc_receivables, and no prerequisites are given. The audience must infer usage from the phrase 'instructions for buying ... credits'.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the call is free, and it discloses the auditor's operational policies (safe-finality, fail-ambiguous matching, scan limits) and the per-batch credit cost model.

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 front-loaded sentence with zero filler; the resource is named first and the payload contents follow as a compact list. Nothing is wasted and nothing essential is buried.

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?

An output schema exists, so return values need not be spelled out, and the description still previews the categories of information returned. Combined with the free-to-call note, an agent has enough to invoke it correctly, though a one-line steer toward sibling tools would make it 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?

The tool takes zero parameters, which is the baseline-4 case; there is no argument semantics to document. The description correctly spends no space on nonexistent inputs.

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 a specific resource (the Base USDC Receivables Auditor) and enumerates the content of the returned overview: dual-RPC safe-finality policy, fail-ambiguous matching, scan limits, and per-batch credit cost. That is far more than a tautology, but it never distinguishes itself from siblings like get_payment_info or reconcile_usdc_receivables, so an agent must infer the boundary.

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?

Calling this 'Free' implies it can be called without spending credit, which is useful guidance and hints at a pre-flight/exploration use case. However, there is no explicit statement of when to use this versus reconcile_usdc_receivables or the other getters, and no exclusions, so usage is only implied.

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?

Adds material behavior beyond the annotations: exact agreement from two public RPCs, safe-finality requirement, a determinism guarantee ('without fuzzy guessing'), a 10-credit cost, and automatic refund on RPC or unsafe-range failure. These are precisely the operational facts an agent cannot infer from readOnlyHint/destructiveHint/openWorldHint alone — the mutation annotations are explained by the credit charge rather than a chain write. The failure/refund path is disclosed rather than left implicit.

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?

Front-loaded with the core action and tightly written; the exception list and the cost/refund clause each carry real information. The first sentence is heavily packed with clauses across two verbs (scan, compare) and could be split for faster parsing, but no sentence is 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?

For a multi-step, cross-RPC reconciliation tool, the description covers the mechanism, the safety model, the credit cost and refund path, and the result categories; an output schema exists so return structure need not be restated. Remaining gaps are parameter-level: block-range boundary rules and the notAfterBlock/lateness semantics implied by the 'late' exception category.

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 does map the top-level intent — 'one receiver', 'bounded block range', 'up to 25 expected receivables' — which corresponds to receiver, fromBlock/toBlock, and expected. However it never explains the expected item fields (payer, amountAtomic, id, notAfterBlock) or that comparison is against expected amounts, leaving the nested semantics and the atomic-amount format undocumented anywhere.

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 chain: scan a bounded Base Mainnet block range for native Circle USDC transfers into one receiver, cross-check two RPCs at safe finality, and diff against expected receivables. It is unmistakable against the sibling info/balance tools, which do no chain scanning. The exception taxonomy (matched, missing, underpaid, overpaid, wrong-sender, late, duplicate, needs-review) further pins down what the tool produces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operating context: bounded block range, one receiver, up to 25 expected receivables, two-RPC agreement at safe finality, and the cost/refund condition. There are no sibling tools that overlap in function, so no alternative routing is required. It stops short of explicit when-not-to-use conditions (e.g. unsupported chains, unsafe/unfinalized ranges are only implied).

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