pay

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

With no annotations provided, the description must carry the full disclosure burden. It clearly explains who signs (agent), the fee payer (relayer), that the bot never holds SOL, the funding source (SpendVault), optional sponsor reimbursement, and failure modes (need_human_signature / need_human_setup). This is strong behavioral transparency, though it omits the return value on success.

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 a single dense paragraph that is not front-loaded with the primary purpose; it starts with implementation details rather than a clear action statement. While it is not excessively long, it mixes environment specifics, signing, fee payer, funding, and preconditions without clear structure, making it harder to parse quickly.

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 complexity of the payment flow, the description covers many crucial aspects: environment-specific behavior, signing, fee payer, funding source, sponsor reimbursement, and required setup. It does not describe the return value or successful output, and it leaves dry_run semantics unexplained, but the coverage is strong for a payment tool without an output schema.

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 descriptions cover 4 of 5 parameters (80%), so the baseline is 3. The description adds some context by linking sponsor_lamports to the optional reimbursement and indicating SpendVault as the source for amount_lamports. However, it does not systematically explain each parameter; for dry_run and root it adds nothing beyond the schema, leaving some ambiguity about their exact roles.

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 'Implemented INTENTS pay' which largely restates the tool name and does not clearly articulate the high-level function (sending lamports to a recipient from a SpendVault). The purpose is implied through context like 'Agent signs' and 'Human-funded SpendVault is the SOL source', but a concise, explicit statement of what the tool does is missing.

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 provides concrete preconditions for success (rooting, grant, funding, RELAYER_KEYPAIR) and environment-specific behavior (localnet vs devnet), which helps an agent understand operational requirements. However, it does not explicitly instruct when to use this tool versus alternatives like swap or call, nor does it state conditions under which this tool is inappropriate.

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