CoverSavvy Term Life Insurance Rates

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

Without annotations, the description carries the full burden. It discloses the return behavior (rates for preferred, standard, and standard_tobacco classes) but omits error handling, rate limits, caching behavior, or what happens with invalid coverage amounts. Just meets minimum viable disclosure.

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 zero waste. First sentence front-loads the core function; second sentence provides the value proposition. Every word earns its place.

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

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

Given no output schema and no annotations, the description adequately hints at return values by enumerating the health classes, but falls short of describing the response structure, format, or error conditions. Sufficient for basic invocation but leaves operational gaps.

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 75% schema description coverage, the baseline is 3. The description merely lists the parameters ('age, gender, coverage, term') without adding semantic context beyond the schema (e.g., explaining that gender and age drive the rate differentials, or clarifying the coverage constraint referencing list_options).

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 specific action ('returns rates across all health classes') and the resource (health class ratings) given a fixed profile. It implicitly distinguishes from siblings like query_rates (single rate lookup) and compare_terms (cross-term comparison) by specifying the comparison dimension is health classes.

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?

Provides an implied use case ('Helps explain the cost impact of health rating or tobacco use'), but lacks explicit when-to-use guidance versus alternatives like query_rates or compare_terms. Also fails to mention the prerequisite of valid coverage amounts from list_options despite the schema hint.

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

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

With no annotations provided, the description carries full disclosure burden. It lists specific available term lengths (10-30 years) and indicates multiple rates are returned, but lacks details on idempotency, side effects, rate limits, or the specific return data structure that would be expected for a read-only lookup tool.

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

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

Two efficient sentences with zero waste. The first sentence front-loads the core functionality with parameter grouping and specific outputs; the second provides the concrete use case. Every word earns its place.

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

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

Given no output schema exists, the description partially compensates by indicating 'rates' are returned across multiple term lengths, but lacks specifics on return structure (objects vs arrays, field names). The input requirements are well-covered through schema and description. Adequate but gaps remain for a 4-parameter tool without 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 75% (high). The description adds conceptual value by grouping the four parameters as a 'fixed profile,' helping the agent understand they function as a unit. However, it doesn't add syntax details or examples beyond what the schema already provides for individual fields.

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 specific action (returns rates), resource (insurance rates), and unique scope (across term lengths 10-30 years). It distinguishes from siblings by emphasizing the 'fixed profile' constraint versus varying term lengths, clearly differentiating it from compare_health_classes and query_rates.

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?

Provides explicit usage context through the example question 'should I get a 20 or 30 year term?' and the 'fixed profile' framing implies when to use this (holding demographics constant). References list_options for valid coverage values. Lacks explicit 'when not to use' or direct sibling comparisons, but the use case is clear.

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

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

No annotations provided, so description carries full burden. It successfully discloses the data domains returned (ages, coverages, terms, genders, health classes), but omits operational details like return format structure, caching behavior, or idempotency that would be useful for a discovery endpoint.

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 zero waste: first states purpose, second states workflow position and enumerates return domains. Front-loaded with critical information and appropriately sized for the tool's simplicity.

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

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

Given zero parameters and no output schema, the description adequately compensates by listing the specific value domains returned. Sufficient for tool complexity, though return format specification would strengthen it further.

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?

Tool has 0 parameters and 100% schema coverage trivially. Baseline 4 applies as there are no parameters requiring semantic clarification beyond the empty 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?

Description uses specific verb 'Returns' with clear resource 'all valid parameter values' and distinguishes from siblings by enumerating specific domains (ages, coverages, terms, genders, health classes) that are likely inputs to the comparison 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?

Provides explicit workflow guidance with 'Call this first', clearly positioning it as a prerequisite step. Lacks explicit naming of sibling alternatives, but the sequencing instruction effectively signals when to use this versus the 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?

No annotations are provided, so the description carries the full burden. It discloses the return values (monthly/annual premiums) but omits safety characteristics (read-only/idempotent), error behaviors for invalid profiles, or rate limiting 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 sentences with zero waste: front-loaded with purpose, followed immediately by critical invocation constraint. Every word earns its place.

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

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

Given the lack of output schema, the description appropriately specifies the return values (monthly/annual premiums). It acknowledges all parameters are required, matching the schema complexity. Minor gap: does not reference sibling tools for comparative workflows.

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 80% (high), establishing a baseline of 3. The description emphasizes that all 5 parameters are required, reinforcing the schema's 'required' array, but does not add syntax guidance, formatting details, or semantic relationships beyond what the schema already 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?

States specific action ('Returns') and resource ('monthly and annual premium') for a 'specific profile'. Implicitly distinguishes from comparison siblings (compare_health_classes, compare_terms) via 'specific profile' phrasing, though it does not explicitly 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?

Notes the constraint that 'All 5 parameters are required,' which aids invocation. However, it lacks guidance on when to use this single-profile query versus the comparison siblings (compare_health_classes, compare_terms) or when to call list_options first.

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