BlindPay MCP Server

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

The annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, and "Remove" is consistent with those. However, the description adds no behavioral context beyond restating deletion, such as irreversibility, side effects, or 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?

Two words are concise but under-specify a destructive, multi-parameter operation. The brevity does not earn its place because essential scope and behavior are missing.

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

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

For a destructive deletion tool with three required identifiers and 50% schema coverage, the description leaves out almost everything an agent needs: instance/customer scoping, effects of deletion, and retry semantics beyond the Idempotency-Key schema note. Annotations cover the safety hints, but the description itself is far from 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 description mentions no parameters at all. With only 50% schema description coverage, the undocumented id and instance_id parameters must be inferred from their names and examples, and the description does not compensate for that gap.

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

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

The description gives a clear verb and resource with "Remove Bank Account", but it is extremely terse and omits the by-ID scope and instance/customer context embedded in the tool name. It does not differentiate this deletion from other bank-account operations such as GetV1InstancesCustomersBankAccountsById or the related create/list 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?

There is no guidance on when to use this deletion versus related tools, nor any mention of prerequisites, consequences, or alternatives. An agent must infer usage entirely from the tool name and sibling list.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered structurally. Beyond echoing "Remove", the description adds nothing about consequences — e.g. whether funds or addresses on the wallet are lost, whether deletion is reversible, or what happens to in-flight payouts.

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 words with zero filler and the action front-loaded, but for a destructive delete this level of brevity is under-specification rather than efficiency.

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?

This is an irreversible destructive operation with no output schema and half the parameters undocumented. The description should at minimum state the resource scope (which blockchain wallet under which customer/instance) and any deletion consequences; it instead says nothing beyond the name.

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 only 50%: customer_id and Idempotency-Key are documented, but id and instance_id carry only examples. The description supplies no parameter meaning at all, so the undocumented half of the identifiers is left entirely to inference.

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?

"Remove Blockchain Wallet" gives a clear verb and resource, so the basic action is unambiguous. However, it does nothing to separate this from close siblings such as DeleteV1InstancesCustomersWalletsById (non-blockchain wallet) or DeleteV1InstancesCustomersById, leaving the agent to infer the distinction from the long tool name alone.

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. An agent must decide entirely from the name whether this is the correct delete endpoint versus the plain wallet delete sibling.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally and the description does not contradict it. However, the description adds nothing beyond that: it does not say whether the delete is soft or hard, what happens to the customer's bank accounts/wallets/limits, or what an error on a missing ID looks like.

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

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

Two words contain no filler but also no information; this is under-specification rather than conciseness. There is nothing front-loaded because there is nothing to load.

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

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

For a destructive, open-world mutation with no output schema and undocumented required parameters, the description supplies none of the context an agent needs (scope, cascading effects, confirmation expectations). It is effectively a label, not a definition.

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 only 33% – only Idempotency-Key is documented in the schema, while id and instance_id carry only examples and length constraints. The description compensates for none of this, never mentioning the instance path parameter or the customer ID it operates on.

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?

"Delete Customer" restates the tool name and title almost verbatim, adding only the verb-object pairing. It does not state that the deletion is scoped to a specific instance/customer pair, nor distinguish it from the many sibling customer operations (PutV1InstancesCustomersById, GetV1InstancesCustomersById, DeleteV1InstancesCustomersBankAccountsById).

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 mention of prerequisites, and no warnings about irreversibility for a destructive operation. The agent gets no help choosing between this and PutV1InstancesCustomersById or the various sub-resource delete tools.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond restating the mutation: it does not say whether the wallet must be empty, what state is destroyed, whether deletion is reversible, or what authorization is required for a destructive financial-resource operation.

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?

"Remove Wallet" contains no wasted words and is front-loaded, but it is under-specified rather than concise. Two words cannot carry the operational context an agent needs for a destructive call.

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?

This is a destructive, idempotent delete on a financial resource with three required identifiers and no output schema. The description should at least confirm the deletion target/scope and consequences; instead it offers two words, leaving a substantial gap.

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

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

Schema coverage is only 50% (customer_id and Idempotency-Key are described; id and instance_id have examples but no description), so the description needs to compensate, and it does not. "Remove Wallet" gives no hint that three identifiers (instance, customer, wallet id) are required or what they identify.

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?

"Remove Wallet" names a verb and resource, but it is the bare minimum and does not distinguish this tool from sibling deletes such as DeleteV1InstancesCustomersBlockchainWalletsById or DeleteV1InstancesCustomersBankAccountsById. An agent must rely almost entirely on the tool name to understand which wallet is being removed and in what scope.

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

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

There is no guidance on when to use this delete versus the wallet-related siblings (blockchain wallets, bank accounts offramp wallets) or versus GetV1InstancesCustomersWallets/Put operations. No prerequisites, no exclusions, no stated alternatives.

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

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

The annotations already declare destructiveHint=true, idempotentHint=true, openWorldHint=true, and readOnlyHint=false, so the safety profile is known. The description adds no further behavioral context, such as irreversibility, side effects on related records, or permission requirements.

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 short phrase with no wasted words, but it is under-specified rather than appropriately concise. It lacks front-loaded detail needed for a destructive mutation.

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

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

For a destructive member-deletion operation with no output schema and low parameter description coverage, the description is too thin. It does not explain what happens to the member, whether related data is affected, or what authorization is required.

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 only 33%: only Idempotency-Key is documented in the schema. The description does not explain the roles of id and user_id, leaving the two required parameters semantically unclear.

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: deleting a member from an instance. It is clear enough to distinguish the action from most siblings, though it does not explicitly say the deletion is scoped by user id or contrast with PutV1InstancesMembersByUserId.

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

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

There is no guidance on when this tool should be used instead of GetV1InstancesMembers or PutV1InstancesMembersByUserId. No prerequisites, warnings, or conditions 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?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true), so the description needn't repeat them. However, it adds no context at all about what is destroyed, whether the removal is recoverable, or side effects on related records, which is what this dimension rewards. No contradiction with 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?

"Remove Partner Fee" is front-loaded with zero waste, but it is under-specified rather than genuinely concise. It is a two-word phrase that provides no structure or actionable detail.

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

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

For a destructive, open-world delete with no output schema and two undocumented required parameters, the description is far too thin. Annotations carry the safety flags, but the agent still lacks confirmation of what the deletion affects or what a successful response looks like.

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 only 33% (only Idempotency-Key is documented; id and instance_id have examples and length bounds but no descriptions). With low coverage the description must compensate, and it says nothing about what id or instance_id refer to or their formats.

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?

"Remove Partner Fee" states a verb and resource, so an agent can infer a deletion of a partner-fee record. But it merely restates the tool name/title and adds no scope, and nothing distinguishes it from the sibling GetV1InstancesPartnerFees / PostV1InstancesPartnerFees / GetV1InstancesPartnerFeesById beyond the name itself.

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 or when not to call it. The agent must infer that this is the destructive path for an existing partner fee rather than, say, the create endpoint.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds zero behavior context beyond that — no mention of whether the delete is soft or permanent, what happens to related records, whether funds/balance implications exist, or what errors arise from a non-existent or non-deletable payable. For a destructive financial mutation it should say more.

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 words with no waste in the literal sense, but this is under-specification rather than conciseness — the sentence does not earn the space it takes by conveying anything actionable beyond 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?

There is no output schema, so the description should at least indicate the return shape or post-delete state, and it says nothing. For a destructive, open-world mutation with two undocumented parameters, the definition is far too thin to call safely.

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

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

Schema description coverage is 0% — neither `id` nor `instance_id` has a description (only length constraints and examples like `pb_...` / `in_...`). The description does nothing to explain that `id` is the payable identifier or that `instance_id` scopes the tenant, which is exactly the gap it needed to fill.

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?

"Delete Payable" names a verb and a resource, so the basic action is identifiable, and the sibling list contains GetV1InstancesPayablesById as its read counterpart. But it is a two-word restatement of the title with no scope detail (what a payable is, what deleting one means in this API), so it barely clears the minimum-viable bar.

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 versus the sibling read/update payables endpoints, and no prerequisites (permissions, whether the payable must be in a certain state). The agent must infer everything from the name.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is known without the description. The description adds nothing beyond that — no note on irreversibility, cascade effects, or whether the endpoint stops receiving events immediately.

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 words is under-specification rather than conciseness. There is no wasted text, but the definition is far too thin to earn its place as the sole prose guidance for a destructive mutation.

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

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

For a destructive, open-world delete operation with no output schema and two undocumented required parameters, the description provides nothing an agent needs: not the target resource shape, not the effect scope, not error or retry 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 only 33%: the required id and instance_id properties carry no description in the schema, and the description supplies no meaning for them either. Only Idempotency-Key is documented, and that documentation lives entirely in the schema, not the description, so the description fails to compensate for the coverage gap.

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

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

"Remove Webhook" only restates the tool name (Delete Instances Webhook Endpoints By Id) in compressed form. It conveys the verb+resource but drops the instance scoping and adds no detail distinguishing this from the sibling GetV1InstancesWebhookEndpoints / PostV1InstancesWebhookEndpoints endpoints.

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

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

There is no statement of when to use this versus alternatives, no prerequisites, and no warning about what happens to in-flight webhook deliveries. The agent must infer everything from the tool name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds no behavioral context beyond those annotations, such as required permissions, path hierarchy, or return behavior.

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

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

The text is short but under-specified rather than concise. It is front-loaded but does not earn its place by conveying useful 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 nested read operation requiring instance_id, customer_id, bank_account_id, and id, the description is inadequate. No output schema exists, and the description does not explain the resource relationships or what the returned wallet represents.

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 only 25%, and the description mentions no parameters at all. With four required IDs and three undocumented in the schema, the description completely fails to compensate for the low coverage.

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

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

"Get Offramp Wallet" restates the tool name/title rather than adding meaning. It does not clarify that this retrieves a single offramp wallet by ID, nor how it differs from the sibling list endpoint GetV1InstancesCustomersBankAccountsOfframpWallets.

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 guidance, no exclusions, and no references to alternatives. It does not mention that this is the by-ID detail endpoint versus the list or create siblings.

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

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

Goes well beyond the readOnly/idempotent annotations by disclosing that no API key is required ('Public'), which annotations cannot express, and by describing the response payload structure (label, key, regex, items). For a read-only lookup, that covers the behavioral burden fully.

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

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

Three dense sentences, front-loaded with the purpose, then the use case, then the payload/validation detail. Nothing is repeated from the schema or annotations and no sentence is filler.

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

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

With no output schema, the description must describe the return payload and it does so precisely, plus it supplies the missing parameter documentation and auth context. An agent has everything needed to call it correctly.

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

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

Schema coverage is 0%, so the description carries the load: it explains that `rail` selects the payout rail and directs the agent to GET /v1/available/rails for valid values, which the bare enum cannot convey. It stops short of explaining the semantic difference between enum values (wire vs ach vs pix).

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

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

States a specific verb and resource ('Returns the fields a bank account needs for a payout rail') and immediately scopes it to the pre-creation validation use case. It is clearly distinguished from sibling GetV1AvailableRails, which it names as the source for valid rail values.

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

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

Explicitly says when to call it ('so a recipient form can collect and validate them before calling create bank account') and names the companion endpoint for obtaining the required `rail` input. Both the when and the prerequisite lookup are spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds nothing beyond that — no statement about caching, stability, or how results are returned — so it contributes no behavioral context of its own.

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 words with no structure is under-specification rather than conciseness. There is nothing to front-load because nothing is stated, so brevity here costs the agent information rather than saving it.

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

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

A zero-parameter read tool with no output schema is simple, but the description still leaves open what a NAICS list contains and in what form. For a reference-data lookup, one sentence on the returned code set would have closed the 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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The empty schema is self-explanatory on its own.

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?

"NAICS list" only restates the title "Get Available Naics" and adds no verb, scope, or resource detail. An agent learns nothing about what NAICS codes are returned or whether they are global reference data versus instance-specific.

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 and no mention of alternatives. The sibling tools GetV1AvailableRails and GetV1AvailableBankDetails occupy the same 'available reference data' family, and the description does nothing to distinguish this lookup from 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?

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds materially: the exact response shape `{ label, value, country }`, the fact that no API key is required (public endpoint), and a caveat that `country` is a display flag hint rather than a coverage guarantee. The last point preempts a very likely agent misinterpretation.

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 with no filler: identity of the resource first, downstream usage second, response shape and caveat last. The auth note is appended rather than buried, and nothing is repeated from the schema or annotations.

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 public list endpoint with no output schema, the description supplies the return shape, the field meanings, the auth requirement, and the consumption path. An agent has everything needed to call it and use the result 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?

There are zero input parameters, so the baseline is 4 by rule. The description instead spends its words documenting output field semantics (`value` vs `country`), which is useful but not strictly a parameter concern.

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

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

States a specific verb and resource ('Lists every payout rail BlindPay supports') and enumerates the actual values returned, so an agent knows exactly what comes back. It is clearly distinguishable from GetV1AvailableBankDetails, which it names as the downstream consumer.

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?

Explains where the returned `value` is consumed — as the `rail` query parameter of `GET /v1/available/bank-details` and as the `type` when creating a bank account — which effectively positions this as a prerequisite discovery call. It stops short of an explicit when-not or a stated alternative, so it lands just under a perfect score.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds nothing beyond that — no disclosure of what 'bank details' contains, whether unknown SWIFT codes return empty or error, or whether responses are cached.

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?

At four words this is under-specified rather than concise. Brevity is not a virtue here because there is no front-loaded statement of what the tool returns or when to use it.

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

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

With no output schema, the description is the only place a caller could learn what 'bank details' means (name, address, country, BIC branch info, etc.), and it does not say. For a lookup tool returning an undocumented payload, this leaves a real gap even though the annotations are rich.

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

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

Schema description coverage is 0%, but the schema itself carries strong structural constraints (8- or 11-character uppercase alphanumeric pattern, example BOFAUS3NLMA) that make the parameter's format evident. The description contributes no additional semantics such as whether BIC8/BIC11 branches differ in result, so it neither harms nor helps.

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?

"Swift code bank details" is a noun phrase that essentially restates the tool name (Get Available Swift By Swift). It implies a lookup of bank information keyed by SWIFT code, but gives no verb, no scope, and no differentiation from siblings such as GetV1AvailableBankDetails or GetV1AvailableNaics, which follow the same lookup pattern.

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 mention of alternatives, and no stated preconditions. An agent cannot tell from this description why it would call this lookup rather than GetV1AvailableBankDetails, nor what counts as a valid input beyond the schema regex.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds the non-obvious return ordering (fiat before blockchain), which is real added value, but says nothing about pagination, completeness of the list, or time-range 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?

A single front-loaded sentence with the verb and resource first and the ordering caveat second. Nothing is wasted, though it is arguably too short for the information an agent needs.

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

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

With no output schema, the description would ideally say something about what a fee record contains (amounts, currencies, payment-method grouping). For a simple one-parameter read tool it is adequate but leaves the return shape entirely unstated.

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

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

Only one parameter and schema description coverage is 100%, so the schema fully documents instance_id. The description adds no extra meaning about the parameter's format or constraints, 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 ("Get all fees for an instance") and adds the ordering rule. It does not distinguish itself from the similarly named GetV1InstancesPartnerFees sibling, so an agent must infer which fee source 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?

There is no explicit when-to-use, when-not-to-use, or named alternative. The scope phrase "for an instance" only implies usage; nothing tells the agent why to pick this over GetV1InstancesPartnerFees.

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

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

Annotations already declare this as a safe, idempotent read. The description adds valuable domain context beyond annotations, especially that `development` simulates settlement while `production` moves real funds, and that `onboarding_step=completed` means the instance can transact.

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

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

The description is three short sentences with no filler. The core purpose is front-loaded, followed by the most important safety and onboarding context.

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 operation with rich safety annotations and no output schema, the description provides enough behavioral context to interpret key fields safely. The main remaining gap is the unexplained `id` parameter.

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 has 0% description coverage for the single required `id` parameter, and the description does not explain what `id` represents, its expected format, or how it relates to the bound instance. It leaves the only parameter semantically undocumented.

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 action and resource: it returns the instance tied to the API key or connection. It is clear enough to distinguish this as an instance lookup tool, though it does not explicitly reinforce the `id`-based selection from the tool name.

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 useful conditional guidance to check `type` before moving money and explains what `onboarding_step` means. However, it does not explicitly say when to use this tool versus sibling instance or onboarding tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered elsewhere. The description adds nothing beyond that — no mention of how results are ordered, whether pagination is cursor- or offset-based despite both being supported, or what the response contains.

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

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

Two words are not wasteful in themselves, but the brevity here reflects under-specification rather than efficiency. There is no front-loaded scope statement because there is no scope content at all.

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

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

For an 11-parameter list endpoint with no output schema, a vague two-word description leaves an agent unable to know what filters combine, how the two pagination styles interact, or what a returned customer looks like. Annotations cover safety but not the operational details an agent needs to call this correctly.

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

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

With 11 parameters and only 36% schema description coverage, the description carries the burden of explaining limit/offset/ending_before/starting_after interplay and the filter fields (status, country, full_name, customer_id, bank_account_id) — but it explains none of them. Undocumented enum and filter behavior is left entirely ambiguous.

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?

"Retrieve Customers" names a verb and a resource, but it is essentially a restatement of the tool name/title and adds no scope. It does not say whether this lists customers within an instance, what filters are supported, or how it differs from the many sibling customer tools (GetV1InstancesCustomersById, PostV1InstancesCustomers).

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 mention of pagination or filtering expectations, and no reference to alternatives such as the by-ID variant. The only hint is the instance_id requirement, which comes from the schema, not the description.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing about filtering behavior, pagination, or result scope for a read-only 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?

Three words is not conciseness but under-specification; nothing is wasted, but nothing meaningful is conveyed either. The brevity leaves no front-loaded information for an agent to act on.

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?

A 7-parameter, 2-enum filtering endpoint with no output schema and no annotations covering return shape needs far more than a two-word phrase. An agent cannot tell what filters are supported or what the response contains.

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 only 14% across 7 parameters, and the description provides no parameter information at all. The filtering semantics of name, type, status, country, and bank_account_id — plus the two enum vocabularies — are left entirely undocumented.

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?

"Retrieve Bank Accounts" names a verb and resource, but gives no hint of scope (list vs. single record) or how it differs from siblings like GetV1InstancesCustomersBankAccountsById or GetV1InstancesCustomersBankAccountsOfframpWallets. An agent must infer from the required instance_id/customer_id pair that this lists bank accounts for a 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?

There is no statement of when to use this tool versus the by-ID getter, the Plaid-linked creation endpoint, or the off-ramp wallet variants. The plural resource name is the only implicit usage cue.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered structurally. The description adds nothing beyond that — no note on what is returned, whether a missing ID yields 404, or whether the bank account is fetched live from an external rail (relevant given openWorldHint).

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 words, front-loaded, zero waste — but the terseness is under-specification rather than efficiency. It is appropriately sized only in the sense that it says almost nothing.

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

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

Three required path-style parameters, no output schema, and partially documented IDs mean the description should carry more weight. It does not explain the identifier format, error behavior, or the relationship between customer_id and the bank account, so an agent has gaps to fill by guessing.

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

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

Schema coverage is only 33% — only customer_id has a description, while id and instance_id are documented solely by example/length constraints. The description does not compensate by explaining the required hierarchy (instance → customer → bank account) or the expected prefixed ID formats.

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?

"Retrieve Bank Account" restates the name/title rather than describing scope or behavior. It does not distinguish this single-item fetch from siblings like GetV1InstancesCustomersBankAccounts (list) or DeleteV1InstancesCustomersBankAccountsById.

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

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

There is no guidance on when to use this versus the list endpoint, nor on prerequisites such as whether the customer must belong to the instance or an existing bank account ID format. The agent is left to infer everything from the URL-shaped name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered by structured fields. The description adds nothing beyond that — no note that results are scoped to a single bank account, no ordering, no empty-result or pagination behavior. Not contradictory, but purely redundant.

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 words, front-loaded, zero waste — but the brevity is under-specification rather than economy, since there is no substantive content to be concise about.

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?

A three-required-parameter, three-segment-path retrieval tool with no output schema and only partial schema coverage needs the description to say what is returned and how the IDs relate. The description says none of that, so an agent must infer the entire contract from parameter names.

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 33%: only customer_id carries a description ("Customer ID"), while instance_id and bank_account_id are documented only by name, example, and length constraint. The description compensates for none of this and never explains that bank_account_id scopes the wallet list.

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?

"Get Offramp Wallets" only restates the title and last path segment; it adds no verb-level detail about what is retrieved or in what shape. It does not distinguish itself from the sibling GetInstancesCustomersBankAccountsOfframpWalletsById, which reads identically apart from the singular/plural trailing segment.

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, when-not-to-use, or alternative routing is given. With many near-identical siblings (wallets, blockchain wallets, virtual accounts, bank accounts), an agent has no basis to prefer this tool over those.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond that — no scoping behavior, no pagination or filtering note, no hint that results are limited to one customer's wallets.

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 words are concise but under-specified rather than efficient: for a list endpoint with eight same-family siblings, the description should be doing routing work and is not. Nothing is front-loaded because there is nothing to load.

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

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

No output schema exists, so the description should at least characterize what comes back (a list of blockchain wallets for a customer). It does not, and nothing compensates for the 50% parameter coverage or the dense sibling cluster.

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 only 50%: customer_id has a bare schema description ("Customer ID") and instance_id has none at all. The description contributes no parameter meaning, so the gap in the schema is left entirely unfilled.

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?

"Retrieve Blockchain Wallets" names a verb and a resource, so the basic operation is clear, but it is essentially a restatement of the tool name/title. It never says this is a list endpoint scoped to one customer within one instance, nor does it distinguish it from closely-named siblings such as ...BlockchainWalletsById or ...BlockchainWalletsSignMessage.

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 or when-not-to-use guidance at all. With siblings like GetV1InstancesCustomersBlockchainWalletsById, PostV1InstancesCustomersBlockchainWallets, and GetV1InstancesCustomersBlockchainWalletsSignMessage, the agent gets no help choosing this tool 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered without the description's help. The description adds nothing beyond that: no note on what the wallet record contains, whether it covers EVM/Solana/Stellar chains, or what happens on a missing or mismatched ID.

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

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

Three words with zero waste and front-loaded, but that brevity comes from under-specification rather than disciplined editing. There is no structure to speak of and nothing to route the agent.

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

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

For a tool requiring three opaque prefixed identifiers and returning a wallet object with no output schema, the description should say what is returned and how errors surface. It provides none of that, leaving the nested instance/customer/wallet hierarchy entirely 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 only 33% - both 'id' and 'instance_id' are left undocumented in the schema, and the description does not compensate at all. The 15-character prefixed identifier format (bk_/in_/re_) and the containment relationship between instance, customer and wallet ID are never explained.

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 'Retrieve Blockchain Wallet' essentially restates the tool name and title with no additional specification. It does signal a read of a single wallet resource, but never contrasts with the sibling list endpoint (GetV1InstancesCustomersBlockchainWallets) or the sign-message variant, so an agent still has to infer that the 'ById' suffix means a single-record fetch.

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, no prerequisites, no mention of alternatives. The agent is left to infer from the tool name alone that this is the single-wallet lookup path versus the list or sign-message 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds nothing beyond the annotations—it doesn't say what message is produced, the signing flow, or any auth requirements, so it fails to add useful behavioral 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?

It is a single short phrase with no wasted words, but it is under-specified rather than genuinely concise—brevity here sacrifices clarity.

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 read tool with no output schema, the description should explain what is returned (e.g., a message to be signed) and how it relates to the wallet ID and customer. Instead it leaves the return semantics and the sign-message flow entirely unexplained.

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

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

Schema coverage is only 50% (customer_id is described, instance_id is not), and the description mentions neither parameter. It does nothing to compensate for the missing instance_id documentation.

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 pairs the verb 'Retrieve' with 'Blockchain Wallet Message', but the tool name says 'SignMessage', leaving it ambiguous whether the tool signs or merely fetches a message to be signed. It also doesn't distinguish itself from the many sibling blockchain-wallet tools such as GetV1InstancesCustomersBlockchainWalletsById.

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

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

There is no statement of when to use this tool versus alternatives, and no prerequisites or context are given. An agent must infer usage purely from the awkward name.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no mention of instance scoping, error behavior for an unknown id, or whether the customer record is expanded with related objects.

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 words with nothing wasted, but this is under-specification rather than conciseness. There is no front-loaded scope or routing information for the agent to act on.

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 lookup-by-id tool with no output schema and zero parameter documentation, the description should explain the required identifiers, what a returned customer contains, and how it differs from the list and mutate siblings. None of that is present.

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

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

Schema description coverage is 0% and the description says nothing about the two required parameters. The schema's example values (re_…, in_… with 15-char bounds) hint at the id formats, but the description does not compensate for the missing semantics at all.

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

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

"Retrieve Customer" is a bare restatement of the tool name/title with no added specificity. It does not clarify that this fetches a single customer scoped to an instance, nor how it relates to the sibling GetV1InstancesCustomers (list) or Put/DeleteV1InstancesCustomersById.

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, no prerequisites, and no mention of alternatives, despite the family containing GetV1InstancesCustomers (list), PutV1InstancesCustomersById (update) and DeleteV1InstancesCustomersById (remove). The agent must infer selection from the tool name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds no additional behavioral context such as pagination, authorization requirements, response shape, or scoping by customer/instance.

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

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

The description is brief and front-loaded, but it is an under-specified fragment rather than a structured explanation. It is concise without wasting words, yet it omits useful context.

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 retrieval endpoint with no output schema, the description should clarify what is returned and how the required identifiers scope the result. Instead, it only restates the resource name, leaving return and filtering behavior unspecified.

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 only 50%, and the description does not explain either required parameter. It does not clarify how instance_id and customer_id scope the limit increase requests being retrieved.

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

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

The description states a specific verb and resource, "Retrieve Limit Increase Requests," so the basic operation is clear. However, it does not distinguish this list-style GET from siblings such as PostV1InstancesCustomersLimitIncrease or GetV1InstancesLimitsCustomersById, leaving scope ambiguous.

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

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

There is no guidance on when to use this tool versus creating a limit increase request or fetching customer limits through another endpoint. No prerequisites or filtering context 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?

Annotations already cover readOnly, idempotent, non-destructive, and open-world. The description adds genuine behavioral content beyond them: only the open (pending) RFI is returned, not resolved ones, and a null result is the documented no-RFI case rather than an error.

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

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

One sentence, front-loaded with the verb and resource, and the null-result caveat is appended without waste. 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?

With no output schema, the description must carry the return contract; it says an RFI (or null) comes back but not what an RFI contains or whether more than one can be pending. Adequate to call correctly, thin for interpreting the result.

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

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

Schema coverage is 50% — customer_id is documented, instance_id is not — and the description adds no format or meaning for either parameter. It neither compensates for the gap nor adds value beyond the schema.

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

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

States a specific verb (returns), resource (the open/pending RFI), and scope (for this customer), which separates it from the sibling GetV1InstancesRfi (instance-level) and PostV1InstancesCustomersRfi (creation). It does not name those siblings explicitly, so it falls short of a 5.

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

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

Usage is only implied by the read semantics: an agent can infer this is the lookup to call when checking whether a customer has an outstanding RFI. There are no explicit when-to-use/when-not conditions and no alternative named.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds nothing beyond that — no note on pagination, result size, ordering, filters, or what happens when the customer has no virtual accounts — so it earns little credit above the structured hints.

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

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

The description is two words long with zero waste, which is maximally concise, but the terseness crosses into under-specification rather than efficient front-loading. There is no structure to speak of and nothing to prioritize for the reader.

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

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

For an open-world, idempotent read endpoint with no output schema, the description should at least indicate the shape of the return (a collection of virtual accounts scoped to a customer) and any pagination behavior. With rich annotations carrying safety, the missing pieces are about output and scoping, and neither is addressed.

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 only 50%: customer_id is documented while instance_id has no description at all. The description mentions neither required parameter, so it does not compensate for the gap — it gives no hint that both IDs are mandatory path-style identifiers with a 15-character fixed format.

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 verb ('Retrieve') and a resource ('Virtual Accounts'), so the general intent is inferable and the plural resource hints at a list operation. However, it does not establish scope (all virtual accounts for a given customer vs. a single account) nor differentiate from the adjacent GetV1InstancesCustomersVirtualAccountsById sibling, leaving the agent to infer from the tool name alone.

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

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

There is no statement of when to use this tool versus the many siblings in the same namespace, including GetV1InstancesCustomersVirtualAccountsById, PostV1InstancesCustomersVirtualAccounts, and PutV1InstancesCustomersVirtualAccountsById. The agent must guess that the plural form means 'list' from naming conventions rather than from any explicit 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description contributes nothing beyond that — no note on what is returned, error behavior for a missing virtual account, or scoping to instance/customer.

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 three-word fragment with no waste but also no information density; brevity here reflects under-specification rather than disciplined conciseness. Nothing is front-loaded because there is nothing to front-load.

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

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

For a tool requiring three opaque prefixed identifiers with no output schema, the description should explain the instance/customer/virtual-account hierarchy and expected response. None of that is present, leaving the definition inadequate for correct invocation.

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

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

Schema description coverage is only 33% — customer_id has a 'Customer ID' description, while id and instance_id rely solely on 15-character examples. The description does not compensate at all, leaving ambiguity about the id prefix types (bk_ vs re_ vs in_) and the parent-child scoping among the three required IDs.

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 is 'Retrieve Virtual Account', which essentially restates the tool name and title without adding scope. It never distinguishes this single-record fetch from the sibling list endpoint GetV1InstancesCustomersVirtualAccounts or the nearby update/delete variants.

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

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

There is no guidance on when to use this tool versus the collection endpoint GetV1InstancesCustomersVirtualAccounts or PutV1InstancesCustomersVirtualAccountsById. An agent must infer selection purely from the tool name's 'ById' suffix.

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

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

Annotations already declare this as read-only, idempotent, open-world, and non-destructive. The description adds no behavioral context such as pagination, filters, auth requirements, or response shape, so it contributes almost nothing beyond the annotations and name.

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 extremely short, but the brevity reflects under-specification rather than efficient communication. Two words do not adequately front-load the endpoint's scope or distinguish it from sibling wallet tools.

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 dense sibling namespace, 50% schema coverage, and no output schema, the description is insufficient for reliable selection and invocation. It omits key distinctions between list and by-ID wallet operations and does not explain the return 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 only 50%: customer_id is described, but instance_id is not. The description provides no parameter guidance at all, so it does not compensate for the undocumented instance_id or clarify scoping.

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 says 'Retrieve Wallets,' which gives a verb and a resource but does not clarify whether this lists wallets, returns a single wallet, or how it differs from GetV1InstancesCustomersWalletsById or the BlockchainWallets siblings. The intent is only minimally interpretable from the name.

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 is provided. It does not explain when to use this list endpoint versus GetV1InstancesCustomersWalletsById, BlockchainWallets, or wallet balance/deposit endpoints, leaving the agent to infer from naming conventions.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior, so the description's real contribution is the non-obvious unit convention (whole tokens, not cents) and the composition of total_amount as amount plus earning_amount. That prevents a serious misinterpretation of returned values. It doesn't cover what happens when the wallet has no balance or when a currency is absent.

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

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

Two sentences, front-loaded with the core action and followed by the one clarification that matters most (units), then the field formula. No filler.

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

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

With no output schema, the description partially pays off by explaining amount, earning_amount, and total_amount, but leaves the rest of the response shape, error/empty cases, and parameter roles unaddressed. Adequate but with clear gaps for a three-required-parameter lookup.

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 only 33%; only customer_id has any documentation, and neither instance_id nor the path id have descriptions or format guidance beyond examples. The description adds no meaning for any of the three required parameters, so it fails to compensate for the schema gap.

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

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

States a specific verb and resource: returns the balance of a BlindPay-managed wallet, with named currencies. It doesn't differentiate itself from close siblings like GetV1InstancesCustomersWallets, GetV1InstancesCustomersWalletsById, or GetV1InstancesCustomersWalletsYield, which an agent could easily confuse it with.

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 call this versus fetching the wallet list or the yield endpoints; usage is only implied by the word 'balance'. There are no exclusions, prerequisites, or named alternatives despite a crowded wallet-related sibling set.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no mention of authorization scoping on instance_id/customer_id, no pagination or not-found behavior, and no disclosure beyond what annotations give.

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 words, so there's no bloat, but this is under-specification rather than conciseness. There is no front-loaded content an agent can act on beyond the bare verb.

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?

A three-required-parameter retrieval tool with no output schema and incomplete parameter documentation needs the description to explain what it returns and how the identifiers combine. Nothing in "Retrieve Wallet" fills that gap for an agent choosing among ~90 sibling endpoints.

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 only 33%; only customer_id has a description ("Customer ID"), and the required `id` wallet identifier has none. The description does not compensate by explaining that the 15-character bk_ prefixed id is the wallet identifier scoped to a customer within an instance.

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?

"Retrieve Wallet" is essentially a restatement of the tool name and title (Get...Wallets...ById) rather than a description. It gives no detail about what a wallet record contains, what scope the retrieval covers, or how it differs from siblings like GetV1InstancesCustomersWallets (the list version) or GetV1InstancesCustomersWalletsBalance.

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

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

There is no guidance on when to use this tool versus the many adjacent wallet endpoints (list, balance, deposits, yield, blockchain wallets). The description provides no conditions, prerequisites, or alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds the useful 'newest first' ordering trait, but says nothing about pagination semantics or return shape. Modest value on top 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?

A single tight sentence with zero waste, and the ordering detail is front-loaded. It is efficient, though the brevity comes at the cost of the guidance dimensions above.

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 endpoint with 8 parameters (3 required), no output schema, and the wallet/payin sibling set, the description is too thin. It omits that results are paginated, what filters exist, and how this differs from related wallet and payin tools.

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

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

Schema coverage is only 50% across 8 parameters, and the description explains none of them — not the required ids, nor the token/status filters, nor the limit/cursor pagination. With low coverage the description should compensate for the undocumented parameters, and it does not.

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

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

States the resource ('incoming stablecoin deposits to a managed wallet') and gives ordering ('newest first'), but never uses an explicit verb like 'list' and does not distinguish it from wallet-adjacent siblings such as GetV1InstancesCustomersWalletsYieldTransactions or GetV1InstancesCustomersWalletsById. The intent is inferable from the name but not clearly established in the prose.

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

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

No statement of when to use this tool versus alternatives, and no mention of prerequisites or the relationship to the wallet/payins siblings. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered for free. The description adds nothing beyond that — no indication of what data is returned, whether it reflects live accrual, or any rate/size considerations that would matter for a yield endpoint.

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 words is not concision but under-specification; there is no front-loaded context an agent can act on. Nothing is wasted, but nothing earns its place either because there is almost nothing there.

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?

Three required parameters with no output schema means the description must carry the burden of explaining what comes back and how the IDs combine, and it does not. Given the crowded yield sub-family, this leaves the agent with insufficient information to call the tool confidently.

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 only 33%, and the sole documented parameter (customer_id) is described only as "Customer ID," which is tautological. Critically, the description does not clarify what the required `id` is (wallet ID? yield position ID?) or what `instance_id` scopes, so the ambiguous parameter is left entirely to guesswork.

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 verb (Retrieve) and a resource (Wallet Yield), but "Wallet Yield" is ambiguous — the sibling set contains YieldEnable, YieldDisable, YieldHistory, and YieldTransactions, and the description gives no clue which facet of yield this returns (current configuration vs. accrued amount). An agent cannot reliably distinguish it from GetV1InstancesCustomersWalletsYieldHistory without inferring from the tool name alone.

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

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

There is no guidance on when to use this versus the four sibling yield tools, nor any stated prerequisites (e.g., whether yield must be enabled first). Usage must be inferred entirely from naming conventions.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds no behavioral context of its own — no mention of pagination, the 366-day window cap, or what a yield history record contains.

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

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

Three words, front-loaded, zero waste — but the brevity is under-specification rather than discipline. There is no sentence that earns its place because there is essentially only the title.

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

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

With 6 parameters (3 required), no output schema, and an undocumented token enum, an agent needs more to call this correctly. The description does not explain what a wallet yield history returns, whether results are time-bucketed, or how it differs from the related yield-transactions endpoint.

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

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

Schema coverage is only 50%: the 'id', 'instance_id' and 'token' parameters carry no description, and 'id' is a required 15-char wallet identifier that is easily confused with the sibling paths. The description does nothing to clarify parameter meaning, so it fails to compensate for the coverage gap.

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

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

The phrase 'Retrieve Wallet Yield History' names a verb and resource, so an agent can roughly tell what it returns. But it is essentially the title restated and does not distinguish it from sibling tools like GetV1InstancesCustomersWalletsYield or GetV1InstancesCustomersWalletsYieldTransactions, leaving the yield-history variant ambiguous.

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

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

There is no guidance on when to call this versus the other wallet-yield endpoints (Yield, YieldTransactions, YieldEnable/Disable) or the plain wallet endpoints. The only hint at usage is the schema's from/to defaults, which is not in the description.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — no mention of pagination behavior, result ordering, or that it is a per-wallet scoped list.

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

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

The single phrase is short but that shortness reflects under-specification rather than efficiency. It is front-loaded but carries no actionable content.

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

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

For an 8-parameter, 3-required-parameter endpoint with no output schema and partial schema descriptions, the description omits pagination semantics, filtering behavior, and return shape. It is not nearly complete enough for an agent to call it confidently.

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?

With 8 parameters and only 63% schema description coverage, the description needs to compensate but supplies zero parameter meaning. Key parameters like 'id', 'token', and 'instance_id' lack descriptions in the schema and get no explanation here, and the cursor/limit interaction is unaddressed.

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 'Retrieve Wallet Yield Transactions' restates the tool name and title almost verbatim, adding no scope or detail. It does not distinguish this tool from close siblings such as GetV1InstancesCustomersWalletsYieldHistory or GetV1InstancesCustomersWalletsYield.

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

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

There is no guidance on when to use this tool versus the several sibling yield/wallet endpoints, and no mention of prerequisites such as requiring a wallet that has yield enabled. The agent must infer usage entirely from the name.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is consistent with a plain read. However, it adds nothing beyond that — no indication of whether the response is a single limits object, whether limits are per-customer or per-instance, or how missing limits are surfaced.

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 words are trivially concise but are under-specification rather than economy; there is no front-loaded scope or constraint because there is almost no content at all.

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 lookup inside a very large, densely overlapping sibling set, with no output schema and no annotation beyond safety hints, the definition supplies none of the disambiguating context an agent needs to call it 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 0% and both required parameters ('id' and 'instance_id') are documented only by string-length constraints and an example. The description never clarifies whether 'id' refers to a customer ID or a limits record ID, so it fails to compensate for the coverage gap.

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

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

The description says 'Retrieve Customer Limits', which identifies a verb and a resource, so an agent can guess the general operation. But it gives no scope or qualifier detail and does nothing to distinguish this from close siblings like GetV1InstancesCustomersById, GetV1InstancesCustomersLimitIncrease, or GetV1InstancesCustomers.

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

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

There is no statement of when to use this tool, when not to, or which sibling to prefer. In a sibling set containing both customer reads and limit-increase reads, that omission leaves selection entirely to inference from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: no pagination behavior, no authorization scope (instance-level vs user-level), and no hint about result shape, which matters for an openWorldHint endpoint.

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?

Extremely short and front-loaded with zero waste, but the brevity comes from under-specification rather than efficiency. It reads as a title, not a usable definition.

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 annotation-level detail covering return contents, the description should at least say what a member record contains or how the list is scoped. It omits everything an agent would need beyond the bare id argument.

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 required parameter `id` has 0% schema description coverage, so the schema tells the agent almost nothing about what the id refers to (instance id, per the example `in_...`). The description does not compensate, though the singular required argument with a 15-char instance-style example makes the intent guessable.

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?

"Retrieve Instance Members" restates the tool name/title without adding a specific verb scope or distinguishing it from GetV1InstancesById. It does hint that the result is a collection (plural "Members"), but an agent cannot tell from the text alone whether it returns all members, paginated results, or a single record.

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 indication of when to call this versus the sibling mutators PutV1InstancesMembersByUserId and DeleteV1InstancesMembersByUserId, nor any prerequisite such as needing an instance id that actually owns members. Usage is only inferable from the tool name itself.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. However, the description contributes nothing beyond that — it does not say what the onboarding business details include, whether KYC status is involved, or whether the payload can be empty pre-onboarding.

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 single phrase is front-loaded and free of padding, so nothing is wasted, but it is under-specified rather than concise. Brevity here costs information rather than saving it.

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

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

For a read tool with one required parameter and no output schema, the description should explain what the returned business details represent and their relation to onboarding state. It provides none of that, leaving the agent to guess at the response contents.

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

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

Schema description coverage is 0% for the single required parameter instance_id, and the description does not compensate at all — it never mentions the instance identifier or its format. The only parameter meaning available comes from the schema's example and length constraints, not the prose.

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 verb (retrieve) and a resource (business details), so the basic action is identifiable, but it adds nothing the title doesn't already say. It gives no indication of which business details or how they differ from the sibling OnboardingBusinessProfile and OnboardingOwnershipDocuments 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?

There is no guidance on when to use this tool versus the many onboarding siblings (BusinessProfile, OwnershipDocuments, Rfi), nor any prerequisite or context. The agent is left to infer everything from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — no information about what the profile contains, whether onboarding must be in progress, or what happens if no profile exists.

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

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

The three-word description is as brief as possible and front-loaded, but its brevity comes from omission rather than economy — it is under-specified rather than tight.

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 output schema and competes with a near-identically named sibling, the description should clarify scope and return content but does neither. An agent cannot determine from this text what a 'Business Profile' returns or how it differs from BusinessDetails.

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

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

Schema description coverage is 0% for the single required parameter, instance_id. The description says nothing about it, though the schema does supply a format example (in_ + 12 digits) and length constraints, which partially compensates.

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

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

The description is essentially a restatement of the tool name/title: 'Retrieve Business Profile' adds only the verb 'Retrieve' to what the name already conveys. It does not distinguish this tool from the very similar sibling GetV1InstancesOnboardingBusinessDetails, which an agent would have no basis for choosing between.

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

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

There is no guidance on when to use this tool, no prerequisites, and no mention of alternatives. The closest sibling, GetV1InstancesOnboardingBusinessDetails, is never referenced, leaving the agent to infer the distinction on its own.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds zero behavioral context—no note about what documents are returned, whether they are per-instance, or anything about the open-world fetch.

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

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

The three-word phrase is efficient and front-loaded, but it is under-specified rather than genuinely concise. There is no wasted text, yet the brevity comes at the cost of meaning.

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 parameter documentation, the description must explain what is retrieved and how instance_id scopes it. It provides neither, leaving an agent without enough to confidently invoke the tool or interpret results.

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

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

There is one parameter, instance_id, with 0% schema description coverage, so the description carries the burden of explaining it. It says nothing about instance_id, its format (a 15-character in_ ID), or what it scopes—failing to compensate for the schema gap.

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

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

The description says "Retrieve Business Documents," which gives a verb and a resource but does not name ownership documents as the tool title does, creating a mismatch. It is essentially a light restatement of the name and offers nothing to distinguish it from the dozens of sibling GET 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?

There is no guidance on when to use this tool, when not to, or which sibling to prefer. With many onboarding-related siblings like OnboardingBusinessDetails and OnboardingBusinessProfile, an agent has no basis for routing to this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds nothing beyond that baseline: no pagination, result volume, or filtering behavior for what is an open-world read.

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 words with no padding or filler, so nothing is wasted, but the brevity reflects under-specification rather than disciplined concision. It is front-loaded but has essentially no content to front-load.

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

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

For an instance-scoped list endpoint with no output schema and an undocumented parameter, the description should say what the response contains (fee records, effective dates, amounts) and whether results are paginated. Neither is present, leaving the agent to call blind.

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

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

Schema description coverage is 0% for the single required parameter, instance_id; the only help comes from the example and 15-char length constraint. The description contributes no meaning about what an instance_id is or where to obtain one, so it fails to compensate for the coverage gap.

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

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

"Retrieve Partner Fees" gives a recognizable verb and resource, matching the minimum needed to know this fetches partner fee data. But it is essentially a restatement of the title, and it does not clarify that this lists fees scoped to an instance nor how it differs from the sibling GetV1InstancesPartnerFeesById.

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 mention of the by-id sibling as the alternative for fetching a single fee, and no prerequisites. The agent must infer from the name alone that this is the collection/list variant.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered structurally. The description contributes nothing beyond that — no note on what a 404 means, whether fees are tied to an instance, or any retrieval characteristics.

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 words is concise but dramatically under-specified rather than efficient; there is no front-loaded scope statement or qualifier to anchor the reader. Brevity here is a deficit, not a virtue.

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 two required undocumented parameters, no output schema, and no annotations explaining return shape, the description should carry the burden of explaining what a Partner Fee record is and what identifying it requires. It supplies none of that.

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

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

Schema description coverage is 0%: neither `id` nor `instance_id` has any description, and the description text mentions no parameters at all. It does not even clarify that both are required nor explain the relationship between the instance and the fee ID, so it fails to compensate for the coverage gap.

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

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

The description "Retrieve Partner Fee" restates the title and name almost verbatim, adding no scope, no statement that it fetches a single fee record by ID, and no differentiation from the sibling list tool GetV1InstancesPartnerFees. An agent learns only what it could already infer from the tool name.

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 is given. It never contrasts itself with GetV1InstancesPartnerFees (list) or DeleteV1InstancesPartnerFeesById, which are the obvious alternatives, leaving routing entirely to the agent's guesswork about the 'ById' suffix.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that—no note on pagination behavior, filter combination semantics, default page size, or ordering of results.

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

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

Two words are technically concise but represent under-specification rather than efficiency. There is nothing front-loaded because there is effectively no content.

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 10-parameter, filter-and-paginate list endpoint with no output schema, the description is wholly inadequate—it explains neither the resource, the filters, the pagination contract (limit/offset vs. ending_before/starting_after), nor what is returned.

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?

Ten parameters with only 40% schema description coverage, yet the description mentions none of them. The enum-bearing filters (type, status, limit, offset) and free-text filters (customer_name, beneficiary_name) are left undocumented in prose, so the description fails to compensate for the coverage gap.

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

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

"List Payables" restates the tool name/title rather than explaining what a payable is or how the listing behaves. It does not distinguish this collection endpoint from siblings like GetV1InstancesPayablesById or PostV1InstancesPayables.

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

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

There is no guidance on when to use this versus GetV1InstancesPayablesById, the create/delete payables tools, or other instance-scoped list endpoints. An agent must infer everything from the tool name and schema.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond that: no mention of what is returned, whether the record may be missing (404 behavior), or any instance-scoping or auth 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 words are technically free of padding, but this is under-specification rather than conciseness. Nothing is front-loaded because there is essentially no content to structure.

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

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

For a read-only single-resource fetch with two undocumented required identifiers and no output schema, the description leaves the agent without the parameter meaning or return shape. Annotations cover safety, but the identifier semantics and expected response remain unexplained.

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

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

Schema description coverage is 0%, so the description carries the full burden for two required parameters, yet it mentions neither. An agent must infer that 'id' is the payable identifier and 'instance_id' the tenant context purely from the 15-character example strings.

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 'Retrieve Payable' restates the tool name (Get Instances Payables By Id) almost verbatim, adding only the singular form to hint at single-record retrieval. It does not explain what a payable is or how this differs from GetV1InstancesPayables or DeleteV1InstancesPayablesById, both of which also appear among the 60+ siblings.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative named. The 'ById' in the name weakly implies fetching one record rather than listing, but the description itself provides no routing guidance among the many sibling GET 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context such as pagination behavior, required instance scoping, or what the returned payin list contains.

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

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

The phrase is short but under-specified rather than usefully concise; it is not structured to front-load scope, required parameters, or filtering behavior. For a 13-parameter list endpoint, this is too terse to guide invocation.

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?

This is a complex list tool with 13 parameters, low schema description coverage, no output schema, and many sibling tools. The description does not explain scoping, filtering, pagination, or return semantics, leaving an agent without enough context to invoke it reliably.

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 only 31% across 13 parameters, so the description must compensate for undocumented parameters. "Retrieve Payins" provides no meaning for required instance_id, filters like status/customer_id/payment_method, or pagination cursors.

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 "Retrieve Payins" essentially restates the tool name and title (Get Instances Payins -> Retrieve Payins). It identifies the resource but does not explain that this is a scoped list operation or distinguish it from siblings such as GetV1InstancesPayinsById.

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

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

There is no guidance about when to use this list endpoint versus GetV1InstancesPayinsById or other payin-related tools. It also gives no indication of how filters such as status, customer_id, or pagination parameters should be used.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so safety behavior is covered. The description adds no additional behavioral context such as error behavior, what a missing payin returns, or any constraints beyond the annotations.

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

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

The description is extremely short, but it is under-specified rather than appropriately concise. It is front-loaded with a verb and resource but omits essential context needed to select and invoke the tool correctly.

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

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

For a tool with two required undocumented parameters, no output schema, and no parameter descriptions, the description does not provide enough information to call the tool confidently. It gives no detail about the ID format, instance scoping, or return value beyond what annotations imply.

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

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

Schema description coverage is 0%, so both required parameters are undocumented, and the description does not explain what 'id' versus 'instance_id' means. The two-word description provides no parameter meaning at all, leaving the agent with only parameter names and examples.

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

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

The description says 'Retrieve Payin', which identifies a read operation on a payin resource, but it does not mention lookup by ID or the instance scope. It is vague enough that an agent cannot distinguish it from sibling list tools like GetV1InstancesPayins without inspecting the name or 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?

There is no guidance about when to use this tool versus GetV1InstancesPayins or other payin-related tools. The agent must infer that this is a single-resource lookup by ID from the tool name alone.

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

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

Annotations already declare this as a safe, read-only, idempotent, open-world operation. The description adds no context beyond that—no mention of pagination behavior, filtering constraints, response shape, or instance scoping.

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 extremely short and front-loaded, but this is under-specification rather than useful conciseness. Two words cannot carry the needed meaning for a 13-parameter list endpoint.

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 complex collection-listing tool with multiple filters, pagination options, no output schema, and sparse schema descriptions, the description is completely inadequate. It gives the agent almost nothing needed to call 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?

The tool has 13 parameters with only 31% schema description coverage, and the description provides no parameter semantics at all. Many enum and filter parameters (status, country, network, customer_id, payment_method, etc.) are left undocumented in both schema and description.

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

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

The description gives a specific verb and resource ("Retrieve Payouts"), so the basic purpose is understandable. However, it does not clarify that this returns a collection scoped to an instance, nor differentiate it from the sibling GetV1InstancesPayoutsById.

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

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

There is no guidance on when to use this endpoint versus the by-ID sibling or how to choose among the many filters. At best, usage is implied by the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing about error behavior (e.g., what happens with an unknown ID), rate limits, or required permissions, leaving the added value near zero.

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?

At three words it is technically concise, but this is under-specification rather than efficient conciseness. There is no front-loaded scope statement or any structure to help an agent decide on invocation.

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, no parameter descriptions, and no annotations explaining the response, the description must carry the full burden of explaining what is returned (a payout object) and how identifiers relate. It does none of this.

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

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

Schema description coverage is 0%, so the description must compensate, yet it says nothing about the two required parameters. It doesn't explain that 'id' is a payout identifier (e.g., po_...) scoped to a specific instance identified by instance_id.

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?

"Retrieve Payout" restates the tool name/title with a verb and resource but adds no distinguishing information. It does not clarify that this fetches a single payout by ID versus the sibling GetV1InstancesPayouts, which lists payouts.

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

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

There is no guidance on when to use this tool, no mention of prerequisites (e.g., needing a valid instance_id and payout ID), and no reference to alternatives such as the list endpoint. Only the name hints at by-ID retrieval.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing the filtering behavior ('open (pending)') and the null-when-absent return contract, but says nothing about what an RFI object looks like or whether history is reachable elsewhere.

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 waste. The parenthetical '(pending)' is mildly redundant with 'open' but serves as a synonym bridge for matching against API docs using either term.

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 with strong annotations, the essentials are present. However, with no output schema the description carries the burden of explaining the return value, and it only says the result is an 'RFI' without characterizing fields or shape.

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 0% for the single instance_id parameter, so the description is the only source of meaning. 'For this instance' confirms the parameter's target, but it adds no format, length, or validity detail beyond what the parameter name already implies.

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

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

States a specific verb and resource ('Returns the open (pending) RFI') and scopes it to 'this instance', which implicitly distinguishes it from the customer-level RFI siblings. It stops short of naming the sibling it differs from, so an agent must infer the instance-vs-customer split from the name alone.

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 guidance and no mention of alternatives such as GetV1InstancesCustomersRfi or the related PostV1InstancesRfi. The only conditional information is the null case, which describes the result rather than when an agent should reach for this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description nevertheless adds nothing whatsoever – no indication of result volume, pagination behavior, filtering semantics, or whether results are limited to the instance given the required instance_id.

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

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

Two words are as short as possible, but this is under-specification rather than conciseness – there is no front-loaded statement of scope, filters, or result behavior to anchor the call.

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?

A 10-parameter, filter-heavy list endpoint with no output schema and an instance-scoped required parameter demands far more description than a two-word phrase. Nothing an agent needs to call it correctly – scope, filter combination rules, pagination approach, or return shape – is present.

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

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

Schema description coverage is 60%, and several parameters (status enum, wallet_id, customer_id, instance_id) have no schema description at all. The description contributes zero parameter meaning, so it fails to compensate for the gap, particularly the ambiguous status values (e.g. 'refunded') and the relationship between offset/limit and the cursor 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?

"Retrieve Transfers" restates the tool name/title (Get Instances Transfers) with no added specificity. Despite the schema showing pagination cursors, filters by token/status/network/wallet/customer, and an instance_id scoping parameter, the description never even clarifies that this is a paginated list operation for a given instance rather than fetching a single transfer.

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, no when-not-to-use, and no mention of the obvious alternatives in the sibling set such as GetV1InstancesTransfersById for a single transfer or PostV1InstancesTransfers for creation. The agent must infer everything from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered structurally. The description contributes nothing beyond that: no statement of what a transfer record contains, whether the lookup returns 404 for unknown ids, or whether the response includes nested payout/payin links.

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 single phrase is short, but this is under-specification rather than conciseness—there is no front-loaded statement of resource, scope, or return value. Length is only a virtue when the necessary information is still present, and here it is not.

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 is the only place an agent could learn what a retrieved transfer looks like, and it provides nothing. Even with the lookup being a simple read, the definition is too thin for an agent to confidently pick this tool among dozens of sibling GET-by-id endpoints.

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

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

Schema description coverage is 0%, so the description must carry the burden of explaining the two required parameters. It says nothing about the relationship between instance_id and id, nor that id refers specifically to a transfer identifier (the `tr_` example and 15-char length constraint are buried in the schema with no prose support).

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?

"Retrieve Transfer" restates the title (Get Instances Transfers By Id) without adding scope: it never says this fetches a single transfer by its 15-character id within a given instance. It does not distinguish itself from the sibling GetV1InstancesTransfers (list) or GetV1InstancesPayoutsById, so an agent must infer the difference from the name alone.

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 versus GetV1InstancesTransfers, which is the obvious alternative for transfer data. No prerequisites, no mention of needing both instance_id and the transfer id, and no exclusion conditions. The agent is left to infer usage entirely from the tool name.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that — no mention of pagination, result ordering, filters, or whether an empty list is possible, which is the kind of context a list tool should supply.

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 words with no fluff, but this is under-specification rather than conciseness — there is no front-loaded scoping, no statement of return contents, and nothing that earns placement in an agent's selection reasoning.

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 instance-scoped list tool with one required parameter and no output schema, the description still leaves the agent without the scope, the return shape (array of endpoint objects), or the sibling routing needed to call it confidently.

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

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

Schema description coverage is 0% and the single required parameter (instance_id, fixed 15-char string) is undocumented in both schema and description. The description should at least clarify that the call is scoped to one instance and what format that identifier takes.

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?

"Retrieve Webhooks" gives a generic verb (Retrieve) and a loosely-named resource that doesn't precisely match the tool's actual scope (webhook endpoints for an instance). It is a partial restatement of the title rather than a distinguishing statement, and it doesn't separate it from siblings like GetV1InstancesWebhookEndpointsSecret or GetV1InstancesWebhookEndpointsPortalAccess.

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 versus the many neighboring webhook tools (secret retrieval, portal access, POST to create, DELETE by id). The agent must infer from the name alone that this is the list operation.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds no behavioral context such as whether access is scoped to the caller, whether it expires, or whether it requires elevated permissions — for a security-adjacent credential retrieval, that silence is notable.

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 short sentence with no filler, so nothing is wasted — but the brevity reflects under-specification rather than economy. There is no front-loaded detail an agent could act on.

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

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

With no output schema, the description is the only place to learn what is returned (portal URL? credential? access flags?) and it says nothing. For a tool in a webhook/credential area of a large API surface, this is insufficient for correct invocation.

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

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

Schema description coverage is 0%, leaving the single required instance_id documented only by type, example format, and length bounds. The description does not explain what an instance is or how the ID relates to webhook endpoints, so it fails to compensate for the coverage gap.

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

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

The description 'Retrieve Webhook Portal Access' essentially paraphrases the tool name and title without adding specificity. It's unclear what 'portal access' means (a URL, a token, permissions?) and nothing distinguishes it from nearby siblings like GetV1InstancesWebhookEndpoints or GetV1InstancesWebhookEndpointsSecret.

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

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

There is no guidance on when to use this tool versus the webhook endpoint or webhook secret siblings. No prerequisites, no exclusions, no context about when portal access is needed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond the title: it does not disclose that the response contains sensitive credential material, whether the secret is rotatable, whether retrieval is audited, or what happens if the endpoint has no secret configured.

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 words with no padding and the verb-object ordering is front-loaded. Brevity here shades into under-specification rather than efficiency, since nothing else compensates for the missing detail.

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 tool returning sensitive credential material with no output schema and entirely undocumented parameters, the description should explain what is returned and any handling caveats. As written, an agent knows only the resource name and must guess at the returned value's shape and semantics.

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

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

Schema description coverage is 0% for two required parameters, so the description carries the burden and supplies none of it. The schema gives only examples and 15-character length bounds for `id` and `instance_id`; the description never says that `id` is the webhook endpoint identifier rather than an instance-level or customer-level id, which is the likely point of confusion.

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?

"Retrieve Webhook Secret" names a verb and a resource, so the basic intent is legible. But it does not distinguish this tool from its close siblings (GetV1InstancesWebhookEndpoints, GetV1InstancesWebhookEndpointsPortalAccess), nor clarify what a "secret" is here (signing key material vs. a webhook payload).

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 call this instead of GetV1InstancesWebhookEndpoints for webhook configuration, and no mention of prerequisites such as permissions or the sensitivity of fetching a credential. An agent must infer everything from the name.

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

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

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=false), yet the description adds the crucial one-shot, null-gated irreversibility semantics that annotations alone would not convey. It does not mention auth requirements or the Idempotency-Key retry behavior, but the core behavioral caveat 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?

Two sentences, no filler, with the operative constraint front-loaded. Every clause carries information the 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 mutation tool with a nested request body and no output schema, the description supplies the key semantic constraint and irreversibility. It is close to complete, though it omits any mention of the idempotency header or path-parameter requirements.

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

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

Schema coverage is only 40%, so the description must compensate; it does meaningfully explain the payload field is_self_custody (holding private keys, only settable while null). However, it says nothing about the three path parameters (instance_id, customer_id, id) or the optional Idempotency-Key, leaving half the surface to inference.

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

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

Names a specific action (declaring private-key custody) on a specific resource (blockchain wallet), which clearly distinguishes it from sibling Get/Delete/Post wallet tools. The verb 'Declares' is slightly non-standard for a PATCH update, but the resource and effect are 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?

Gives a clear precondition ('Only works while is_self_custody is null') and a clear exclusion ('once saved it cannot be changed'), which tells the agent exactly when this call is valid. It does not name alternative tools for the already-set case, so it falls short of a 5.

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