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

With no annotations, the description must carry the full behavioral burden. It discloses the fixed 90-day deterministic window, but does not state whether the audit is read-only, whether it stages chargebacks or disputes, what permissions are needed, or what side effects may occur.

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 definition is a single front-loaded sentence with no filler. It states the verb and scope immediately and every phrase contributes to the audit 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?

This is a complex cross-domain audit with no annotations and no output schema, yet the description says nothing about the return shape, read-only nature, or how optional inputs affect the audit. The schema documents parameters, but the description is not complete enough for an agent to understand the tool's behavior and output.

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

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

Schema coverage is 100%, so the parameter schema already documents all five optional inputs, including defaults and ranges. The description only names the broad data domains and does not add meaning for costPerEventCents or dunningGracePeriodDays, so baseline 3 is appropriate.

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

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

The description gives a specific verb and resource: 'Run a deterministic 90-day B2B revenue leakage & chargeback readiness audit' across explicitly named data sources. Its broad cross-domain audit scope distinguishes it from siblings such as revclamp_evaluate_ghost_usage and revclamp_stage_stripe_dispute_ce3 without needing to name them.

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

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

The audit framing implies when the tool is useful, but there is no explicit when-to-use, when-not-to-use, or comparison to sibling tools. An agent can infer that this is the broad audit option, but the description does not route it against narrower 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?

With no annotations, the description carries the full behavioral burden. It does add important domain behavior: fail-closed pagination and a 0-14 day dunning grace window. It still omits whether the operation is read-only, what it returns, and how incomplete or paginated subscription data affects the result.

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 definition is a single dense sentence with the core evaluation purpose front-loaded. There is no filler or repetition, and every clause adds domain-specific 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?

There is no output schema and no annotations, so the description should clarify the decision result and key parameter behavior. It does not explain what the evaluation returns, how fail-closed behavior manifests, or how the two timestamp parameters differ, leaving significant gaps for a 6-parameter tool.

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

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

Schema description coverage is only 33%, so the description should compensate more. It contextualizes subscriptions, pagination via 'fail-closed,' and the dunning grace range, but it does not explain customerId or distinguish occurredAtSec from usageTimestampSec.

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 ('Evaluate') and a precise resource/decision ('unpaid ghost usage') scoped to multi-subscription Stripe state. It is not a tautology, but it does not explicitly distinguish this tool from sibling revenue/compliance tools beyond the unique 'ghost usage' framing.

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 intended usage is implied by 'Evaluate whether ... is unpaid ghost usage,' so an agent can infer when this tool is relevant. However, there are no explicit when-to-use/when-not-to-use conditions, prerequisites, or comparisons to the sibling tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses 'exact integer EUR-cent accounting', which is useful, but it does not state whether reconciliation mutates records, what side effects or idempotency look like, whether permissions are required, or what is returned.

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, and the core purpose appears first. It is very compressed, but that compression is appropriate for conciseness even though other dimensions need more 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?

Given seven parameters, no annotations, no output schema, and a financial reconciliation workflow, the description is not complete enough. It identifies the domain and arithmetic precision but leaves out parameter meanings, side effects, return behavior, and usage routing.

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% across seven parameters. The description alludes to deposits, credit notes, and payment terms, but it does not define orderId, totalOrderCents, paidAmountCents, creditNotesCents, paymentTermsDays, requiredDepositCents, or requiredDepositPercent, nor their units or relationships.

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, 'Reconcile', and names the resource area: B2B wholesale Net-15/30/60 upfront deposits and credit notes. It also adds the accounting constraint 'exact integer EUR-cent', making the purpose clear. It does not explicitly differentiate itself from the sibling tools, though their names suggest different domains.

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 explicit guidance on when to use this tool versus alternatives, no when-not conditions, and no prerequisites. The B2B Net-15/30/60 context implies a usage scenario, but an agent must infer it rather than being routed to this tool over siblings.

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

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

With no annotations, the description carries the burden, and it does disclose the most important trait: the operation is non-destructive because 'submit is hardcoded to false'. However, it omits what staging actually creates (a real Stripe draft object?), whether it is idempotent, what permissions/API keys are needed, and what happens on ineligible disputes.

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 two well-packed clauses and no filler. Jargon density (CE3.0, access_activity_log-style staging) costs a bit of immediate readability but nothing is wasted.

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

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

Seven parameters including a nested object, zero required fields, no annotations and no output schema. The description never explains what the tool returns (a staged draft? an eligibility verdict?), what inputs are effectively mandatory, or how the two halves (evaluation vs staging) relate, which is a large gap for a tool of this complexity.

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

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

Schema coverage is only 14% (only usageEvents is documented), so the description must compensate. It hints at priorTransactions (120d-365d window, IP/device overlap) but says nothing about disputeId, customerId, disputeReason, disputedTransaction, or existingUncategorizedText, leaving six of seven parameters uninterpretable.

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 two concrete actions: evaluating Visa Compelling Evidence 3.0 eligibility and staging a Stripe dispute draft. The resource (Visa dispute / CE3.0 evidence) is distinct from every sibling (revenue leakage, ghost usage, EU VAT, net terms), though differentiation is implicit rather than stated.

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

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

The parenthetical '120d-365d prior charges with IP/device overlap' encodes the eligibility window for CE3.0, which implies when the tool applies, but there is no explicit when-to-use/when-not or named alternative among the sibling tools. Guidance must be inferred from domain knowledge.

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

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

No annotations exist, so the description carries the full disclosure burden. It hints at external VIES consultation (and a LIVE enum value implies a real network call), but never states whether a live lookup occurs, caching, rate limits, failure behavior, or what a 'MS_UNAVAILABLE fulfillment hold' actually does to downstream state. For a tool with a network-dependent and potentially state-affecting branch, 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?

A single front-loaded sentence with the main verb and resource up front and no filler. The density of unexplained jargon ('MS_UNAVAILABLE fulfillment hold') costs it slightly, but nothing is redundant.

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

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

With four undocumented parameters, no annotations, and no output schema, the one-line description is not sufficient for correct invocation. An agent cannot tell what consultationNumber supplies, how viesMode alters behavior, or what the tool returns.

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% across four parameters, so the description must compensate and largely does not. The GR -> EL note gives useful format context for buyerVatId, but viesMode's four enum values, consultationNumber, and sellerCountry are all left unexplained 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 names a specific operation on a specific resource: normalizing EU/XI B2B VAT identifiers and evaluating VIES consultation state. It is clearly distinguishable from the accounting/reconciliation siblings (audit_revenue_leakage, reconcile_b2b_net_terms). The phrasing is jargon-heavy ('MS_UNAVAILABLE fulfillment hold') but the core verb+resource pair is unambiguous.

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

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

There is no explicit when-to-use statement, no prerequisites, and no named alternative among the sibling tools. An agent must infer from the tool name that this is the VAT-validation entry point, and the 'fulfillment hold' branch is not explained in terms of when an agent should choose it.

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