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

Annotations already comprehensively cover the behavioral profile: readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds minimal context beyond 'get the credit balance' and 'authenticated account'. Since the annotations carry the full safety burden, a 3 is appropriate — the description confirms the read-only nature but adds little new behavioral information.

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

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

A single sentence with zero waste. Every word earns its place: 'Get' states the operation, 'authenticated' clarifies the account source, 'credit balance' specifies the exact data returned. Nothing could be trimmed without losing meaning.

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

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

For a zero-parameter, read-only tool with comprehensive annotations, the description is fully adequate. An agent can confidently invoke this without any missing information. Though no output schema exists, the return value (credit balance) is self-evident from the 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?

With zero parameters and 100% schema coverage, the baseline is 4. The description adds the valuable clarification that no parameters are needed because the account is derived from authentication, which preempts any agent confusion about how the account is identified. This is genuinely helpful for a zero-parameter tool.

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

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

The description uses a specific verb (Get) and a precise resource ('the authenticated account's credit balance'). It clearly distinguishes this account-oriented tool from the 40+ sibling tools, which are all document-processing operations (parse, redact, classify, summarize). There is zero ambiguity about what this tool does.

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

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

While there is no explicit when-to-use or when-not-to-use statement, the purpose is so distinct from all siblings — every other tool operates on documents while this one queries account state — that usage context is unambiguous. The authentication qualifier ('authenticated account') implies it requires an authenticated session, but this is not stated as an explicit prerequisite.

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

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

Annotations already indicate this is not read-only, not idempotent, and not destructive. The description adds useful operational context beyond annotations: a batch limit of one hundred items, a cost/credit side effect, and the fact that each item returns a confidence score. This helps the agent anticipate real-world consequences.

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 and front-loads the most important information: batch size, taxonomy relationship, and cost. The sentence is a bit run-on, but every part contributes useful information without repetition 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 covers key operational details like the 100-item limit, cost, and confidence output, and the schema covers most parameters. It is incomplete because it does not differentiate the tool from closely related siblings and does not explain the optional instructions parameter, which lacks schema documentation.

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 high at 75%, and the description adds helpful examples of item types and the 100-item batch limit. However, it does not clarify the optional 'instructions' parameter or add much meaning beyond what the schema already provides for items, taxonomy, and multi.

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 indicates that the tool categorizes up to one hundred items against a user-supplied taxonomy and that it works for products, transactions, and tickets. It does not explicitly distinguish itself from sibling tools like parserail_classify, but the core purpose is specific and understandable.

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 'Up to a hundred items ... in one call' implies this is for batch categorization, and 'Costs credits from the account wallet' signals a cost consideration. However, there is no explicit guidance about when to choose this over parserail_classify, parserail_match, or other closely related sibling tools.

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

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

The description discloses that the tool 'costs credits from the account wallet,' a resource-consumption side effect that the annotations do not cover (they only state readOnlyHint=false, which implies mutation but not cost). This is genuinely valuable behavioral context beyond the structured annotations and directly affects whether an agent should invoke it. It could add more (e.g., persistence or irreversibility), but the cost disclosure is a strong addition.

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 with no filler. The core purpose is front-loaded, and the credit-cost caveat is appended efficiently. It earns a 4 for being tight, though the brevity leaves out parameter and usage guidance that the tool needs.

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

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

This is a complex tool (5 parameters, a nested transaction object, an enum, no output schema, sparse annotations), so the description carries a heavy burden. It lists four output types, which helps the agent know what to expect, but it omits output structure, parameter semantics, and usage context. For a tool with no output schema and 20% parameter coverage, this is 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 only 20%, with just 'reason' documented. The description does not compensate: it refers generically to 'dispute details' without explaining context, network, evidence, or the transaction object. The network enum is especially important because reason codes vary by card network, yet nothing in the description maps inputs to the stated outputs. With coverage this low, the description should have explained parameters and did not.

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 what the tool produces: given dispute details it generates a representment narrative, evidence checklist, reason code, and win-likelihood. This is a specific transformation that distinguishes it from siblings (e.g., parserail_fraud_flag handles fraud flagging, not representment). It loses a point because the arrow notation ('Dispute details →') is informal and omits an explicit verb for the operation.

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

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

No guidance is given on when to invoke this tool versus the many parserail siblings. There is no mention of when a chargeback representment is needed, no exclusions (e.g., 'not for first-time disputes'), and no alternative tools named. The agent is left to infer the use case entirely from the name.

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

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

The description adds a useful behavioral note—'Costs credits from the account wallet'—and names the output fields. Annotations already cover the read-only/destructive profile, so the description does not need to restate that; it could still say more about model behavior or the meaning of 'route'.

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, both purposeful: the first states the action and outputs, the second adds cost. The list in the first sentence is slightly awkward and ambiguous, but there is no dead weight.

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 classification tool with four parameters and no output schema, the description gives the core inputs, output shape, and credit cost. However, missing sibling differentiation and the unexplained `instructions` parameter leave real gaps for an agent selecting and invoking 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?

Schema description coverage is only 25% (multi is the sole documented parameter). The description adds that labels form the caller's taxonomy, but it never explains the `instructions` parameter, and `text` remains implicit; this does not adequately compensate for the undocumented 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 names the action ('Route or tag') and resource ('text'), and clarifies that it uses a caller-supplied taxonomy and returns a label, confidence, and rationale. It does not explicitly differentiate from the similar sibling parserail_categorize, so it stops short of a 5.

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

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

No usage guidance or alternative tools are mentioned. 'Against your own taxonomy' hints that it fits custom classification needs, but it never states when to choose this over parserail_categorize, parserail_triage, or other classification-adjacent siblings.

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

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

The description discloses that it costs credits from the account wallet, a behavioral trait not present in annotations (annotations only state readOnlyHint false, openWorldHint true, etc.). This adds valuable transparency about side effects. It does not contradict annotations; the cost is consistent with readOnlyHint false implying 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 sentences: the first states the core function and outcome, the second states the cost. It is front-loaded with the purpose and contains no superfluous words. Perfectly concise and easy to parse.

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 there is no output schema, the description gives a hint of the output ('every material change, what it means, and the risk it carries') and covers the cost. It does not explain return format or detailed behavior, but for a comparison tool whose inputs are well-specified in the schema, it is sufficiently complete. The cost warning is an important addition.

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 100%, with each property (a and b) described as earlier/later version. The tool description adds the phrase 'two versions' which is already implicit in the schema. It does not add meaningful parameter semantics beyond the schema, so baseline 3 is appropriate.

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

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

The description explicitly states the tool compares two versions of a contract/document and identifies material changes with meaning and risk. This is a specific verb+resource (compare versions) and clearly distinguishes from all siblings, none of which mention comparison.

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

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

The purpose implies it should be used when two versions of a document need comparison, but it does not explicitly state when to use versus alternatives, nor does it mention exclusions or direct references to sibling tools. The usage context is 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?

Annotations already provide read-only/destructive/idempotent hints, and the description adds a meaningful side-effect disclosure: 'Costs credits from the account wallet.' This goes beyond the annotations and tells the agent that invoking the tool consumes wallet funds. It does not detail processing time, file-size limits, or error behavior, but the added credit-cost context is valuable.

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 entire description is one compact sentence with no filler. It front-loads the tool's output fields before including the credit-cost warning. Every part earns its place, and the telegraphic arrow style keeps it highly scannable.

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

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

With no output schema, the description usefully lists the expected result fields, so an agent knows what the tool produces. The credit-cost behavior is also included. It does not explain input precedence when multiple fields are supplied or describe an exact output format, but for a straightforward contract-analysis tool with fully documented parameters, the description 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 100%, so the baseline is 3. The description does not add any parameter-specific meaning; it only says 'A contract' generically. The schema already adequately documents text, fileUrl, fileBase64, and fileMimeType, so no compensating explanation is needed.

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

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

The description states a specific resource ('contract') and enumerates the extracted fields: parties, effective date, term, renewal, governing law, obligations, and risk clauses. The arrow notation implies analysis/extraction, though no explicit verb appears. It distinguishes from sibling tools by being contract-specific, though it does not name a sibling alternative.

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

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

There is no guidance on when to use this tool versus sibling tools like parserail_parse, parserail_extract, or parserail_summarize. The only extra instruction is the warning that it costs credits, which is a cost caveat rather than a usage guideline. No conditions, prerequisites, or alternative-selection criteria are provided.

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

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

The description adds a significant behavioral fact beyond the annotations: 'Costs credits from the account wallet.' This warns the agent that the call has a financial side effect, which is not captured by readOnlyHint, idempotentHint, or destructiveHint. No statement contradicts the annotations.

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

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

Three short sentences, front-loaded with the essential image-to-output behavior, followed by the use case and cost warning. Every sentence earns its place and there is no filler.

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

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

Without an output schema and with 0% parameter coverage, the description should clarify how to provide the image and what each purpose value produces. It does not explain the relationship between the image object and imageUrl, nor how the four purpose enum values change the result, leaving an agent to guess at invocation details.

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

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

Schema description coverage is 0%, so the description must compensate, but it never mentions the purpose parameter, its enum values, or the imageUrl alternative. The output list ('alt text, a caption, tags, and any text found inside') loosely hints at what purpose may control, but an agent cannot determine how to choose alt vs product vs detailed or when to use imageUrl instead of image.

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

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

The description states the exact resource (an image) and the expected outputs (alt text, caption, tags, and any text inside the image). This makes it distinguishable from the many sibling parserail tools, none of which promise this specific image-description 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 phrase 'Accessibility and catalogs in one call' gives clear use-case context: generate alt text for accessibility or build image catalogs. It does not explicitly name alternatives or exclusions, but the intended context is clear enough for an agent to know when this tool applies.

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

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

Beyond the annotations (readOnlyHint false, openWorldHint true), the description discloses a significant behavioral trait: it costs credits from the account wallet. It also describes the escalation behavior ('escalating at the right pace and tone for how late it is'). This adds value beyond what annotations provide, though it doesn't mention idempotency or side effects on the invoice itself.

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

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

The description is two sentences with no redundant words. The main function is front-loaded ('An overdue invoice → a ready-to-send collection sequence'), and the credit cost is a crucial detail placed in the second sentence. Every phrase earns its place.

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

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

Given the complexity (nested objects, 5 parameters, no output schema), the description is insufficient. It does not explain what the returned collection sequence looks like, what 'steps' means, how 'tone' interacts with escalation, or what 'channel' options imply. The openWorldHint suggests possible side effects, but only the credit cost is mentioned. An agent would struggle to call this tool correctly without inspecting the schema, and the schema lacks descriptions for most fields.

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 only 20% schema description coverage, the description must compensate for undocumented parameters, but it does not. It mentions 'overdue' and 'how late it is', which loosely relates to daysOverdue and dueDate, but gives no detail on steps, channel, or tone values. The enums and integer steps are unexplained, leaving the agent to guess their semantics. The description provides high-level context but fails to clarify individual parameter meaning.

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

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

The description states a specific conversion: 'An overdue invoice → a ready-to-send collection sequence' with escalation based on lateness. It clearly identifies the resource (invoice) and the output (collection sequence), and is distinct from the many parserail siblings which focus on parsing or extraction. The credit cost is also mentioned, adding to purpose specificity.

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 (for overdue invoices) but does not explicitly mention alternatives or when not to use it. There is no comparison to sibling tools, though the name 'dunning' makes its niche clear. It lacks explicit conditions like 'use this only if invoice is overdue' or 'for other actions use X'.

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

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

Annotations already indicate non-read-only, non-idempotent behavior, and the description adds the key side effect: it costs credits from the account wallet. It also discloses the output shape, which supplements the minimal annotations. It does not mention failure or invalid-input behavior, but that is a minor gap for a simple enrichment 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 one compact, front-loaded sentence with no filler. The core transformation is stated first, and the cost warning is added as a relevant tail.

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 tool with two optional parameters and no output schema, the description covers the input trigger, output fields, and cost. It is slightly thin on parameter constraints and error behavior, so it is not fully complete, but it is sufficient for initial selection and invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify that the parameters correspond to a 'domain or work email,' but it does not explain expected formats, whether one parameter is required, or what happens if both are supplied.

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 transformation: a domain or work email becomes a structured company profile with named output fields (name, description, industry, HQ, size, links). It is specific about the resource, though it does not explicitly differentiate itself from nearby siblings like parserail_describe or parserail_research.

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 trigger condition is clear: use it when you have a domain or work email and want company firmographic data. It does not enumerate exclusions or explicitly name when to prefer an alternative, but the input-to-output mapping provides enough routing context.

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

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

Annotations already carry the safety profile (not read-only, not idempotent, open world), and the description adds genuinely new behavioral context: it 'costs credits from the account wallet' and returns 'typed values with confidence.' The cost disclosure is especially valuable because readOnlyHint=false alone would not tell an agent this operation has a wallet charge. No contradiction with annotations.

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

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

Three short sentences, each carrying a distinct fact: the extraction action, the typed-value return contract, and the cost. The core purpose is front-loaded in the first sentence and there is zero filler or repetition of what annotations already state.

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

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

With a flat 3-parameter schema, no output schema, and safety covered by annotations, the description addresses purpose, cost, and output flavor ('typed values with confidence'). It stops short of describing the exact response shape or behavior on unresolvable fields, but those gaps are minor given 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?

Schema coverage is 67%, and the required 'text' property has no schema description; the description compensates by defining it as 'any block of text.' The phrase 'you name the fields' clarifies that the enum-less 'fields' array holds arbitrary user-chosen keys, which is meaning beyond the schema's 'The field names to pull out.' The 'instructions' param is already self-described ('Optional extra guidance'), so no prose needed.

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

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

The description names a specific action ('Pull... out'), a concrete resource ('a field set you define' from 'any block of text'), and the core contract ('you get typed values with confidence'). It clearly goes beyond the tautological title 'Field extraction' by explaining the user-defined schema model. However, it never names any sibling (e.g., parserail_parse, parserail_invoice) to state what it is not, so sibling differentiation is implicit rather than explicit.

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

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

The phrase 'any block of text' combined with 'a field set you define' implies the general-purpose case: use this when you need custom fields not covered by a domain-specific tool. But the description never states when not to use it or points to alternatives among the 41 siblings, so the routing guidance is left mostly to inference.

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

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

The description adds an important side effect not captured by the annotations: 'Costs credits from the account wallet.' It also frames the output as advisory checks rather than executed actions. This meaningfully supplements the readOnlyHint, openWorldHint, and destructiveHint annotations, though it does not cover auth/rate-limit details.

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

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

Two short sentences carry the entire payload: input, output, use context, and cost. The arrow-based formulation is front-loaded and efficient, with no filler or repetition of the tool name/title.

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 input, expected outputs (risk score, signals, checks), the pre-shipment context, and the cost implication. With only two parameters and no output schema, this is largely sufficient, though it does not spell out response format or edge cases around insufficient credits.

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

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

Schema description coverage is 100%, and the schema already documents that `order` can include whatever data is available and `context` carries store-level patterns. The description only restates 'an order or transaction in context' conceptually and does not add field-level detail beyond the schema.

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

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

The description clearly states the core transformation: an order/transaction plus context produces a risk score, the signals behind it, and checks to run before shipping. It is specific enough to distinguish fraud triage from general parsing tools, though it lacks an explicit verb and does not directly contrast with nearby siblings like parserail_chargeback.

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 you ship' gives a clear timing/context cue, implying this is for pre-shipment fraud triage. However, it does not name alternatives or state when not to use the tool, and with many similar siblings in the list, an agent must infer the selection 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the description does not need to repeat that. It adds valuable cost disclosure ('Costs credits from the account wallet') not present in annotations. It does not mention output format or failure behavior, but given the simple generation task and annotation coverage, this is a minor 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?

Three short sentences with no filler. The purpose is front-loaded, followed by use cases and cost. Every sentence adds value, and the structure is easy to scan.

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

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

For a simple tool with one required parameter, the description covers purpose, use cases, and cost. However, it lacks details on the output format (e.g., URL vs. base64) since there is no output schema, and it does not explicitly state that sufficient credits must be available. These gaps are minor given 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?

Schema description coverage is 67%, and the description adds no parameter-specific details beyond what the schema already provides. It only implies the prompt is the input; style and aspectRatio are not mentioned. Since coverage is not high, the description could have compensated but did not, so it stays at the baseline of 3.

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

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

The description clearly states 'A prompt → a production-ready image', which specifies the action (generate) and resource (image). It lists concrete use cases (marketing visuals, product scenes, brand imagery), and the sibling tools are all text-processing, so this tool's image-generation purpose is unambiguous.

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

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

The description gives clear context on when to use the tool (for marketing visuals, product scenes, consistent brand imagery). It does not explicitly state when not to use it or name alternatives, but the sibling list is dominated by text-processing tools, making the distinction implicit and sufficient for most agents.

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

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

The disclosure 'Costs credits from the account wallet' adds genuine beyond-annotation context about wallet consumption, which is the kind of practical behavioral trait the rubric rewards. Yet the description says nothing about failure modes, file-size limits, or behavior when multiple inputs are supplied. With annotations already covering the safety profile (destructiveHint=false), the added value earns a mid score.

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

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

The definition is compact and every clause carries content, but the main clause is an ungrammatical fragment ('An invoice, PDF, photo, or text, into vendor, dates...') with no main verb. The useful credit-cost note is placed second, but the broken syntax undermines the overall 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?

With no output schema, the description's field list (vendor, dates, PO refs, tax, totals, line items) is the only return-value guidance an agent receives, and it is adequate. Missing is any note about how to choose among the four optional inputs, whether they are mutually exclusive, or whether any input is required at all given that zero parameters are marked required.

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

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

Schema coverage is 100%, so all four parameters (text, fileUrl, fileBase64, fileMimeType) are already documented with descriptions. The description loosely maps accepted input types (PDF, photo, text) onto these parameters but adds no format constraints, mutual-exclusion rules, or preference guidance beyond what the schema provides.

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

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

The title 'Invoice extraction' supplies the verb, and the description names the resource (invoices, PDFs, photos, text) and the extracted fields (vendor, dates, PO refs, tax, totals, clean line items). However, the description is a verb-less fragment — 'An invoice, PDF, photo, or text, into...' — and does nothing to distinguish this from overlapping siblings like parserail_extract, parserail_receipt, or parserail_statement.

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 offered for when to choose this tool over its 40+ siblings, despite obvious overlap with parserail_receipt, parserail_statement, and parserail_contract. The description only lists accepted input types; it never states exclusions, prerequisites, or alternative tool names, so an agent cannot learn selection criteria from it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, and the description neither contradicts nor merely restates them. It adds meaningful behavioral nuance: results are 'statute-verified conservative safe floors,' so they may understate rather than overstate permissible rates, and invocation is free. This is useful context beyond what the structured annotations provide.

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

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

The description is short and front-loaded with the core purpose, immediately followed by the useful data-quality caveat. The phrase 'Free, costs no credits' is slightly redundant, but the overall structure is efficient and avoids unnecessary detail. Nearly every clause 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 one-optional-parameter lookup with no output schema, the description states what will be returned—the ceiling and the statute cite—and includes the relevant caveat about conservative floors. The all-51-rows default is already covered by the schema. No significant missing context prevents an agent from using this tool correctly.

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

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

The single optional 'state' parameter is fully documented in the input schema, including the two-letter USPS format and the omit-for-all-51-rows behavior. The description adds no additional parameter-level meaning beyond reinforcing that the lookup is state-scoped. With 100% schema coverage, 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 opens with a concrete action, 'Look up,' and specifies the exact resource: the maximum late-fee/interest rate a US state allows on commercial B2B invoices, along with the statute cite. It also adds 'statute-verified conservative safe floors,' which helps distinguish this from a generic legal or calculation tool. Compared with siblings like parserail_dunning or parserail_extract, the scope is unmistakable.

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 conveys when this tool is appropriate: when an agent needs a state's allowed commercial late-fee ceiling or statute citation. It does not explicitly name alternative tools or state when not to use it, but the commercial/B2B qualifier implicitly rules out consumer or personal contexts. The 'free, costs no credits' note also helps agents decide whether to invoke it.

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

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

Annotations include readOnlyHint=false, openWorldHint=true, and destructiveHint=false, but the description adds a critical behavioral fact: 'Costs credits from the account wallet.' It also discloses output elements 'confidence and reasoning' not present in annotations. No contradiction exists; the description supplements the annotation information.

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 core purpose front-loaded in an arrow notation ('Two record sets → which rows are the same real-world thing'). Every sentence contributes: purpose, fuzzy-handling capability, and cost. No filler or redundancy.

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

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

For a tool with no output schema, the description covers purpose, fuzzy matching behavior, cost, and mentions output components (confidence, reasoning). It does not specify the exact return shape, but the agent has enough to invoke and interpret the result. Given the moderate complexity, this 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 100%: parameters a, b, and keys each have descriptions ('First record set', 'Second record set', 'Fields that most identify an entity'). The description's 'Fuzzy names, typos, aliases handled' adds marginal context about how keys should be chosen, but does not significantly deepen parameter meaning beyond the schema.

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

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

The description states a specific verb and resource: 'Two record sets → which rows are the same real-world thing'. This clearly identifies an entity-resolution action and distinguishes it from generic operations like parserail_compare or parserail_classify. The mention of 'confidence and reasoning' further clarifies the output nature.

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 by noting 'Fuzzy names, typos, aliases handled', which implies when to use the tool (for messy, approximate matching). It does not explicitly name alternatives or when-not conditions, but the context is clear enough for an agent to select it over exact-match or comparison 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?

The description and schema reveal genuinely destructive behavior: 'forget' can delete a memory and omitting id with a namespace can wipe it. This contradicts annotations.destructiveHint=false, which tells the agent the tool is non-destructive. Per the rubric, this contradiction forces a score of 1 despite the description adding useful context about credit cost and no vector DB.

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

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

Two short sentences front-load the actions and then add the two differentiators that matter operationally: no vector DB to run and wallet credit cost. Every clause earns its place and there is no filler.

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

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

For a 7-parameter tool, the description plus the fully-covered input schema is mostly sufficient, but the description does not characterize the result of a search/recall payload, and there is no output schema. It also relies entirely on the schema for the important namespace-wipe behavior, so a slightly more complete op-level description would round it out.

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

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

Schema description coverage is 100%, with each parameter tagged by operation (store/search/forget), defaults, and enum values. The description adds no parameter-specific detail beyond the action names, so the baseline 3 is appropriate.

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

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

Description enumerates three concrete actions (store, search, forget) on a specific resource (agent memories) and adds namespace scoping ('semantic recall on your own namespace'). This distinguishes it from the document-processing siblings in the parserail family, so an agent won't confuse it with parserail_summarize, parserail_extract, or similar 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?

It gives clear context: memories are per-agent, recalled semantically, and require no vector DB, so an agent can infer when to use this over other parserail tools. It does not explicitly state when not to use it or name an alternative memory tool, but none appears in the sibling list, so exclusions are less critical.

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

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

Beyond annotations, the description discloses that the operation consumes wallet credits, a non-obvious side effect not visible in readOnlyHint/destructiveHint. It also gives a compact picture of the output content, though it does not cover failure modes or prerequisites.

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

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

Two short sentences provide the core behavior and a cost warning with no filler. The output components are listed compactly and the credit-cost note is separated into its own sentence.

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

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

With no output schema, the description compensates by naming the output sections, and it flags the wallet-cost behavior. The main missing piece is the meaning/usage of the optional `attendees` input, but the required path is clear enough for correct invocation.

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

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

Schema coverage is only 50%: the optional `attendees` parameter has no schema description, and the tool description does not explain how it is used or whether it maps to action-item owners. The description adds no parameter meaning beyond the schema's 'The meeting transcript.'

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

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

The description identifies a specific transformation ('meeting transcript → clean minutes') and enumerates recognizable minutes components (summary, decisions, action items with owners, open questions). This clearly separates it from sibling processing tools such as parserail_summarize or parserail_transcribe.

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 use case: pass a meeting transcript to receive minutes. However, it never explicitly says when to prefer this over parserail_summarize or other alternatives, nor does it state exclusions such as 'use parserail_transcribe for audio input.'

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

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

Beyond annotations (readOnlyHint=false, openWorldHint=true, etc.), the description adds that the call costs credits from the account wallet and discloses the output includes categories and excerpts. This provides useful behavioral context not present in annotations, though it does not detail side effects or error handling.

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, well-structured sentence that front-loads the core purpose and includes the cost implication at the end. No unnecessary words or repetition; it earns every word.

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 complexity (4 params, nested object, no output schema), the description is incomplete. It mentions the decision output and categories/excerpts but does not specify required inputs, behavior when both text and image are provided, or error handling. The cost note is useful but the overall context is not fully specified.

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

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

Schema description coverage is only 25% (only 'policy' has a description). The description says 'Text or an image' but does not clarify the relationship between text, image, and imageUrl, nor whether any are required. It fails to compensate for the lack of parameter documentation in the schema, leaving significant ambiguity.

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

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

The description states a specific verb ('moderate') and resource ('text or an image') against a policy, with a clear output (allow/review/block) and supplementary data (categories and excerpts). It clearly distinguishes itself from siblings like parserail_classify by emphasizing policy-based decisions rather than generic classification.

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 when content needs policy-based moderation, but it does not explicitly state when to use it versus alternatives like parserail_classify or parserail_sentiment. No when-not-to-use guidance is provided, though the purpose is clear enough for an agent to infer the primary use case.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds valuable behavioral context: it produces a change log of every fix, and it costs credits from the account wallet. It also implies transformation (messy → clean) which aligns with readOnlyHint=false. No contradiction. The credit cost is a behavioral trait not in annotations, adding transparency.

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

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

The description is a single sentence that front-loads the core transformation and includes the change log and credit cost. It's concise and every phrase earns its place. Slightly more could be said about when to use it, but as a concise description it's effective.

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 transformation tool with no output schema, the description covers the main behavior and cost, but doesn't mention return format details (e.g., what the change log looks like) or edge cases. The annotations cover safety profile. It's adequate but has gaps: no output schema means the agent doesn't know the response structure, and the description doesn't compensate 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 100%, so the schema already documents all three parameters. The description adds the concept of 'canonical rows' and 'change log' but doesn't add parameter-specific meaning beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description states a specific verb ('normalize') and resource ('messy records → clean canonical rows'), and mentions a change log. It distinguishes itself from siblings like parserail_redact or parserail_extract by focusing on normalization with a change log. However, it doesn't explicitly name a sibling alternative, so it's clear but not fully differentiated.

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

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

The description implies usage: use when you have messy records and want clean canonical rows. It doesn't explicitly state when not to use it or name alternatives. The 'Costs credits from the account wallet' is a usage consideration but not a when-to-use guideline. Overall, usage context is implied but not 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?

The description adds a material behavior not visible in annotations: 'Costs credits from the account wallet.' It also communicates that output is personalized based on lead fit, which is useful beyond the openWorldHint flag. Nothing contradicts the annotations.

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, scannable sentence that conveys the core operation and a key side-effect. There is no filler and the main information is front-loaded.

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

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

With five parameters, including an undocumented nested sender object and an enum channel, plus no output schema, the description leaves significant gaps. It never explains what steps/sender/channel mean or what the sequence output looks like, so the definition is not complete enough for a correct call.

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

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

Schema coverage is only 40%: lead and product have descriptions, but steps, sender, and channel are undocumented. The description explains lead ('enriched profile') and product ('what you sell and value proposition') but does nothing to clarify the missing parameters, so it only partially compensates.

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 explains the transformation: an enriched lead plus product information produces a personalized outreach sequence. It goes beyond the title 'Outreach sequence' and distinguishes this as the outreach-specific tool among the parserail siblings, though it does not explicitly contrast with any alternative.

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

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

The arrow notation and 'what you sell' imply this is used when an agent has an enriched lead and a value proposition and needs personalized outreach. However, it gives no explicit guidance on when to choose this over a sibling tool, no exclusions, and no conditions for channel/steps.

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

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

Annotations already carry the readOnly/destructive/idempotent profile, and the description adds useful behavioral context beyond them: it costs wallet credits and produces validated output. This is a meaningful disclosure, and it does not contradict any annotation.

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

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

Two short, information-dense sentences with no filler. The scope is front-loaded, and the wallet-cost warning is a necessary behavioral note that earns its place.

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

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

The description is minimally viable: it names inputs, output, and cost. However, with five optional parameters and no output schema, it omits how to choose among input sources and what the resolved JSON contains, leaving an agent to infer call structure from the schema alone.

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

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

Schema description coverage is 100%, so the parameter meanings are already fully documented. The description's mention of document types and file formats adds breadth but no parameter-level guidance such as exactly one of text, fileUrl, or fileBase64 being required.

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

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

The description clearly specifies the resource (invoice, receipt, EOB, ERA, COI, PDF/image) and the outcome (structured, validated JSON), so an agent can tell what the tool does. However, the verb is implicit rather than explicit, and it does not distinguish itself from specialist siblings like parserail_invoice or parserail_receipt.

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

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

There is no when-to-use or when-not-to-use guidance. With dozens of sibling tools, the agent receives no help deciding between this generic parser and specialized alternatives, nor is there any instruction about which input mode to prefer.

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

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

The description directly discloses that invoking the tool costs credits from the account wallet, a non-obvious behavioral side effect beyond the annotations' readOnlyHint=false and idempotentHint=false. It also promises that discrepancies are both flagged and sized, giving a concrete sense of the result behavior. With annotations already covering safety, this additional context earns a solid score.

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

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

Two sentences, zero filler: the first delivers the core match logic and output categories, and the second flags the wallet cost. The key resource trio is front-loaded, so an agent can immediately tell what the tool acts on.

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 top-level outcomes and side effects, which is necessary given there is no output schema. However, it leaves an important ambiguity: the receipt is optional in the schema, yet the description frames a three-way match as if receipt is always part of the comparison, without explaining what happens when it is omitted or how tolerancePct affects the outcome. For a tool with no output schema, these gaps matter even though the core behavior is clear.

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

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

The input schema already documents all four parameters with 100% coverage, including the optional receipt and tolerance default. The description does not add parameter-level semantics, but it does establish the conceptual roles of invoice, PO, and receipt in the match. A baseline 3 is appropriate because the schema carries the burden.

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 arrow phrasing clearly communicates that the tool compares the invoice, PO, and receipt and classifies the result as matched, partial, or mismatched, with discrepancies reported. It is distinguishable from generic siblings like parserail_match because it names a concrete three-way comparison and result categories. However, it lacks an explicit action verb like 'compare' or 'reconcile' and does not name alternatives.

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

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

The description gives no explicit guidance on when to choose this tool over siblings such as parserail_match or parserail_compare. The only usage signal is the implicit one in the title and required parameters, which isn't enough for an agent facing many similar tools. No exclusion or fallback behavior (e.g., when receipt is omitted) is 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?

Annotations indicate this is a write operation (readOnlyHint=false) that is not idempotent and not destructive, and is openWorld. The description adds the credit cost from the wallet, which is useful for budgeting. However, it doesn't detail other behavioral aspects like credit consumption per call or whether it modifies any state, though the openWorld hint already signals potential external 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 concise and front-loaded with the core value proposition, then mentions the cost in a single additional sentence. It avoids fluff and is easy to scan.

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

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

Given the presence of a nested object and an enum, the description covers the main inputs and outputs but omits details like the exact structure of the output (e.g., how many bullets or titles), any formatting constraints, or credit cost amount. It is adequate for a deployable tool but leaves some gaps that could affect correct invocation.

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

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

The description mentions 'specs and an audience' and 'per channel', which aligns with the product object and channel parameter, but it doesn't add meaning beyond what the schema provides. Since schema description coverage is 0%, the description already covers the key conceptual parameters but doesn't explain nuances like the 'keywords' field or the required 'name', making 3 a reasonable baseline.

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

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

The description states a clear verb ('generate') and resource ('product copy') with specific output types (titles, bullets, description, SEO keywords) and the audience requirement. It is distinct from siblings which mostly focus on parsing or analysis rather than copy generation, though it doesn't explicitly name an alternative.

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

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

The description implies usage through the input requirements (specs and audience) and channel options, and notes the cost implication. However, it does not state when to use this tool over alternatives (e.g., parserail_rewrite for rewriting existing copy) or when not to use it, lacking explicit 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?

The description adds valuable behavioral context beyond annotations: it explicitly states that the tool 'costs credits from the account wallet', which is a critical side effect not covered by the annotations. It also describes the output content (itemized, assumptions, scope notes). Annotations already indicate non-read-only and non-destructive, but the cost disclosure is additional. This is a meaningful enhancement, though not exhaustive (e.g., no mention of execution time 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 a single, tightly worded sentence that front-loads the core transformation (job description + rates → quote) and adds the crucial cost note. There is zero waste; every word contributes. It is well-structured and concise.

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 four parameters and no output schema, the description provides essential context: what the output includes (itemized, assumptions, scope notes) and the cost implication. It does not describe the currency parameter's behavior or how pastQuotes influences output, but these are secondary given the schema's own descriptions. The description is sufficient for an agent to correctly invoke the tool in most scenarios, though a little more detail on optional parameters would push it to a 5.

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 75% (job, rates, pastQuotes all have descriptions; currency lacks one). The description highlights 'job description plus your rates' aligning with the main parameters but adds no additional semantics for the parameters themselves. It doesn't clarify currency format or how pastQuotes are used. Since the schema already covers most parameters and the description repeats rather than enriches, 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 clearly states the tool's function: taking a job description and rates to produce an itemized, professional quote. It uses a specific verb ('→' implying generation) and a clear resource (quote). It is distinct from siblings like invoice or contract because it explicitly mentions quotes, and the phrasing 'itemized, professional quote with assumptions and scope notes' makes the output concrete. No tautology; it adds meaning beyond the title.

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 use case: when you have a job description and rates, generate a quote. It provides clear context but does not explicitly mention alternatives or exclusions (e.g., when to use invoice instead). Since the context is unambiguous and no misleading guidance, it earns a 4 rather than a 5 for lacking explicit 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?

The description transparently discloses the cost behavior: 'Costs credits from the account wallet.' This is meaningful beyond the annotations, which only state readOnlyHint=false. Since annotations don't cover billing side effects, this addition provides important 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 short and includes two useful pieces of information: output categories and cost. However, the first sentence is grammatically awkward and missing a verb ('A receipt into merchant...'), which hurts clarity and polish.

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, output fields, domain context, and cost, which is decent for a simple extraction tool. With no output schema, it does not describe return format, and it lacks guidance on choosing among the four input options or differentiating from invoice/statement extraction 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 100%, so the parameters text, fileUrl, fileBase64, and fileMimeType are already fully documented in the schema. The description adds no parameter-specific meaning beyond listing output fields, so the baseline 3 applies.

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

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

The description clearly identifies the resource (receipt) and the output categories (merchant, items, totals, payment method, expense category), and the title reinforces 'Receipt extraction'. However, the first sentence lacks an explicit verb like 'parses' or 'extracts', making it grammatically incomplete and slightly ambiguous.

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 'built for expense flows' provides useful usage context, implying this tool should be used when processing receipts for expense reporting. However, it does not mention alternatives among the many parserail siblings or provide when-not-to-use guidance.

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

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

The description adds a behavioral detail not present in annotations: 'Costs credits from the account wallet.' It also clarifies the operation as 'detect and strip,' consistent with readOnlyHint=false. No contradiction with annotations exists.

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

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

The description is a single sentence that front-loads the action and resource, then adds the cost detail. Every clause is informative with no filler or redundancy.

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

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

With no output schema, the description should indicate the return value; 'strip... from text' implies a redacted text output, but placeholder behavior and return format are unspecified. The irreversible nature of redaction is not mentioned, which could be a gap for a redaction tool.

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

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

Schema description coverage is only 33% (only 'types' has a description). The description partially compensates by listing example entity types, but it does not explain 'text' or 'placeholder' semantics beyond their names. Given the low coverage, more parameter guidance would be expected.

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

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

The description states a specific verb ('detect and strip') and resource ('text'), listing concrete entity types (names, emails, phones, SSNs, cards, PHI). This clearly differentiates it from sibling tools like parse or extract, making its purpose immediately obvious.

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 you store or log it' provides a clear usage context, implying when redaction should be applied. However, it does not explicitly mention alternatives or exclusions, though the specific use case helps distinguish it from other text-processing 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?

The description discloses a meaningful behavioral trait beyond the annotations: 'Costs credits from the account wallet.' It also states that the output includes both a reply and an internal note, which is useful context. No contradiction with the annotations was found.

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

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

The description is one compact sentence that front-loads the core transformation and output, then adds the important credit-cost caveat. Every phrase earns its place and there is no redundant restating of the title or schema.

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

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

The description is adequate for a five-parameter drafting tool: it names the input type, indicates the output shape, and flags a cost side effect. However, with no output schema and no mention of how the internal note is returned or what happens on low wallet balance, some operational detail is missing.

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?

Input schema coverage is 80%, so the baseline is 3. The description adds little beyond mapping 'thread plus context' and 'right tone' to the corresponding parameters, and it does not clarify the meaning or defaults for goal or senderName.

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

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

The description clearly identifies the tool's function: turning a customer thread plus context into a ready-to-send reply with the right tone and an internal agent note. It is distinct from review or rewrite tools by emphasizing 'ready-to-send' drafting, though it does not explicitly compare itself to any sibling.

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

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

The description implies the tool should be used when a reply draft is needed from a thread and context, but it gives no explicit when-to-use or when-not-to-use guidance. It also does not mention alternatives like review_reply or rewrite for follow-up steps, leaving the selection logic mostly to inference.

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

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

Annotations only indicate readOnlyHint=false, so the description must clarify side effects. It discloses that it performs real web work and costs credits from the account wallet, which is critical behavioral context. However, it does not mention whether results are cached, how long it takes, or any rate limits, but the disclosed cost and web access are valuable beyond annotations.

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 value proposition and immediately distinguishing features. Every clause earns its place, with no fluff or redundancy.

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

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

For a research tool with 3 parameters and no output schema, the description covers the key operational facts: what it produces (a brief), how it works (web research), and the cost implication. It doesn't specify asynchronous behavior or potential delays, but given the tool's unique role among siblings and the schema's completeness, it is sufficiently complete for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no extra parameter-level details, merely echoing the 'focus' concept. Per the baseline for high schema coverage, a 3 is appropriate.

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

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

The description clearly states the tool converts a company or topic into a multi-source, citation-backed brief, covering what it is, recent changes, and what matters. It explicitly distinguishes itself as 'Real web work', setting it apart from the parsing-oriented sibling tools like parserail_parse and parserail_extract.

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 use for research (vs. parsing local files) but does not explicitly name alternatives or state when not to use it. It gives context ('Real web work', costs credits) but leaves the selection decision to the agent without direct comparison to sibling tools.

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

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

The description adds a key behavioral detail not present in annotations: it costs credits from the account wallet. Annotations already indicate readOnlyHint=false (non-read-only) and destructiveHint=false, so the description does not contradict them. However, it does not disclose other behavioral aspects such as whether the input is retained, how long processing takes, or any side effects beyond the credit cost. Given the annotations cover the basic safety profile, the cost disclosure is a useful addition but the description is still thin on 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 a single sentence (with a colon) plus a short cost note. It front-loads the primary purpose and output fields, making the core function immediately visible. The grammar is slightly awkward ('A resume or CV into...'), but the text is efficient and has no filler. It earns a 4 for being concise and well-structured, losing a point for the grammatical flaw.

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

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

The description lists the output fields (contact, skills, experience, education, links), which is helpful given there is no output schema. However, it does not mention that the tool accepts three mutually exclusive input sources (text, fileUrl, fileBase64) or that at least one is needed – the schema marks all as optional, so an agent might not know to supply one. It also does not mention any error handling or limitations. The credit cost is disclosed, which is a plus. Overall, the description covers the 'what' but misses the 'how to invoke correctly' in terms of input selection, making it incomplete for a tool with no required parameters and no output schema.

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

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

Schema coverage is 100% – all four parameters (text, fileUrl, fileBase64, fileMimeType) have descriptions in the schema. The tool description adds no additional parameter-level guidance, such as when to prefer text over fileUrl or how they interact. Since the schema already documents each parameter, the description does not need to repeat that, but it also doesn't add clarifying notes (e.g., 'exactly one of text, fileUrl, or fileBase64 should be provided'). Baseline 3 is appropriate because the schema does the heavy lifting and the description adds nothing beyond it.

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

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

The description clearly states the resource (resume/CV) and the output (structured candidate profile with contact, skills, experience, education, links). It implicitly indicates a parsing/transformation action, though the missing explicit verb ('parse' or 'convert') and the awkward phrasing 'A resume or CV into...' slightly reduce clarity. It differentiates from generic siblings like parserail_parse or parserail_extract by being resume-specific.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or conditions that would help an agent choose between parserail_resume and other parsing tools like parserail_parse, parserail_extract, or parserail_structure. The only hint is the resume-specific output, but no explicit 'use this when...' 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?

Beyond the annotations, the description adds a concrete, important side effect: 'costs credits from the account wallet.' It also discloses that the result includes triage output (issues to log and escalation need), which is useful since readOnlyHint is false and no output schema exists.

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

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

Two short sentences with no filler; the transformation is front-loaded and the cost warning earns its place at the end. Every word adds information.

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

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

The description names the key outputs (public response, issues to log, escalation flag), warns about credit cost, and the schema covers the remaining parameters. It is not exhaustive—no output format or when-not-to-use guidance—but it is complete enough for selection and basic invocation.

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

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

Schema description coverage is 75%, so the schema already documents rating, review, and resolution. The description does not add meaning to individual parameters or mention how business.voice/name interact with 'brand-safe,' so it does not improve on the schema baseline.

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 an arrow to convey a clear transformation: a customer review becomes a brand-safe public response, issues to log, and an escalation flag. It is specific to review replies and distinct from generic siblings like parserail_reply, though it never names an alternative or uses an explicit verb like 'generate'.

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 'a customer review → a brand-safe public response' gives clear context for when to use the tool: when a user has review text and needs a public reply. It does not state exclusions or alternatives, but the review-specific framing makes the intended use unambiguous.

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

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

The description adds real behavioral context beyond annotations: 'Costs credits from the account wallet' discloses a monetary side effect, and 'get the rewrite and what changed' discloses the response shape, which matters since no output schema exists. This is consistent with readOnlyHint:false and idempotentHint:false. No contradiction.

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

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

Three tight sentences, front-loaded with purpose, using compact arrow notation. Every sentence earns its place: the transformation, the input mechanism, and the cost side effect. No filler or redundant schema restatement.

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 moderate-complexity generation tool with no output schema, the description covers the essential call contract: what goes in, how to specify voice, what comes back, and the cost implication. It falls short only on the undocumented goal/length/audience parameters, which the sparse schema leaves unexplained.

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

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

Schema description coverage is only 40%, so the description must compensate for the undocumented text, length, and audience parameters, but it does not. It only restates the voice parameter ('describe the voice or paste a sample'), which the schema already documents, adding no new meaning for goal, length, audience, or text.

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

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

The description states a specific verb-resource pair ('Any copy → your brand voice') with an explicit input-output contract: copy in, brand-voice rewrite plus change log out. It clearly distinguishes itself from the sibling family, which is dominated by analysis tools (parse, extract, summarize, classify), by being a generation/transformation tool.

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 says 'Any copy' but gives no when-to-use vs when-not-to-use guidance. It never names alternatives like parserail_reply, parserail_outreach, or parserail_product_copy, which are also generation tools an agent could confuse it with. There is no exclusion criteria or routing hint beyond the cost warning.

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

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

Annotations already indicate readOnlyHint=false and openWorldHint=true, and the description adds meaningful behavior details: the operation is web-grounded and consumes credits from the account wallet. This goes beyond the structured annotations and alerts the agent to a cost implication.

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 compact sentence communicates the transformation, the web-grounded nature, the evidence-based output, and the credit cost. Every element earns its place and the key input-to-output relationship is front-loaded.

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

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

For a two-parameter tool with no output schema, the description adequately explains both the expected output (qualification verdict with evidence) and an important side effect (credit cost). The agent has enough information to call the tool correctly and interpret its result.

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

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

The input schema already has 100% coverage, with clear descriptions for both 'lead' and 'criteria'. The description only restates the conceptual role of the parameters ('A lead plus your ICP criteria') without adding format, syntax, or additional constraints, so it adds no semantic value beyond the schema.

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

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

The description clearly defines the input (a lead plus ICP criteria), the operation (screening/qualification), and the output (a web-grounded qualification verdict with evidence for and against). This distinguishes it from sibling tools like parserail_classify or parserail_sentiment by specifying the qualification purpose and evidence-based result.

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

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

The description gives clear context for when to use the tool: when the agent has a lead and ICP criteria and needs a qualification verdict. It does not explicitly name alternatives or exclusions, but the purpose is specific enough that an agent can infer appropriate usage.

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

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

The description discloses that the tool costs credits from the account wallet, which is valuable behavioral context beyond the annotations. The annotations already cover safety and idempotence, and nothing in the description contradicts them.

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

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

Two sentences with no filler. The first sentence front-loads the purpose and outputs; the second adds an important operational cost warning. Every word earns its place.

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

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

For a simple two-parameter tool with no output schema, the description covers what the tool does, what inputs it expects, what outputs it produces, and a key operational constraint. It could add the score's scale or format, but the description is substantially complete for selection and invocation.

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

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

Schema coverage is only 50%: the required 'text' parameter has no schema description, and the description helps by narrowing it to reviews or support messages. The optional 'aspects' parameter is documented in the schema and echoed by 'per-aspect breakdown,' but no length limits, examples, or formatting guidance are provided.

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

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

The description uses a specific verb ('Turn ... into') and names concrete outputs: a sentiment score, per-aspect breakdown, and driving themes. It clearly identifies the input type (review or support message), and these outputs distinguish it from sibling tools like parserail_classify or parserail_summarize.

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

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

The description gives clear usage context: use this for sentiment analysis of reviews or support messages. It does not explicitly name alternatives or exclusion cases, so it misses the top bar, but the intended use is unambiguous.

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

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

The description discloses a meaningful behavioral consequence beyond annotations: it costs credits from the account wallet, which is important for an agent deciding whether to invoke it. It also indicates the output is embeddable audio. Annotations are readOnlyHint=false, consistent with a side-effecting operation, and there is no contradiction.

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

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

The description is compact and front-loaded: the core transformation is stated first, followed by use cases and a key side effect. Every sentence adds value and there is 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?

For a simple three-parameter TTS tool, the description covers the essential context: input text, output audio, example uses, and cost. There is no output schema, so a bit more detail about the return format (e.g., audio URL or file) could help, but the 'ready to embed' phrase partially covers this.

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

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

Schema description coverage is only 33%, with only the voice parameter described in the schema. The description does not explain pace or text semantics, and while 'text' is obvious, the tool description adds no guidance on how parameters affect output. The low coverage requires more compensation than this provides.

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

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

The description clearly defines a specific function: converting text into natural speech audio, with concrete example use cases (voice notes, IVR lines, narration). This distinguishes it from the sibling parserail tools, which focus on text processing, parsing, and analysis rather than audio generation.

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: when spoken audio is needed from text. It gives example applications and notes the credit cost, which helps the agent decide whether this is the right tool. It does not explicitly name alternatives or exclusions, but no other sibling appears to offer TTS.

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

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

Annotations already indicate this is a mutating, non-idempotent operation (readOnlyHint=false, idempotentHint=false). The description adds valuable behavioral context beyond annotations: it discloses that the operation costs credits from the account wallet, which is important for an agent deciding whether to invoke it. It also clarifies the output shape (document boundaries and summary), which is not in 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 a single sentence that front-loads the core function and output, then adds the cost warning. It is compact and every clause earns its place, though it could be slightly more structured with a separate sentence for the cost 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?

For a tool with no output schema, the description does a good job of explaining what the agent will get back (document identity, start/end, summary). It also discloses the credit cost, which is a key operational constraint. It does not mention input format requirements or limits, but the schema covers input options and the description is otherwise sufficient for a 4-parameter tool with 100% 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?

Schema description coverage is 100%, so the schema already documents all four parameters (text, fileUrl, fileBase64, fileMimeType). The description does not add parameter-level meaning beyond the schema, but it does clarify that the tool accepts a multi-document bundle, which helps an agent understand that the input should contain multiple documents. Baseline 3 is appropriate.

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

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

The description states a specific verb ('classified and split') and resource ('multi-document scan bundle'), and names the outputs: document identity, start/end positions, and a summary. It is clear enough to distinguish from siblings like parserail_classify or parserail_summarize, though it does not explicitly name a sibling alternative.

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

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

The description implies the tool is for multi-document bundles that need both classification and splitting, which gives some context for when to use it. However, it does not explicitly state when not to use it or name alternatives such as parserail_classify for classification-only or parserail_summarize for summary-only tasks.

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

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

Annotations already indicate this is not read-only and not idempotent; the description adds concrete behavioral value by disclosing that the call costs wallet credits. It also summarizes the output shape, though it does not cover failure modes or malformed input 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 definition is compact, front-loads the transformation result, and includes the wallet-credit cost without wasted words. The grammatical fragment in the first sentence is a minor structural flaw 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?

With no output schema, the description does a reasonable job of sketching what the tool returns, but it omits operational details such as requiring one of text, fileUrl, or fileBase64. For a tool with four optional-looking parameters, an agent needs more guidance to invoke it successfully on the first try.

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?

All four parameters already have full descriptions in the schema, so the schema carries the semantic weight. The description adds no per-parameter guidance or preferred-input rules, matching the baseline for high schema coverage.

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

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

The title and description together identify a statement-parsing tool with a concrete deliverable: account, period, balances, and per-transaction normalized rows. The description's first sentence lacks an explicit main verb ('A bank or card statement into…'), relying on the title to supply the action, but it is still clear enough to distinguish from sibling parserail_* 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 handles bank or card statements but gives no guidance on when to prefer it over siblings like parserail_invoice, parserail_receipt, or parserail_extract. It also doesn't state that at least one input source must be provided despite all parameters being marked optional in the schema.

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

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

The description discloses meaningful behavior beyond the sparse annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false): validation against required fields/property types, an automatic corrective retry, a `valid` flag in the result, and that it costs credits from the account wallet. The cost disclosure is particularly valuable and not present in any structured field. No contradiction with annotations — the non-destructive transformation aligns with destructiveHint=false.

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

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

A single dense sentence with an arrow progression that front-loads the core purpose and packs in validation, retry, and cost details without filler. Efficient, though slightly dense; it earns its words with no waste.

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 a custom user-supplied schema and no output schema, the description conveys the essential contract: input, schema, validation, corrective retry, and the valid flag. It covers cost and non-destructive behavior well. The only gap is failure handling after corrective retries exhaust — what happens when the output never validates — but the description is otherwise complete for an agent to call it correctly.

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

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

Schema description coverage is 100% for all three parameters (input, schema, instructions), so the baseline is 3. The description adds modest reinforcement — characterizing input as 'messy input, text, HTML, an email' and schema as 'YOUR JSON schema' — but doesn't add materially new semantics beyond what the schema descriptions already state. It confirms rather than extends.

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

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

The description states a specific verb-resource contract: take messy input (text, HTML, email) plus a user-supplied JSON schema and produce output shaped to it, validated against required fields and property types. The phrase 'plus YOUR JSON schema' clearly differentiates this general-purpose tool from the 40 specialized siblings (resume, invoice, contract) that use fixed schemas.

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 use case — 'any messy input ... plus YOUR JSON schema' — but never explicitly says when to choose this over a specialized sibling like parserail_resume or parserail_invoice. The differentiation from alternatives is implicit rather than stated; it would be stronger with an explicit 'use this for custom schemas not covered by specialized tools' clause.

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

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

The description adds a valuable behavioral detail beyond the annotations: it costs account credits. It also discloses the output components (summary, key points, action items). This is useful context and does not contradict any annotation.

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, front-loaded sentences with no filler. The core transformation appears first, and the cost warning earns its place as the second sentence.

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

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

With no output schema and no parameter descriptions, the tool is under-specified: length behavior, actionItems semantics, and return format are all missing. The cost disclosure is helpful but does not make the tool fully actionable.

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 only partially clarifies the 'text' parameter by listing accepted inputs. The 'length' enum and 'actionItems' boolean are left entirely unexplained, so an agent must guess their behavior.

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 transformation arrow makes it immediately clear the tool converts meeting transcripts, threads, or reports into a summary with key points and action items. It is distinct from the parserail siblings, though it lacks an explicit verb and does not name an alternative.

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

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

Listing specific input types (meeting transcript, thread, report) gives an agent clear context for when the tool is relevant. It does not state exclusions or name alternative tools, so it stops short of full routing 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?

Beyond annotations, the description discloses that the tool costs credits from the account wallet, which is a meaningful side effect. It also mentions support for scanned documents and output normalization, adding value without contradicting the provided hints.

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 that front-load the core function before the cost note. 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?

With no output schema and four optional parameters, the description covers the core value and cost, and the schema covers parameter semantics. However, the exact output shape (beyond 'headers and rows') and input combination expectations are left unspecified, making it adequate but not exhaustive.

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?

All four parameters have complete schema descriptions (100% coverage), so the description adds no parameter-specific meaning. It does not explain when to use text versus fileUrl versus fileBase64, but the schema already handles that, warranting the baseline score.

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: extracting every table from a document, including scanned ones, as clean headers and rows. This is specific to tables and distinguishes it from the many parserail_* siblings, though it does not explicitly name an alternative.

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

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

The description implies usage for converting document tables into spreadsheet/DB-ready data, but provides no explicit guidance on when to choose this over sibling tools like parserail_extract or parserail_structure, nor any exclusions. The use case is clear but under-specified.

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?

It discloses a meaningful side effect beyond the annotations: 'Costs credits from the account wallet,' which is important given readOnlyHint=false. It also reveals useful output characteristics (speakers, paragraph timestamps). No contradiction exists with the annotations, though auth requirements or failure behavior are not covered.

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 tightly written and front-loaded with the core transformation. Use cases and the cost side effect are conveyed in minimal words with no filler.

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

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

For a tool with no required parameters and no output schema, the description partially covers what the tool produces, including speakers and timestamps. However, it does not clarify whether audio must be passed inline via base64 or can be a URL, nor what happens when both are provided, so an agent must infer the calling convention from the schema.

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

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

Schema coverage is only 50%, with audioUrl and mimeType lacking descriptions. The description's mention of 'audio recording' only weakly hints at the input options and does not explain the relationship between the audio object and audioUrl, the purpose of language, or the base64 format. It adds little beyond what the schema already states.

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

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

The description identifies a clear action: transcribing an audio recording into text, with specific output features like speakers and paragraph timestamps. It lists concrete use cases (Meetings, calls, voice notes), but does not explicitly differentiate from sibling tools such as parserail_minutes or parserail_summarize.

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 listed use cases provide clear context for when to use this tool, conveying it is for audio content. However, it does not mention when not to use it or name alternative sibling tools, so it falls short of explicit routing 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?

The description adds a meaningful behavioral detail beyond annotations: 'Costs credits from the account wallet.' This is useful for an agent deciding whether to invoke the tool. Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description does not contradict them.

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

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

The description is a single, dense sentence that front-loads the core purpose and output list, then adds the cost warning. Every element earns its place with no filler or repetition.

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

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

With no output schema, the description does a good job enumerating the expected outputs, which an agent needs to understand the return value. It also flags the credit cost. It could be slightly more complete by mentioning that teams and categories are optional inputs or by noting how the suggested first response is generated, but the overall context is sufficient for a triage 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 100%, so the baseline is 3. The description does not elaborate on the teams or categories parameters beyond what the schema already provides, but it does clarify that the tool outputs a category and team, which indirectly hints at the purpose of those 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 clearly identifies the resource (support ticket) and the transformation it performs, enumerating concrete outputs: priority, category, team, sentiment, SLA risk, and suggested first response. It is distinct from siblings like parserail_sentiment or parserail_classify because it combines multiple triage outputs in one call, though it does not explicitly name any sibling as an alternative.

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

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

The phrase 'A support ticket → ...' implies the tool is meant for triaging support tickets, which gives some context. However, there is no explicit guidance on when to use this tool versus the many sibling tools that overlap with sentiment, categorization, or classification, and no when-not-to-use guidance.

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