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

The description adds one genuinely useful behavioral fact beyond the annotations: the generated PDF is returned attached to the response, which explains the return channel given there is no output schema. However, for a destructive, non-idempotent, open-world write that produces a legally binding document, it says nothing about permanence (issuance cannot be undone; only reversal exists) or required authentication.

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

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

Two sentences, zero filler, with the core action front-loaded and the return artifact disclosed immediately after. 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?

The rich schema compensates for most of the tool's complexity and the description covers the return artifact, but for a 34-parameter, multi-variant invoice-issuance tool it omits which variant path to take and what constraints apply (currency/exchange-rate coupling, required item totals, correction dependencies).

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

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

Schema description coverage is 100%, so all 34 parameters are self-documenting and the baseline is 3. The description's enumeration of invoice types gives indirect meaning to the proforma/advanceInvoice/correctionInvoice booleans but adds no format, default, or dependency detail 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 and resource ('Issue a new invoice') and enumerates the four invoice variants it covers (normal, proforma, advance, correction), which maps directly onto the proforma/advanceInvoice/correctionInvoice flags. It does not differentiate against siblings such as create_receipt or reverse_invoice, which is the one remaining ambiguity.

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: nothing says to prefer create_receipt for receipts, or to use reverse_invoice rather than issuing a correction invoice, and no prerequisites are given (e.g. that a correction needs an existing invoice number). Only the implied 'use this to issue invoices' is conveyed.

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=false and openWorldHint=true, so the description's job is to add context like irreversibility, finalization/legal issuance, or numbering side effects. It adds none of that: it does not say the receipt is finalized on issue, whether it can be voided (a sibling reverse_receipt exists), or that callId is the only duplicate guard. With rich annotations supplied, this is a real gap rather than a contradiction.

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 filler, and the required content (items) plus optional element (payment breakdown) are stated in order of importance. It is efficient, though its brevity is achieved by omitting behavior rather than by tight editing.

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 13-parameter, legally meaningful creation tool with nested item arrays and no output schema, the description says nothing about what is returned or what happens on success. The schema covers all fields, so an agent can technically call it, but the definition is thin relative to the operation's weight and irreversibility.

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 every parameter including the 13 top-level ones and nested item fields is already documented. The description only restates that items are required and payments optional, adding no format, default, or constraint detail beyond the schema. Baseline 3 applies when the schema carries the semantics.

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 ("Issue") and resource ("new receipt") and names the payload shape (items plus optional payment breakdown). An agent can tell it creates a receipt rather than an invoice. It never names a sibling such as create_invoice or send_receipt to sharpen the boundary, so it stops short of a 5.

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

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

There is no when-to-use or when-not-to-use guidance, no mention of prerequisites (company selection, prefix numbering), and no routing to alternatives like create_invoice or send_receipt. The sentence is purely descriptive of what gets sent, leaving the agent to infer the context in which issuing a receipt is appropriate.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it does not state that deletion is permanent and irreversible, that deleting by orderNumber may remove multiple proformas in one call, or what happens if the record is already gone, which is notable since idempotentHint=false implies repeat calls may 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?

A single front-loaded sentence with no filler; the action and the two targeting methods come first and nothing redundant is included.

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

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

For a three-parameter mutation with full schema coverage and an annotation set that already flags destructiveness, the definition is close to sufficient. It falls short only on irreversibility and the multi-delete consequence of orderNumber, which an agent about to run a destructive call would want stated explicitly.

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

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

Schema description coverage is 100%, so all three parameters (company, orderNumber, invoiceNumber) are already documented in the schema. The description echoes the two keying options but adds no format, precedence, or ambiguity-resolution rules beyond what the schema states, 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?

The description states a specific verb and resource ('Delete a proforma invoice') and adds the two selection keys, so an agent can tell what it removes and how it is targeted. It does not distinguish the tool from the neighbouring reverse_invoice sibling, leaving the proforma-vs-finalized-invoice distinction to be inferred.

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 prerequisites, and no exclusions; it never says whether to prefer invoiceNumber or orderNumber, nor points to reverse_invoice as the alternative for non-proforma invoices. The only hint is the parenthetical 'alternative' on orderNumber, which lives in 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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds useful context that the response contains the actual invoice content and can optionally carry the PDF, but says nothing about failure behavior for a missing invoice or about the size/latency cost of includePdf.

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

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

Two short sentences, front-loaded with the resource and the identifying key, with no filler. The trailing PDF clause mildly duplicates what the schema's includePdf already states, but costs only a few words.

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

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

For a simple read tool with full schema coverage, no output schema and complete annotations, the description is mostly sufficient. The notable gap is that the existence of the sibling get_invoice_pdf makes the description's optional-PDF behavior ambiguous: it never tells the agent which of the two to use for retrieving a PDF.

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%: company, includePdf and invoiceNumber are each documented with defaults and an example in the schema. The description's "Optionally the PDF too" merely restates the includePdf parameter and adds no new semantics or format detail.

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 resource and lookup key ("outgoing invoice by invoice number") and enumerates the returned content (seller, buyer, items, totals, amount paid, outstanding), so an agent knows exactly what it fetches. It does not, however, distinguish itself from the sibling get_invoice_pdf 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?

Usage is only implied: "by invoice number" plus "Optionally the PDF too" suggests single-invoice retrieval with optional attachment. There is no explicit when-to-use guidance, no mention of when to prefer get_invoice_pdf or list_invoices, and no statement of what happens with an invalid or unknown number.

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 readOnly, idempotent, non-destructive, open-world behavior, so the bar is lower. The description still adds real value beyond them: it discloses that the PDF is returned as an attachment on the answer and that nothing is written to disk, which is exactly the delivery detail an agent needs and no annotation conveys.

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

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

Two short sentences, zero filler, and the identification of the resource and its key comes first, followed by the delivery mechanic. Nothing could be removed without losing information.

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

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

For a two-parameter read tool with full schema coverage, the definition covers the essentials, and since there is no output schema, the note that the PDF arrives attached to the answer usefully fills the return-value gap. Only the routing versus get_invoice_data/list_invoices is left 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?

Schema description coverage is 100%, so both parameters are already documented in the schema, including the company default and the list_companies pointer. The description only echoes that lookup is by invoice number, adding no syntax or format detail beyond the schema example. 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 resource and lookup key: 'PDF of an existing outgoing invoice by invoice number.' An agent can distinguish it from get_invoice_data (structured data) and list_invoices (enumeration) by the 'PDF' output, though the description never explicitly contrasts 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?

'existing outgoing invoice' implies scope (not drafts or proforma) and the required invoice number implies lookup-by-identifier, but the description never states when to prefer this over get_invoice_data or how to obtain a valid invoice number via list_invoices. Usage is inferable 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description only adds that the response includes receipt data and optionally a PDF, without noting permission requirements, error/not-found behavior, or that PDF inclusion is opt-in.

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 compact sentence with the key lookup mechanism front-loaded and no filler. It is arguably over-terse for a tool that returns two distinct payloads, 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?

With annotations and full schema coverage the call mechanics are clear, but there is no output schema, so the description is the only place to describe the returned data shape (and it merely says 'Data and PDF'). For a retrieval tool with two return modes, that leaves a meaningful gap.

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

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

Schema description coverage is 100%, so all three parameters (company, includePdf, receiptNumber) are already documented in the schema, including the company default and list_companies reference. The description adds only the receipt-number lookup framing, 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 (get) and resource (receipt) plus the lookup key (receipt number), and 'Data and PDF' signals it returns both structured data and a document. It does not, however, distinguish itself from siblings such as get_invoice_data/get_invoice_pdf or clarify its relationship to create_receipt/send_receipt.

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 list_invoices/other siblings, no prerequisites, and no statement about what happens if the receipt number is unknown. Usage must be inferred 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?

Beyond the read-only and idempotent annotations, it discloses the external web-interface source and the absence of matching status, both operationally useful details. Listing returned fields also sets expectations, though it adds nothing about freshness, ordering, or truncation 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?

Three compact statements front-load the resource and date scope, then cover the source and a material limitation. The field list is useful because there is no output schema, and there is 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?

Together with the fully documented schema and safety annotations, this is enough to select the tool and construct a valid date-bounded request, while the field list partly compensates for the missing output schema. It remains short on ordering or truncation behavior and gives no route for users who need matching status.

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 baseline is 3. “For a period” loosely reinforces dateFrom and dateTo, but the description adds no parameter syntax, defaults, filtering interactions, or constraints beyond the schema.

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

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

The description identifies a period-based read of bank transactions from Számlázz.hu and enumerates the principal returned fields. “Bank transactions” distinguishes the resource from the invoice and receipt siblings, although it does not explicitly contrast with any particular sibling.

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

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

The period scope provides concrete selection context, and “No matching status included” supplies a useful exclusion for status-aware workflows. It does not say which alternative to use when matching status is required or provide other explicit when-to-use 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real context beyond that: the data is fetched live from Számlázz.hu, and there is a default-company fallback used by other tools when the company parameter is omitted. That fallback semantic is the kind of behavior annotations cannot express.

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

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

Two compact sentences with no filler, and the core scoping information leads. The second sentence mixes the switching instruction into the same breath, which is efficient but slightly dense; nothing is wasted though.

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

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

For a zero-parameter read tool with no output schema, the description does most of the work by explaining what the result represents: the accessible companies plus the one used by default. It stops short of describing the shape of each entry (name vs. id fields), which is the only meaningful gap given no output schema exists.

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

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

The tool takes zero parameters, so the schema carries nothing to explain, and the baseline is 4. The description still adds value by pointing at the company parameter that exists on the sibling tools and explaining how a value from here feeds into it.

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 the resource (the companies the configured Számlázz.hu login can work in) and its scope (read from Számlázz.hu), plus the key fact that it reveals the default company used when none is given. It does not use an explicit verb like 'list', and it never names a sibling tool, but the resource is specific enough to separate it from the invoice-oriented 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?

It gives actionable guidance for switching companies ('pass the company name or id in the other tools' company parameter'), which is genuinely useful. However it never states when an agent should call this tool — e.g., to discover company ids before create_invoice — so the trigger for invoking it is only implied.

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 establish that this is a safe, read-only, idempotent list operation. The description adds useful behavioral context beyond those annotations by stating the default ordering (newest first), the searchable dimensions (invoice number or buyer name), pagination, and the shape of each returned row.

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 dense sentence with no wasted wording. Ordering, searchability, pagination, and returned fields are front-loaded and 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 read-only list tool with full schema coverage and no output schema, the description gives an adequate picture of returned rows and pagination behavior. It could be slightly more complete about edge cases or total counts, but an agent has enough information 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 100%, so defaults, enum values, and constraints are already documented in the input schema. The description reinforces the search and ordering semantics but adds little parameter meaning that is not already present in the schema.

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

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

The description uses a specific verb-plus-resource framing: it lists outgoing invoices, describes default order, searchability, pagination, and row contents. It clearly separates this from retrieval/mutation siblings such as get_invoice_data and create_invoice, although it does not name any sibling explicitly.

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

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

Usage is implied by the description's focus on searching and paging outgoing invoices, but there is no explicit when-to-use guidance or when-not-to-use condition compared with get_invoice_data or list_bank_transactions. An agent can infer the browsing/search use case, but must decide alternatives 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 destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is known. The description adds one useful hard constraint (at most 5 entries per invoice) but omits the most consequential behavior: that with additive=false ALL existing payments are replaced, which is the actual destructive path. It also says nothing about permissions, error conditions, or whether the invoice state changes.

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

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

Two short sentences with the purpose front-loaded and no filler. The second sentence duplicates the schema's maxItems=5 constraint, so it is mildly redundant, but it is short enough not to harm readability.

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, non-idempotent mutation with no output schema, the description should warn about the additive=false replacement path and indicate what the call returns or changes. It covers the entry-count cap but leaves the agent without the information needed to avoid accidentally wiping existing payments.

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 every parameter (company, additive, payments, invoiceNumber, plus nested date/method/amount) is already documented in the schema, including the additive replacement semantics. The description's only parameter-adjacent content is the max-5 limit, which merely restates the schema's maxItems constraint. Baseline 3 applies.

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

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

The description uses a specific verb and resource ("Register payments on an invoice"), which is clearly distinct from siblings like create_invoice, reverse_invoice, or create_receipt. It stops short of naming a sibling or stating how it differs from related write operations, so it is clear but not fully differentiated.

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

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

Usage is only implied by the purpose statement: an agent can infer this is the tool for recording payment against an existing invoice. There is no explicit when-to-use, no mention of prerequisites (does the invoice need to exist in a specific state?), and no guidance on choosing between this and receipt-related 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 destructive=true, idempotent=false and openWorld=true. The description contributes the important non-obvious trait that reversal is a counter-document issuance rather than an in-place mutation, but it does not disclose that repeated calls likely produce multiple reversing invoices, whether the original is voided, or any NAV/e-invoice submission 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?

A single short sentence, front-loaded with the verb and resource, with no filler wording. It is arguably too terse for a destructive financial tool, but nothing in it 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?

This is a destructive, non-idempotent financial operation with no output schema, and the description says nothing about what is returned (e.g. the new reversing invoice number), failure modes such as an already-reversed invoice, or required permissions. The one sentence is not sufficient context for an agent to invoke 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 100%, so all five parameters are already documented, including the crucial nuance that issueDate and fulfillmentDate refer to the reversing invoice, not the original. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

The description names a specific verb and resource ('Reverse an invoice') and clarifies the mechanism ('issues the reversing invoice for the original'), distinguishing it from a delete operation. It does not explicitly contrast with siblings such as reverse_receipt or delete_proforma, but the 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 guidance on when to use this rather than delete_proforma, reverse_receipt, or creating a corrective invoice, and no stated preconditions (e.g. original invoice must exist and not already be reversed). The implied use case is inferable from the name alone, so this is close to no 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 destructiveHint=true, idempotentHint=false, readOnlyHint=false, and openWorldHint=true, so the safety profile is known. The description adds nothing beyond them — it never says whether a reversal creates a storno document, whether it is irrevocable, or what side effects (stock, numbering, e-invoice reporting) occur, which is exactly the context a mutation tool needs.

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

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

The single sentence is front-loaded and free of waste, but for a destructive financial operation it is under-specified rather than concise. Appropriate sizing would require at least one more clause about consequences or confirmation behavior.

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, non-idempotent, open-world mutation with no output schema, so the description carries real weight for outcome and side-effect disclosure. It provides none of that, leaving the agent unable to predict what reversing actually produces or how failures surface.

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 receiptNumber, company (with its default-to-current-company note), and includePdf are all documented in the schema. The phrase "by receipt number" merely echoes the required parameter, so the baseline 3 applies.

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

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

The description states a specific verb plus resource ("Reverse a receipt") and identifies the key ("by receipt number"), which clearly separates it from read siblings like get_receipt and from reverse_invoice. It stops short of explicitly differentiating reverse from alternatives such as delete_proforma or creating a correcting receipt.

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

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

There is no when-to-use guidance, no prerequisites (e.g., receipt must be non-reversed or within a permitted window), and no statement of what to do instead if the goal is a correction rather than a reversal. The agent must infer everything about applicability from the single sentence.

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 disclose a non-read-only, open-world, non-idempotent operation. The description adds the concrete external side effect of sending an e-mail, but does not clarify duplicate sends on retry, queued versus completed delivery, failure behavior, or whether the receipt itself is modified.

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 sentence is direct, front-loaded, and contains no filler or redundancy. Its operational omissions are assessed in the other dimensions rather than being a problem with wording or 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?

Three flat, fully documented parameters and the supplied annotations make the definition minimally sufficient for selection and invocation. However, with no output schema, the description would benefit from indicating the result or delivery status, and the non-idempotent external action warrants clearer resend and failure 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 100%, including the company default and the pointer to list_companies, so the baseline score applies. The phrase 'given address' merely restates the email parameter's role and adds no semantics beyond the schema.

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

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

The description specifies the action ('E-mail'), resource ('a receipt'), and destination ('the given address'), making the basic operation clear and practically distinct from create_receipt and reverse_receipt. It does not explicitly state that the receipt must already exist or provide any sibling comparison.

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 wording implies using the tool to deliver an existing receipt to a recipient, but gives no explicit prerequisites, exclusions, or alternatives. For example, it does not explain when company selection is necessary or whether this should follow create_receipt.

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