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 the critical input constraint: the file must be a base64 data URL with an explicit example. It does not say what happens on duplicate uploads, size or MIME limits, required permissions, or whether the document then becomes visible to compliance review.

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 filler, with the operation and target front-loaded and the format constraint second. Nothing could be removed without losing 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?

For a five-parameter mutation with full schema coverage and no output schema, the description supplies purpose, target objects and payload format. It stops short of covering behavioral outcomes (post-upload visibility, error conditions) that an agent would want before invoking a write 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 description coverage is 100%, so the schema already documents all five parameters including the enums and their defaults. The description only reinforces the base64Url format with an example, adding minor value over 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 ('Attach a supporting document') plus the two attachment targets (transfer or payment route deposit). This is clearly distinguishable from siblings like list_documents, get_document_download_url and delete_document, which operate on already-existing documents.

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?

Offers one concrete use case ('for example when Stables compliance asks for one'), which implies when to reach for it. However, it never mentions alternatives such as submit_rfi_evidence when an RFI is open, nor any when-not-to-use condition, so routing among document-related siblings 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?

No annotations exist, so the description carries the full behavioral burden, and it adds little. It states a mutation but says nothing about permissions/entitlements required, idempotency or duplicate handling, whether whitelisting triggers verification, or what happens if the account is already whitelisted for the route. Only the Australian format implied by 'BSB and account number' 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?

A single tight sentence with the action front-loaded and a useful parenthetical clarifying the account identifiers. Nothing is padded, though the brevity comes partly from omitting information an agent would want.

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 4-required-parameter mutation with no annotations, no output schema and no enum constraints, the description should say more about prerequisites, entitlement requirements and post-call state. Given that complexity, a one-line description leaves meaningful gaps, though it does not mislead.

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% across all 5 parameters, so the schema already documents customerId, virtualAccountId, bsbNumber, accountNumber and enabled. The description only restates BSB and account number and adds no format, constraint, or default information beyond the schema, so the baseline 3 applies.

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

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

The description gives a specific verb ('Whitelist') plus two concrete resources (an Australian bank account identified by BSB/account number, and an AUD payment route). This implicitly separates it from register_route_payid (PayID, not bank account) and create_virtual_account, but it never explicitly names or contrasts a sibling, 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?

There is no when-to-use guidance, no prerequisites (e.g. the route must already exist, the customer must be verified), and no mention of alternatives such as update_route_whitelist_account or list_route_whitelist despite both being siblings. The scenario is only faintly implied by 'to pay into an AUD payment route'.

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 full burden. It discloses that the secret key is only shown once and must be saved immediately, which is a critical behavioral trait. However, it does not mention other relevant behaviors such as side effects, authentication requirements, or typical response structure.

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: the first clearly states purpose, the second provides critical behavioral information. Every word earns its place, and the description 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?

Given no output schema and a simple creation tool, the description covers the essential purpose and the one-time secret behavior. It could be improved by mentioning that the API key ID is returned or providing more context about the response, but the current information is largely sufficient for an agent to use the tool 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 description coverage is 100%, so the input schema already documents both parameters adequately. The description does not add meaning beyond the schema; the note about saving the secret key is unrelated to parameter semantics. Baseline score of 3 is appropriate.

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

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

The description clearly states the verb ('Create') and the resource ('a new API key for accessing the Stables API'). It is specific and distinguishes this tool from sibling tools like `get_api_key`, `list_api_keys`, and `revoke_api_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?

The description provides no guidance on when to use this tool versus alternatives (e.g., when to create vs. get vs. list). It only includes a note to save the secret key immediately, which is about post-creation action, not usage context.

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 well: it discloses the asynchronous lifecycle, the initial 'creating' state, and that repeat calls during flight are safe. It omits auth/permission requirements and any rate-limit or failure semantics, keeping 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 short sentences, each earning its place: purpose first, then the async contract, then the retry safety. No filler and no redundancy with 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 one-parameter async creation tool with no output schema, the description covers everything an agent needs: what it makes, that the result is deferred, which sibling to poll, and that retries are safe. 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% and the single 'network' parameter has a documented enum, so the schema already does the heavy lifting. The description only echoes 'on a network' without adding format or selection meaning, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('Create the deposit wallet') plus its purpose ('tops up your balance on a network'). It also names the related sibling get_balance_wallet, so an agent can distinguish this creation tool from the read tool without opening either 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 operational guidance: creation is asynchronous, the first answer is 'creating', and the agent should poll get_balance_wallet until 'active'. It also states the retry condition ('safe to call again while creation is in flight'), covering both the follow-up action and idempotent re-invocation.

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 behavioral burden. It implies a write operation ('Create'), but discloses nothing about idempotency, required permissions, the subsequent KYC state, or what happens to fields not supplied. For a 43-parameter mutation tool this is a substantial 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?

Three short sentences, front-loaded with the core action and with the type guidance close behind. No filler, though the entitlements sentence is slightly loose ('like').

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 43 parameters, a single required field, several conditional field groups (business legal address, money-services descriptions), no annotations and no output schema, the description is too thin. It omits any guidance on the field dependencies an agent must satisfy to get a valid creation through.

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 every parameter including enums and conditional requirements. The description's mention of customerType values and entitlements largely restates what the schema provides, meriting the baseline 3.

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 new customer') plus the downstream purpose (KYC verification and transfers). It does not, however, distinguish this from closely-named siblings such as create_customer_onboarding_link or update_customer, so the agent must infer which creation path applies.

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 conditional guidance on customerType ('individual' for personal, 'business' for company) and hints that entitlements like 'base_payout' enable transactions, but offers no when-to-use versus alternatives like create_customer_onboarding_link, and no prerequisites such as accepting terms.

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 disclose genuinely non-obvious behavior: an existing customer with the same email is reused, customer_created is false, and the submitted fields are ignored. It still omits permission/auth requirements and what happens to the link on expiry beyond the schema's ttlInSecs default.

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

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

Three short sentences, front-loaded with the outcome, then the reuse caveat, then the field guidance. Every sentence carries distinct information with no filler.

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

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

For a 47-parameter, no-output-schema tool with no annotations, the description covers the key decision points (link generation, customer reuse, field delegation) and names the returned customer_created flag. It is somewhat thin on the returned link payload and expiry semantics, but the schema documents ttlInSecs.

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 baseline is 3, and the description adds real meaning on top: it delegates the field set to create_customer and advises sending only what is already known, which tells the agent most fields are optional despite the 47-property schema. It does not clarify the interaction between the two APIs' field sets beyond that.

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 compound action ('create a customer and get a hosted verification link ... in one call') with the resource and the rationale (customer self-enters KYC/KYB). This clearly distinguishes it from the sibling create_customer, which does not return a link.

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

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

Gives clear usage context ('so the customer enters their own KYC/KYB details') and an explicit relationship to the sibling ('Takes the same fields as create_customer; send what you already know'). It stops short of stating when to prefer plain create_customer or get_verification_link instead, so it is not a full when/when-not rule.

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 present, so the description carries the full behavioral burden and does disclose meaningful traits: quotes expire, preview prices 'without committing', and the off-ramp/on-ramp requirements differ. It omits the expiry window, whether a non-preview call persists an artifact, auth/permission needs, and error behavior, which leaves gaps for an unannotated creation 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?

Four sentences that are front-loaded with purpose, then timing, then mode conditions, then the preview flag. Every sentence earns its place and no phrasing 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 annotations and no output schema, the description needs to carry the operational context, and it covers purpose, lifetime, mode requirements and the preview distinction adequately. The remaining gaps (expiry duration, what a persisted quote returns, failure modes) are minor for a 100%-covered schema but keep it short of complete.

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 value by synthesizing the cross-parameter conditional logic (source network and destination country for off-ramp; destination address for on-ramp) into a single readable rule rather than leaving the agent to reconcile scattered per-field notes. It does not add format details beyond the schema.

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

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

States a specific resource ('a quote for a currency exchange') and enumerates what it produces (rate, fees, what the customer receives), so the agent knows exactly what it gets. It implicitly separates itself from the get_quote sibling via 'create one immediately before the transfer', but never names that sibling explicitly, so full differentiation credit is withheld.

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

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

Gives clear when-to-use context ('create one immediately before the transfer' because quotes are short-lived) and branches by mode, spelling out what each of off-ramp vs on-ramp requires. It stops short of naming alternatives (e.g. get_quote for retrieving an existing quote) or stating when not to call it.

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 this initiates real money movement, requires human approval, and depends on an unexpired quote. It does not cover failure/idempotency behavior or the fundingSource/destinationType branches, leaving some gaps.

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

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

Four sentences, front-loaded with the core action and then the critical constraints. Every sentence earns its place, though the final corridor sentence is dense and could be slightly tightened.

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 34-parameter mutation tool with no annotations and no output schema, the description covers the essential safety and corridor requirements. It omits the crypto-destination and fundingSource paths, but those are thoroughly documented in the schema, so the gap is minor.

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-field conditional logic (recipientType + full address + dateOfBirth required for AED/CAD/EUR/GBP/MXN/USD when the recipient is an individual) that is not obvious from individual field descriptions.

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 ('Execute a transfer using an active quote') and clearly distinguishes itself from siblings like create_quote (prerequisite) and get_transfer/list_transfers (read operations). An agent can identify the action 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 concrete preconditions: the quote must not be expired and explicit human approval is required before execution. It also states corridor-specific requirements. It stops short of naming explicit alternatives or when-not-to-use cases, but the context is clear.

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 disclose meaningful behavior: a server-side validation that rejects routes lacking a destination, a server-side default of auto_payout, and the fact that deposit handling is mutable after creation. It omits auth/permission requirements and idempotency behavior, keeping 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 sentences, no filler, and the core purpose plus the critical constraint (mandatory destination) are front-loaded before the optional follow-up guidance.

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 annotations and no output schema, the description covers purpose, the blocking validation, defaults, and the follow-up tool. It leaves the response shape (e.g., returned route/account identifiers) unspecified, which is a minor gap given no output schema 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 description coverage is 100%, so the schema already documents all five parameters including enums and the destinationCurrency default. The description adds the mandatory nature of the payout destination and the network-validation of destinationAddress, but nothing beyond what the schema states.

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

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

The description uses a specific verb+resource ("Create a payment route (virtual bank account)") and explains the end-to-end effect: receive fiat deposits, convert to stablecoin, pay out to a wallet. It is clearly distinguishable from siblings like update_virtual_account and create_customer.

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

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

It states a hard precondition (payout destination is mandatory; the API refuses a fiat-to-crypto route without one) and routes the agent to update_virtual_account for later changes to deposit handling. It does not cover when to prefer other route types or account-creation alternatives, but the primary when-to-use context is explicit.

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, this carries the full burden and does fairly well: it discloses the delivery mechanism (POST callbacks), the event-type naming convention (dotted, lowercase), and the security model (secret enables HMAC-SHA256 via X-Webhook-Signature). It omits retry behavior, failure handling, and what is returned on creation.

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 paragraphs, purpose front-loaded, then event-type convention, then the security note. No filler sentences; each line 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?

For a 4-parameter mutation tool with no annotations and no output schema, the description covers mechanics and security adequately. Remaining gaps are operational details (retries, delivery failure behavior, whether the secret is returned once) that an agent might want before committing.

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 genuine meaning: event types follow a dotted lowercase convention and 'all' is a valid wildcard, and the secret parameter is tied to signature verification rather than left as an abstract option.

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 ('Subscribe to Stables events via webhook') plus the outcome ('POST requests to your URL when events occur'). It doesn't distinguish itself from siblings like list_webhooks or delete_webhook, but the creation 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?

Offers one usage hint ('Use all to receive everything') but does not say when to create a webhook versus using alternatives such as list_webhooks to check existing subscriptions, nor any prerequisites like URL validation or entitlement requirements.

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 it does disclose the two most important traits: the operation is irreversible ('cannot be undone') and it requires human confirmation before execution. It omits auth/permission requirements, idempotency, and what happens to the parent transfer or deposit, which keeps it below 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 short sentences, front-loaded with the action and scope, followed immediately by the destructive warning. No filler or 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 three-parameter destructive tool with no annotations and no output schema, the description covers the essential decision inputs: what it removes, from what, and that it is irreversible and needs human sign-off. Remaining gaps (auth needs, response shape, effect on the parent record) are minor but real.

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

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

Schema description coverage is 100%, so all three parameters (on, documentId, transactionId) are already documented in the schema, including the enum and where IDs come from. The description's phrase 'from a transfer or a payment route deposit' merely restates the `on` enum, adding no new meaning; 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 (Remove) and resource (a document) and scopes it to two container types (transfer or payment route deposit), which separates it from add_document, list_documents, and get_document_download_url. It does not explicitly name or route against any sibling, 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 the object scope; there is no explicit when-to-use versus an alternative. The one concrete guideline given — 'confirm with a human first' — is a workflow prerequisite rather than a selection rule, so this is minimum-viable 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 description discloses that deletion stops event delivery, which is a key behavioral detail. However, it does not mention if the action is immediate or reversible, nor any authentication requirements. With no annotations, the description carries the full burden but provides only moderate transparency.

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 concise with two sentences, front-loading the action and consequence. No unnecessary words.

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 delete tool with one parameter and no output schema, the description covers purpose and effect adequately. It is complete enough for an agent to understand 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 input schema already fully describes the parameter (webhookId) with a description. The tool description adds no additional parameter semantics, so baseline 3 is appropriate.

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

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

The description clearly states the action 'Delete a webhook subscription' and explains the consequence 'You will stop receiving events at this endpoint.' This distinguishes it from sibling tools like create_webhook or list_webhooks.

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

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

No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, such as requiring existing webhook IDs, or when deletion is appropriate.

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. It states 'Get details' implying a read operation, but provides no additional behavioral context such as authentication requirements, rate limits, or what constitutes 'details'. The minimal description leaves significant gaps.

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

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

The description is a single sentence, concise and front-loaded with the action and resource. However, it lacks additional context that would improve its utility without being overly long.

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 low complexity (1 param, no output schema), the description is adequate but incomplete. It does not explain what 'details' are returned, leaving the agent uncertain about the tool's output. For a simple tool, this is 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?

Schema description coverage is 100% for the single parameter, which already documents 'The API key ID to look up'. The description adds no additional meaning beyond what the schema provides, resulting in a baseline score of 3.

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 uses the verb 'Get' and specifies the resource 'details about a specific API key'. It distinguishes from siblings like list_api_keys (listing all) and revoke_api_key (revoking), making the tool's specific retrieval purpose 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?

No explicit guidance on when to use this tool versus alternatives like list_api_keys or revoke_api_key. The description implies usage when you have an API key ID, but does not state exclusions or compare 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 disclose useful return structure (one entry per asset and network) plus a semantic field (transfers_enabled) and its cross-tool dependency. It does not describe auth requirements or the full response shape, but for a zero-parameter read operation this is meaningful added context.

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 tightly written sentences, front-loaded with the core purpose followed by the one non-obvious field and its downstream use. No filler.

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

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

There is no output schema, so the description must convey the return shape, and it does provide the key structural fact (per asset/network entries) and the significant transfers_enabled flag. It is close to complete for a zero-param read tool, missing only full field-level return detail.

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. There are no parameter semantics to clarify, and nothing in the description misleads on inputs.

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 ('Get your organisation's stablecoin balance') and clarifies the granularity ('one entry per asset and network held'), which helps distinguish it from the wallet-scoped sibling. It does not explicitly contrast with get_balance_wallet or list_pending_balance_deposits, 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 implied rather than stated: the mention that transfers_enabled is what create_transfer with fundingSource 'prefund_balance' needs tells the agent why the field matters, but there is no explicit 'use this when / not when' guidance and no differentiation from the other balance-related 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 provided, the description carries the full behavioral burden and delivers a genuinely non-obvious trait: the address field is only populated once status is 'active'. It does not mention auth requirements or whether the wallet must be created first, but the conditional-field disclosure is the key quirk an agent needs.

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

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

Two short sentences, zero waste, and the important conditional (address only present when active) is front-loaded right after the tool's 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?

There is no output schema, so the description must convey return-shape information; it does so for the critical address field, which is the one an agent would otherwise misread. It could say more about the status values, but for a one-parameter read tool this is nearly complete.

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 single 'network' parameter is fully documented in the schema (100% coverage), including its default of polygon and enum values. The description adds only the vague phrase 'on one network', so the schema is doing the heavy lifting; 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 (get) and resource (deposit wallet that tops up your balance) scoped to one network, which separates it from create_balance_wallet and get_balance. It does not explicitly name the sibling it complements, so it falls 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?

There is no when-to-use guidance or reference to alternatives such as get_balance, list_balance_activity, or create_balance_wallet. The agent must infer from the resource name alone that this is the read counterpart to create_balance_wallet.

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 behavioral burden, and it discloses almost nothing: it doesn't state that the call is read-only, that the 'include' option is slower or intended only for syncing verification data, or what the response looks like. It only hints that verification status is part of the payload.

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 padding or redundancy. It is efficient, though its brevity overlaps with its lack of substance rather than reflecting well-chosen density.

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 annotations and no output schema, the description should explain what 'details' actually contains and flag the include-parameter tradeoff. Neither is present, leaving the agent under-informed about both the return payload and the costly optional path.

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 documents both customerId ('customer ID to look up') and the include enum with its slowness caveat. The description's mention of 'verification status' faintly maps to the include parameter but adds no syntax or behavioral detail beyond the schema, 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 clear verb ('Get') and resource ('a specific customer'), which distinguishes it from list_customers, create_customer, and update_customer by the singular, read-oriented framing. It doesn't 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?

The description gives no when-to-use, when-not-to-use, or alternative routing. With list_customers available for browsing and update_customer for mutation, an agent gets no help deciding between them beyond the word 'specific'.

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. It usefully discloses that the link is 'short-lived' (an expiration behavior), which is valuable. However, it omits other behavioral traits such as read-only nature, permission requirements, error behavior, 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 a single, well-structured sentence with no wasted words. The core action and resource are front-loaded, making it easy to parse quickly.

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

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

For a simple read tool with complete parameter schema coverage, the description is largely complete: it states the purpose and the short-lived nature of the link. It could be more complete by explaining the return value (a URL) explicitly, since no output schema exists, but it is adequate overall.

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 three parameters in detail. The description only restates the 'transfer or payment route deposit' concept already covered by the 'on' enum, adding no new syntax or format details. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Get') and resource ('short-lived link to download a document attached to a transfer or a payment route deposit'). It clearly distinguishes this tool from siblings like list_documents, add_document, and delete_document by focusing on obtaining a download URL.

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 explicit guidance on when to use this tool versus alternatives. It does not mention that documentId should come from list_documents (the schema does), nor does it state any prerequisites or exclusions. Usage is only implied by the purpose.

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 behavioral burden. 'List' implies a read-only operation, and the description discloses what information is returned, but it does not mention permissions, pagination, error behavior, or side effects.

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 compact sentences with no wasted text. The return contents are front-loaded, followed by the key domain usage note about RFI requirements.

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

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

For a simple one-parameter read tool with complete schema coverage and no output schema, the description explains the main returned information and the RFI satisfaction semantics. It is nearly complete, though it could say more about scope or historical versus current capabilities.

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

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

Schema description coverage is 100%, and the single customerId parameter is fully documented in the schema. The description reinforces that results are scoped to a customer, but it does not add syntax or formatting details beyond what the schema already 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 uses a specific verb and resource: it lists the verification capabilities a customer holds, with examples and returned fields (level, when). It is clearly a customer-scoped KYC read tool, though it does not explicitly distinguish itself from siblings such as list_available_entitlements.

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 second sentence gives a concrete usage context: checking whether a kyc_capability requirement on an RFI is satisfied. It does not name alternatives or exclusions, but the primary use case is clear enough for an agent.

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 provided so description carries full burden. States it gets details and status but doesn't disclose that it is read-only, or any authentication/rate limit needs. Adequate but minimal.

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?

Single sentence, no wasted words. Essential information presented efficiently.

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?

Simple tool with one parameter and no output schema; description covers main purpose. However, lacks information on return structure or potential errors, which would be helpful.

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 parameter description is clear ('The quote ID to look up'). Description adds no extra context 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?

Clearly states the tool retrieves details of an existing quote including status, with a specific verb 'get' and resource 'quote'. Distinguishes from sibling 'create_quote' which creates quotes.

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 use for existing quotes but no explicit guidance on when to use versus alternatives like 'list_transfers' or when not to use. Sibling tools exist but no comparison.

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. 'Get' plus the content preview establishes a read-only retrieval, which is useful, but it says nothing about permission requirements, behavior on an unknown/closed RFI ID, or sensitivity of compliance data.

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 with the verb and scope front-loaded and a compact clause enumerating the response contents. Nothing is wasted and nothing needs to be trimmed.

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 single-parameter read tool with no output schema and no annotations, the description supplies the essentials and even characterizes the return payload. It falls short only on permission/error behavior, which is a minor gap at this complexity.

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?

One parameter with 100% schema description coverage, so the schema already documents rfiId as 'The RFI ID' and the baseline is 3. The description adds no format, sourcing (e.g., obtained via list_rfis), or validity detail beyond that.

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 ('Get one ... RFI'), expands the acronym, and previews the returned content (why raised, requirements, how to answer). It implicitly distinguishes itself from list_rfis/list_customer_rfis by scoping to a single request, though it never names those siblings explicitly.

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

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

Usage is only implied: 'one' suggests singular retrieval versus the list_* siblings, but there is no explicit when-to-use guidance, no mention of what precondition (e.g., needing an existing rfiId from list_rfis) applies, and no named alternative for the plural case.

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. It usefully discloses the return content (the form plus the current submission if one was sent), which is genuine behavioral context, but says nothing about permission/auth requirements, whether it is strictly read-only, or failure behavior for a missing/invalid requirement.

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 primary purpose and immediately followed by the actionable next step. No filler; every clause contributes either scope, an example, or the downstream workflow.

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 present, the description partly compensates by stating that it returns the form along with any current submission and referencing fields/documents. This is sufficient for an agent to know what comes back and how to use it, though it stops short of describing the form's structure in any detail.

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% (rfiId, customerId, requirementId are each documented), so the schema already carries parameter meaning. The description adds a clarifying note that requirementId is of type 'evidence', but no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb (Get) and a precise resource: the form an `evidence` requirement on an RFI asks for, with a concrete example (source of funds behind a held payment). It also distinguishes itself from the sibling submit_rfi_evidence by framing this as the retrieval step that feeds that tool's answers.

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?

Clear workflow context: use this to obtain the form, then build submit_rfi_evidence answers from its fields and documents. It routes the agent toward the related submit tool, but offers no explicit when-not-to-use or alternative retrieval paths (e.g. get_rfi / list_customer_rfis).

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 full burden. It only says 'get', implying read-only, but does not explicitly state that it is non-destructive, lacks side effects, or mention any authentication or rate limit considerations.

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

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

The description is a single clear sentence with no wasted words, front-loading the 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?

Given the low complexity (1 parameter, no nested objects, no output schema), the description adequately covers the tool's purpose and what it returns. However, it could elaborate on the specific details included in the response.

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 the 'transferId' parameter described. The description adds minimal extra meaning by mentioning 'current status and details', hinting at the response content, but does not elaborate on parameter format or constraints 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 clearly states the verb 'Get' and the resource 'a transfer', specifying it retrieves 'current status and details', which distinguishes it from sibling tools like 'create_transfer' and 'list_transfers'.

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 for checking a specific transfer's status and details, but provides no explicit guidance on when to use this versus alternatives, or when not to use it.

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. It only states that a link is generated and a precondition for transfers, but does not disclose side effects, required permissions, rate limits, link expiration behavior (despite the ttlInSecs parameter), or what happens if verification is already complete.

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 sentences, front-loaded with the core action and followed by a key contextual constraint. Every sentence earns its place with no wasted words.

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

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

The description covers the basic purpose and a usage constraint, but for a tool with 5 parameters and no output schema, it omits important context such as what the returned link looks like, how long it is valid, and how the optional URLs and verificationType affect 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%, so the schema already documents all parameters. The description adds no additional meaning beyond what is in the schema (e.g., it does not explain the verificationType options or the default TTL).

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 (Generate) and resource (KYC verification link) for a customer, making the purpose clear. However, it does not differentiate from the sibling tool create_customer_onboarding_link, which likely has overlapping functionality.

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

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

Usage is implied by the statement that the customer must complete verification before making transfers, but there is no explicit guidance on when to use this tool versus alternatives like create_customer_onboarding_link or get_kyc_capabilities, nor any exclusions.

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 falls short: it says nothing about pagination or cursors, result ordering, the time window covered, or whether history is bounded. The 'etc.' leaves the set of returned event types undefined, which matters when the agent must reason about what it will receive.

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 the verb and resource first. The trailing 'etc.' is mild filler that slightly weakens precision but costs little space.

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 paginated list-style tool with no output schema and no annotations, the description should cover return shape and paging behavior; it only gestures at return content via two examples. Ordering, pagination, and the meaning of the limit cap are absent, leaving real operational 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 description coverage is 100%, with all three parameters documented in the schema including the limit default of 10. The description adds no parameter meaning beyond that, 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?

States a specific verb ('Get') and resource ('activity history for a virtual account') and clarifies the content with concrete event examples (deposits, payouts). An agent can distinguish it from the other virtual-account siblings (create/update/list_virtual_accounts), though the description never names those alternatives explicitly.

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

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

No when-to-use guidance and no exclusions or alternatives. It does not tell the agent how this differs from list_balance_activity or list_virtual_accounts, leaving the choice entirely 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?

No annotations provided, so description bears full burden. It does not disclose pagination behavior, response format, or potential limits. Only says 'list all', which may imply a single response without pagination.

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?

Single sentence with no waste. However, it could be slightly expanded to mention pagination or response format without losing conciseness.

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 list tool with pagination and no output schema or annotations, the description is minimal. It does not mention that the result is a list, that it could be empty, or any authentication requirements. Adequate but with clear 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 has 100% description coverage for both parameters. Description adds no additional meaning beyond the schema, but baseline 3 is appropriate as the schema already documents the parameters.

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?

Description clearly states verb 'list', resource 'API keys', and scope 'for the current account'. It distinguishes from sibling tools like create_api_key, get_api_key, and revoke_api_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?

No guidance on when to use this tool versus alternatives like get_api_key (single key) or other list tools. No context about prerequisites or when to use pagination.

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. It does disclose the shape of what is returned (per-entitlement availability and required verification), which is genuinely useful, but says nothing about auth requirements, pagination, rate limits, or read-only guarantees. A 'list' verb implies a safe read, but the disclosure is partial.

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 zero filler, front-loaded on the verb and resource. The parenthetical definition and the three output facets are packed efficiently, though the trailing clauses make it slightly heavy to parse.

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 and no annotations, the description usefully compensates by enumerating the three things returned per entitlement (existence, current availability, verification needed). For a single-param read tool this is close to sufficient; only pagination and auth context are 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?

There is one parameter (customerId) with 100% schema description coverage, so the schema already documents it fully. The description adds no format, sourcing, or constraint detail beyond what the schema provides, which is the expected baseline 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?

States a specific verb (List) and resource (entitlements), defines the resource inline (products and payment rails) with a concrete example ('aed_local'), and narrows scope to entitlements the customer 'has not applied for yet.' This scope effectively distinguishes it from request_entitlements and submit_entitlement_requirements, though it never names those siblings explicitly.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative routing. The phrase 'has not applied for yet' hints that this is a pre-request discovery step relative to request_entitlements, but the agent must infer that; nothing tells it whether to call this first or what to do with the results.

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. It usefully discloses sort order ('newest first') and the returned fields, but says nothing about permissions, pagination behavior, or whether results are user- or account-scoped.

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

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

One sentence, front-loaded with verb and resource, and the ordering and payload hints are packed in without waste. Every clause earns its place.

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

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

With no output schema, the description valuably enumerates the returned fields and ordering, which an agent would otherwise have to guess. It is nearly complete for a simple read-only list; only pagination semantics and scope behavior are left implicit.

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

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

Schema description coverage is 100%, so network, pageSize, and pageToken are already documented in the schema. The description only echoes 'network' via the returned fields and adds no filter syntax or enum context beyond the schema, 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?

Specific verb (List) plus resource (deposits crediting the balance) with the scope qualifier 'credited' that separates it from sibling list_pending_balance_deposits. An agent can tell what it returns and how it differs from pending-deposit and get_balance tools 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 implied: 'credited your balance' and 'newest first' suggest a historical, settled-deposit listing as opposed to the pending variant, but no explicit when-to-use or when-not guidance and no sibling is named. Adequate but leaves routing 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?

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a read-only operation and the phrase 'with what each requirement needs next' discloses something about the returned content, but there is no mention of permissions, pagination, rate limits, or other operational traits.

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 wasted words; the verb and scope appear immediately. It is appropriately sized for a simple two-parameter list 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?

With no output schema and no annotations, the description should carry more of the return-value burden. It says each requirement includes 'what each requirement needs next', which is helpful, but omits pagination behavior and the broader shape of returned RFI records.

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 both customerId and status fully documented including enum values. The description adds no parameter syntax or format detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific verb (List) and resource (compliance requests for information / RFIs), scoped to one customer, which distinguishes it from the general list_rfis and single get_rfi siblings. However, it does not explicitly name those alternatives, so it falls short of the 5-calibration example that routes the agent by naming the sibling.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as list_rfis or get_rfi. The scoping word 'one customer's' hints at context but does not tell the agent when this tool is preferred over the sibling listers.

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 disclose a real behavioral trait: omitting pageSize yields only the API's default first page, so the agent must deliberately paginate. It does not cover auth model, rate limits, ordering, or return shape, but it surfaces the main operational trap.

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 filler, and the scope statement is front-loaded ahead of the pagination guidance. Nothing here is redundant with the name 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?

For a two-param read-only list tool with no output schema and no annotations, the description covers the critical gap (pagination) and tenancy scope. It leaves ordering, filtering options, and the shape of returned customer objects unspecified, but no output schema exists to relieve that burden either.

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 would be 3; the description goes beyond the schema by explaining the consequence of omitting pageSize (default first page) and the combined pageSize + pageToken pagination loop, which the schema alone 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 ('List customers') and scopes it to 'the authenticated tenant'. It does not explicitly name sibling tools, but 'list_customers' vs 'get_customer'/'create_customer' is unambiguous from the name alone, so differentiation is effectively achieved.

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 second sentence gives practical guidance on how to read the full result set ('pass pageSize and follow pageToken to read them all'), which is genuine usage direction. However, it never states when to prefer this tool over siblings or any exclusions/preconditions beyond the pagination mechanics.

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 behavioral burden. It discloses the sort order ('newest first'), which is useful, but it does not mention pagination, authentication requirements, or the shape of returned document objects. The read-only nature is implied by 'List' but not stated.

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?

It is a single front-loaded sentence with no filler. Every element—verb, resource, scope, and ordering—earns its place.

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

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

For a simple two-parameter read tool with no output schema, the description states what is listed, the two parent types, and the ordering. It does not describe the response fields or pagination, but it is complete enough for an agent to call it correctly given 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 description coverage is 100%, so the schema already fully documents both 'on' and 'transactionId', including the enum values and the source of the deposit ID. The description adds no syntax or format details beyond what the schema provides. Baseline 3 applies 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 uses a specific verb+resource ('List the documents') and states the exact scope ('attached to a transfer or a payment route deposit'). It also specifies ordering ('newest first'), which distinguishes it from sibling tools like add_document or get_document_download_url. An agent can identify the operation 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?

The description implies when the tool applies by naming the two possible parent objects (transfer or deposit), but it does not explicitly say when to prefer this over alternatives such as get_document_download_url. No exclusions or prerequisites are 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?

No annotations are provided, so the description carries the full burden, and it does disclose real behavioral context: the deposits are on-chain but withheld before crediting, and the hold reasons are an unwhitelisted sender or compliance review. It still omits anything about permissions/scoping, whether the state is transient, pagination, or return shape.

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 that front-loads the resource and the essential distinction (held vs. credited), then supplies the reasons as a compact clause. 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 zero-parameter, no-annotation, no-output-schema list tool, the description covers what the list contains and why items appear, which is enough to call it correctly. It stops short of describing the returned fields (amounts, timestamps, sender) or ordering, which an agent might want since no output schema 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?

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly adds no parameter-like details, consistent with the 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?

The description gives a specific verb and resource ("List deposits") and qualifies it precisely as "seen on-chain but held before crediting your balance", which separates it from the balance-history sibling list_balance_activity. It never names that sibling, so the differentiation is implicit 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?

The holding condition plus the enumerated reasons imply when an agent would call this (to diagnose why a deposit hasn't credited). There is no explicit when-to-use, when-not-to-use, or named alternative such as list_balance_activity, so usage must be 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?

With no annotations, the description carries the full behavioral burden. It discloses sort order and default statuses, which is useful, but omits permissions, pagination behavior, and return-value characteristics for a six-parameter list 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 front-loaded, appropriately sized, and every sentence contributes: purpose, default behavior, and operational trigger. There is no redundant or wasted text.

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

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

For a list tool with full schema coverage, the description is sufficient to select and invoke it correctly. It is slightly thin on return format and pagination, but those gaps are minor given the schema and the tool's straightforward read-only nature.

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 six parameters. The description only reinforces the default status behavior and adds no extra syntax or filter semantics 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 states a specific verb and resource: it lists the organisation's compliance RFIs and defines RFI. It also specifies ordering (newest first) and default statuses, though it does not explicitly name the sibling list_customer_rfis as the customer-scoped alternative.

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 a clear use case: check this when a transfer or deposit is held, or subscribe to rfi.* webhooks instead. It does not explicitly say when not to use it versus list_customer_rfis or get_rfi, but the guidance is actionable.

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 carries the full behavioral burden, and it omits anything beyond the data's meaning: no pagination, ordering, empty-list behavior, permission requirements, or return shape. The domain context about Australian routes is useful but is semantic framing rather than 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?

Two short sentences, zero waste, with the core action stated first and the qualifying context second. Nothing needs to be trimmed or reordered.

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

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

For a simple two-parameter read tool with fully documented params this is close to adequate, but with no output schema the description should ideally say what the returned list contains (account identifiers, bank details, status) so the agent knows what it will get back.

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 customerId and virtualAccountId are already documented, including the note that virtualAccountId is the AUD payment route ID. The description adds no format, constraint, or example beyond that, 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?

The description gives a specific verb and resource ('List the bank accounts whitelisted to pay into an AUD payment route') and the second sentence scopes it to Australian routes. It is clearly distinguishable from list_whitelisted_wallets and from the mutation siblings add_route_whitelist_account/update_route_whitelist_account, though it never names them explicitly.

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

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

The note that 'some Australian routes only accept deposits from whitelisted source accounts' implies when an agent would care about this list, but there is no explicit when-to-use, no exclusions, and no pointer to the add/update whitelist siblings for the write path.

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. It does not state that this is a read-only operation, does not mention pagination behavior (despite pageSize/pageToken params), sorting, or default result ordering.

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 efficient sentence with the resource front-loaded and the filter scope attached. No waste, though it leans toward under-specification rather than tight completeness.

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 list tool with no output schema and no annotations, the description is minimally adequate but omits read-only semantics and pagination behavior. The schema covers the parameters, so the remaining gap is behavioral context.

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 five parameters including enums and the pagination token. The description only echoes the filter dimensions and adds no syntax or format 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?

The description states a specific verb ('List') and resource ('transfers') and names the filter dimensions. It implicitly distinguishes from get_transfer (single) and create_transfer, but never names or contrasts with those siblings explicitly.

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

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

It notes the filters are optional but gives no guidance on when to use this versus get_transfer for a single record or create_transfer. No prerequisites, no exclusions, no routing cues are provided.

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. It discloses one behavioral trait, the default cross-customer scope when customerId is omitted, but says nothing about read-only nature, result volume, pagination behavior, or authorization requirements. For a mutation-free listing tool this is thin but not misleading.

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, well-formed sentence with no filler. The scope-defining condition is placed at the end where it reads naturally, and nothing is repeated.

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 annotations and no output schema, the description is the only place for behavioral context, and it covers just the scope default. Pagination expectations (how limit and startingAfter interact), return shape, and whether an unbounded all-customer listing is safe to call are left unaddressed. Adequate but with clear gaps for a 4-parameter listing 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 description coverage is 100%, so all four parameters (limit, status, customerId, startingAfter) are already documented in the schema. The description's customerId clause restates what the schema property already says, adding no new syntax, format, or constraint detail. Baseline 3 applies 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?

States a specific verb (List) and resource (payment routes / virtual accounts), including the useful synonym mapping that ties 'payment routes' to 'virtual accounts'. The scope distinction (one customer vs. all customers) is stated. It stops short of naming a sibling like get_virtual_account_history to disambiguate further, but the purpose itself 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 description implies usage by describing the two modes: pass customerId for one customer, omit it to list across all. There is no explicit when-not guidance or pointer to alternatives such as get_virtual_account_history for a single account's events. Usage is inferable but not routed.

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 behavioral burden. It usefully discloses the semantics of the returned data ('whether Stables sent them and what the endpoint answered') and implies a read-only, recent-first listing, but says nothing about auth requirements, ordering guarantees, or pagination beyond what the schema's pageSize already states.

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 core action is front-loaded and the diagnostic use case follows immediately; every clause earns its place.

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

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

With no output schema and a read-only list tool, the description adequately previews what records contain (status, retry state). It omits ordering/pagination behavior and any note about what happens when no deliveries exist, but nothing essential for invoking the tool 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 description coverage is 100%, with each of the three filters documented including the status enum values, so the schema does the heavy lifting. The description mentions status and retry state conceptually but adds no filter syntax or combination guidance beyond the schema, 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 — listing webhook delivery attempts — and adds what each record contains (HTTP status, retry state). It is distinguishable from the sibling list_webhooks (which manages webhook configurations) by the word 'deliveries', though it never names that sibling to make the distinction explicit.

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 triggering scenario: 'the first place to look when an integration is not receiving events.' That is clear usage context, but it stops short of naming alternatives (e.g. list_webhooks for configuration problems) or stating exclusions.

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 discloses the read-only nature of the tool by using 'list'. However, it does not mention potential behavioral details such as pagination or rate limits. Given no annotations are provided, the description carries the full burden, and mentioning that it lists 'all' subscriptions is helpful.

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

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

The description is a single sentence with no wasted words, effectively communicating the tool's 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?

Given the tool has no parameters and no output schema, the description is complete. It unambiguously states what the tool does without requiring additional detail.

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 input schema has zero parameters, so the baseline is 4. The description does not need to add parameter information, and it correctly implies no additional configuration is needed.

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

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

The description clearly states the verb 'list' and the resource 'webhook subscriptions', and specifies the scope 'for the current account'. It effectively distinguishes from sibling tools like create_webhook and delete_webhook which have different actions.

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 clearly indicates when to use this tool (to list all webhook subscriptions). While it does not explicitly mention when not to use it or provide alternatives, the context of a simple list operation with no parameters makes this omission acceptable.

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. It adds the domain fact that only 'active' wallets can actually deposit/withdraw, but says nothing about authorization requirements, the default status filtering behavior when 'status' is omitted, or pagination semantics (the archived-wallets note is already 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?

Three short sentences, front-loaded with the core purpose and free of filler. The middle fragment ('Only active wallets can.') is truncated and slightly ambiguous about what active wallets can do, which costs a point.

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

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

For a read-only list tool with full schema coverage and no output schema, the description covers what is listed, the active-wallet constraint, and how whitelisting is created. It omits the default return set and result fields, which is a modest gap given no output schema 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 description coverage is 100%, so all four parameters (status, network, pageSize, pageToken) are already documented with enums and defaults. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource (list wallets whitelisted for balance deposits/withdrawals) and scopes it to the balance domain rather than routes. It does not explicitly distinguish itself from the sibling list_route_whitelist, which covers the analogous route-side concept, so 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?

Provides real routing context: whitelisting is configured in the dashboard and 'there is no API for it,' which stops an agent from hunting for a create-whitelist tool. It does not, however, name alternative list tools (e.g. list_route_whitelist) or state when to prefer this list over them.

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. It usefully discloses idempotent-style behavior (re-calling returns the existing PayID) and the activation prerequisite, but omits permission/auth requirements, failure modes for inactive routes, and any rate or format details.

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, no filler, with the core action and its benefit front-loaded and the idempotency caveat second. Every clause earns its place.

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

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

For a two-parameter mutation with no output schema, the description covers the action, the prerequisite state, and the repeat-call return behavior. It could say more about the resulting PayID's form or error conditions, but nothing essential to invoking it 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 description coverage is 100% and both parameters already documented, so the baseline is 3. The description adds mild meaning by characterizing virtualAccountId as an activated AUD payment route, but does not clarify format or relationships beyond that.

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 (register), resource (PayID), and the exact target (an activated AUD payment route/virtual account), and explains the user-visible outcome (payers can send to an email-style alias instead of BSB/account). No sibling tool touches PayID, so there is no ambiguity to resolve.

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 precondition — the route must already be activated — and clarifies the repeat-call case. It does not name alternative tools or state when not to use it, so it falls short of explicit when/when-not routing, but the 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?

With no annotations, the description carries the full burden. It usefully discloses a failure mode ('the response lists what is missing') and its remediation, but says nothing about authorization requirements, whether the request is applied immediately or requires approval, or reversibility/idempotency for what is clearly a mutation.

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, zero filler, and the core action is front-loaded ahead of the prerequisite and the follow-up branch. Every sentence carries routing or behavioral 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?

No output schema and no annotations, so the description must carry return-value and behavior context; it does mention what the response can contain (missing verification items) and the next step. It is close to complete, but omits the outcome semantics (does the entitlement become active immediately?) that an agent would want before applying.

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 parameters are already documented in the schema (customerId, entitlements with enum values). The description adds no syntax or format detail beyond the example phrasing, so the baseline 3 applies.

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

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

States a specific verb and resource ('Apply for one or more entitlements for an existing customer') plus a concrete example use case ('to add a payment rail'). It names two sibling tools, list_available_entitlements and submit_entitlement_requirements, so an agent can place it in the workflow 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 prerequisite ('Check list_available_entitlements first') and a conditional follow-up path when verification is incomplete, naming the alternative tool explicitly. It stops short of stating when NOT to use this tool, so it is strong but not exhaustive.

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 transparently states that revocation is permanent and irreversible, which is critical for an agent to understand. However, it omits details about potential side effects (e.g., immediate termination of active sessions) or required permissions, which would be beneficial given the absence of 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 extremely concise with two sentences, each carrying essential information. The first sentence front-loads the action, and the second adds irreversibility without redundancy.

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

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

For a simple, one-parameter destructive tool with no output schema, the description covers the essential behavioral information (permanent revocation) and the parameter is fully described in the schema. No obvious gaps remain.

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 provides 100% coverage with a description for the sole parameter, and the tool description adds no additional meaning beyond what the schema already states. Per guidelines, baseline 3 is appropriate.

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

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

The description clearly states the action 'Revoke' and the resource 'API key', and distinguishes it from related operations like create_api_key or list_api_keys by emphasizing permanence and irreversibility.

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 that the tool should only be used when the key is to be permanently disabled, but it does not explicitly state when to use it versus alternatives, such as deactivating a virtual account instead, nor does it provide prerequisites like having the correct API key ID.

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 does disclose the most important trait: this only works in the sandbox and fails on production. It omits other behaviors an agent would want, such as whether a simulated deposit record persists or what permissions are required.

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 with zero waste, and the most decision-critical fact ('SANDBOX ONLY') is front-loaded before the explanation. Every clause earns its place.

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

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

With no output schema and no annotations, the description covers environment, purpose, and the effect of the call, which is enough to invoke it correctly. Missing side-effect and permission details keep it short of fully complete for a 7-parameter mutation-style 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 description coverage is 100%, including the enum semantics for 'scenario', so the schema already does the heavy lifting. The description adds no parameter-level meaning beyond that, making the baseline 3 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 ('Simulate a fiat deposit into a payment route') and adds the observable outcome ('watch the conversion and payout complete'). The route-versus-transfer distinction is implicit rather than stated, so it does not explicitly separate itself from the sibling simulate_transfer_deposit.

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 environment condition — sandbox use with 'Fails on production' as an explicit exclusion. It does not name an alternative tool or say what to use for real deposits, so the routing guidance is contextual rather than explicit.

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 discloses important behavior: sandbox-only execution, production failure, and that the call causes a transfer to progress to payout without an actual on-chain payment. It does not mention idempotency, side effects on other objects, or response behavior, but the core behavioral constraints are present.

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 the most critical constraint ('SANDBOX ONLY'), and every clause adds useful information without repetition.

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

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

For a simple single-parameter sandbox simulation with no output schema, the description supplies the essential operational constraint and the intended effect. It could be stronger by noting the expected return or error semantics, but it is sufficient for correct invocation.

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

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

The sole parameter, transferId, is fully documented in the schema ('The transfer awaiting funds'), so the baseline is 3. The description does not add additional format, constraint, or selection guidance beyond what the schema already says.

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

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

The description uses a specific verb ('Simulate') and resource ('transfer deposit'), and explains the effect: progressing an off-ramp transfer to payout without an on-chain payment. It does not distinguish this tool from the similar sibling 'simulate_route_deposit', so an agent must infer the difference.

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 states the operating context ('SANDBOX ONLY') and the exclusion ('Fails on production'), which tells an agent when not to use it. However, it does not explicitly compare against the sibling simulation tool or explain when one should be chosen over the other.

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. It usefully discloses that documents must be base64-encoded and that submission is partial (only missing fields), which is genuinely behavioral. It omits idempotency (can it be re-called?), permission/auth requirements, whether resubmitted fields overwrite prior data, and what happens on an incomplete submission.

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 tight sentences, front-loaded with the action and followed by field-format and encoding rules; nothing is wasted. The parenthetical example list is long but each example earns its place by disambiguating the free-form requirements object.

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 requirements parameter is an open free-form object (additionalProperties: {}), yet the description only gives 'e.g.' examples rather than the full set of accepted keys, leaving the agent uncertain about valid field names. With no annotations and no output schema, there is also no signal about auth needs or the response on success/failure, though the base64 and partial-submission notes do cover the most critical call-shaping details.

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 goes modestly beyond the schema by giving concrete requirement key examples (tax_id_number, financial_profile, id_documents, proof_of_address_documents) and the base64 encoding rule for document fields, which the schema does not state. It restates the snake_case convention already present in the schema, so the gain is incremental rather than substantial.

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: sending further verification data for a requested entitlement, with a nod to the entitlement-request flow ('Stables asked for'). It distinguishes from generic siblings like update_customer, though it never explicitly names which sibling (request_entitlements, submit_rfi_evidence) precedes it or how it differs from submit_rfi_evidence.

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?

'Send only what is missing' is a real usage constraint and implies this follows an entitlement request that came back with outstanding requirements. However, it never states when to use this versus submit_rfi_evidence or update_customer, nor any prerequisite (e.g. that a request_entitlements call must have flagged missing fields).

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 present, so the description carries the burden and does well: it discloses the state transition to 'submitted', that compliance review follows, and that approval releases the held payment. It also specifies the file encoding format. It omits failure/validation behavior and required 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?

Three tight sentences, front-loaded with the action and format, followed by the downstream consequence and the safety caveat. No filler; every sentence earns its place.

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

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

For a mutation with nested objects, no annotations, and no output schema, the description covers the format, the workflow dependency, the post-submit state, and the payment-release consequence. It leaves out error handling and anything about the returned response, but nothing critical 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 100% and the schema already documents each parameter, including the answers object and its base64 example. The description adds only the pointer that keys must match get_rfi_evidence_form's listing, so the schema does the heavy lifting and 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+resource: submitting answers and documents for an `evidence` requirement in a single request. It differentiates from siblings by naming get_rfi_evidence_form as the source of the keying scheme, so an agent can distinguish it from the read-side RFI 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?

Implies the correct workflow ('keyed as get_rfi_evidence_form lists them', 'in one request') and adds an explicit human-confirmation gate before sending. It does not spell out when NOT to use it (e.g. other requirement types), so it stops short of full guidance.

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