use_payment_method

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

With no annotations, the description carries full burden and does so well: it discloses the confirmation prompt with card brand/last 4/merchant domain before filling, that the fill domain comes from the resolved tab URL rather than the request, the dual unlock prerequisite, and the TAB_NOT_OWNED cross-agent rejection.

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?

Four sentences, front-loaded with the action and confirmation behavior, then prerequisites and multi-agent routing. No filler, though the multi-agent clause is fairly dense.

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?

Covers prerequisites, confirmation step, security derivation, and error behavior for a no-output-schema tool. Leaves slightly unclear what the tool returns on success or whether the form is submitted versus only filled.

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 coverage is 100% and the description's tab_id guidance essentially restates the schema's own 'omit when exactly one tab, pass to disambiguate' wording. No parameter detail is added beyond the schema, so the baseline 3 applies.

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: 'Fill checkout form on the active tab with a saved payment method.' This is clearly distinguishable from list_payment_methods and fill_credential by resource, though no sibling is named explicitly.

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 precondition context ('Requires both credential vault and payment access to be unlocked') and a rule for tab_id usage ('Pass tab_id only when this agent owns multiple tabs; auto-resolves otherwise'). No explicit when-not or named alternative, so it stops short of a 5.

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