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

No annotations are provided, so the description carries the full behavioral burden. It only says a new business context is created; it does not disclose side effects, payout requirements, uniqueness constraints, required setup, or response behavior. For a mutating create operation, this is a significant transparency gap.

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

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

The description is a single front-loaded declarative sentence with no filler. It efficiently names the operation and purpose, leaving parameter details to the input schema.

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

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

The input schema covers all parameters fully, and the description establishes the resource being created. However, with no annotations and no output schema, the definition still leaves operational details—such as what is returned, what happens after creation, and any constraints—unaddressed. It is minimally viable but not rich enough for full autonomous decision-making.

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

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

Schema description coverage is 100%: business_name, wallet_address, and solana_wallet_address all have meaningful inline descriptions. The tool-level description adds no parameter-specific meaning, but with full schema coverage the baseline of 3 is appropriate.

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

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

The description clearly states a specific action and resource: 'Create a new business context' with the purpose 'for receiving direct crypto payments.' This is distinct enough to separate it from create_invoice, though it does not explicitly contrast with the other business-management 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 guidance on when to use this tool versus alternatives such as update_business or list_businesses. The purpose clause implies a use case for setting up a crypto payment business, but no exclusions, prerequisites, or alternative-selection 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add value beyond the name by disclosing the key side effect: a buyer checkout URL is generated. But it does not disclose what state the invoice enters, auth requirements, reversibility, or what the response contains — meaningful gaps for a mutation 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?

A single 14-word sentence with zero wasted words. The primary action is front-loaded, and the additional buyer-checkout-URL outcome is stated in a second clause without redundancy.

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

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

With 8 parameters, no output schema, and no annotations, the description is on the thinner side. The schema fully documents parameters, and the description hints at the primary deliverable (checkout URL), but it never states what the tool returns (invoice ID? URL field?), nor any prerequisites. An agent would likely need to inspect actual return behavior to safely chain this with downstream steps.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters, including defaults (currency, expires_in_minutes) and fallback behavior (business_id). The description adds no parameter-level detail, but with complete schema coverage the baseline of 3 applies.

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

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

The description states a specific verb ('create') with a clear resource ('payment checkout invoice') and adds a distinct outcome ('generate the buyer checkout URL') not obvious from the name alone. It cleanly differentiates from sibling tools like list_invoices, get_invoice_details, and delete_invoice by making the creation + checkout intent explicit.

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

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

Usage context is implied by the verb 'create' — the agent can infer it is the right choice over list/get/delete invoice siblings when a new checkout is needed. However, there is no explicit when-to-use guidance, no exclusions, and no mention of prerequisites such as requiring an active business or API keys.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' implies destructiveness, but the description does not state whether deletion is irreversible, whether it cascades to dependent data (invoices, transactions, chains), or whether any confirmation is required. This is a significant transparency gap for a destructive 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?

The description is a single, front-loaded sentence with no filler. It efficiently conveys the action, the resource, and the identifier mechanism. Every word contributes to the core meaning, making it extremely economical and well-structured.

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

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

Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is fairly complete. It tells what to delete and how (by UUID). However, because there are no annotations, it misses details like irreversibility or side effects, but these are more relevant to behavioral transparency. For basic invocation, it is sufficient.

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

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

The schema covers the sole parameter (business_id) with 100% coverage, including a description ('UUID of the business context to delete'). The tool description only adds the phrase 'by UUID,' which merely reiterates what the schema already states. Hence, the description provides minimal incremental value over the structured schema.

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

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

The description states a clear verb ('Delete'), a specific resource ('business context'), and the identifier mechanism ('by UUID'). This unambiguously distinguishes it from sibling tools like create_business, update_business, get_business, and list_businesses, so an agent can immediately tell what this tool does and how it differs.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives, nor does it warn when not to use it (e.g., 'Use this only when you want to permanently remove a business context'). It relies on the inherent meaning of 'Delete' to convey its use case, but offers no exclusions or conditions that might help an agent decide between this and a similar 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?

No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states the basic action without revealing consequences (e.g., irreversibility, impact on related records, or authorization needs). For a destructive operation, this is a significant gap.

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

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

The description is a single short sentence, easy to parse and front-loaded with the action. Minor redundancy exists in 'cancel or delete', but overall it is concise and free of filler.

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

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

For a simple one-parameter tool with no output schema, the description is functionally adequate. However, it omits important behavioral context (such as whether deletion requires special permissions or whether it is reversible), which a caller would benefit from knowing.

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

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

The input schema already describes the invoice_id parameter clearly, and schema coverage is 100%. The description adds minimal extra meaning beyond confirming that deletion is by UUID, so it meets the baseline for schema-covered parameters without enriching semantics further.

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

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

The description clearly states the action (cancel or delete) and the resource (invoice) with a specific identifier (UUID). It is distinct enough from sibling tools like create_invoice or list_invoices, though the dual verb 'cancel or delete' introduces slight ambiguity about the exact operation.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites such as invoice status or permission requirements. No exclusions or contextual conditions are mentioned.

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?

There are no annotations, so the description carries the burden. It states the operation is a retrieval of the active context, implying read-only behavior, but does not disclose what happens if no active business is set, nor the exact return format. For a simple getter this is adequate but not detailed.

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

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

A single sentence that is densely informative, with no filler. Every word contributes to the tool's purpose and 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 zero-parameter getter, the description covers the core purpose and use case. However, since there is no output schema, it could clarify whether 'business context' refers to an ID, an object, or a lightweight reference. Minor gap but mostly 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 tool has zero parameters and the schema is empty, so there are no parameter semantics to document. The baseline for 0 params is 4, and the description adds no conflicting or redundant parameter info.

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

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

The description clearly identifies the action (retrieve), the resource (currently active business context), and its purpose (default for invoice generation). It distinguishes itself from siblings like list_businesses and get_business by focusing on the active context.

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 implicitly indicates when to use it (when needing the default business for invoice generation) but does not explicitly state when not to use alternatives like get_business or switch_active_business. No exclusions or alternative routing is 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?

With no annotations, the description carries full behavioral disclosure responsibility. It does not explicitly state safety (read-only), authentication needs, or any caveats about the operation. Although 'get' implies a read, the description does not concretely disclose behavioral traits beyond the verb.

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, lean sentence communicates the essence. It is front-loaded with the resource and action, and no unnecessary words. Every part serves a purpose.

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

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

The tool is simple (one param, no output schema, no annotations) so that the description covers the core mapping. If it stops there; however, it leaves out contextual details like how the returned 'full details' are structured or when to prefer this tool over siblings, making it just barely adequate.

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 already documents business_id as 'UUID of the business context' with 100% coverage. The description merely repeats that the operation is done by UUID, adding no extra value about format, constraints, or usage. It equals the baseline without enriching the parameter understanding.

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

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

The description clearly states the operation (get), the resource (business context), and disambiguates by 'specific' and 'by UUID'. This distinguishes from list_businesses (broad dataset) and get_active_business (targeted at active context). It is clear what the tool does and how it relates to 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 guidance on when to use this tool versus alternatives like get_active_business or list_businesses. No mention of context, exclusions, or preference. An agent has to infer the usage from the name and description alone, which is insufficient for routing.

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

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

No annotations are provided, so the description carries the full burden. It discloses the content scope (active payment deposit sessions and payment transactions) but does not mention whether the operation is read-only, requires special permissions, or returns paginated data. For a simple get operation this is acceptable but not richly transparent.

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

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

A single sentence that is efficient and front-loaded with the main purpose, followed by the specific included components. No wasted words.

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

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

Given the tool's simplicity (one required parameter, no output schema, no annotations), the description covers the core purpose and included details. It lacks explicit mention of read-only behavior or prerequisites, but these are minor gaps for a straightforward get operation.

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

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

Schema description coverage is 100% and the only parameter, invoice_id, is already described as 'The UUID of the invoice'. The description adds no further meaning beyond what the schema provides.

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

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

Description clearly states the tool retrieves full details of a specific invoice, including active payment deposit sessions and payment transactions. The verb 'Get' and resource 'specific invoice' distinguish it from list_invoices and other siblings.

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

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

The description implies usage for fetching a single invoice's details, but it does not explicitly state when to use this tool versus list_invoices or provide any exclusion criteria. No alternative tools are named.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation through the verb 'Retrieve', which is a positive indicator. However, it does not disclose potential rate limits, authentication requirements, or whether the data is real-time or aggregated with a delay. Given the zero annotation coverage, a 3 is appropriate: the description conveys the core behavior but omits deeper operational 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?

The description is a single, tightly worded sentence that lists the key outputs without any redundancy or filler. Every word contributes meaning: 'Retrieve' indicates the action, the rest specifies the exact data. It is front-loaded with the verb and resource, making it easy to scan.

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 tool with no output schema, the description provides a solid enumeration of return categories, which is sufficient for an agent to understand what it will get. It lacks information about response format or typical use cases, but since there are no parameters to configure and the output is straightforward, the description is nearly complete. A score of 4 reflects the minor gap of not stating when to prefer this over sibling metrics 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?

The tool has zero parameters, so there are no parameter semantics to clarify. According to the guidelines, 0 params corresponds to a baseline of 4. The description adds value by summarizing what data will be returned, which indirectly informs the agent of the tool's scope. No parameter information is needed.

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

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

The description clearly states the tool retrieves merchant analytics and enumerates specific data categories: volume analytics, invoice counts (paid/pending/expired), net revenue, and compliance tier limits. It uses a specific verb (Retrieve) with a clear resource (merchant stats), making the purpose unambiguous and distinguishable from sibling tools like get_profile or list_invoices.

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 implicitly indicates this is for fetching aggregated merchant statistics, but it does not explicitly state when to use this tool versus alternatives. For example, it does not mention that this is for overview-level metrics compared to get_invoice_details for individual invoice data. No alternatives or exclusions are given, but the purpose is clear enough that an agent could infer appropriate usage.

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

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

With no annotations, the description must carry behavioral context. It indicates a read operation ('Get details') but does not disclose potential errors, authentication requirements, or whether any state changes occur. For a simple read tool, this is adequate but not rich.

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

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

A single, dense sentence that front-loads the action and resource, then lists specific return fields. Every word adds value with no redundancy.

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

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

For a parameterless read operation without an output schema, the description provides the essential context: what is returned (tier, KYC status, compliance limits, active business context). An agent can understand the tool's purpose and output shape without additional details.

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

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

The tool has zero parameters, and the schema is empty with 100% coverage by definition. The description adds no parameter details, but none are needed, so the baseline of 4 applies.

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

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

The description uses a specific verb ('Get details') and identifies a precise resource: the currently authenticated merchant profile, listing concrete fields (tier, KYC status, compliance limits, active business context). This clearly distinguishes it from siblings that target specific businesses, invoices, or transactions.

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

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

The description implies that this tool is for retrieving the current merchant profile but does not explicitly state when to prefer it over alternatives like get_business or get_active_business. There is no when-not-to-use guidance or mention of sibling tools, leaving selection partially to inference.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Fetch', without revealing pagination behavior, ordering, authentication requirements, or what 'logs' contain. Essentially no behavioral transparency beyond the action itself.

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

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

A single efficient sentence that wastes no words and places the core action and scope upfront. However, it is so brief that it misses opportunities for useful 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?

No output schema, no annotations, and limited description. The tool involves pagination and delivery logs, but the description does not explain return structure, ordering, or any edge cases. An agent would need to infer behavior from parameter names alone.

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

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

Schema description coverage is 100%, so each parameter (limit, offset, invoice_id) is already documented. The description adds no extra semantic nuance, but the baseline of 3 applies because the schema carries the load.

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 'Fetch' with a specific resource 'webhook delivery attempt logs' and a clear scope 'for a specific invoice'. Unambiguously distinguishes from siblings like get_webhook_secret or get_invoice_details.

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

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

Implies usage for retrieving delivery logs for an invoice, but does not explicitly state when to use it versus alternatives or provide any exclusions. No direct sibling competes, but guidance is minimal.

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

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

Since no annotations are provided, the description carries the burden of behavioral disclosure. It conveys a read-only action ('Retrieve') but does not explicitly state the absence of side effects, sensitivity of the secret, or any authentication requirements. This is adequate for a simple getter but leaves room for more transparency.

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

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

The description is a single sentence with no filler. It front-loads the key information (what is retrieved) and adds the purpose efficiently. Every word earns its place.

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

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

For a tool with no parameters and no output schema, the description sufficiently explains what the tool does and why it would be used. An agent can confidently call it when needing the webhook signing secret for callback verification without missing essential context.

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

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

The tool has zero parameters, so the description does not need to explain parameters. The baseline for 0 params is 4, and the description adds useful context about the secret's purpose without needing to elaborate on inputs.

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

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

The description clearly states the action 'Retrieve' and identifies the resource as the 'merchant webhook HMAC signing secret'. It also explains the purpose ('used for verifying webhook callbacks'), which distinguishes it from sibling tools like 'get_webhook_deliveries' that retrieve delivery records rather than secrets.

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 context by stating the secret is used for verifying webhook callbacks, implying when this tool would be needed. However, it does not explicitly compare to alternatives or state when not to use it, such as when rotating the secret via 'regenerate_api_keys'. The usage guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden. The verb 'List' implies a read-only, non-mutating operation, and the description explicitly states what information is returned (payout wallet addresses and domain verification status). It does not mention pagination or rate limits, but those are less critical for a no-arg list 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?

The description is a single, information-dense sentence. It front-loads the core action and resource, then adds only the relevant output attributes. No filler or unnecessary 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 zero-parameter, list-all tool, the description gives sufficient information to invoke it correctly, including what the response will contain. Without annotations or an output schema, a bit more detail (e.g., whether all items are returned at once or paginated) could help, but the core call is fully specified.

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 parameters, so the schema fully documents the absence of inputs. The description does not need to compensate. Baseline 4 is appropriate because no parameter explanation is needed or provided.

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

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

The description uses a specific verb 'List' with a clear resource 'business contexts' and scope 'all under the merchant account'. It also names the return content (payout wallet addresses and domain verification status), fully distinguishing it from sibling get_business or get_active_business which target a single context.

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 phrase 'all business contexts' clearly implies this tool is for enumerating the full set rather than fetching a single business. It offers no explicit exclusions or pointers to alternatives, but the scope statement gives a definitive when-to-use context.

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

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

With no annotations, the description carries the burden of behavioral disclosure. 'Retrieve' signals a read-only operation, but it does not mention whether inactive chains are excluded by default (the parameter implies that), any pagination, or the return structure. Some behavioral context is present but incomplete.

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

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

A single sentence that is front-loaded with the main action and resource, with no filler or repetition. Every word earns its place.

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

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

For a simple list tool with one optional parameter and no output schema, the description gives enough context about what is returned (chains and their active payment currencies). It could mention the default behavior regarding inactive chains, but the schema parameter description covers that. Overall, sufficient for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so the parameter is documented in the schema. The description does not add extra detail about the include_inactive parameter beyond what the schema provides, which matches the baseline of 3.

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

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

The description uses a specific verb ('Retrieve') and clearly identifies the resource (configured EVM and Solana chains) plus the scope (their active payment currencies/tokens). It distinguishes itself from the sibling list tools like list_businesses and list_invoices by naming the exact domain.

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

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

The description implies when to use this tool (when you need configured chains and currencies), but it does not explicitly state when not to use it or mention alternatives. Since no sibling tool covers chains, the context is adequate but left implicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses pagination behavior ('with pagination'), which is useful, but it does not mention that this is a read-only operation, nor does it describe the return format, ordering, or potential pagination limits beyond the parameter defaults. For a simple list tool this is adequate but not comprehensive.

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

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

The description is a single efficient sentence that conveys the action, scope, and key feature (pagination) without any filler or redundancy. Every word earns its place, and the most important information is front-loaded.

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

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

Given the tool's low complexity (three optional parameters, no nested objects, no output schema), the description is sufficient for basic invocation. However, it lacks guidance on how the returned list behaves (e.g., newest first or oldest first), and without annotations it does not explicitly confirm the operation is read-only. A slightly richer description would improve completeness.

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

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

The input schema covers all three parameters with descriptions (100% coverage), so the description does not need to explain them. The description's mention of pagination adds a small amount of context that maps to limit and offset, but it does not add deeper semantic meaning beyond what the schema already provides. This meets the baseline for full schema coverage.

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

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

The description uses a specific verb ('List') and resource ('invoices'), and adds a scope constraint ('created by this merchant'). It clearly identifies the list operation, but it does not explicitly name or contrast sibling tools like get_invoice_details or list_transactions, so it falls just short of full differentiation.

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

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

The phrase 'created by this merchant' provides a clear context that this is scoped to the current merchant, but there is no explicit guidance on when to use this tool versus alternatives such as get_invoice_details for a single invoice. The usage context is implied rather than explicitly stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List', implying a read operation, but does not mention ordering, status filters, date ranges, response shape, or side effects.

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

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

The description is one efficient sentence with no filler or repetition. It front-loads the primary action and clearly names the resources involved.

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

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

The tool is a simple read operation with two well-documented pagination parameters, so the core calling information is present. However, it lacks sibling differentiation and behavioral context beyond the schema, leaving some usage ambiguity.

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

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

The input schema fully documents both parameters with meanings, defaults, and maximum values, so description-level parameter explanation is unnecessary. Baseline 3 applies because schema coverage is 100%.

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

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

The description uses a specific verb and resource: 'List payment transaction records and ledger settlements associated with the merchant account.' This clearly distinguishes the tool from siblings like list_invoices and list_businesses by its subject matter.

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

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

The description provides no guidance on when to use this tool versus alternatives such as list_invoices, nor does it state exclusions, preconditions, or typical use cases. It only states what the tool does without contextual direction.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Regenerate' without explaining consequences such as old keys being invalidated, potential downtime, permission requirements, or any irreversible effects. This is a destructive operation that lacks critical 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?

The description is a single, focused sentence that clearly conveys the action, targets, and scope without any wasted words. It is appropriately concise and front-loaded.

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

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

Given the simplicity of a parameterless operation, the description is largely complete for identifying what the tool does. However, it omits behavioral consequences (e.g., old keys become invalid) which an agent should know before invoking a destructive action. Minor gap, but not severe.

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

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

The tool has zero parameters, so the description does not need to explain parameters. The schema is empty and coverage is 100%. Baseline 4 applies because no parameter information is required.

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

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

The description clearly states the action (regenerate), the resource (public and secret API keys), and the scope (for the merchant account). It specifically identifies key formats (pk_live_... and sk_live_...), making it unambiguous and distinguishable from sibling tools like get_webhook_secret or get_profile.

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

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

The description implies usage context by naming the purpose (merchant account key regeneration), but it does not explicitly state when to use this tool versus alternatives or any prerequisites. It is implied that this is for rotating credentials, but no exclusions or alternatives are mentioned.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It notes the switch impacts checkout defaults, but it does not state whether the change is persistent beyond the current session, what permissions are required, or whether it can be reverted. The lack of side-effect details leaves significant uncertainty for a mutation 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?

The description is a single, efficient sentence that presents the action first and adds the purpose parenthetically. It is appropriately front-loaded and contains no unnecessary words, making it easy to parse quickly.

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

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

Given this is a simple tool, the description covers the basic 'do this' aspect, but it omits any mention of what happens on success or failure, whether the switch is immediate, or whether it returns any confirmation. Because there is no output schema, the description should specify the expected result but does not, leaving the agent uncertain about the command's effect.

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

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

The input schema already describes the parameter fully ('UUID of the business context to switch to') with 100% coverage. The tool description adds no extra meaning about the parameter beyond confirming that the business context is being switched to. The baseline of 3 applies because the schema does the heavy lifting.

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

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

The description clearly states the verb 'switch' and the target 'active business context,' and the parenthetical explains why this matters for checkout invoice generation. It distinguishes itself from read-only siblings like get_active_business by being a state-changing operation, though it doesn't explicitly name an alternative.

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

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

The description hints at when to use it (to set the default for checkout invoices) but provides no guidance on when not to use it, nor does it compare to alternatives such as get_active_business or update_business. The agent must infer the appropriate context of use.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states 'update' without mentioning required permissions, reversibility, side effects, or idempotency. This falls short for a mutation tool.

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

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

The description is a single concise sentence that efficiently lists the updatable fields. It is front-loaded and free of waste, though it could have included more structural guidance.

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

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

With no annotations, no output schema, and only a basic verb+fields description, the tool lacks behavioral and usage context. An agent has enough to know what fields it can change but not when to use it or what to expect.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description lists field names but adds no extra semantic meaning beyond what the schema provides. 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?

Description clearly specifies the verb 'update', the resource 'existing business context', and the exact fields that can be changed (name, payout wallets, or domain). This distinguishes it from sibling tools like create_business and delete_business.

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

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

The description implies usage for updating an existing business context, but does not explicitly state when to use it versus alternatives or provide exclusion criteria. It gives clear context but no alternative routing.

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