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

Annotations cover the safety profile (readOnlyHint false, openWorldHint true, idempotentHint false), and the description adds value beyond them: an explicit consent/disclosure obligation and the fact that a quote_id is returned to seed the rest of the workflow. It does not describe failure modes (e.g., invalid address or under-18 applicant) or how long the quote persists, which keeps it below a 5.

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?

Four tight sentences, front-loaded with purpose before execution instructions and the next step. The only waste is the DOB/date-picker guidance, which duplicates the schema's date_of_birth description almost verbatim.

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 6-required-parameter write tool with no output schema, the description covers purpose, prep steps, consent, return value and follow-up tool. It stops short of explaining what happens on validation failure or whether a partially-started quote can be resumed, but nothing essential to calling it correctly 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?

Schema coverage is 67% and the schema already documents email, address, phone_number and date_of_birth in detail. The description's DOB-as-typed-text advice largely repeats what the date_of_birth schema description already says, and it adds no meaning for first_name/last_name. Baseline 3 is appropriate since the schema carries most of the load.

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 a specific verb and resource (start a homeowners or landlord insurance quote) plus a meaningful scope constraint (property in California). It is clearly distinguishable from siblings like get_quotes, select_quote and submit_property_details, since this is the entry point that produces a quote_id.

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?

Explicit sequencing guidance: collect every field first, disclose the DwellQuote/Somerset Agency data-sharing before calling, and call get_property_details next. It names the follow-up tool and the prerequisite for invoking this one, leaving little to inference.

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