SnapEX Pay

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

Goes well beyond the annotations (readOnlyHint=false, idempotentHint=false, openWorldHint=true) by disclosing what the call actually produces and its consequences: a full-scope key shown once, auto-adopted on this connection, credentials for the web cabinet, a zero starting balance, and a per-IP hourly rate limit. This is exactly the operational context annotations cannot carry.

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-loaded with the action and its payoff, then the gating condition, then the follow-up instructions. It is dense but nearly every clause carries new information; the api_key/cabinet_url/mcp_personal_url passage is slightly overloaded for a single sentence and could be split for scanability.

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 still tells the agent what comes back (api_key, generated login/password, cabinet_url, mcp_personal_url) and what to do with it next time. Combined with the zero-balance and rate-limit caveats, nothing an agent needs before invoking this call is missing.

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 already documents each optional field, so the description's contribution is explaining what the generated login/password are for (opening the cabinet at cabinet_url) and that everything is optional. It does not add format or validation detail for 'agent', 'email' or 'telegram', hence not a 5.

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 ('Opens a new SnapEX Pay merchant account') and immediately names what it produces: a merchant API key with all scopes. It is unmistakable against the sibling set, where get_account reads and everything else (create_invoice, create_payout, ...) operates on an already-existing key.

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?

Explicit when-to-use and when-not-to-use: 'Call it once, only when you have no key yet (other tools answer "unauthorized")'. That gives the agent both the triggering condition and the observable symptom that selects this tool over any sibling.

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 description adds substantial behavior beyond the annotations: it names the prerequisite preview_conversion quote, the expires_at timing constraint, the immediate balance change, and the idempotent behavior of returning the same conversion on repeat calls. These details are consistent with the destructive and idempotent hints.

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 two tight sentences, front-loaded with the step and action, and every clause adds operational meaning 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 one-parameter mutation tool with rich annotations, the description covers the prerequisite, timing, side effect, and idempotent behavior. An agent has enough information to invoke it correctly without needing 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 coverage is already 100%, including the preview_id description. The tool description adds only the expiry constraint on the preview quote, which is useful but does not go much beyond what the schema already documents for the single parameter.

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: it executes a preview_conversion quote. It also frames the operation as 'Step 2', which clearly distinguishes it from the sibling preview_conversion step.

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 clearly says this is the execution step for a preview_conversion quote and must happen before expires_at, which gives strong usage context. It does not explicitly state exclusions or failure behavior if the quote has expired, so it falls just short of fully explicit when/when-not guidance.

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 write, open-world, idempotent, non-destructive, so the safety profile is partly covered. The description goes beyond them with real behavioral detail: test invoices self-pay ~10s after coin selection and do not touch the balance, and funds settle to USDT minus fee. It stops short of stating auth/permission requirements or expiry/rate limits, so a 4 rather than a 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?

The purpose and return value are front-loaded, then usage rules, then the test-mode caveat, then follow-up steps — a sensible priority order with no filler. It is dense and long-ish for a single paragraph, but each sentence carries distinct operational information.

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 13 optional parameters and no output schema, the description still covers what matters: what is returned (pay_url), what happens to the money, how test mode behaves, and how to track status afterwards. Remaining gaps (redirect URLs, expiry) are fully documented in the schema, so nothing an agent needs to call this correctly is missing.

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. The description still adds cross-parameter meaning the schema doesn't: the either/or between amount_usd and price_amount + price_currency, and that asset_id (+ lock_method true) yields a deposit address instead of a page — exactly the dependency an agent could otherwise miss.

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?

A specific verb plus resource ('Creates an invoice') followed immediately by the concrete return value (pay_url) and the money semantic (credited to balance in USDT minus fee). It distinguishes itself from lookalike siblings by explaining the pay_url page versus a raw deposit address and pointing to select_invoice_payment_method for that other case.

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 the two accepted amount paths (amount_usd, or price_amount + price_currency with get_fiat_rates named), the test-mode path, and the follow-up path (get_invoice or invoice.paid webhook). Alternative tools and the conditions that select them are named explicitly rather than inferred.

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 this is a non-read-only, idempotent, non-destructive, open-world call, so the safety profile is covered. The description adds valuable context the annotations lack: the response shape (deposit_address/deposit_memo/amount) and the expires_at deadline the payer is bound to. It stops short of describing what happens on expiry or duplicate external_id conflicts.

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?

A single front-loaded sentence with no filler, opening on the verb and resource. The trailing return-value clause is slightly dense with nested parentheses, but each element is informative rather than 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?

There is no output schema, and the description compensates by enumerating the key return fields and the payment deadline. Combined with fully documented parameters and clear annotations, an agent has enough to call it correctly; only edge-case behavior (expiry, retry conflicts) is unstated.

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%, with each parameter documented including the idempotency_key retry semantics, so the schema carries the load. The description only reinforces that credit_lock_id originates from preview_payment, adding no syntax or constraint detail beyond the schema. 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 ('Creates a payment') and names the exact input source ('from a preview_payment quote'), which cleanly separates it from the sibling preview_payment. The return contract (deposit_address, deposit_memo, amount, expires_at) further pins down what this call produces.

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 makes the workflow prerequisite explicit by tying the call to a preview_payment quote, so an agent knows it must preview first. It does not, however, exclude adjacent options such as create_payout or create_conversion, nor state what to do if the quote has expired.

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 flag destructive/idempotent/openWorld, but the description adds context they cannot: funds are real and irreversible once sent, and the idempotency key must be reused on retry after a timeout so funds are never sent twice. That is precisely the operational knowledge an agent needs before invoking a money-moving call.

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?

A single tight paragraph: flow position first, then the irreversible warning, then the idempotency rule, then the follow-up path. Every sentence carries non-redundant information and the highest-risk fact 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 destructive, money-moving tool with no output schema, the description supplies the full lifecycle: prerequisite quote, parameter-matching rule, retry safety, and where to read the outcome (get_payout status/transaction_url or webhooks). Nothing an agent needs to call it safely is missing.

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 cannot: destination_network and destination_address must be identical to the preview, and idempotency_key has a retry-reuse contract rather than just being a unique string. It stops short of describing external_id or destination_memo, which is acceptable given full schema coverage.

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 ('executes a preview_payout quote and sends real funds from your balance') and positions itself as step 2 of a flow, which cleanly distinguishes it from preview_payout and get_payout. An agent can identify the tool's role 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 sequencing ('Step 2 ... executes a preview_payout quote'), a precondition (preview must not be expired, carried via preview_id), a constraint (destination fields must match the preview), and named alternatives for the follow-up path (get_payout vs webhooks payout.completed / payout.failed).

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=false, idempotentHint=true, and destructiveHint=false. The description meaningfully elaborates on the idempotency (same address for same customer_ref) and discloses the key side effect that transfers are credited to the balance in USDT as separate payments. It still omits authentication needs and rate limits, but adds useful context beyond the annotations.

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 three dense sentences with zero waste. The core action and idempotency are front-loaded, followed by the use-case hint and a sibling pointer, all without unnecessary 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?

Given the moderate complexity, rich schema, and annotations, the description covers the essentials: what the tool does, idempotency behavior, credit conversion, and where to find network codes. It does not explain what happens when customer_ref is omitted (e.g., whether a new address is generated per call) or the exact return value, but these are minor gaps for a create/upsert operation 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 description coverage is 100%, so the schema already documents all four parameters, including the customer_ref semantics ('one address per customer'). The description reinforces the idempotency link for customer_ref but adds no new formatting or constraint details; baseline 3 is appropriate when the schema does the heavy lifting.

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: 'Gets (or creates) a permanent deposit address for a coin/network and optional customer_ref.' It clearly differentiates itself from the sibling list_static_address_networks by pointing to it for network codes, and the permanent/idempotent nature separates it from one-off payment creation tools.

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 gives clear context for when this tool is appropriate ('good for top-ups') and points to list_static_address_networks for network selection. However, it does not explicitly contrast with create_payment or create_invoice for one-off deposits, so the agent must infer that this is only for reusable customer addresses.

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 only cover the safety profile (not read-only, not destructive, not idempotent, open-world), and the description goes well beyond them: the secret is returned once and never again, deliveries are at-least-once so consumers must dedupe by Webhook-Id, signature verification uses HMAC-SHA256 over timestamp plus raw body, and there is a hard cap of 10 endpoints. That is exactly the operational context an agent cannot get from structured fields.

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 dense sentences with no filler; the what-is-it sentence leads, followed by the return value and the delivery contracts. It is information-heavy but front-loaded, with only minor compression loss from stacking signature, dedupe, and limit details together.

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 correctly carries the return-value burden by explaining the one-time secret, and it also covers verification procedure, delivery semantics, and the endpoint quota. An agent has everything needed to create the webhook and tell the user how to consume it.

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 url and events are already documented, including an enum list and a typical event set example. The description adds the delivery payload shape ({id, type, created_at, data}) but nothing further about the two parameters themselves, 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?

"Registers a public HTTPS URL that receives a POST for each chosen event" is a specific verb+resource statement with the payload shape spelled out. It clearly conveys creation, but it never names update_webhook, list_webhooks, or rotate_webhook_secret as the alternatives, so sibling differentiation is inferred rather than stated.

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 "Registers" and the "Up to 10 endpoints" ceiling, which tells an agent this is the create path for a limited resource. There is no explicit when-to-use/when-not guidance or pointer to update_webhook for modifying an existing endpoint.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the non-obvious behavioral fact that mcp_personal_url is a secret containing the key, which an agent needs before echoing output — useful context beyond the annotations, though it doesn't spell out the exposure risk explicitly.

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, zero waste: the return contents come first, then the usage cue. The field enumeration earns its place because there is no output schema to carry it.

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 enumerating the returned fields (login, key prefix and scopes, cabinet_url, mcp_personal_url). An agent has everything needed to call it and interpret 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?

Zero parameters, so the schema baseline is 4 and there is nothing for the description to clarify. It correctly adds none of its own parameter detail, which is the right choice.

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 ('Returns') and precise resource ('the account behind the API key in use'), then names the concrete fields returned. It is unmistakable against siblings like get_balances or list_transactions, which return different resources.

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?

'Use it to check you are connected to the right account' gives a clear triggering context. It doesn't name an alternative or state when-not to use it, but with no comparable sibling (nothing else reads the current key's account) the omission is minor.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantive context beyond them: all amounts are normalized to USDT TRC20 accounting regardless of the payer's coin, and each balance is returned both as a decimal string and in atomic units. No output schema exists, so explaining the two buckets and their meaning ('held' = reserved by payouts in progress) is doing real work.

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?

A single compact sentence pair, front-loaded with the verb and result, then the accounting rule, then the two bucket definitions. The parentheticals are dense but each one carries semantics an agent needs; nothing is redundant 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 zero parameters, full annotation coverage, and no output schema, the description is exactly the right place to define return shape, and it does: two balance categories with definitions plus dual numeric representations. An agent has everything needed to call and interpret 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?

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. No wasted text is spent restating an empty 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 ('Returns the account balance') and immediately scopes it to the two balance categories (available, held). This is unmistakably distinct from siblings like get_account or list_transactions, so an agent can select it 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?

Usage is only implied: the mention that 'available' can be paid out or converted now hints at pre-payout/pre-conversion checks, and 'held' being reserved by in-progress payouts signals reconciliation use. There is no explicit when-to-use statement or named alternative, which is a real gap even for a zero-param read.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety and determinism are covered. The description adds that the response includes status and amounts, but says nothing about behavior when the ID is unknown or about object relationships (e.g. preview_id linkage).

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?

A single short clause with no filler, and the return content (status, amounts) is front-loaded. It is efficient but borders on under-specification rather than tight prose.

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 single-resource read with full schema coverage, no output schema and strong read-only annotations, this is close to adequate. Still missing is a not-found/error note and any hint of how the returned ID relates to preview_conversion output.

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% for the single required parameter, and the schema already documents conversion_id as the preview_id. The description adds no further parameter meaning, so the baseline 3 for a fully covered schema 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 identifies the resource (a single conversion) and what it returns (status and amounts), which implicitly separates it from list_conversions. However, it is a noun phrase with no verb, so it reads as a label rather than a stated action, and it never explicitly says 'retrieve by ID'.

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 guidance on when to use this versus list_conversions (fetch many) or preview_conversion/create_conversion. The singular noun hints at single-resource retrieval, but no alternative is named and no condition for selection is given.

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 readOnly/idempotent/non-destructive/closed-world, and the description adds genuinely new behavior context: no API key required, that the route-quote data is cached and frequently empty, and how fee_on=customer shifts the invoice fee to the payer. It doesn't cover freshness/staleness of the quotes or response shape details, but for a read-only reference endpoint that is a minor gap.

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 what it charges, then split into 'pricing:' and 'data:' buckets with comma-separated field names. Every clause carries information (auth, fee formula, cross-tool pointers, emptiness caveat) and nothing is padded.

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?

There is no output schema, and the description compensates by enumerating the pricing fields an agent will receive (invoice_fee_percent, min/max USD, static address and payout service fees) and by flagging that the cached quote list may be empty. Combined with the cross-references to preview_payout and list_assets, an agent has enough to call it and interpret 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 coverage is 100% and the schema already explains route and the two asset_id codes, so the baseline is 3. The description only adds that route/asset filter the cached-quote portion; most of its text documents returned fields rather than parameter meaning.

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 concretely that this returns SnapEX Pay's fee schedule (invoice, static address, payout service fees) plus cached route fee quotes, and it explicitly separates static pricing from the dynamically quoted network fee. It names the sibling tools that cover the parts this tool doesn't, so an agent can distinguish it from preview_payout and list_assets immediately.

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 gives real routing guidance: network fees come from preview_payout, per-coin minimums come from list_assets, and the cached quote section is 'often empty'. It stops short of a crisp 'call this first, then preview_payout' ordering or saying when the cached data is worth querying at all, but the alternatives are named explicitly.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond them: no API key required, and an unknown currency yields not_found rather than an error or empty result. Rate freshness/caching is not mentioned, which keeps it short of a 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 compact clauses, front-loaded with the core definition, then behavioral branches, then the auth note. No filler, and every clause carries information an agent needs.

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 must hint at return shape, and it does: an all-rates collection versus a single rate plus a not_found case. It stops short of describing the all-rates structure (e.g., keyed by currency code), a minor residual gap for a one-parameter lookup tool.

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% (pattern, example, ISO 4217 note), so the baseline is 3. The description goes further by explaining the semantics of omission (returns all rates) and of a non-matching value (not_found), which the schema does not convey.

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 (fiat → USD rates) with directionality, and ties it to the concrete consumer (create_invoice with price_amount + price_currency). No sibling in the list retrieves exchange rates, so the distinction is unambiguous.

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 invoice-pricing context tells the agent when this tool is relevant, and the two modes (omit currency = all rates, supply currency = one rate) are spelled out. There is no explicit when-not or named alternative, but none is needed here.

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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds value beyond them: the exact status vocabulary (open, awaiting, underpaid, paid, partially_paid, expired) and a polling cadence that implies expected latency/rate behavior. Missing only error behavior (e.g. unknown invoice_id).

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 dense sentences, zero filler: the return contract comes first and the operational advice second. Every clause earns its place and nothing is repeated from annotations or schema.

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 usefully enumerates the return fields and status values, and the polling/webhook guidance covers the blocking decision an agent faces. Slightly short of complete because nothing is said about failure modes (invalid or expired invoice_id) or whether payment attempts are truncated.

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 single parameter already carries the 'invoice_id from create_invoice' provenance note in its schema description. The tool description adds no further parameter meaning, 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 ('Returns') and resource ('one invoice'), then enumerates the payload: status with its enum values, pay_url, credit_usd, selected coin, and payment attempts. This clearly separates it from list_invoices (many) and get_payment (a different resource).

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 concrete operational guidance: poll every 15–30 s while the payer pays, or use webhooks instead — naming a real alternative pattern backed by the create_webhook sibling. It lacks explicit exclusions against sibling getters like get_payment, but the usage context is unambiguous.

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 this as read-only, idempotent, and non-destructive. The description adds useful behavioral context by naming example status values and the returned payment details, though it does not mention error cases such as an unknown payment_id.

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 compact and front-loads the resource before enumerating key fields. It is phrased as a fragment rather than a sentence, but every element is relevant.

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 read-only annotations and no output schema, the description supplies the essential return-value context: status states, expected/received/credited amounts, and deposit address. It is adequate for a simple one-parameter lookup, missing only edge-case 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 coverage is 100%, so the payment_id parameter is documented structurally, though its schema description is only tautological. The description adds slight meaning by noting that a payment can originate from an invoice, a static address, or create_payment.

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 clearly identifies a single-payment lookup and lists the returned status/amount/address fields, distinguishing it from list_payments by singular scope. It does not explicitly say "retrieve" but the intended purpose is clear from the title and field list.

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 implies usage by mentioning the payment may come from an invoice, static address, or create_payment, but gives no explicit when-to-use guidance versus siblings such as list_payments or get_invoice.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond that by enumerating the status values and explaining that manual_review means SnapEX staff reviews the payout, plus noting the hash/URL are in the destination network's explorer.

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?

A single compact sentence with the resource front-loaded and no filler; every clause conveys return-field or status-value information the agent would otherwise have to guess.

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 carries the burden of describing returns, and it does so for the key fields (status, amounts, fee, tx hash/url). Only pagination/error behavior and the create_payout prerequisite are left unstated, which are minor for a single-record read.

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 single parameter is already documented as "payout_id from create_payout." The description adds no further parameter meaning, which is acceptable but hits the baseline 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?

"One payout:" plus an enumeration of what is returned (status, amounts, fee, transaction_hash, transaction_url) makes the singular-record retrieval purpose unambiguous. It does not explicitly name the sibling it contrasts with (list_payouts), so sibling differentiation is only implicit via "One".

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 only implied: the singular framing signals "fetch one known payout", implicitly selecting it over list_payouts. There is no explicit statement of when to use it, what prerequisite a payout_id has, or when to prefer the list tool.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful context beyond annotations by saying no key is needed and that the list reflects assets currently supported, though it does not discuss pagination or rate limits.

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 front-loaded with the core purpose and return fields, followed by the key usage instruction. 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?

With no input parameters, no output schema, and rich read-only annotations, the description provides enough context for correct invocation. It explains what the tool returns and when to call it, which is sufficient for this simple catalog endpoint.

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 has zero parameters, so there are no parameter semantics to explain. The baseline for a parameterless tool is 4, and the description appropriately does not invent parameter details.

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: it lists the coins and networks supported by SnapEX Pay. It also names the returned fields, including asset_id, symbol, network, decimals, price_usd, payment, payout, and payout_min_usd, so the agent can distinguish this catalog tool from transaction-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 gives clear usage context: call it before creating invoices, payouts, or conversions to pick valid asset codes. It does not explicitly state when not to use it or name an alternative, but there is no obvious sibling alternative for asset discovery.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavior: results are ordered newest first and pagination is cursor-based. It says nothing about rate limits, total counts, or what a conversion record contains.

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 fragments with no filler, and the most important facts (scope, ordering, pagination) are front-loaded. It is arguably too terse given the undocumented status filter, but nothing is wasted.

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 should say more about what a conversion record looks like or how the cursor loop terminates, and it should cover the status filter. Annotations carry the safety burden, so the remaining gaps are moderate rather than fatal.

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 67%: limit and cursor are well documented in the schema and the description only echoes the cursor pagination idea. The 'status' parameter has no description and no enum, and the description never mentions that filtering by status is even possible, leaving a real gap uncompensated.

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 names the resource (conversions) and the scope (of the account) plus the ordering (newest first), which is enough to distinguish it from get_conversion or the create_* siblings. It is a noun phrase with no explicit verb, but the intent is unambiguous.

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_conversion (single item) or list_transactions, nor any prerequisite or exclusion. The agent must infer usage entirely from the name and the 'of the account' scoping.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results are ordered newest first and results are cursor-paginated, which tells the agent how to page through.

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, no filler, with the resource and ordering front-loaded and pagination mentioned last where it belongs.

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, annotated list tool with no output schema, the description covers scope, ordering, filtering, and pagination. Only the shape of returned invoice records is unaddressed, which is a minor gap given the absence of 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 coverage is 75% and the limit/cursor parameters are well documented there, so the schema does the heavy lifting. The description confirms status and environment act as optional filters but adds no syntax or format detail beyond the schema's enum and examples.

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 (invoices of the account), plus sort order and available filters – enough to distinguish it from the get_invoice single-resource sibling. It does not explicitly contrast with list_payments/list_conversions, so differentiation is implied rather than stated.

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: this is the listing tool for invoices, versus get_invoice which fetches one. No explicit when-to-use, exclusions, or named alternatives are given, leaving the agent to infer the choice.

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 readOnly, idempotent, non-destructive, so safety is covered. The description adds two genuinely useful beyond-schema facts: results are ordered newest first and paging is cursor-based. It stops there, saying nothing about whether filters other than status exist or what the page envelope looks like.

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 clauses, front-loaded with the resource, ordering, optional filter, and pagination model. Every phrase carries information and nothing is padded.

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 zero-required-parameter read-only list tool with full schema coverage and rich annotations, the description covers scope, ordering, filtering, and paging — enough to call it correctly. No output schema exists, so a brief note on the response envelope would be the only remaining gap.

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%, with limit bounds and the cursor semantics fully documented in the schema, so baseline is 3. The description only restates that status filtering is optional and pagination is cursor-based, adding no syntax or default detail 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 the resource scope (payments of the account) plus ordering (newest first) and the optional status filter, so an agent knows exactly what it retrieves. It does not explicitly distinguish itself from siblings like get_payment or list_payouts, but the list-vs-get framing makes the intent clear.

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 only implied through the resource description and the 'optionally filtered by status' clause; there is no explicit when-to-use guidance pointing to get_payment for single-record retrieval or list_payouts for a different resource. An agent could infer the split, but nothing is spelled out.

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 read-only, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: result ordering ('newest first') and cursor-based pagination, both of which affect how an agent consumes results.

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 compact sentence plus a fragment, both front-loaded with the most important information (resource, scope, ordering) before the secondary pagination note. No filler or repetition of the title.

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 three-parameter, read-only list tool with no output schema and full schema coverage, the description covers resource, ordering, filtering, and pagination. The main omission is that no valid status values are given, which matters because the parameter has no enum.

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, and the description still adds some meaning by confirming the status filter is optional and that the listing is cursor-paginated. It does not add format details beyond the schema (e.g., valid status values, since there is no enum), leaving a small gap.

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 ('Payouts of the account') and adds scope ('newest first, optionally filtered by status'), which clearly separates it from get_payout and create_payout. It does not explicitly name the sibling list tools it must be distinguished from, but the resource is specific enough to select the right tool.

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 rather than stated: 'of the account' tells the agent this is the account-wide listing rather than a single-payout lookup, and 'optionally filtered by status' hints at the filtering alternative. There is no explicit when-to-use vs. when-not, and no mention that filtering by payout ID requires get_payout.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds that results are paginated with a cursor and what each record contains (status, credited USDT), but says nothing about ordering, whether pending/unconfirmed deposits are included, or cursor exhaustion 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?

Two short sentences with the scope front-loaded and no filler. The trailing 'Paginated with cursor' is largely duplicative of the cursor parameter description, a minor redundancy rather than a flaw.

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, fully-described 3-parameter list tool with no output schema, the description does the needed extra work by saying what a returned deposit carries (status and credited USDT). Only ordering and filtering/edge-case behavior are absent, which are secondary here.

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 address_id, limit (1–100, default 25) and cursor semantics are already fully documented. The description only restates that the call is paginated via cursor, adding no format or hint beyond the schema — 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 the resource precisely: transfers received on one permanent (static) address, including status and credited USDT. The verb is implicit in the tool name (list) rather than the description, and no sibling such as list_static_addresses or list_transactions is named to sharpen the boundary, but the scope is unambiguous.

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 only implied: the required address_id and the schema note 'address_id from create_static_address' suggest the follow-up pattern after creating a static address. There is no explicit when-to-use, when-not-to-use, or pointer to alternative listing tools.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds pagination behavior ('Paginated with cursor'), though the schema already documents the cursor parameter. It says nothing about ordering, what happens with an unknown customer_ref, or what each item contains.

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 with no filler; the resource identity is front-loaded and the scope qualifier follows immediately. The fragmentary telegraphic style borders on under-specification rather than excess.

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 zero-required-parameter read-only list tool whose annotations carry the safety profile, the description is adequate but thin: with no output schema, an agent learns nothing about the shape of a returned address (address string, network, customer_ref) or the ordering of 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?

At 67% schema coverage, the two pagination params are fully documented in schema and the description only restates cursor paging. Its real contribution is clarifying that customer_ref is an optional single-customer filter — the one parameter the schema leaves bare. That is useful but minimal, so baseline 3 holds.

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?

Names the resource precisely ('permanent deposit addresses of the account'), which is a different object from the sibling list_static_address_deposits and list_static_address_networks. It's a noun phrase rather than a verb, but the listing action is unambiguous. It does not explicitly contrast itself with create_static_address or the two other static_address list tools, so it falls short of full sibling differentiation.

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?

'optionally for one customer_ref' implies the filtered-listing use case, but there is no statement of when to prefer this over list_static_address_deposits or create_static_address, nor any prerequisite or exclusion. Usage is inferable from the resource name only.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: no API key is required, and deposits are always credited in USDT regardless of the network chosen — a non-obvious rule an agent could otherwise get wrong.

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?

A single dense sentence with no filler: purpose first, then the field list, then the workflow pointer and the USDT crediting rule. Every clause carries information an agent needs.

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 full schema coverage, the description's enumeration of returned fields (asset code, symbol, network, available, credit currency) fills the only real gap. Nothing needed to call it correctly is missing.

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 zero parameters, so the baseline is 4. The description correctly makes no parameter claims and instead spends its words on the return fields, which is the right allocation for a no-arg listing call.

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 ("lists the coins/networks for which you can get a permanent deposit address") and enumerates the returned fields, which separates it cleanly from list_assets and list_static_addresses. An agent can tell what it gets without opening a 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?

The parenthetical reference to create_static_address makes the intended workflow clear: call this first to pick a network, then create the address. It does not explicitly state exclusions (e.g. when to use list_assets instead), so it falls 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 cover readOnly/idempotent/non-destructive, so the description's added value is the ordering guarantee (newest first) and the pagination model (cursor), both of which the agent needs to page correctly. It does not say how pagination terminates or whether meta.next_cursor is absent on the last page, which keeps it from a 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?

A single dense sentence with the core identity front-loaded and the qualifying details (contents, ordering, pagination) packed into the tail. No filler and nothing repeated from the schema.

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 zero-required-parameter read tool with rich annotations and no output schema, the description covers what the entries are, their fields, ordering and pagination — enough to call it correctly. The one real gap is the ambiguous `status` filter, which neither the schema nor the description resolves.

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 limit and cursor are already fully documented and the description only echoes the paginated-with-cursor idea. Notably it says nothing about the `status` filter, and the schema's own wording ('Filter by ledger entry type') is odd against a parameter named status, so the description could have disambiguated but does not.

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 names the resource precisely (ledger of the balance) and enumerates its contents — credits and debits from payments, payouts, fees and conversions — with amount, direction and time. That enumeration implicitly separates it from the single-resource siblings (list_payments, list_payouts), but no sibling is named explicitly, so it falls short of 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?

Usage is only implied by content: it is the place to look for a historical, chronological record of balance movements. There is no statement contrasting it with get_balances (current balances) or with the per-resource list tools, so an agent must infer which one it wants.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds only the returned field set; it says nothing about pagination, ordering, or what an empty account returns.

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?

A single fragment with no waste and the resource front-loaded, but it is compressed to the point of being verbless, and the field enumeration is jammed in as a colon list. It is efficient rather than well-structured.

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's field list does useful work in place of one. But for a list endpoint it leaves out pagination/result-limit behavior and any indication of scope (all webhooks for the authenticated account), which is the main thing an agent still has to guess.

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 zero parameters and the schema is fully described, so there is nothing for the description to disambiguate. Baseline 4 applies; the field list is a bonus rather than a gap-filler.

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 names the resource precisely ('Webhook endpoints of the account') and enumerates the returned fields (endpoint_id, url, events, status), so an agent knows it is a read of webhook endpoints rather than the create/update/rotate siblings. The verb is only implied by the tool name rather than stated, which keeps it short of 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?

It conveys no when-to-use guidance, no exclusions, and does not point at create_webhook, update_webhook, or rotate_webhook_secret as alternatives for non-listing needs. A reader must infer from the name alone that this is the discovery step before updating a webhook.

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?

Adds real context beyond the annotations: 'nothing moves yet' clarifies state despite readOnlyHint=false, and the return shape (preview_id, amounts, expires_at) is disclosed. It doesn't cover auth requirements or how long a preview stays valid beyond the expires_at mention, so it stops short of a 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?

Front-loads the step number and purpose, then mode semantics, then the follow-up call. Dense but every sentence carries routing or behavioral information; the parenthetical about USDT crediting is slightly discursive but justifies why the tool exists.

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 7-parameter mutation-adjacent preview with no output schema, the description covers purpose, mode branching, the no-side-effects guarantee, the returned fields, and the next step. An agent has everything needed to call it correctly and interpret 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 coverage is 100%, so the baseline is 3, but the description adds the mode interaction that the schema documents only piecemeal: 'single' converts amount of from_asset_id to USDT or to to_asset_id, while 'all_to_usdt' sweeps every non-USDT holding. It also implies the USDT default for to_asset_id, which is useful cross-parameter semantics.

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 ('Step 1 of converting assets... into USDT') and explicitly positions itself as the preview stage before create_conversion. An agent can distinguish it from create_conversion and preview_payout without opening any 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 when-to-use context ('this matters only for an account that still holds another asset'), names the alternative for the opposite direction (send a payout via preview_payout), and names the follow-up call (create_conversion). Nothing about routing is left 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 idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the bar is lower. The description still adds real context beyond them: the result is a time-limited lock ('valid until expires_at') that is consumed by create_payment, which explains why a quote tool is marked readOnlyHint=false. It doesn't mention auth or rate-limit 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?

Three short sentences, each doing distinct work: what it is, what it returns and the downstream handle, and the sibling recommendation. The routing advice is placed last, after the agent already knows what the tool does.

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?

There is no output schema, but the description covers the key return fields (credited USDT, credit_lock_id, expires_at), which is exactly what the agent needs to chain into create_payment. With 100% schema coverage and clear annotations, nothing material is missing.

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 schema already documents amount, amount_atomic, asset_id, and idempotency_key in detail. The description adds only the framing that the amount is what the payer sends in a single coin; it says nothing about the amount vs. amount_atomic exclusivity or idempotency, so 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 ('quotes a payment of an exact amount in one coin') and what comes back ('how much USDT you will be credited'). It explicitly positions itself as a low-level alternative to invoices, which separates it from create_invoice, preview_conversion, and preview_payout without opening any 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 an explicit routing rule: 'Most agents should use create_invoice instead,' plus the handoff to create_payment via credit_lock_id. It stops short of stating the positive condition under which an agent should actually prefer this tool (e.g. need for an exact-amount, single-coin quote), leaving that 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?

Adds real context beyond the annotations: 'Nothing is sent yet and the quote is free' clarifies that the non-readOnly tool has no fund movement, and the expires_at / invalid_address behavior is disclosed. It doesn't discuss idempotency or retry semantics of the preview itself, but with annotations already covering safety and idempotency this is strong.

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 compact sentences, each earning its place: purpose and step, return fields, safety/expiry, and error case. Front-loaded with the workflow role and the no-side-effect guarantee.

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?

No output schema exists, so the description carries the return values (preview_id, to_amount, fee, expires_at) and does so explicitly. Combined with the expiry, error case, and next-step guidance, an agent has everything needed to call this 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 baseline is 3, but the description adds a constraint not in the schema: the destination coin must have payout=true in list_assets. That is genuinely useful filtering guidance beyond the field definitions.

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 ('Quotes a payout of amount USDT from your balance to an address') and positions it as 'Step 1 of sending money', which cleanly separates it from create_payout and the other preview_* tools. An agent can tell exactly what this does 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 a clear workflow: check address and amounts, then call create_payout with preview_id before expires_at, and points to list_assets for valid destination coins. It does not explicitly say what to do if a valid preview already exists or warn against skipping the preview, so it stops short of full when/when-not coverage.

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; the description goes further and discloses the two facts those hints don't convey: the new secret is displayed only once, and the old secret stops working immediately. That is exactly the irreversibility detail an agent needs before invoking a destructive write.

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?

A single sentence, front-loaded with the action, followed by two parenthetical-style consequences. No wasted words and nothing buried.

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 does cover the return-value nuance (secret shown once). For a destructive, non-idempotent mutation it could still mention auth/permission requirements or confirm that the endpoint itself is unaffected, but the essentials are 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?

Only one parameter, and schema coverage is 100% — the schema already documents endpoint_id with a UUID format and a pointer to list_webhooks. The description adds nothing beyond the schema, which is the baseline-3 case.

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 concrete verb+resource ('Issues a new signing secret for an endpoint'), which maps cleanly to the rotate_webhook_secret name. It does not explicitly contrast itself with update_webhook or create_webhook, so the sibling differentiation is only implicit.

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?

Rotation usage is implied by 'a new signing secret', but there is no explicit when-to-use, no exclusion (e.g., 'not for changing the endpoint URL — use update_webhook'), and no prerequisite statement. An agent can infer intent but must guess at 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 this mutates non-destructively and is idempotent and openWorld, so the bar is lower. The description adds real value beyond that: it discloses the return contents (deposit address and exact amount) and that the result lives in the invoice payment attempt, revealing the side effect. Auth requirements aren't mentioned.

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?

A single dense sentence that front-loads the action and the key return info, with the usage condition trailing. Every clause earns its place; the parenthetical is slightly awkward but informative.

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 correctly fills the gap by describing the returned deposit address and amount. Combined with annotations covering the safety profile, an agent has enough to call it correctly; only auth/permission context is absent.

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 both params are documented (asset_id from get_invoice_payment_methods, invoice_id from create_invoice). The description adds no syntax or format meaning beyond the schema, so the baseline of 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?

States a specific verb and resource ('chooses the coin for an invoice') and clarifies the return payload (deposit address + exact amount). It distinguishes the manual-payer flow from the pay_url flow, though it doesn't name the closest sibling get_invoice_payment_methods as the source of asset_id directly in prose.

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?

Explicitly says when to use it: 'when you pass the address to the payer yourself instead of pay_url.' That names the conditional and implicitly the alternative, leaving little inference. It doesn't discuss prerequisites or failure cases, keeping it just shy 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 readOnly=false, idempotent=true, destructive=false and openWorld=true, so the safety profile is covered. The description adds genuinely useful semantics beyond that: 'Replaces' signals full overwrite of url and events rather than a partial patch, which changes how an agent must construct the call. It does not explain the effect of omitting status, keeping it from a 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?

A single front-loaded sentence with no filler; the replacement semantics come first and the status toggle is appended as a secondary case. Nothing is wasted.

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 mutation tool with no output schema and 50% parameter coverage, the description leaves open whether status is optional, whether omitted fields are cleared, and what the response contains. It is adequate to call the tool but not fully self-sufficient.

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 50%, so the description must compensate, and it does name three of four parameters (url, events, status) with their roles. However, it never clarifies that status is optional or what happens when it is omitted, and endpoint_id is only explained in the schema itself.

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 ('Replaces') and resource ('url and events of an endpoint') plus the secondary status toggle, which clearly separates it from create_webhook and rotate_webhook_secret. It does not explicitly name a sibling, so it stops short of 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?

Usage is only implied by the verb 'Replaces' — an agent can infer this is for modifying an existing endpoint rather than creating one. There is no explicit guidance on when to use this versus rotate_webhook_secret, nor any note about prerequisites such as needing an endpoint_id from list_webhooks.

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