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 well: it discloses the two-phase payment flow, the exact payment scheme (EIP-3009), chain ID (eip155:8453), and the HTTP alternative. It does not mention side effects or reversibility, but the payment requirement is the most critical non-obvious behavior and is clearly explained.

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 compact and front-loaded with the main purpose, then the payment flow, then the HTTP note. It is dense but every sentence adds operational detail. Minor formatting improvements could separate the protocol steps, but there is essentially 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 the two-step payment complexity, the description is largely complete: it covers the mainnet NEAR + Base USDC receipt, the EIP-3009 payload, and the HTTP header. An output schema exists, so return values do not need description. However, it omits the optional agent_sig/agent_pubkey semantics and does not explicitly differentiate this tool from the notarize siblings.

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 context for work_hash ('a work hash') and documents the payment meta-parameter, but it never explains agent_sig or agent_pubkey, which are optional schema fields. The agent is left guessing what those values should be or why they are needed.

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 clear verb and resource: 'Notarize a work hash on AOTrust'. It further specifies the paid nature ('$0.01 USDC via x402-over-MCP'), which distinguishes it from the sibling tools like notary_free and notary_notarize by payment model.

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 a concrete invocation strategy: call without payment, receive PaymentRequired, retry with a signed PaymentPayload. However, it never explicitly states when to choose this tool over notary_notarize or notary_free, leaving the selection decision to inference from the name and payment wording.

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