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

Beyond the readOnly/idempotent annotations, it discloses real behavioral traits: cells that fail to answer are 'unavailable' and explicitly NOT negative, the verdict downgrades to 'unknown' under three vantage points, and the caller should report vantage_reached/vantage_total rather than claim convergence. 'Observation only: no record is ever composed here' further clarifies scope beyond what the annotations convey.

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 long but front-loads the when-to-use trigger and the core global-propagation mechanic. It is dense with edge-case semantics rather than padding, though the parameter recap overlaps the schema and the opening 'check whether a DNS change has propagated' repeats the usage sentence slightly.

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 an output schema present, the description need not explain return values, and it still covers the critical interpretive edge cases (unavailable ≠ negative, partial-coverage downgrade to unknown). For a network-dependent read tool with three parameters, nothing an agent needs in order to call and interpret 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 description coverage is 100%, so the schema already documents name, record_type enum and expected_value, including that www. is not stripped and expected_value switches cells to match/mismatch. The description largely restates this, adding only marginal reinforcement, so the 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 description states a precise verb+resource (check whether a DNS change has propagated globally) and names the exact mechanism (six vantage points across four continents plus the server's own resolver). It is clearly distinguishable from single-lookup siblings like check_record because it explicitly contrasts 'GLOBAL' propagation against 'you have ONE network vantage point.'

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?

It gives explicit trigger conditions: 'when the user asks whether a DNS change has propagated globally, or why a record shows in one place and not another,' plus timing guidance ('call it after the human publishes a record'). It does not name a sibling alternative such as check_record for the single-name lookup case, so it stops short of full when/when-not routing.

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