Create payment link

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

The annotation readOnlyHint=false already signals a write operation, and the description repeats this with 'Write operation.' It adds that the result is a hosted checkout link and QR code, but does not disclose behavioral details like idempotency, expiration handling, required permissions, side effects, or what happens on failure.

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 concise sentence that is front-loaded with the operation type. It has no filler or irrelevant details, though 'Write operation' is somewhat redundant with the annotation readOnlyHint=false.

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 seven parameters, no output schema, and no usage guidance, the description is too sparse to support correct invocation. It states the intended artifact but omits required parameter semantics, return value expectations, and behavioral context, so an agent would still need substantial external knowledge.

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%, and the description provides no parameter-level meaning. None of the seven parameters (amount, currency, merchantTransactionId, expiresAt, customIpnUrl, idempotencyKey, description) are explained, leaving the agent with only raw JSON schema constraints and no semantic context.

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 uses a specific verb ('create') and a specific resource ('hosted ZEN checkout link and QR code for a customer to pay'). This clearly distinguishes the tool from read-oriented siblings like get_payment_link and list_payment_links, and from other create operations like create_payout and create_customer.

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 no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. The agent is left to infer that this is the creation tool for payment links based solely on the name and sibling list.

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