purchase-order

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

Annotations carry no readOnly/destructive hints, and the description does not explicitly state that this is a read-only report or whether it has side effects. It adds the 'Pro' access requirement, but for a report tool with no safety annotations, the description should disclose non-mutating behavior, data scope limits, or performance implications; none are provided.

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 that front-loads the report contents and ends with the licensing note. It is compact and organized, though the phrase 'every open order past its delivery date with days late' is slightly awkward but still understandable.

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

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

The description lists four output components, giving a good sense of return value coverage. However, there is no output schema, no mention of date range defaulting when parameters are empty, no indication of result limits or pagination, and no statement about whether all items are always included. For a multi-section report, this is adequate but not complete.

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

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

Schema coverage is 100% and the description mirrors the date-range concept already present in the from/to parameters. It does not add details about date format handling, inclusive bounds, default behavior when parameters are omitted, or whether both are required; the schema already carries the essential 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 names a specific verb ('credited back', 'on order', 'open order past its delivery date') and a clear resource ('billing docs report') with date-range scoping. It enumerates exactly what the report returns and contrasts itself with the free list tools, making it distinguishable from siblings like credit_note_list and purchase_order_list.

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 only guidance is 'Pro; the list tools are free,' which is a licensing note rather than a usage rule. It does not explicitly state when to choose this report over the individual list tools, nor does it describe conditions like needing aggregate summaries or wanting all overdue orders in one place.

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 are all false, so the description carries the behavioral burden. It discloses useful internal behavior: 'Amounts store negative, reusing the invoice's own rates,' which explains storage and VAT handling. It also surfaces the quota 'Free: 5 a month' and the companion workflow with credit_note_text. No annotation contradiction exists.

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

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

The description is short and front-loaded. The first sentence immediately states the core action and modes, while each following clause adds distinct value: storage behavior, quota, and the follow-up with credit_note_text. No sentence 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?

For a creation tool with six parameters, no output schema, and no useful annotations, the description covers the key decision space: what modes exist, how amounts behave, quota limits, and the intended follow-up action. It does not describe return values or failure behavior, but the schema covers parameter needs and the description provides enough contextual guidance for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value above the schema by summarizing how the parameters relate: the whole invoice, a GROSS amount_minor split across VAT rates, or named lines. This clarifies the mode-selection semantics beyond individual field descriptions.

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

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

The description opens with a specific verb and resource ('Credit one invoice') and then distinguishes the three supported modes: whole invoice, gross amount_minor split over VAT rates, or named lines. This clearly separates credit_note_create from siblings like credit_note_delete, credit_note_get, and credit_note_list.

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 clear context for when to use this tool: to credit an invoice in one of three ways. It also provides actionable follow-up guidance by saying 'Send it with credit_note_text.' It does not explicitly state when not to use alternatives or mention exclusions, but the sibling roles are clear enough.

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 carry destructiveHint=true, readOnlyHint=false, so the mutation is expected. The description adds valuable context beyond annotations: deleting frees the month's slot, makes the invoice creditable again, and dependent notes are refused. This makes the operational effect and a key failure condition clear.

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 dense sentences carry all necessary information: eligibility criteria, outcome, and the alternative when deletion is not allowed. There is no filler or repetition of schema/annotation content.

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

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

For a one-parameter destructive action with annotations covering safety, the description is complete: it explains when deletion is allowed, what happens if it is not, what the effect is, and what to do instead. No output schema is present, but none is needed for this level of 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 description coverage is 100%, with the id parameter fully described as a credit note id like CN-2026-0001 or an exact client name. The description adds no further parameter-specific meaning, so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Remove one credit note', and immediately scopes it to notes 'never posted to its invoice and never rendered'. This clearly differentiates it from sibling tools like credit_note_create, credit_note_get, and credit_note_pdf, so an agent knows exactly what this tool does.

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 explicit conditions for use: only notes never posted and never rendered, and that notes with a dependent are refused. It also names an alternative action, 'issue a fresh note to reverse a sent one', which routes the agent away from deletion when a note has already been sent.

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

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

The description claims 'Reads only,' but annotations set readOnlyHint=false and idempotentHint=false, which directly contradicts that claim. This is a serious annotation contradiction and the description provides no additional behavioral context such as error behavior, permissions, or side effects. An agent cannot trust whether this tool mutates state.

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

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

Two sentences with no filler. The first sentence is dense but well-organized around the operation, lookup keys, and return contents; the second is an actionable pointer to the sibling list tool. The most important scoping detail 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?

The description covers the single parameter, the exact-match rule, the return fields in prose since no output schema exists, and how to discover ids. For a simple one-parameter getter this is nearly complete; the only remaining concern is the conflicting annotation, which is already captured under behavioral transparency.

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 schema already states that the id parameter can be a credit note id 'such as CN-2026-0001, or an exact client name.' The description repeats this semantic and adds 'exact,' but does not materially extend what the schema already provides, so the baseline 3 is appropriate.

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

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

Description immediately names the operation (return one credit note), the exact scope ('in full'), the lookup keys (id or exact client name), and the expected content (negated lines, VAT lines, totals, reason, reversed invoice reference). It is clearly distinguishable from credit_note_list, and the sibling pointer reinforces the boundary.

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 explicitly routes to credit_note_list when ids are needed and states that this operation reads only, giving a clear usage context. It does not contrast with credit_note_pdf or credit_note_text, but it fully separates this tool from the closest sibling.

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

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

The description discloses important behavioral details beyond the annotations: the total is NEGATIVE, the list is sorted newest first, and the amount credited per currency is included. Since the annotations are only false hints (readOnlyHint=false, destructiveHint=false) and do not provide a clear safety profile, the description carries the burden and does it well by highlighting the negative total and ordering behavior.

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

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

The description is two sentences with zero fluff. The first sentence front-loads the action, resource, and key output details (including the critical negative total); the second sentence covers all filters. Every word earns its place, and the structure is scannable for an agent.

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

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

For a list tool with 4 optional parameters and no output schema, the description explains what will be returned (fields, ordering, negative total, per-currency amount) and the available filters. It lacks explicit mention of pagination or response format, but given the simplicity of the tool and that the schema covers parameters, this is sufficient. It is not fully exhaustive but is clearly above the minimum viable.

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. The description adds little beyond the schema: it mentions filters by invoice, client, or date range, which maps directly to the parameters, but does not add extra meaning or clarify value formats that the schema already provides. The 'amount credited per currency' is an output behavior, not parameter 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 states a specific verb and resource: 'List credit notes' and specifies the output fields (id, invoice, client, basis, reason, currency, NEGATIVE total) and filtering options. It distinguishes itself from siblings like credit_note_get by focusing on listing, and from credit_note_text/pdf by describing the structured list output.

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 through the filter options and the 'newest first' ordering, but it does not explicitly mention when to use this tool versus alternatives such as credit_note_get or credit_note_text. There are no exclusions or alternative routing, so the 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 all annotation hints set to false, the description carries most of the behavioral burden. It adds useful details like the one-hour link validity, A4 print-ready format, and the CREDIT NOTE layout with the reversed invoice. However, it does not explain any side effects or the meaning of the non-read-only/idempotent hints, leaving some behavioral ambiguity.

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 that front-loads the primary purpose and output format. The trailing 'Pro.' is a compact but somewhat cryptic way to indicate a paid feature; otherwise, every part 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 only two simple parameters and no output schema, the description conveys the essential return value (a one-hour download link), the document format, and the layout details. It could mention error conditions or the Pro requirement more explicitly, but the context is largely complete.

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

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

Schema description coverage is 100%, so the input schema already explains both parameters. The description reinforces that this is for one credit note and that the output is a download link, but it does not add parameter-specific meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool renders one credit note as an A4 print-ready PDF and returns a download link. It uses a specific verb ('render'), targets a specific resource ('one credit note'), and the explicit mention of a PDF download distinguishes it from sibling tools like credit_note_text.

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 opening phrase 'Call this tool to render one credit note as an A4 print-ready document' gives clear context for when to use it. It does not explicitly name alternatives or say when not to use it, but the PDF-vs-text distinction among siblings is reasonably clear from 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 provide no behavioral hints beyond all-false flags, so the description carries the burden. It adds useful behavior: output is email-ready plain text, the .txt download link is valid for one hour, and the tool is free. It also implies a non-mutating operation by saying 'turn a credit note into a summary' rather than update or delete. It does not explicitly state that no changes are made to the credit note, but the disclosed content and link behavior are solid.

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 concise sentences deliver the purpose, output contents, link validity, pricing, and an explicit alternative. Everything is front-loaded and every clause adds value; no fluff or repetition.

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

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

With no output schema, the description explains the return content well enough for an agent to invoke the tool and interpret the result. It also covers the temporary link and the alternative PDF tool. Minor gaps remain: it doesn't describe error behavior or explicitly confirm that the operation is read-only, but for a simple text-generation tool the coverage is strong.

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 schema already fully describes id, greeting, and sign_off, including a concrete example for id and defaults for greeting and sign_off. The description does not need to repeat these details, and it adds little parameter-specific meaning beyond clarifying the purpose of the generated text. 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 states a specific verb and resource: 'Turn a credit note into a plain-text summary to paste into an email.' It then enumerates the exact content pieces (negated line table, VAT lines, total, reason, what comes off the invoice), and it explicitly distinguishes itself from credit_note_pdf by noting that tool writes the A4 document. This removes any ambiguity about the tool's purpose.

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 makes the intended use clear: generate a plain-text summary for email, plus a temporary .txt download link. It also names the alternative credit_note_pdf for A4 documents. It does not explicitly state when not to use other credit note tools, but the email-vs-PDF contrast provides actionable 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 indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the 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 two sentences with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential 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 single-parameter activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information for an agent 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?

The schema already documents the key parameter and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not 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 and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.

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 clear context for use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing the read-only nature of the call.

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 dense sentences cover output, purpose, usage context, and side-effect guarantee. Every sentence 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?

With no output schema, the description sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this tool correctly.

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

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

There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.

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 begins with a specific verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.

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 explicitly states when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state when not to use it.

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

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

Annotations already mark this as non-read-only and non-idempotent, so the description only needs to add context, and it does: it returns PO number and totals, inherits currency/VAT/buyer block from the shared profile, and states the 5-document monthly free quota. These details do not contradict the annotations and are genuinely useful.

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

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

Three sentences, front-loaded with the main purpose, then key defaults and the quota. There is no filler. It loses one point because the second sentence uses 'unit_price' instead of the schema's unit_price_minor, creating an avoidable ambiguity in an otherwise compact 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?

There is no output schema, so the description's mention of PO number and totals is valuable, and the quota note is useful. However, the central monetary parameter is described incorrectly, which is a critical completeness failure for a PO creation tool; an agent cannot safely call it correctly without spotting and resolving the contradiction with the schema. It also does not state that repeated calls will create new documents, though the annotation covers that.

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

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

The schema documents all 11 parameters, so the baseline is 3, but the description actively contradicts the schema: it says 'unit_price is in MAJOR units' while the actual parameter unit_price_minor is documented as MINOR units with examples (9000 = 90.00 EUR, 90 = JPY 90). An agent following the description would format amounts incorrectly by a factor of ~100, and it also references a parameter name that does not exist.

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 ('raise') and resource ('purchase order to a supplier from items'), and states the concrete outcome: return its PO number and totals. This clearly distinguishes purchase_order_create from siblings like credit_note_create, purchase_order_get, and purchase_order_delete.

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's context is clear: use this when raising a PO from items. It does not, however, name alternatives or exclusion conditions (e.g., use purchase_order_get to retrieve a created PO, or credit_note_create for supplier credits), so the 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 destructiveHint=true already present, the description adds meaningful behavioral context: refusal of received orders, that the PO number is never reissued, and that the operation frees a monthly slot. It also notes the related logging behavior of purchase_order_receive. This goes beyond the annotation without contradicting it.

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 efficient and front-loaded with the primary action, followed by eligibility, refusal behavior, and an important permanence note. Each sentence adds distinct information, though 'naming it' is slightly ambiguous and 'freeing that month's slot' is optional flavor. Overall, it uses words well without excess.

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 one-parameter tool with no output schema, the description covers the essential context: what can be deleted, what will be refused, the side effect of never reissuing the PO number, and the sibling tool for arrivals. It could mention permission requirements or error response shape, but it is sufficiently complete for an agent to invoke 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?

The schema already provides 100% coverage for the single id parameter, including example format and the alternative of an exact supplier name. The description does not need to add parameter detail and does not materially extend beyond the schema, so a 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 opens with a specific action and resource: 'Remove one purchase order,' clearly distinguishing this from siblings like purchase_order_get, purchase_order_list, and purchase_order_receive. It further narrows scope by specifying eligibility conditions ('nothing received and never rendered'), making the tool's purpose unambiguous.

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

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

The description gives clear conditions for use: only purchase orders with nothing received and never rendered can be removed, and one with a receipt is refused. It also points to the sibling purchase_order_receive for logging arrivals, providing an explicit alternative. It stops short of fully enumerating when to prefer other siblings, but the guidance is materially useful.

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

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

The description discloses the retrieval behavior and the full composition of the returned object, which adds value beyond the all-false annotations. It does not mention not-found behavior or potential duplicate supplier-name issues, but for a simple get operation the disclosed behavior is largely sufficient.

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 that leads with the action and scope, then uses a colon-delimited list for the return contents. Every element is informative, with no filler or 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 no output schema, the description does well to specify the return contents in detail, covering buyer/supplier blocks, line items, totals, delivery date, status, and receipts. It is complete enough to call successfully, though it does not cover the not-found case or exact-match semantics in depth.

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

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

Schema coverage is 100% and the schema already documents that id can be a purchase order id or an exact supplier name with an example. The description reinforces this but does not add meaningful parameter semantics beyond the schema, so the baseline score 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 ('Return') and a specific resource ('one purchase order in full'), and it clearly distinguishes from the sibling list tool by emphasizing a single order. It also enumerates the exact contents, leaving no ambiguity about what this tool produces.

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 the tool: when a full single purchase order is needed by id or exact supplier name. However, it does not explicitly contrast this with sibling tools like purchase_order_list, purchase_order_pdf, or purchase_order_text, so an agent must infer the boundary between them.

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

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

The description ('List purchase orders') implies a read-only operation, while the annotation readOnlyHint is explicitly false, indicating the tool may modify state. This is a direct contradiction between the description and annotations, so this dimension is scored 1.

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 deliver the ordering, output fields, and available filters with no filler. The key action and ordering are front-loaded, and every phrase 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?

The description lists the returned fields and filter options, providing enough context for a list tool with all optional parameters and full schema coverage. It omits pagination or limit details, but these are not essential for a basic call.

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 each parameter already has a clear description in the schema. The tool description only restates the filter categories without adding new parameter-level detail, meriting the baseline 3.

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

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

The description begins with a specific verb and resource ('List purchase orders') and enumerates the output fields, ordering, and filters. It clearly distinguishes this from sibling tools like purchase_order_get and purchase_order_create.

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 verb 'List' implies this tool is for retrieving multiple purchase orders, and the filter options clarify scope, but the description does not explicitly state when to use this instead of purchase_order_get or purchase_order_pdf. Usage is implied rather than directly contrasted with 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 annotations providing no safety signals (all hints false), the description carries the burden and does add useful behavior: it is a one-PO render, A4 print-ready, returns a download link, and that link is valid for one hour. The only oddities are the unexplained trailing 'Pro' and calling the layout an 'invoice layout' in a purchase-order tool, but overall behavior is disclosed.

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

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

The description is short, but it is a single rambling sentence with a comma splice and ends with an unexplained 'Pro.' The phrase 'invoice layout titled PURCHASE ORDER' is confusing and doesn't earn its place. It could be tightened and cleaned up.

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 2-parameter tool with no output schema, the description covers the key return information (download link and one-hour expiry), the document layout, and the input scope (one PO). It is mostly complete, though it leaves the 'Pro' detail unexplained.

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

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

Schema coverage is 100%, so parameters are already documented including examples and the out_path default/expiry behavior. The description adds no parameter-specific meaning beyond restating that a download link is returned, so the high-coverage 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 identifies the action ('render'), the resource ('one purchase order'), and the output ('A4 print-ready document' with a download link), so an agent knows what this tool does. It doesn't explicitly name sibling tools, but the PDF/download focus distinguishes it from purchase_order_text and list/get variants.

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

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

The opening 'Call this tool to render one purchase order as an A4 print-ready document' gives a clear use case for when this tool should be invoked. It doesn't explicitly mention when not to use it or alternatives such as purchase_order_text, but the context is clear and not misleading.

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 all annotations set to false and providing little safety signal, the description carries the behavioral burden and meets it well. It discloses that partial receipts are repeatable and retained with date and note, a full receipt closes the order, and invalid states are refused (already received or predated).

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

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

The description is three sentences with no filler: purpose first, then behavior, then refusal conditions. Every clause adds operational information an agent needs.

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

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

Given the tool's moderate complexity, the description covers the key state transitions, repeatability, retention behavior, and error conditions. There is no output schema, but the description provides enough context for an agent to understand what will happen when the tool is invoked.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds meaningful semantics beyond the schema: partial's repeat behavior, the closing effect of a full receipt, and the date-before-order-date refusal. It does not add much about id or note, but those are already well described 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 opens with a specific verb and object, 'Record that an order arrived,' which immediately identifies the operation. It then distinguishes the two receipt modes (partial vs. full) and their state effects, making the tool's purpose distinct from the other purchase_order_* 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 gives clear conditions: use partial when only some of the order arrived and the order should stay open, and full receipt when it should close. It does not explicitly name sibling alternatives or say 'use X instead,' but no sibling performs receipt recording, so the context is still clear.

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

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

Given annotations that are all false and unhelpful, the description carries the burden of behavioral disclosure. It adds valuable details: the generated text includes specific sections, a one-hour-valid .txt download link is produced, and the feature is free on every tier. It does not explicitly address side effects or authentication, but nothing suggests destructive behavior.

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

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

The description is two sentences with no wasted words. The core purpose and output content are front-loaded, followed by the time-limited download link and pricing note, both of which add contextual value.

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

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

With no output schema, the description compensates by explaining exactly what the agent will receive: a plain-text order with line table, VAT lines, total, and supplier instructions, plus a one-hour .txt link. This is sufficient for an agent to use the tool correctly, though it does not detail the exact response envelope.

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 provides 100% coverage with descriptions for id, greeting, and sign_off, including the PO id format and defaults. The description adds no parameter-specific meaning, so 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 states a specific verb and resource: 'Turn a purchase order into a plain-text order to paste into an email.' It enumerates the expected content (line table, VAT lines, total, delivery date, PO number) and clearly differentiates from the sibling purchase_order_pdf by emphasizing plain-text email output.

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 clear context for when to use the tool: when a plain-text purchase order is needed for pasting into an email. It does not explicitly name alternatives or exclusions, so it stops short of a 5, but the intended use case is unambiguous.

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