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

Adds substantial context beyond the annotations: it discloses that no money moves server-side and settlement is on-chain to `destination`, that the network is determined by the API key and dv_ keys are test networks with no real funds, and that reusing a memo is refused. These are operational facts the annotations (readOnlyHint=false, openWorldHint=true) cannot convey. The memo-based idempotency note sits alongside idempotentHint=false but is a caller-supplied key rather than a contradiction of server-side idempotency.

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?

Front-loads the core identity in the first clause and then packs conditional rules efficiently; nearly every sentence carries decision-relevant information. It is dense for a single paragraph, and the chain-standard parenthetical could be trimmed, but there is 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?

With no output schema, the description compensates by naming the return fields an agent must act on (`checkoutUrl`, `paymentUri`, optional QR) and by describing the full lifecycle through to settlement. For a 9-parameter mutation on an open-world payment rail, that is complete enough to invoke correctly.

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%, so the baseline is 3, but the description adds cross-parameter meaning the schema does not: the Monad exception to omitting `amount`, and the native-coin default when `asset_code` is omitted. It stops short of explaining `memo`, `checkout_theme` or `include_qr` behavior, which remain schema-only.

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 ('Create a payment request... a payment link') and immediately disambiguates by naming the per-chain standards it produces (SEP-7, Solana Pay, EIP-681) plus the QR code and checkout page artifacts. An agent can tell this apart from the read-side siblings get_payment/list_payments without opening the schema.

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 explicit conditional guidance: omit `amount` to let the payer choose (except Monad), omit `asset_code` to charge the native coin, then send `checkoutUrl`/`paymentUri` and poll with get_payment. It names the follow-up sibling tool and the condition that selects it, leaving nothing to inference.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the description's added value is the precondition (only unpaid payments), the downstream effect on the payment link, and the explicit confirm-with-user instruction for an irreversible action. It does not mention permission requirements or what error surfaces if the payment is already paid, which keeps it at 4 rather than 5.

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?

Three short sentences, front-loaded with the effect, then the precondition, then the irreversible-action warning. Nothing is redundant.

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 one-parameter destructive tool with no output schema, the description covers purpose, precondition, consequence and safety guidance. Only the failure mode on an invalid or already-paid id is left implicit.

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?

Single required parameter with 100% schema description coverage, including the pattern and provenance ('as create_payment_link or list_payments returned it'). The description adds nothing about the id, but the schema already does the work, so baseline 3 is correct.

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?

Specific verb+resource (delete a payment) plus the exact effect (its link can no longer be paid). The precondition clause cleanly separates it from read-only siblings like get_payment and from create_payment_link.

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?

States a clear exclusion condition — a paid (SUCCEEDED) payment cannot be deleted — and instructs confirmation before use. It doesn't name an alternative tool for handling paid payments, 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds valuable semantic context: settled vs pending amounts are per asset and reflect payments brought in rather than a stored wallet balance. It says nothing about freshness, aggregation window, or auth requirements, which keeps it at a 3.

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?

One sentence, front-loaded with the resource and scope, and the parenthetical disambiguation earns its place by preventing the wallet-balance misreading.

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?

With no parameters, no output schema, and annotations covering safety, the description is sufficient to call this correctly. It would be stronger if it hinted at the return shape (asset plus settled and pending amounts) or the aggregation window.

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?

Zero parameters, so the baseline is 4. The description correctly implies no inputs 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?

States a specific resource (settled and pending balances per asset) and scopes it to the API key's organization, with an explicit negative clarification that it is not a wallet balance. It does not explicitly differentiate from siblings like get_summary, so not a 5.

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?

There is no statement of when to use this versus get_summary or list_payments. The parenthetical explains what the data means but gives no routing guidance or preconditions.

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

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

The readOnlyHint and openWorldHint annotations already cover the safety profile. The description adds useful behavioral context by listing the status values and the fields returned, including the transaction hash once paid, though it does not mention not-found or error behavior.

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 front-loaded sentence that begins with the core action and then lists the relevant return fields. It contains no redundant or wasted text.

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 simple read-by-id tool with no output schema, the description does the important work of explaining what is returned, including status values and payment details. It is nearly complete, though it could mention not-found behavior.

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 100%, and the id parameter is fully documented in the schema. The description adds no parameter-level detail beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 states a specific verb and resource: 'Read one payment.' The word 'one' distinguishes it from list_payments and get_payment_history, and the enumerated fields make the scope concrete.

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?

Usage is implied by 'Read one payment' and the required id parameter, but the description does not explicitly say when to use this tool instead of list_payments, get_payment_history, or validate_payment.

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

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

Annotations already establish that this is a read-only, open-world operation. The description adds useful behavioral context by specifying chronological ordering ('oldest first') and that each event includes its timestamp. It does not mention pagination, result limits, or authorization requirements, so it adds moderate but not rich behavioral detail.

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 efficient sentence with zero waste. The key information, status changes of one payment, oldest first, with timestamps, is front-loaded.

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 simple one-parameter read-only history tool with annotations covering safety and a fully documented id schema, the description is nearly complete. It explains what is returned and the ordering, though it could mention whether all history is returned or whether pagination applies.

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 100%, and the single id parameter is fully documented in the schema, including its format and where it comes from. The description adds no parameter-specific meaning beyond that, so the baseline of 3 is appropriate.

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 states a specific resource and scope: the status-change history of one payment, ordered oldest first with timestamps. This clearly distinguishes it from get_payment, which likely returns current payment details, and from list_payments, which returns multiple payments.

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?

Usage is implied by the purpose: an agent can infer this is the tool for viewing status transitions of a single payment. However, the description does not explicitly state when to use it versus get_payment or list_payments, nor does it mention exclusions or alternatives.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds the important scoping trait that data is limited to the API key's organization plus the time horizon of the series (30 days). It does not say whether figures are live or cached, what units/currencies they use, or how webhook health is expressed.

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?

One sentence, front-loaded with the scope ('API key's organization') followed by the content inventory. Every element earns its place.

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?

With no output schema, the description is the only source of return-value information, and it only names categories rather than structure, keys, or units. It is enough to decide to call it, but thin for interpreting results.

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?

The tool takes no parameters, so there is nothing for the description to document beyond the fixed scope; stating that the summary is scoped to the API key's organization is a useful implicit account of why no inputs exist.

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 clear resource and enumerates its contents (payment totals, settled volume, webhook health, 30-day series), which distinguishes it from record-level siblings like get_payment and get_balances. It lacks an explicit verb but 'Overview of the API key's organization' effectively conveys the aggregate read.

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?

No statement of when to use this versus list_payments or get_balances, and no prerequisites or exclusions. The word 'Overview' only weakly implies it is a starting-point/dashboard call.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds useful behavior beyond those annotations: results are scoped to the organization, ordered newest first, optionally filtered, and paged with a total count. It does not discuss permissions or rate limits, but the notable behavioral traits are disclosed.

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 compact sentences with the core listing scope and ordering front-loaded, followed by filtering and paging details. Every sentence adds useful information without repetition.

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 read-only list tool with full parameter schema coverage and annotations, the description provides enough to call it correctly: scope, ordering, filters, and paging behavior. It could be slightly more complete by naming when to choose it over get_payment_history, but the core operational context is present.

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 100%, so all five parameters are already documented in the schema. The description adds a high-level summary of filtering by status, chain, or creation date and mentions paging, but does not add syntax or format details beyond the schema.

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: listing payments scoped to the API key's organization, with ordering and filters. It is clear what the tool does, though it does not explicitly differentiate itself from siblings like get_payment_history.

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?

Implies usage through mention of optional filters and paging, but gives no explicit guidance on when to use this versus get_payment, get_payment_history, or get_summary. The agent can infer it is for browsing payments, but alternatives are not addressed.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and external-data profile is covered. The description adds that entries carry code and issuer, but says nothing about freshness, whether the catalog is live-fetched, result size, or ordering — the kind of context that would matter for a reference-data listing.

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 short sentences, zero filler, with the resource definition front-loaded and the downstream usage instruction second. Every clause earns its place.

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 simple two-optional-parameter read tool with no output schema, the description conveys what an entry looks like (code + issuer) and how to use it, which is most of what an agent needs. Minor gaps remain around result volume and whether the list is filtered by network by default.

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 100%, and the schema already documents the network default and the verified_only default. The description adds no meaning beyond that — it never mentions network scoping or the verified filter. Baseline 3 applies when the schema carries the parameter burden.

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 identifies the resource precisely as the Stellar asset catalog and states what each entry contains (codes and issuers), with concrete examples (USDC, EURC by Circle). The listing verb is only implied by 'catalog', but the resource is unmistakable and clearly distinct from payment-oriented siblings.

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 explicitly tells the agent how to consume the result: feed an entry's code and issuer into create_payment_link's asset_code and asset_issuer. That is a strong, actionable usage link to a named sibling. It stops short of stating when not to use it or how to choose between networks, but no real alternative tool exists.

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

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

The annotations already declare that this is not read-only, is idempotent, is open-world, and is not destructive. The description adds the important conditional mutation detail that it settles the payment only if the transaction pays it, which is meaningful context beyond the annotations, though it does not describe error behavior or authorization needs.

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 sentences, front-loaded with the core action and then the usage condition. There is no wasted framing, and the key settlement behavior is stated immediately.

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?

The description covers what the tool does and when to use it, but for a mutation tool with no output schema it does not explain what happens when the transaction does not pay the payment, nor what result or error the caller should expect. That leaves a meaningful gap for correct invocation.

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 100%, so both required parameters are already well documented in the schema. The description mentions the transaction hash/signature but does not add meaning for the id parameter, so the baseline of 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?

The description gives a specific verb and resource: check a transaction against a payment and settle it if it pays it. It is clearly a settlement/verification action, though it does not explicitly contrast itself with nearby read-only siblings such as get_payment or get_payment_history.

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 clear triggering condition: use it when the payer sent the payment but its status has not changed. It also tells the caller what to pass, but does not name when not to use it or which sibling to use for status checks instead.

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