AP Control Labs Finance Controls

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

No annotations are present, so the description carries the full burden. It discloses key behaviors: the operation is asynchronous, an ID is returned for polling, and idempotency is required. However, it does not explain side effects (e.g., whether the invoice is stored) or what the response contains beyond an ID, leaving gaps in transparency.

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

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

Two sentences, front-loaded with the primary action and followed by critical workflow warnings. Every word is purposeful; there is no redundancy or 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?

The tool has a complex nested invoice schema and an output schema, and the description covers the asynchronous submission workflow. However, it leaves the polling target unspecified (no sibling tool is named), and the next step after obtaining the ID is unclear. It is adequate but incomplete for an agent navigating many related tools.

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

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

Schema description coverage is 0%, so the description must compensate. It merely calls the first parameter a 'normalized invoice' and mentions 'idempotency_key' without explaining any field semantics or the key's deduplication role beyond the warning. The invoice object's fields (vendor_name, total, etc.) are left entirely to schema constraints, which is insufficient for a tool with nested objects.

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

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

The description clearly states the verb (submit), the resource (a normalized invoice), and the purpose (asynchronous duplicate analysis). It distinguishes from siblings by focusing on the submission flow rather than validation or retrieval, making the tool's role 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?

It provides explicit workflow instructions: use the returned ID to poll and do not resubmit with a new idempotency key. This is clear context, but it does not name the specific polling tool or mention other alternatives, so the 'when-not' is not fully explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose a key limitation (no authenticity validation), which is valuable, but it does not state whether the operation is read-only, how errors are handled, or what happens with invalid or incomplete metadata.

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 compact—two sentences that state the purpose and a key limitation with no filler. Information is front-loaded in the first sentence, and every phrase adds 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?

The tool has 4 parameters and an output schema, but the description only covers the general purpose. While the output schema reduces the need to explain return values, the complete lack of parameter semantics and minimal usage guidance leave the description insufficiently complete for effective autonomous 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?

The input schema has 0% description coverage, and the description does not compensate. It vaguely references 'supplied certificate metadata' but never explains the meaning or role of vendor_reference, certificates, as_of_date, or warning_days. The array-of-objects structure for 'certificates' remains completely opaque.

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 ('Check') with a clear resource ('expiry windows and customer verification flags for supplied certificate metadata'), and distinguishes the tool by explicitly stating it does not validate certificate authenticity. This makes its scope unambiguous and differentiates it from potential sibling tools like check_tax_form or check_vendor_domain_risk.

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 checking expiry windows and verification flags on certificate metadata—and adds a useful exclusion ('It does not validate certificate authenticity'). It does not explicitly name alternative tools for authenticity validation, which keeps it just shy of a 5.

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

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

With no annotations provided, the description carries the burden of disclosing side effects. It does so by explicitly stating that this tool never authorizes a payment or vendor-record change, which is critical behavioral information that prevents an agent from mistakenly assuming it executes the action. This is high-value transparency beyond the schema.

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 exactly two sentences, front-loaded with the verb 'Evaluate' and the resource. Every word adds value: the first sentence defines scope and the second sentence constrains behavior. There is zero redundancy or 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?

Given the tool's complexity (evaluating multiple policies) and the presence of an output schema, the description covers the essential behavioral contract (non-mutating check) and input categories. It could add more context about preconditions or expected outcome format, but the output schema compensates for return values. It is reasonably complete for a validation tool.

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

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

The input schema has 13 parameters with 0% schema_description_coverage, so the description must compensate. While it mentions policy areas like 'budget, authority, category, vendor, contract, and approval policy,' it does not clarify specific parameters such as agent_id, currency, restricted_categories, or approval_required_above. The mapping is generic and does not help understand individual parameter meanings or formats.

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

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

The description clearly states a specific verb-resource pair ('Evaluate a proposed procurement agent action') and defines its scope (against budget, authority, category, vendor, contract, and approval policy). It also distinguishes itself from sibling tools by explicitly noting what it never does ('never authorizes a payment or vendor-record change'), which sets it apart from execution-oriented tools like create_purchase_order or release_payment.

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 its role as a pre-execution check by stating it evaluates policies and never authorizes changes, but it does not explicitly say 'use this before executing an action' or name alternative tools. Clear context is provided, but no explicit when-to-use versus when-not-to-use guidance or alternative references are present.

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

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

With no annotations, the description carries the full burden. It discloses a consequential behavior: a detected change requires human out-of-band verification. It also clarifies it is not ownership verification. However, it does not state whether the tool mutates any state, requires permissions, or has other side effects, leaving some opacity.

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. The primary action leads immediately, and the caveats are efficiently stated in the second sentence. Every clause adds value, making it a model of concise 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?

Given the tool's simplicity (3 params, no nested objects) and the presence of an output schema, the description covers the core purpose and a key behavioral outcome. It lacks parameter semantics and explicit usage boundaries, but for a straightforward comparison tool, it is reasonably 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 0%, and the description does not explain the three required parameters (vendor_reference, remittance_reference, account_fingerprint). It hints at 'fingerprinted remittance details' but does not map these to parameter names or explain their roles, leaving the agent to infer from the schema alone.

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 'Compare submitted fingerprinted remittance details with a customer-controlled vendor baseline' – a specific verb and resource that clearly identifies the tool's function. It also distinguishes itself from bank-account ownership verification, helping the agent differentiate it from related sibling tools.

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

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

The description implies when to use the tool (when comparing remittance fingerprints against a baseline) and provides a negative exclusion ('this is not bank-account ownership verification'), but it does not explicitly name alternative tools or provide explicit when-to-use/when-not-to-use criteria. The guidance is present but implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool uses limited inputs ('using only...') and that it is not tax advice or tax-ID verification, which gives some insight into its behavioral boundaries. However, it does not state whether the operation is read-only, whether it validates against external databases, or any side effects or error 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 exactly two sentences, with the first stating purpose and inputs, and the second adding exclusions. Every word earns its place, and it is front-loaded with the action verb 'Check.'

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

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

The tool has 6 parameters, an output schema, and no annotations. The description is too sparse to fully support understanding: it fails to mention form_type (a required parameter), does not explain what constitutes 'form completeness,' and does not clarify the role of entity_country. While an output schema exists, the input semantics remain unclear, making this minimally viable but incomplete.

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

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

Schema coverage is 0%, so the description must compensate. It maps 'legal name' to legal_name, 'final four identifier digits' to tax_identifier_last4, and 'supplied dates' to signed_on/expires_on, but it omits form_type, which is required, and entity_country. It also does not explain the enum values for form_type or the meaning of entity_country, leaving significant gaps.

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's purpose: checking W-9 or W-8 form completeness. It specifies the input basis ('legal name, final four identifier digits, and supplied dates') and explicitly distinguishes itself by stating what it is not (tax advice or tax-ID verification). This differentiates it from sibling tools focused on invoices and purchase orders.

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 you need to check form completeness) and includes an explicit when-not via 'It is not tax advice or tax-ID verification.' However, it does not name alternative tools or provide a more detailed decision tree, but given its uniqueness among siblings, this is adequate.

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

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

With no annotations, the description must bear the full burden of behavioral disclosure. It only says to compare and verify changes out of band, but does not clarify what the tool returns, whether it flags or blocks, or any side effects. This leaves significant 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?

Two sentences, front-loaded with the core action, no redundant words. Every phrase contributes to understanding the tool's purpose and a key behavioral note.

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?

Although an output schema exists, the tool has 4 parameters and no annotations. The description does not address vendor_reference, the verification workflow, or edge cases (e.g., what counts as a change). For a tool in a broader procurement/invoice context, this is insufficiently 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 0%, so the description must compensate. It adds meaning for 3 of 4 parameters: sender_email, approved_domains, and prior_sender_domains. However, vendor_reference is omitted, and the schema lacks descriptions, so not all parameters are semantically clarified.

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 ('Compare') and resource ('sender email domain'), clearly distinguishing it from sibling tools like check_certificate_expiry or check_remittance_change. The scope is unambiguous: comparing against customer-provided baselines.

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 a use case (checking sender domain risk) but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or alternative tool references. The 'out of band' note offers a procedural guideline but not a usage discriminator.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It discloses a key non-goal ('does not approve or create a vendor') which implies a read-only nature, but it does not mention whether data is modified, required permissions, or what happens when the packet is incomplete. This is minimally acceptable but lacks deeper behavioral context.

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

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

The description is two sentences, front-loaded with the main action, and contains zero filler. Every word adds meaning, and the clarifying sentence about non-goals 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?

Despite having five parameters, no annotations, and 0% schema description coverage, the description is only two sentences. It does not explain how completeness is determined, the role of each boolean/array parameter, or expected usage context (e.g., before vendor creation). The existence of an output schema mitigates return-value explanation, but the overall behavioral context remains insufficient.

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

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

Schema description coverage is 0%, and the description provides no explanation of any of the five parameters. It does not clarify how required_items and supplied_items interact, what approved_by_customer or remittance_fingerprint_present signify, or how vendor_reference is used. The description adds no value beyond the basic property names 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 ('Check') and identifies the resource ('customer-defined supplier onboarding packet completeness'). It also distinguishes the tool from siblings by explicitly stating it does not approve or create a vendor, which clarifies its narrow scope.

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

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

The description clearly implies when to use the tool (for checking onboarding packet completeness) and provides an explicit when-not ('does not approve or create a vendor'). However, it does not name any alternative tools or provide explicit prerequisite or contextual 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that the tool does not select or send quotes (implying read-only, non-mutating behavior), which is useful transparency. However, it does not disclose other behavioral traits such as how comparison is performed (e.g., line-by-line vs totals aggregation) or any error conditions.

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 long with zero fluff. The first sentence states the core purpose, and the second adds a critical constraint. It is well-structured and appropriately sized.

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 output schema is present, the description does not need to explain return values. It addresses the core purpose and a key behavioral boundary. However, it could provide more context on input expectations (e.g., how quotes should be structured, what 'totals' refers to) to be fully complete, though the minimal complexity (2 params) makes this acceptable.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. The description mentions 'quote lines and totals' but does not map these to the 'quotes' or 'expected_currency' parameters, nor does it explain the structure of quote objects or the role of the currency parameter. The parameter names are somewhat self-explanatory, but meaningful usage details are missing.

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 ('Compare') and names the resource ('customer-provided vendor quote lines and totals'). It distinguishes the tool from siblings by explicitly stating it never selects or sends a quote, which clarifies its analytical scope.

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

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

The description provides a clear when-not-to-use guidance ('It never selects or sends a quote') but does not explicitly state when to use this tool versus alternatives. It implies usage for pure comparison analysis, but lacks explicit alternative references or prerequisites.

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

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

With no annotations provided, the description correctly discloses two key behaviors: 'stores only the caller's data' and 'never writes to an ERP'. These add valuable context beyond the schema, but the description omits details about idempotency, return behavior, and what happens if the PO already exists. It provides some transparency but not comprehensive.

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

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

The description is two sentences, front-loaded with the primary action, and contains no filler. Every sentence adds meaningful information about scope and side effects.

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

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

The tool has four parameters, three required, and an output schema, but the description does not explain the input structure beyond 'purchase order', leaving the agent to rely solely on the schema. The description covers the core concept and non-ERP side effect, but misses parameter semantics and usage guidance. Given the output schema exists, return values are covered, but the overall guidance is adequate yet incomplete.

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

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

Schema description coverage is 0%, and the description provides no information about the four parameters (po_number, vendor_name, lines, currency). It only describes the business object ('purchase order') without explaining the required fields, line structure, or currency constraints. The description fails to compensate for the schema gaps.

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

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

The description clearly states the action ('Register one customer-provided purchase order') and the purpose ('baseline for AP Match'), distinguishing it from extraction or comparison siblings. It also adds the scope 'customer-provided' to differentiate from extracted POs, making the tool's role 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 phrase 'customer-provided' gives clear context for when to use this tool (when a PO is provided by the customer, not extracted). However, it does not explicitly exclude alternatives or mention when not to use it, or name sibling tools like save_extracted_purchase_order.

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

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

With no annotations, the description carries the burden. It discloses that the tool compares revisions and returns changes, and mentions ownership and saved status, but does not explicitly state that it is read-only, whether it modifies anything, or error/authorization conditions. This is a modest amount of transparency for a diff 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 the first one flagging 'Private preview' and the second delivering the entire purpose. There is no redundant filler, and the key information is front-loaded after the warning.

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

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

Given the tool's simplicity and the presence of an output schema, the description covers the essential input constraints (saved, caller-owned) and the outcome (header, term, line changes). It omits details like read-only confirmation or same-PO requirement, but these are largely inferable from the name and context. Overall it is sufficient for a preview tool.

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

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

Schema description coverage is 0%, so the description must contextualize the two parameters. It does so by referring to 'two saved caller-owned PO revisions,' giving meaning to the IDs, but it does not clarify whether they must be revisions of the same purchase order or how before/after ordering is handled. The names are self-explanatory, but the description adds limited depth.

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 the specific verb 'Compare' with the resource 'two saved caller-owned PO revisions,' clearly stating the tool's function. It also specifies the output type ('header, term, and line changes'), which distinguishes it from sibling tools like compare_quotes.

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 guidance on when to use this tool versus alternatives, nor any exclusions. The phrase 'private preview' implies limited availability, and 'saved caller-owned' implies the POs must belong to the caller, but no alternative tools or conditions are mentioned. This leaves usage context implied rather than stated.

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

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

With no annotations, the description carries the transparency burden. It discloses that results are 'candidate' (not definitive) and provides a disclaimer ('not legal advice') and a required review step. This adds meaningful behavioral context beyond what a schema would show, though it doesn't detail return format or side effects.

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

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

The description is two concise sentences, front-loaded with the core purpose. Every word earns its place, with no redundant phrasing or filler, making it easy to parse quickly.

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

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

The tool has 4 parameters (2 required) with no schema descriptions, and an output schema exists. The description covers the main purpose and a caution, but it lacks guidance on parameter roles and when to use the tool, leaving gaps 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?

Schema description coverage is 0%, so the description needs to explain parameter semantics. It only mentions 'contract text', leaving contract_reference, as_of_date, and lookahead_days unexplained. The phrase 'ISO dates' hints at output but not how parameters control the extraction process.

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

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

The description clearly states a specific action ('Find'), the resource ('candidate ISO dates and obligation indicators'), and the context ('in supplied contract text'). This distinguishes it from sibling tools like extract_purchase_order and analyze_invoice, which target different document types and objectives.

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: use when you need to extract date/obligation information from contract text. However, there is no explicit guidance about when to use this tool versus alternatives, nor any exclusions. The instruction to 'review results against the source' hints at a post-processing step but does not clarify scenarios.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It informs the agent that the operation is asynchronous ('Queue... Poll'), which is valuable. However, it does not disclose potential side effects, idempotency behavior, or whether the document is consumed or remains available. The 'Private preview' note hints at limited stability but adds no concrete behavioral context.

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

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

The description is concise and front-loads the primary action ('Queue...') followed by the key polling instruction. The 'Private preview' sentence is an extra status note that does not contribute to functional understanding, but the overall length is appropriate.

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 two-parameter async queueing tool with an output schema, the description covers the core workflow (queue then poll). However, it omits parameter semantics and any details about idempotency or duplicate handling. Given the tool's moderate complexity and available schema/output schema, this is a minimally viable but not comprehensive description.

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

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

The schema has 0% coverage (no parameter descriptions), so the description must compensate, but it fails to do so. It never mentions `upload_id` or `idempotency_key` directly. The phrase 'uploaded document' implies upload_id, but the semantics of idempotency_key are entirely unexplained, leaving the agent to infer its purpose from the name alone.

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 'Queue' with a clearly defined resource ('uploaded customer-owned purchase-order document') and purpose ('structured extraction'). It also differentiates from sibling tools by explicitly directing to poll with get_purchase_order_extraction, which is unique to this workflow.

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 clearly instructs the user to poll with get_purchase_order_extraction after queueing, establishing the expected workflow. It also scopes usage to a single uploaded customer-owned purchase-order document. However, it does not explicitly state when not to use this tool or mention alternative tools for different document types.

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

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

With no annotations present, the description carries the full burden. It discloses that the return is 'agent-readable' and that the invoice must be 'caller-owned', but it does not describe error behavior, permissions beyond ownership, or whether the operation is read-only. 'Retrieve' weakly implies non-mutation.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and it is immediately clear what the tool does.

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 a single parameter and the presence of an output schema, the description is largely sufficient. It provides the essential scope and a hint about the output's purpose, though it lacks explicit usage alternatives and detailed parameter semantics.

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

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

Schema description coverage is 0%, and the description does not explain invoice_id beyond the ownership constraint. It adds some context with 'caller-owned invoice' but fails to describe the parameter's format, source, or relationship to caller identity.

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 the specific verb 'Retrieve' with the resource 'exception packet', and scopes it to 'one caller-owned invoice'. This clearly distinguishes it from sibling tools like get_invoice_status or get_invoice_extraction.

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

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

The phrase 'for one caller-owned invoice' implies when the tool is appropriate, but there is no explicit guidance on when to choose this over alternatives such as get_invoice_risk_score or analyze_invoice. No exclusions or alternative tool names are mentioned.

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

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

No annotations are provided, so the description must disclose behavioral traits. The verb 'Retrieve' implies read-only, and the description lists outputs, but it does not mention error handling, prerequisites, or side effects. It adds some context but could be richer.

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

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

One concise sentence that front-loads the verb and clearly lists the key outputs. No unnecessary 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 single-parameter retrieval tool with an output schema, the description adequately lists what is returned. It could mention usage guidance or boundary cases, but given the simplicity and output schema presence, it is nearly 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 0%, so the description should compensate. The parameter 'invoice_id' is self-explanatory (an invoice ID) and the description mentions 'submitted invoice,' but it doesn't elaborate on format or usage. The single parameter is simple, so a 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 uses a specific verb ('Retrieve') and specifies the resource (canonical fields, OCR confidence, source evidence, next action for an invoice). This clearly distinguishes it from sibling tools like get_invoice_status or get_invoice_risk_score.

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 it (when extraction data is needed) but does not explicitly mention alternatives or exclusions. Context is present but guidance is not clearly articulated.

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

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

With no annotations, the description must disclose behavioral traits. It mentions 'deterministic' and 'completed invoice,' but omits potential side effects, authorization requirements, rate limits, or handling of incomplete invoices. The 'Private preview' note signals limited availability but adds little behavioral depth.

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

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

The description is a single, front-loaded sentence with no fluff. Every clause adds value, stating the outputs and the input condition. It is appropriately concise for the tool's simplicity.

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

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

The tool has an output schema, so return values are covered. The description explains the core purpose clearly, but lacks usage alternatives or caveats. Given the simple parameter and existing output schema, it is adequate but not fully complete, especially without annotation support.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does by noting the invoice must be completed, which clarifies the expected state of the invoice_id parameter. However, it does not explain the parameter format or additional semantics beyond what the schema's name implies.

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

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

The description clearly states the tool returns a deterministic 0-100 control score, priority band, and named evidence signals for a completed invoice. This specific verb+resource+output combination distinguishes it from sibling tools like get_invoice_status and validate_invoice.

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

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

No guidance is provided on when to use this tool versus alternatives like analyze_invoice or get_invoice_exceptions. The phrase 'for a completed invoice' implies a precondition but does not explicitly state usage context or exclusions.

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

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

With no annotations, the description is the only source of behavioral disclosure. It reveals that the tool polls until COMPLETED or FAILED and that the analysis must be owned by the caller's organization, adding a security context. It does not mention error behavior, rate limits, or whether the operation is purely read-only.

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

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

The description is brief without wasted words: two sentences convey purpose, ownership, and polling behavior. It is exemplary in being front-loaded with the main action.

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 purpose and polling, but with the schema providing no parameter documentation and no annotations, it leaves gaps around the relationship between the invoice_id and the analysis, and when this tool is appropriate. The presence of an output schema reduces the need for return-value details, but the description still lacks essential context for a tool with zero schema coverage.

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 has a single parameter invoice_id with no description coverage (0%). The description never explains how invoice_id maps to the 'analysis' being retrieved, leaving the parameter semantics unclear. The tool name suggests the ID identifies an invoice whose analysis status is being checked, but this is not stated.

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 the verb 'Retrieve' with a specific resource ('one analysis owned by the caller's organization'), which clearly differentiates it from sibling tools like get_invoice_exceptions or get_invoice_extraction. However, the term 'analysis' is somewhat generic; specifying that it's an 'invoice analysis' would be clearer.

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

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

The description implies usage for polling the status of an analysis until it reaches a terminal state (COMPLETED or FAILED), which is valuable context. However, it does not explicitly state when to use this tool versus alternatives, such as after analyze_invoice, nor does it name any alternatives or exclusions.

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?

Without annotations, the description discloses the read-only nature implicitly by 'Get', the authorization scope ('caller-owned'), and the return payload components. However, it omits error behavior, prerequisites, and the meaning of 'next action', leaving some behavioral aspects unclear.

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

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

One sentence of 14 words, front-loaded with a limitation marker ('Private preview') and then the action. No redundant information; every word earns its place.

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

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

The tool is simple with one parameter and an output schema, so the description is mostly sufficient. However, it lacks guidance on where extraction_id comes from and what 'next action' means, leaving some gaps for an agent trying to invoke the tool correctly.

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

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

The single parameter extraction_id is not described in the text; with 0% schema description coverage, the description does not compensate by explaining what the ID refers to or how to obtain it. The parameter meaning is inferred only from the tool name.

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 the verb 'Get' and specifies the exact resource ('caller-owned PO extraction') and the data returned (status, canonical fields, OCR evidence, next action). This clearly distinguishes it from sibling tools like get_invoice_extraction or extract_purchase_order.

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 context—'caller-owned' implies access restrictions and 'Private preview' signals availability—but it does not explicitly state when to use this tool instead of alternatives, nor does it mention prerequisites like first creating an extraction.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the operation is 'read-only,' a critical safety trait, and notes the requirement for the PO to be 'registered.' This adds meaningful context beyond the schema, though it does not describe error handling or output specifics.

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 exceptionally concise—two short sentences that immediately state the action and the key constraint. There is no redundant or filler content; every word contributes 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?

Given the tool's moderate complexity (4 parameters, one enum, oneOf, and an output schema), the description provides the essential purpose and key constraint. It omits explicit references to invoice_id and mode semantics, but the input schema and output schema compensate for these details, making the description adequately complete for the tool's scope.

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

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

The schema has 0% description coverage, so the description must compensate for parameter meaning. It clarifies the mode concept with 'two- or three-way' and reinforces the oneOf condition with 'supply exactly one purchase-order identifier.' However, it does not mention invoice_id or elaborate on parameter values, so compensation is partial.

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's function: 'Run a read-only two- or three-way match against one registered purchase order.' It specifies a concrete action, resource, and scope, distinguishing it from sibling tools like match_reconciliation or match_remittance_advice by focusing on matching a single purchase order.

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

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

The description implies usage context through phrases like 'read-only' and 'against one registered purchase order,' and instructs to supply exactly one PO identifier. However, it does not explicitly mention alternatives or conditions when not to use this tool, so usage guidance is only implied rather than fully explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly discloses two key behaviors: 'deterministic' and 'never posts a reconciliation,' which inform the agent about side effects and reliability. It also indicates that the tool operates on caller-provided data. While it does not disclose internal matching algorithm details or error handling, the mention of determinism and non-persistence provides substantive behavioral context beyond the schema.

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 concise sentences with no filler. The first sentence front-loads the core purpose, and the second adds a critical behavioral constraint. Every word contributes to the understanding, making it an efficiently structured description.

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 provides a clear overview but misses essential details for correct invocation. It does not explain what the record sets should contain, how matching is performed, or the meaning of date_tolerance_days. While an output schema exists and would cover return values, the input semantics are insufficiently described for an agent to construct correct inputs. The lack of usage guidance further reduces completeness.

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

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

Schema description coverage is 0%, so the description must compensate, but it does not. It mentions 'two caller-provided record sets,' which loosely maps to source_records and target_records, but it does not explain the structure of these records or what constitutes a match. The optional date_tolerance_days parameter is completely undocumented in the description, leaving its meaning and usage unclear.

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

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

The description clearly states the tool's purpose: 'Produce deterministic candidate matches between two caller-provided record sets.' It specifies the action (produce), the resource (candidate matches), and the scope (between two record sets), which distinguishes it from sibling tools like match_invoice or match_remittance_advice that target specific invoice or remittance matching. The addition of 'deterministic' also differentiates its expected behavior.

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 phrase 'caller-provided record sets' and 'never posts a reconciliation,' suggesting it is for matching without persisting results. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The usage context is only implied, not clearly defined.

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

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

With no annotations provided, the description carries full burden. It explicitly discloses a key behavioral trait: 'It never posts a payment,' which assures the agent this is non-mutating. It also implies the baseline is caller-supplied, adding context about data flow. However, it does not detail other potential behaviors (e.g., whether it modifies local state), but the non-posting statement is a strong positive signal.

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 just two sentences with no fluff. It front-loads the core action and adds the critical non-posting caveat. Every word earns its place.

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

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

Given the tool has 6 parameters, no schema descriptions, and an output schema, the description provides enough context for core usage: what it matches and what it does not do. It does not explain matching logic or edge cases, but for a simple matching tool with an output schema, this is reasonably complete. The 'never posts' statement reduces risk of misuse.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does by clarifying the roles of key parameters: 'customer-supplied remittance amount' (remitted_amount), 'invoice references' (invoice_references), and 'caller's supplied open-invoice baseline' (open_invoices). However, it does not explain optional parameters like currency, vendor_reference, or remittance_reference, leaving gaps for these.

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's function: 'Match a customer-supplied remittance amount and invoice references to the caller's supplied open-invoice baseline.' It uses a specific verb ('match') and resources, and the clarification 'It never posts a payment' distinguishes it from payment-posting tools. This differentiates it well from siblings like match_invoice or match_reconciliation.

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: the tool matches a customer-provided remittance against an open-invoice baseline. It implies when to use it (when you have a remittance and need to match to open invoices) but does not explicitly mention alternatives or exclusions. This meets the 'clear context, no exclusions' bar.

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

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

With no annotations, the description carries the full burden and does disclose two important behavioral traits: it never connects to a bank and does not store account numbers. However, it does not mention other side effects or return behavior, leaving some ambiguity about persistence or output format.

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 short sentences, front-loaded with the core purpose, and contains no filler. It is concise and well-structured.

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

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

The tool is simple with only two parameters, and the description covers the main purpose and privacy traits. However, it lacks guidance on the expected structure of the transactions array items or any normalization rules, which is important given the empty input schema descriptions.

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

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

The schema has 0% description coverage, and the tool description does not explain the parameters. 'account_reference' and 'transactions' are left undefined, so the agent must rely solely on the parameter names, which is insufficient for constructing correct input.

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 'normalize' and clearly identifies the resource 'customer-provided bank transaction records' and the purpose 'for reconciliation.' This makes it distinct from sibling tools that deal with invoices, vendors, or purchase orders.

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 clearly implies when to use the tool (when you have customer-provided bank transaction records to normalize) and adds context that it never connects to a bank or stores account numbers. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full 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?

Despite no annotations, the description explicitly discloses determinism and that it does not invent missing values—key behavioral traits. However, it does not cover other potential behavioral aspects like error handling, idempotency, or rate limits.

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

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

The description is extremely concise, comprised of two short sentences with no fluff. It front-loads the core purpose and includes the important caveat about not inventing values.

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 core purpose and a key constraint but omits details about normalization rules, input structure, prerequisites, or when this tool should be preferred. Given the output schema exists, return values are not described, but the input remains under-specified for a single-param tool.

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

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

With schema description coverage at 0%, the description must compensate, but it only vaguely implies that line_items contain descriptions, SKUs, and units. It fails to specify the array item structure, required fields, or formatting, leaving significant ambiguity for a single parameter.

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 specifies the tool's function: deterministically normalize customer-supplied invoice descriptions, SKUs, and units. It distinguishes itself from sibling tools like normalize_bank_statement by targeting invoice lines specifically.

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

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

The description provides no guidance on when to use this tool versus other invoice-related tools such as get_invoice_exceptions or match_invoice. The 'Private preview' note hints at availability but does not explain selection criteria or exclusions.

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?

Even though no annotations are provided, the description explicitly discloses a critical behavioral guarantee: 'This tool never connects to or writes to an ERP.' This assures the agent that the operation is safe and non-mutating, which is highly valuable for a preflight validation tool.

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

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

The description is two sentences, front-loaded with the primary action and target, followed by a crucial safety disclaimer. Every word earns its place with no redundancy.

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

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

For a tool with 10 parameters, a nested object, and an output schema, the description is too sparse. It doesn't explain what 'preflight' entails, what validations will run, which references are required, or how the output should be interpreted. The existing output schema covers return values, but parameter usage and preflight logic remain undocumented, leaving the agent under-informed.

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

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

The schema has 0% description coverage, and the description adds no parameter-level semantics. The only hint is 'customer-supplied record references,' which could map to source_record_id and vendor_reference, but it doesn't specify required fields, the nested invoice object, or how to construct the request. The description fails to compensate for the schema's lack of parameter documentation.

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

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

The description clearly states the action ('Check'), the target ('a proposed NetSuite or QuickBooks vendor bill'), and the key constraint ('using customer-supplied record references'). It also differentiates itself from sibling preflight tools by focusing on the generic ERP vendor bill rather than franchise, freight, or subcontractor invoices.

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

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

The description provides clear context for when to use this tool: to preflight-check a vendor bill before ERP interaction. It also notes that no ERP connection occurs. However, it doesn't explicitly mention when to prefer this over sibling preflight tools (e.g., franchise/freight/subcontractor) or other invoice validation 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?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It discloses one behavioral trait (never searches another organization's records) but fails to mention side effects, permissions, or return format. Since 'find' implies a read-only operation, this is not explicitly confirmed, and the tool's behavior beyond searching is opaque.

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 consists of two concise sentences, with the primary purpose front-loaded in the first sentence and a key behavioral constraint in the second. There is no unnecessary information, making it appropriately sized and well-structured.

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

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

The tool is complex with 6 parameters, nested objects, and an output schema, but the description is minimal. It does not explain return values (though an output schema exists), does not clarify parameter roles, and lacks behavioral context beyond the core search. The description is insufficient for an agent to use the tool correctly without additional inference.

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 description coverage is 0%, so the description must compensate for parameter meaning. The phrase 'same-vendor, same-invoice, same-amount' provides some semantics for vendor_name, invoice_number, and total, but it does not explain expected parameters like location_reference, vendor_reference, historical_invoices, or approved_vendor_references. The description leaves the purpose of the majority of parameters undefined.

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's function with a specific verb ('Find') and a specific resource ('exact same-vendor, same-invoice, same-amount duplicates across customer-supplied multi-location history'). It also distinguishes itself from other tools by clarifying it never searches another organization's records, which helps differentiate from similar preflight or matching tools in the sibling 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 implies its usage context ('Find duplicates across customer-supplied multi-location history') but does not explicitly state when to use it compared to alternatives, nor does it provide exclusions or mention sibling tools. The 'never searches another organization's records' phrase gives a constraint but not a clear usage guideline.

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

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

With no annotations, the description must carry the behavioral burden. It does disclose that the tool does not connect to TMS or carrier systems, which is a useful limitation. However, it does not explicitly confirm that the operation is read-only (though 'check' implies it), nor does it describe any side effects, authorization requirements, or failure modes. The added context is minimal but not contradictory.

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

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

The description is extremely concise: two sentences, front-loaded with the primary purpose, and no unnecessary words. Every clause adds value—the second sentence clarifies an important limitation. This meets the highest standard for conciseness.

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 complexity (11 parameters, nested objects, and a preflight context), the description is too sparse. It does not explain what 'preflight' entails, what policy criteria are used, or any preconditions for using the tool. While an output schema exists, the input side remains underspecified, leaving the agent with insufficient context to invoke the tool reliably.

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

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

Schema description coverage is 0%, so the description must compensate. It only provides high-level categories ('shipment, linehaul, fuel, and accessorial policy data') that vaguely map to some parameters, but it does not explain specific parameter meanings, formats, or relationships. For an 11-parameter tool with nested objects, this is insufficient parameter-level guidance.

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's function: 'Check a freight invoice against supplied shipment, linehaul, fuel, and accessorial policy data.' This uses a specific verb ('check') and resource ('freight invoice') and distinguishes it from sibling preflight tools by mentioning freight-specific components like linehaul, fuel, and accessorials. The additional 'does not connect to a TMS or carrier system' further clarifies scope.

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

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

The description implies usage: it is a preflight check that uses supplied data rather than external systems. However, it does not explicitly state when to use this tool over alternatives like match_invoice or compare_quotes, nor does it name any exclusions beyond the TMS/carrier system note. The guidance is implicit rather than explicit.

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

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

With no annotations, the description carries the transparency burden. It discloses a meaningful limitation—does not determine legal validity—but remains silent on whether the tool has side effects, requires permissions, or returns a report. The 'preflight' name hints at read-only behavior, but this is not stated.

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 filler. The first sentence states the core function and scope, the second adds a clear boundary. Every word earns its place.

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

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

Given the tool's complexity (13 parameters, nested objects, 2 enums) and the presence of an output schema, the description provides a useful overview and one limitation, but it is too terse to fully guide an agent on all required parameters and their relationships. The evidence-type list helps but does not fully compensate for the schema's lack of descriptions.

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

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

Schema description coverage is 0%, so the description must compensate. It maps several parameters to evidence types (e.g., retainage to retainage_rate, insurance to insurance_status), aiding interpretation, but it leaves many parameters unexplained, including billed_to_date, approved_change_order_amount, and the full invoice object structure.

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 'check' and a specific resource 'subcontractor invoice', then enumerates six evidence categories (commitment, retainage, schedule-of-values, work, lien-waiver, insurance). This clearly distinguishes it from sibling tools like analyze_invoice or other preflight tools for different invoice types.

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

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

The description implies usage for preflight validation of subcontractor invoices, and the sibling tool names (e.g., preflight_erp_bill) provide context, but it does not explicitly state when to choose this over alternatives or mention any exclusions beyond the legal validity boundary.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It adds key context about side effects (or lack thereof) by stating 'it never updates a warehouse or ERP.' However, it does not explain what the tool actually does affect (e.g., writes to a receipt table), any prerequisites, or potential side effects like validation or status changes, 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 exceptionally concise, consisting of two short sentences that front-load the primary purpose and then add key usage context. Every word earns its place, with no redundancy or 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?

The description gives a clear high-level purpose and a critical usage constraint, but given that the tool has 4 parameters (including an array of line items) and no annotations, it lacks important context about inputs and expected behavior. The existence of an output schema helps with return values, but the description does not fully compensate for the missing parameter semantics and broader workflow integration.

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

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

Schema description coverage is 0%, and the description provides no parameter-level detail. It mentions general concepts like 'purchase order' and 'receipt,' but does not explain the meaning of fields such as purchase_order_id, receipt_number, lines, or received_at. With zero percent coverage and no compensation in the description, this is a significant gap.

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

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

The description clearly states the tool's purpose with a specific verb+resource: 'Record a customer-provided goods receipt for a registered purchase order.' It also distinguishes itself from siblings by explicitly stating what it does not do ('never updates a warehouse or ERP') and provides context about its role in the AP process.

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 usage context: 'Use it before a THREE_WAY AP Match.' It also gives an exclusion ('it never updates a warehouse or ERP') which helps guide against using it for those actions. However, it does not explicitly mention alternative tools by name, so it falls short of a full 5.

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

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

No annotations are provided, so the description must carry the transparency burden. It adds one important limitation ('not official verification'), but does not disclose whether the tool performs writes, requires permissions, or how it handles ambiguous matches.

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

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

Two sentences, front-loaded with purpose and a clarifying caveat. No redundant 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?

Given 7 parameters and no annotations, the description gives a high-level overview but lacks details on match logic, return values (though output schema exists), and edge cases. It is sufficient for basic understanding but could be more complete.

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

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

The schema has 0% description coverage, but the description compensates by grouping input fields into 'customer-supplied' (vendor names, aliases, addresses, domains) and 'customer-provided expectations' (expected_name, approved_domains, expected_address). This adds semantic meaning that helps the agent map the parameters.

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

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

The description uses the specific verb 'resolve' and clearly identifies the resource (vendor entity fields) and the comparison target (customer-provided expectations). It also explicitly states what it is not ('not official verification'), aiding in correct tool selection and distinguishing it from other vendor-related tools.

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

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

The description implies the tool is for validating vendor-supplied information against expected values, and the caveat 'It is not official verification' provides a clear exclusion for when not to use it. However, it does not name alternative tools or give explicit when-to-use conditions beyond this.

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

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

No annotations are provided, so the description must disclose behavior. It hints at a prerequisite ('completed extraction') and sequence ('before matching...'), but does not explain side effects, label uniqueness, or idempotency. This is a mutation tool, so more detail would be expected.

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 the first being a status note and the second containing the core purpose and timing. It is concise and well-structured, with no redundant text.

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 save operation with two required parameters and an existing output schema, the description provides the essential context: what is saved, under what label, and when. It lacks explicit error scenarios but is otherwise adequate for the tool's simplicity.

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

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

With 0% schema description coverage, the description carries the burden for explaining parameters. 'Save a completed extraction as a named PO revision' implies extraction_id is the identifier for the completed extraction and revision_label is the name for the revision. This is indirect but sufficient for inference.

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

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

The description clearly states the verb 'Save' and the resource 'completed extraction' transformed into 'named PO revision', which is specific and distinguishes it from sibling tools like extract_purchase_order and diff_purchase_order_amendment. The qualifier 'before matching or amendment diffing' further clarifies its role in the workflow.

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 use this tool: before matching or amendment diffing, and only after a completed extraction. It does not name alternative tools or provide exclusions, but the workflow positioning is 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?

With no annotations, the description carries the burden of behavioral disclosure. It adds useful context: the scope is 'caller's own' (privacy), only 'completed' invoices are searched, and 'scores are explainable, not a fraud probability'. This gives insight into output interpretation and distinguishes from risk scoring. It could still mention side effects (implied read-only) but the description goes beyond a bare statement.

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, front-loaded with the core purpose, and every word adds value. It is neither verbose nor under-specified in terms of purpose and caveats.

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 is reasonably complete given that an output schema exists, so return values are covered. It clearly states the scope and the nature of the scores. However, it omits any guidance on the input parameters, which is partially compensated by the descriptive schema property names but not fully.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It does not mention the 'limit' or 'invoice' parameters at all, leaving the agent to infer their semantics from the schema alone. This is a significant gap for a tool with a nested invoice object.

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's function: finding exact and near matches in the caller's own completed invoice history. It uses a specific verb ('Find') and a specific resource ('caller's own completed invoice history'), which distinguishes it from sibling tools like get_invoice_status or match_invoice.

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 on when to use the tool: when searching the caller's own completed invoice history. It also explicitly contrasts the output with fraud probability, guiding away from risk-score tools. However, it does not name alternative tools or state explicit exclusions, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It does reveal a critical input constraint (fingerprint over raw account number) and states a limitation (no ownership verification), but it does not explain the 'replace' semantics—whether it overwrites an existing baseline, is idempotent, or has any side effects. For a mutation tool, this is a moderate gap.

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

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

The description is two sentences long, with no redundant words. Key guidance is front-loaded ('Create or replace...') and the second sentence delivers a crucial security note. Every sentence earns its place.

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

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

For a simple 4-parameter, all-required tool with an output schema, the description is functional but not complete. It lacks when-to-use context beyond a vague 'customer-controlled' qualifier, and the replace behavior is left unspecified. However, the critical fingerprint instruction and the explicit non-goal add essential context, making it adequate for basic correct usage.

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

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

Schema description coverage is 0%, so the description must compensate. It adds critical meaning to account_fingerprint ('fingerprint, not a raw account number'), but provides nothing specific about vendor_reference, vendor_name, or remittance_reference. The parameter names are somewhat self-explanatory, but the description does not fully clarify their purpose or format, leaving the burden on the schema's basic types and patterns.

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

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

The description clearly states the action ('create or replace') and the resource ('customer-controlled remittance baseline'), which directly distinguishes it from sibling tools like check_remittance_change or match_remittance_advice. It also explicitly disambiguates from ownership verification, making the primary 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 provides explicit guidance on what to provide ('fingerprint, not raw account number') and what the tool does NOT do ('not bank-account ownership verification'), which helps choose it over alternatives. However, it does not explicitly name any sibling tools as alternatives or describe broader use cases, so it stops short of full when/when-not 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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It explicitly states 'This does not create or alter accounting records' and labels the checks as 'deterministic', giving strong transparency about side effects and predictability. It does not detail error behavior, but this is less critical for a non-mutating validation tool.

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

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

Two sentences, front-loaded with the main action and followed by a key side-effect disclaimer. No fluff or repetition; every word earns its place.

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

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

The presence of an output schema means return values need no explanation. The description covers the tool's purpose, when to use it, and its non-mutating nature. It is complete for a validation tool, though it could mention prerequisites (e.g., invoice extraction) or differentiate from specialized preflight siblings.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaning by indicating the types of checks performed (required-field, date, line-total) which implicitly points to the relevant fields within the nested 'invoice' object. However, it does not explicitly explain the structure or any parameter-specific semantics beyond that.

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 runs deterministic required-field, date, and line-total checks on an invoice before AP routing. It distinguishes itself from sibling analysis, extraction, risk-scoring, and mutation tools by emphasizing validation and non-alteration.

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

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

The phrase 'before AP routing' provides a clear context for when to use this tool. However, it does not explicitly name alternatives or exclusions (e.g., when to use preflight_erp_bill instead), so it lacks explicit negative guidance.

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