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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-structured behavior: it discloses that LiveDataLink does not retain customer watchlists, so the caller must persist the snapshot and drive the schedule itself — important state-management 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?

Three sentences, front-loaded with purpose, then comparison scope, then operational guidance. Every sentence carries distinct load with no 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?

With no output schema, the description fully covers return values (unchanged/changed status, severity, field-level changes, next reviewer action) and the persistence/scheduling workflow. Nothing an agent needs to invoke or chain this tool 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 100%, so the baseline is 3, but the description goes further by clarifying the snapshot lifecycle: DOT/MC/name are the lookup inputs and previous_snapshot is the prior carrier_vetting result or JSON snapshot returned by an earlier call, which explains how the param relates to the tool's output.

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+resource ('Recheck an existing carrier snapshot') and the exact comparison intent ('identify meaningful changes since the previous check'). This distinguishes it from the initial-vetting siblings like carrier_vetting_score by framing it as a diff against a prior snapshot, and it enumerates the compared fields, so an agent knows precisely what it 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?

Gives concrete when-to-use context ('call this on a schedule' after storing a snapshot) and implies the prerequisite that a prior result must exist as previous_snapshot. It does not explicitly name a sibling as the alternative for initial vetting, but the operating context is clear.

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