CoinVello

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

With no annotations, the description carries the full burden and does disclose real behavior: the call returns a `url` the customer must be sent to, amounts are decimal strings rather than minor units, and order fulfilment must be driven by the invoice.paid webhook rather than the browser redirect. It omits auth requirements, what happens to expired sessions, and error/idempotency behavior (the latter only appears in the schema).

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 tight sentences with zero filler: identity of the resource, the required redirect action, the two format constraints that most often cause bugs, and the fulfilment rule. The most actionable guidance (redirect to `url`, fulfil from webhook) 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 17-parameter tool with nested objects, no annotations, and no output schema, the description covers the core contract — what gets created, what comes back (`url`), and how the order lifecycle completes. Remaining gaps are auth/prerequisite context and any note about test-mode sessions, which sibling simulate_test_payment implies exists.

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 59% across 17 parameters; the description only reinforces `amount` (decimal string) and `currency` (ISO code or asset id), both of which the schema already documents. Undocumented-in-schema params such as `locale`, `branding`, `customer`, `line_items`, `cancel_url`, and `collect_email` get no compensating explanation in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Create a CoinVello hosted checkout session') and immediately glosses the artifact ('an invoice plus a payment page at pay.coinvello.com'), which is far more informative than the title alone. It doesn't explicitly contrast with siblings like create_credit_purchase or simulate_test_payment, so routing between creation tools is left to inference.

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: 'Redirect the customer to the returned `url`' and 'Fulfil orders from the invoice.paid webhook, never from the redirect' — an explicit when/when-not for downstream fulfilment that prevents a common integration error. It stops short of saying when to choose this tool over create_credit_purchase or when to use simulate_test_payment instead.

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?

Since no annotations are present, the description is highly valuable. It goes beyond the technical API contract by explaining the full business flow: invoice creation -> payment option return -> payment confirmation -> credit addition.

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 three sentences are logically structured: the first defines the success/return, the second sets an operational constraint, and the third provides specific testing context, making every sentence serve a distinct purpose.

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?

Despite having no output schema, the description clearly defines what the agent should expect back (a payment option object containing an address and URL), which is necessary for successful tool usage.

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 schema coverage is only 50%, requiring the description to provide semantic value. While it confirms the nature of the payment (crypto wallet), it does not provide operational guidance on the required bundle_id or metadata construction.

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 states the tool creates a 'crypto credit purchase' and explicitly identifies the output as payment options (address/URL), distinguishing it from sibling tools like get_invoice or list_credit_bundles.

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 provides clear operational boundaries by stating what it does not handle (card/automatic top-ups, which are dashboard features) and gives specific instructions on testing ('pay it with simulate_test_payment').

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

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

With no annotations, the description carries the full burden and does: it discloses the return object shape (file name, content_type, bytes, sha256, signed download_url), the 7-day file retention and download_expires_at, the queued/processing states, the 422 failure mode for preset/dataset mismatches, and test-key behavior for include_simulated. This is unusually complete behavioral disclosure.

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 purpose and scope, and every sentence carries operational information. It is a single dense paragraph packing return format, polling rule, validation constraint, and test-mode caveat, which slightly hurts scanability but wastes nothing.

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 9-parameter tool with no output schema, the description supplies the return-value semantics, the async polling path, retention windows, and the failure constraint an agent would otherwise have to discover by trial. Nothing material to correct invocation 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 89%, so the baseline is 3, but the description adds real meaning beyond it: the preset/dataset/format coupling constraint and the test-mode semantics of include_simulated. It does not restate period/timezone/currency behavior, relying on the schema for those.

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?

Opens with a specific verb+resource ("Create an export of the records") and immediately enumerates the scope options (default records, another dataset, or `all` year-end package). It is clearly distinguishable from siblings like get_export and list_records.

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 routes the agent: null/omitted period means entire history, and "while `queued` or `processing` call get_export" names the alternative tool and the condition that selects it. It also states the constraint that vendor presets and journal require dataset=records with format=csv or else 422.

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?

With no annotations, the description carries the full burden and delivers real behavior: the wallet is usable immediately in both live and test mode, addresses are validated strictly on format/checksum/network and token contracts are rejected, and the returned first_address should be surfaced for merchant confirmation. It omits auth/permission requirements and what happens on a duplicate or invalid registration, 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?

Front-loaded with the core purpose, then type routing, then safety caveat — the ordering matches how an agent would plan the call. It is dense with long parenthetical sentences and the trailing signed-message verification sentence is somewhat tangential, but nothing is pure padding.

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 an 11-parameter mutation with a nested metadata object, no annotations and no output schema, the description covers the critical path and one return field (first_address) but leaves optional parameters and the full response shape unaddressed. Adequate for the happy path, incomplete as a complete specification.

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 45% across 11 parameters, so the description must compensate, and it does for the most important ones: the type branching, the xpub-vs-address requirement, and the chain pairing. It says nothing about label, enabled, metadata, assets, start_index, address_type or derivation_path, leaving half the surface to the schema alone.

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 ('Register a receiving wallet the merchant controls') and immediately splits the tool into its two operating modes, xpub for bitcoin vs address for EVM/Solana/Tron chains. An agent can tell exactly what this creates and which mode applies 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?

Explicitly routes the caller: use type=xpub for bitcoin, type=address for the ten listed chains, and 'Never pass a private key or seed phrase' closes off a plausible failure mode. It also notes verification is optional and never required, preventing unnecessary extra calls. It does not name a sibling (e.g. list_wallets or list_assets) as the alternative flow, 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?

No annotations are provided, so the description carries the full burden, and it delivers the single most important behavioral fact: `secret` is returned once and must be stored as COINVELLO_WEBHOOK_SECRET. It also discloses URL scheme rules (HTTPS for live, http://localhost for test), which is real operational context. Gaps remain around auth/permissions, idempotency, and what happens on duplicate URLs.

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 core action, then the critical secret caveat, then constraints. Four compact sentences with no filler, though the phrasing is dense and could group the URL rules more cleanly.

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 5-parameter mutation with a nested `metadata` object, no annotations, and no output schema, the description covers the highest-risk items (one-time secret, URL scheme) but leaves a third of the parameters and the full response shape undocumented. Adequate but with real gaps.

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 only 40%, so the description should compensate more than it does. It explains `events` (`["*"]` or a list of event types) and the `url` scheme rules well, but `enabled`, `metadata`, and `description` get no semantic treatment in the description at all.

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 ("Register a webhook endpoint") that maps unambiguously to a single action, and it is trivially distinguishable from siblings like verify_webhook_signature or create_checkout_session.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies when to use it (registering an endpoint for testing vs live, choosing event lists) but never names an alternative tool or states when not to use this one. The live-URL vs test-URL constraint is useful context, but there is no explicit routing guidance among the many create_* siblings.

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?

With no annotations, the description carries the full behavioral burden and does substantial work: it defines balance = available + reserved, guarantees non-negativity, explains that reserved represents estimated fees of open invoices paid with credits, and states the redemption formula (≈30 bps of fiat, floor 2, cap 2000). It stops short of saying this is read-only or what the response looks like when no wallet exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core return shape, then the pricing/consumption model that an agent needs to interpret the numbers. The dense field enumeration is load-bearing because there is no output schema to document 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?

Because there is no output schema and no parameters, the description must define the return fields and their units, and it does — including the credit-as-$0.01 conversion so values are interpretable. It omits edge behavior such as the response when no credit wallet exists, which would round it out.

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 adds no parameter discussion and instead spends its words on the return payload, which is the right allocation here.

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 — return the merchant's prepaid processing-credit balance — and immediately enumerates the returned fields, which cleanly separates it from siblings like create_credit_purchase and list_credit_bundles. An agent can tell this is the read-side of the credit lifecycle 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?

Usage is only implied: it is a zero-argument read of current credit state, so invocation itself is unambiguous. But nothing states when to prefer this over get_records_summary or get_rates, nor any precondition such as requiring an existing wallet, and no alternatives are named.

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?

With no annotations, the description carries the behavioral burden and does so well: it discloses status lifecycle values (queued, processing, ready, failed, expired), returned file metadata, download URL expiry, and failure_reason. It does not cover auth or rate limits, but the core retrieval behavior is transparent.

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-loaded, moving from the verb and ID format directly into return fields and polling guidance. Every element earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because there is no output schema, the description usefully explains the return fields and status values. It is nearly complete for a simple retrieval tool, though it does not mention error or auth behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents the sole id parameter as an exp_... ID from create_export. The description restates that context but adds no additional parameter semantics 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?

The description states a specific verb and resource: retrieve an export identified by an exp_... ID. It also enumerates the returned status values and fields, making the tool's purpose unmistakable and distinct from create_export.

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 explicitly says to poll after create_export until ready, which gives clear usage context and timing. It does not mention alternatives or exclusions, but the relevant sibling workflow is identified.

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?

With no annotations, the description does real work: it discloses the response contents, and critically that a cs_... id is accepted and returns the session with the invoice expanded — behavior an agent could not infer from the schema. It omits error/not-found handling and any rate-limit guidance for the polling use case it recommends.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with what is returned and back-loaded with the dual-id behavior. No filler or restatement of the tool name.

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 read tool with no output schema and no annotations, the description adequately conveys both input modes and the shape of the result. Missing pieces are failure behavior and pagination/refresh characteristics, which matter for the polling use it recommends.

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 notes "inv_... or cs_... id", so the baseline is 3. The description earns an extra point by explaining the consequence of passing a cs_ id (session returned with invoice expanded), 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 and resource (retrieve an invoice) and enumerates the returned payload: status, payment_options with address/amount/payment_uri/qr_payload, and paid summary. That payload detail plus the single-id form makes it trivially distinguishable from list_invoices and the rest of the sibling set.

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 for polling or reconciliation" gives an explicit usage context rather than leaving it implied. It stops short of naming when-not-to-use or pointing at an alternative (e.g. list_invoices for enumeration), so it falls just 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?

Since no annotations are provided, the description handles the behavioral disclosure. It successfully communicates that the returned data is indicative, which is essential behavioral knowledge for an agent using this tool.

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 brief and highly effective, front-loading the core function and immediately adding the necessary business context in a single, efficient sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete regarding the tool's purpose and limitations. Given the 100% schema coverage, no further information regarding inputs is strictly necessary.

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%, establishing the baseline of 3. The description does not add specific syntactic or semantic meaning to the parameters (like 'base' or 'assets') beyond what the schema provides.

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 the tool as providing mid-market rates for specific assets against a fiat base, setting it apart from the creation and listing 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?

The description provides crucial operational context by stating the rates are 'Indicative only' and contrasting this with the rate locking mechanism used when an invoice is created.

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?

With no annotations and no output schema, the description carries the full burden and does meaningful work: it names the returned aggregates, explains that sales use locked rates and that received_market_value is the value at arrival time, states period_start inclusive / period_end exclusive, and discloses the test-key filtering behavior. Gaps remain around authentication scope, aggregation limits, and the shape/units of the returned numbers, but the substantive behavior is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is dense but mis-ordered: a long comma-separated field list leads, while the actual operation and its period semantics trail behind it. Some material duplicates the schema (inclusive/exclusive boundaries are already stated on period_start and period_end), weakening the value per sentence.

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 6-parameter read tool with no annotations and no output schema, the field enumeration usefully substitutes for missing return documentation and the test-mode note covers a real edge case. However, nothing addresses authorization/permission scope, size limits on returned groups, currency defaulting, or error behavior — gaps an agent would likely hit.

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%, with timezone, period boundaries, and include_simulated already documented in the schema. The description adds value beyond it by explaining that occurred_at is bucketed in the given timezone and currency, and by naming the output container `groups` for group_by — semantics the schema's bare enum does not convey. It still says nothing about currency's default or conversion behavior, leaving one parameter thin.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a dense enumeration of returned fields rather than a verb+resource statement, so the purpose (aggregate totals over occurred_at for a period) must be inferred from the clause 'with payment counts, over occurred_at in the given timezone and currency' plus the title. It never distinguishes itself from the sibling list_records, which is exactly the ambiguity an agent facing both tools needs resolved.

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 boundary semantics of the period and 'group_by returns the same totals per month, asset, chain, type or address' hint at when the tool applies, and 'With a test key, simulated rows count only with include_simulated=true' is a genuine usage rule. But there is no explicit when-to-use / when-not-to-use guidance and no named alternative (e.g., list_records for row-level data).

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?

With no annotations, the description carries the full burden and does well: it discloses mode-dependence of results and the concrete consequence that a test key omits live-only tokens, naming them. It stops short of stating ordering, whether the list is static/cacheable, or rate limits, which would have made it 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?

Two sentences, front-loaded with the core meaning and followed by the important exception. The field list is dense but every item earns its place; the parenthetical examples of ids help rather than pad.

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 returned fields (id, symbol, chain, kind, contract_address, decimals, required_confirmations, min_amount, testnet name, wallet_type). Combined with the test-key caveat, an agent has enough to call and interpret it; only ordering and the chain-filter relationship are unaddressed.

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 chain parameter is fully documented by its enum, so the description adds nothing about filtering. Baseline 3 applies since the schema does all the work and the description never references the chain argument.

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 ('Every asset CoinVello accepts in the API key's mode') and then enumerates exactly what each entry contains. No sibling tool in the list deals with asset discovery, so 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 implied rather than stated: an agent can infer this is the discovery call before creating wallets or checkouts, and the test-vs-live caveat gives useful context. But there is no explicit 'use this when...' routing and no mention of the chain filter as a narrowing option.

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?

With no annotations provided, the description carries the full burden, and it does useful work: "List" implies a safe read, and the qualifier "indicative" on crypto_prices is a genuine caveat telling the agent those figures are not executable quotes. The volume-discount note also describes the shape of the data. It stops short of mentioning auth requirements or whether the bundle catalogue is static.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the resource and its returned fields, then a single pricing-structure note. Every clause carries information an agent would otherwise have to discover by calling the tool.

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-parameter, read-only catalogue tool with no output schema and no annotations, the description covers the resource, its return fields, and the pricing relationship. The only gap is that a caller comparing crypto pricing is told the values are indicative but not what to call to get firm rates.

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 disambiguate; baseline 4 applies. The description adds no parameter noise, which is correct here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb + resource ("List purchasable credit bundles") and it enumerates the fields returned (USD price, price_per_credit, crypto_prices per asset), so the agent knows exactly what it gets. It does not explicitly distinguish itself from near-neighbours like get_rates or get_credits_balance, 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?

Usage is only implied: the word "purchasable" and the price-per-credit detail suggest this is the tool to call before buying credits or comparing bundle economics. There is no explicit when-to-use, no prerequisites, and no named alternative for cases where the agent wants exchange rates (get_rates) or an account balance (get_credits_balance).

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?

With no annotations at all, the description must carry the behavioral load, and it does disclose two genuine traits beyond the schema: deterministic newest-first ordering and the pagination contract (has_more, next_cursor). It does not say anything about read-only semantics, rate limiting, or auth requirements, so the safety profile is left implicit in the word 'List'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences with zero filler: the core operation and ordering lead, filters follow, and the return shape is packed into the second sentence. Nothing is repeated from the schema unnecessarily.

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 seven-parameter read tool with no annotations and no output schema, the description covers the operation, ordering, main filters, and return envelope, which is most of what an agent needs. The gaps are the unmentioned date-range parameters and the absence of any explicit safety statement, which a mutation-free tool can largely get away with.

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 57%, and the description adds meaning for three of the seven parameters (status, order_id, customer_email) plus explains that cursor comes back as next_cursor. It says nothing about limit, created_gte, or created_lte, and does not clarify the enum values for status, leaving created_gte/created_lte dependent on the thin 'RFC 3339 timestamp' schema note.

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 ('List invoices') plus sort order and the filterable fields, so the agent immediately knows both what it does and the shape of the query surface. It implicitly separates from get_invoice (single record) but never names a sibling, so it stops short of full 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?

The mention of filterable fields implies usage contexts (find by status, by order, by customer), but there is no explicit guidance on when to prefer this over get_invoice for a known ID or list_payments for payment-level data. Usage is inferable but not stated.

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?

With no annotations, the description carries the burden: it does disclose the returned fields and the four payment lifecycle statuses, which is genuine value. However, it does not state that this is a read-only, non-mutating operation, nor anything about pagination semantics, ordering, or permissions.

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, front-loaded with what the tool returns and followed by the filterable dimensions. No filler, no restatement 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 six-parameter read tool with no annotations and no output schema, the description covers the return shape (tx_hash, confirmations, amount, status) and enumerates statuses, which is the key missing structured information. It omits pagination behavior and default ordering, but limit/cursor are described in the 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 33% (only limit and cursor are documented), so the description must compensate — it names invoice_id, status, chain and tx_hash as filters but adds no format or matching semantics (e.g., exact match, combinability). It partially fills the gap but leaves meaningful ambiguity.

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 ('List on-chain payments') and identifies the object prefix (pay_...), so the agent knows exactly what entity is returned. It doesn't explicitly contrast with sibling list tools (list_invoices, list_wallets, list_assets), but the resource is unambiguous enough to distinguish them.

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 naming the filterable fields, but there is no explicit when-to-use guidance, no statement of relationships to siblings (e.g., use get_invoice for a single invoice's detail vs. this tool for enumerating payments), and no note that all filters are optional.

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?

Given zero annotations, the description carries the full burden and excels by disclosing the internal logic of the data, such as how 'value' and 'currency' re-values are calculated and the specific return structure including pagination (`has_more`, `next_cursor`).

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 tool uses a very dense, single paragraph structure. While the information is comprehensive and efficient, the lack of separation or formatting makes it challenging for an AI agent to quickly parse the definition vs. the return structure.

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?

Due to the complexity of the data and the various optional filters (date ranges, asset types, simulation), the description is highly complete. It covers the data structure, the calculation logic, the ordering, and the pagination mechanism.

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 schema coverage is 58%. The description adds semantic value by defining the meaning of the output fields, such as 'contract_value' and 'on-chain proof,' helping the agent understand the data the parameters filter for, but it doesn't dramatically exceed the input schema 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 goes beyond merely listing records; it defines them as an 'immutable row per movement of value' and specifies exactly what financial data points (e.g., value, value_usd, tax, tx_hash) constitute the record, clearly distinguishing it from simple payment logs.

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 implies usage by detailing the specific transaction types it tracks (payments, fees, refunds). It also provides a specific instruction on how to handle test data via the 'include_simulated' parameter, which is a practical usage guideline.

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?

No annotations exist, so the description carries the full burden. 'List' plus the field enumeration implies a safe read, but it does not say whether archived/unverified wallets are included by default, how results are ordered, or that results are paginated. It also lists status values (active/verified/archived) that omit the schema's 'unverified', leaving ambiguity about default scope.

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, front-loaded with what the tool returns and followed by the use case. No filler, though the field enumeration is slightly muddled by mixing return fields and filterable fields in one phrase.

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 no-annotation, no-output-schema read tool with four optional parameters, the description covers purpose and return shape but omits pagination expectations, default inclusion of archived wallets, and the relationship to list_assets. Adequate to invoke, but leaves real decisions to inference.

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%: limit and cursor are documented in-schema, while chain and status rely on enums alone. The description partially compensates by naming the filterable fields, but it mentions a 'type' field that is not a parameter and gives an incomplete status list, which can mislead an agent about what is filterable.

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 ('List registered wallets') and enumerates the returned attributes (chain, type, status, accepted assets), which is enough to distinguish it from create_wallet and list_assets. It stops short of explicitly naming the closest sibling, list_assets, so it is clear but not fully differentiated.

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 sentence 'Use it to see which assets can be offered on an invoice' gives a concrete selection context rather than a generic 'use to list wallets'. However, it offers no exclusions or alternatives (e.g., when to prefer list_assets), so an agent must still infer the boundary with sibling 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?

With no annotations, the description carries the full burden and does well: it discloses that real webhooks fire, that test keys are required, and the state transitions tied to confirmations. It stops short of covering irreversibility, rate limits, or the effect of delay_seconds/from_address.

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, front-loaded sentences with no filler; the key constraint (test keys only) and the state-transition mappings are stated in shorthand that an agent can act on immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, no-output-schema mutation tool, the description covers the essential mechanics (state machine, webhooks, confirmations thresholds, tx_hash reuse). The two underexplained parameters and absence of error/response behavior leave a minor 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?

Only confirmations, tx_hash, and amount get meaningful semantic treatment (advance same payment, underpaid/overpaid). At 57% schema coverage, from_address and delay_seconds are undocumented in both places, so the description only partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a synthetic on-chain payment') scoped to invoice (inv_) or credit purchase (cpu_) IDs, and clarifies it drives the real state machine and webhook pipeline. This clearly separates it from siblings like create_credit_purchase or list_payments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly restricts usage to test keys and explains the confirmations-based outcomes plus how to simulate underpaid/overpaid. It gives strong operating context, but never names an alternative tool or an explicit 'do not use in production' exclusion beyond 'test keys only'.

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