chasa

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

With no annotations, the description carries the full burden and does well: it discloses the output (subject+body) and the critical behavior that the tool does not send the email. This is useful, though it could mention more about how the draft is generated.

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 purpose and immediately followed by a clarifying behavioral note. There is 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 simple tool with three well-documented parameters and no output schema, the description covers the purpose, output, and the critical non-sending behavior. It is complete for an agent to understand and invoke 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 input schema provides 100% coverage with clear descriptions for all three parameters (client_name, invoice_amount, days_overdue). The description adds no extra parameter semantics, so the baseline of 3 applies.

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

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

The description clearly states the tool drafts a payment follow-up email for an overdue invoice, specifies it returns subject and body, and distinguishes it from sibling tools by focusing on email drafting rather than tips or template listing.

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 an email draft is needed, and the non-sending note clarifies that the user must handle sending. However, it doesn't explicitly reference sibling tools or provide exclusion criteria, so it's implied rather than explicit.

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

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

No annotations exist, so the description must disclose behavioral traits. It does not mention side effects, read-only nature, or edge cases (e.g., negative days_overdue). The verb 'Get' implies read-only but does not confirm it.

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

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

One sentence, front-loaded with the action, no wasted words.

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

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

For a single-parameter read-only tool, the description is adequate. It explains the purpose, but lacks explicit output format or edge-case handling. Given no annotations, more context would be helpful, but the tool is simple enough.

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 describes days_overdue fully (Days past due (0 = due today)). The description adds no additional parameter semantics, so baseline 3 applies.

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

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

The verb 'Get' and noun 'chase-tone tip' clearly indicate the retrieval function. The phrase 'for how late an invoice is' ties to the input parameter and distinguishes from sibling tools that draft emails or list templates.

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 explicit usage guidance is provided. The description does not state when to prefer this over draft_chase_email or recommend_template, though the sibling names offer implicit 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by specifying that only 'free' templates are listed and that URLs are included, which are details beyond the name. However, it does not mention pagination, return format, or any potential side effects, though the read-only nature is clear.

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

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

The description is a single, concise sentence that immediately conveys the purpose. It contains no redundant words or filler, and every word earns its place—'List,' 'Chasa,' 'free,' 'invoice follow-up email templates,' and 'with URLs.'

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 list tool with no output schema, the description is largely complete. It notes that templates come with URLs, hinting at the return structure. However, it doesn't specify whether the response is an array or how many items may be returned, which would be useful for an agent. Given the simplicity, the gap is minor.

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

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

The tool has zero parameters, and the schema coverage is 100% (empty properties). The description does not need to explain any parameters, and since there are none, the baseline of 4 is appropriate. It neither adds nor omits parameter-related information.

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: listing Chasa free invoice follow-up email templates, with the added detail that they include URLs. This is a specific verb (list) and resource (templates), and it distinguishes itself from sibling tools like draft_chase_email, get_chase_tip, and recommend_template.

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 by stating what the tool does, but it does not explicitly say when to use this tool versus alternatives like recommend_template. No exclusions or alternative references are provided, so the agent must infer that listing is the appropriate action when needing all templates rather than a recommendation.

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

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

With no annotations, the description bears the burden. It indicates the operation is a recommendation (likely read-only) and that a URL is provided, but it does not disclose potential edge cases (e.g., no matching template), whether the tool has side effects, or any permissions/rate limits. This is adequate but not rich.

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

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

The description is a single, front-loaded sentence that states the action, object, and output. It has no wasted words and is immediately understandable.

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

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

With no output schema, the description should clarify the return value. It mentions 'with a URL' but does not specify what else is returned (e.g., template name, content, or whether multiple options are provided). For a tool with one parameter and simple behavior, this is a notable gap, but the core purpose 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 schema already fully describes the only parameter (days_overdue) with 'Days past due (0 = due today)'. The description's 'days-overdue stage' aligns with this but does not add new semantic detail or clarify valid values/ranges. Schema coverage is 100%, so the description adds little 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 action ('Recommend'), the resource ('free Chasa payment-reminder template'), and the specific condition ('for a given days-overdue stage'), while also noting the output ('with a URL'). This distinguishes it from siblings like list_templates (which lists all) and draft_chase_email (which drafts an email).

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

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

The phrase 'for a given days-overdue stage' implies the tool should be used when a specific overdue stage is known and a matching template is needed. However, it does not explicitly state when to use this over alternatives (e.g., list_templates, get_chase_tip) or provide exclusions.

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