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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral detail beyond annotations by explaining that cost calculations are only performed when complete evidence exists and that catalog-only rows do not infer totals or savings. This meaningfully shapes agent expectations.

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

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

The description is three tight sentences with no filler. The core purpose is front-loaded, and the important cost-calculation caveat is stated compactly without 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?

Given the annotations cover safety and the output schema exists, the description is largely complete for invocation. The main gaps are the lack of guidance on optional eligibility/current-service parameters, but these are structurally visible in the schema and less critical given the tool's clear comparison purpose.

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 only indirectly addresses plan_ids via the 'up to five plans' constraint. It does not clarify line_count, eligibility, or current_service_monthly_cents, all of which are meaningful for running the comparison correctly.

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 purpose: comparing site prices, features, and conditions for up to five plans. It uses a specific verb and resource, and the comparison focus distinguishes it from siblings like get_plan_details or search_plans.

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

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

The description makes the intended use clear: compare multiple plans, capped at five. It does not explicitly name alternatives or state when not to use this tool, but the context is strong enough that an agent can infer this is for multi-plan comparison rather than single-plan lookup.

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