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

With no annotations, the description does carry useful load: it discloses the output is an unsigned transaction (nothing is broadcast), the cost model ('free, gas only'), the 30-day pass duration, and the one-agentId-one-vote constraint. It omits what to do with the tx afterward and whether the call fails or no-ops on re-registration.

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 tight sentences, front-loaded with the output type and the core action. The identity/vote clause is short and materially informs the caller rather than padding.

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 tool with no annotations, no output schema, and 0% schema coverage, the description leaves too much open: 'referrer' is undocumented, the shape of the returned unsigned tx is unstated, and downstream submission is not addressed. It covers the economics but not the mechanics an agent needs to invoke and use 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 description coverage is 0%, so the description must compensate. It only implies that agentId is an ERC-8004 token the caller owns on Base; the optional 'referrer' parameter is never mentioned at all, leaving half the inputs undefined.

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+resource: build an unsigned transaction that registers the caller as an AgentPad v2 agent using an ERC-8004 agentId. The 'build_*_tx' prefix plus the explicit ERC-8004 framing distinguishes it from spend-related siblings like build_buy_tx or build_vote_tx, though no sibling is named directly.

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 a real prerequisite ('an ERC-8004 agentId you own on Base'), which helps an agent decide eligibility. But it never says when to choose this over adjacent tools (onboard_and_buy, agent_status) or what happens if the wallet is already registered.

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