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

Annotations already declare readOnly/openWorld/non-idempotent/non-destructive, and the description adds genuinely new behavior: paid operation at $0.01 USDC with no free trial, ambiguous matches failing without charge, and returned artifacts (signed observation, OFAC flags, confirmations, printable HTML). It doesn't explain settlement mechanics or what a failure/payment-refund path looks like.

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 primary lookup mode and tight overall, but the telegraphic fragment style ('Signed observation, OFAC flags, confirmations and printable HTML') reads as a compressed feature list rather than structured prose. Nearly every clause carries information, so little is wasted.

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 and no annotation-level detail on returns, the description steps in by naming the response payload (signed observation, OFAC flags, confirmations, HTML) and the failure mode for ambiguity. It leaves the cost/charge interaction and error taxonomy slightly under-specified for a paid verification 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 must carry the load, and it does: it ties tx_hash to an optional log_index, groups pay_to + decimal amount + start/end into an alternative lookup path, and imposes a 90-day window on the dates. It adds little on field formats (hex patterns, amount precision), which remain schema-only.

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 ('Verify a native Base USDC transfer') and enumerates the two exact identification modes. An agent can tell this apart from siblings like check_token or preflight_payment purely from the description.

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 specifies the two invocation modes (tx_hash [+log_index] vs pay_to + amount + date range) and scopes the date range to max 90 days in the past. It also carves out what the tool is not ('not invoice ownership or finality proof') and states pricing/no-free-trial. It stops short of explicitly routing to a sibling alternative when this tool doesn't fit.

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