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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds only that the summary is period-scoped; it says nothing about return format, freshness of the counts, or auth needs, but with annotations present the bar is lower.

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?

A single front-loaded sentence with no filler. It is efficient, though the trailing 'within the chosen period' is vague enough that it does less work than its word count suggests.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. For a one-parameter read-only overview the description is largely sufficient; the only real gap is not clarifying what the 'chosen period' parameter actually controls.

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?

The schema has 0% description coverage on its single parameter (expiry_days, default 30, range 0-3650). The phrase 'within the chosen period' hints that the parameter controls a time window, but it never names expiry_days, its units, or the default, so it only partially compensates for the schema gap.

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?

Names a specific verb (Summarize) and the exact resources it aggregates: domain counts, statuses, and expiring domains. An agent can tell this is an aggregate/overview tool rather than a per-item lister like list_domains or get_domain, though no sibling is named explicitly.

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 only usage signal is 'within the chosen period', which relates to the parameter rather than telling the agent when this tool is preferable to list_domains. No prerequisites, exclusions, or alternative-selection guidance is provided.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is largely covered. The description adds genuine value by clarifying that existing TXT/SPF records are preserved and that this is a preview rather than a mutation, which resolves the apparent conflict between the 'add_' name and the read-only annotation. It stops short of describing auth needs or rate limits.

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?

A single front-loaded sentence that leads with the action and follows with the key constraint; no filler or restatement of the name. It is tight, though its brevity comes at the cost of the missing parameter detail noted elsewhere.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. But with 0% parameter description coverage on a four-param tool and no routing guidance against the many DNS-mutating siblings, the definition is not complete enough for reliable invocation.

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% across four parameters, so the description carries the full burden and largely fails: it only hints at a 'TXT verification token' value and the domain implicitly. The 'host' and 'ttl' parameters, their defaults, and the expected value format are undocumented in both the schema and the description.

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 gives a specific verb-plus-resource ('Preview adding a TXT verification token') and adds a scope constraint about not replacing existing TXT/SPF records. An agent can tell this apart from the raw create_dns_record sibling by the 'preview' framing, though no sibling is named explicitly.

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?

'Preview' implies this is a dry-run step to inspect before committing changes, which is useful implied usage. However, it never states when to prefer this over create_dns_record, ensure_dns_records, or apply_plan, nor what to do with the preview result, leaving the workflow to inference.

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?

Adds substantial behavior beyond the annotations: backs up state, rejects drift, verifies writes by readback, stops on failure, never auto-replays, non-atomic multi-operation plans, and that the caller must inspect returned status rather than tool success. This is exactly the operational context a destructive, non-idempotent tool needs and goes well past the destructiveHint/openWorldHint flags.

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 the action and timing constraint, followed by failure/verification semantics. No filler; each clause carries an operational fact.

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 single-parameter apply tool with an output schema present, the description supplies the critical missing context: drift rejection, backup, readback verification, non-atomicity, and the instruction to read status. Nothing essential to correct invocation is absent.

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 0% for the single required plan_id, so the description must carry the load. It links the parameter implicitly to 'an authorized preview' that expires, which gives some semantics, but it never says where plan_id comes from (get_plan / plan_dns_batch) or its format.

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 ('Execute') and resource ('an authorized preview', i.e. a previously created plan), which lets an agent separate it from get_plan (retrieval) and plan_dns_batch (creation). The phrasing 'execute an authorized preview' is slightly indirect about what is actually being applied, but the intent is recoverable.

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?

'before it expires' implies the tool is used on a preview that was authorized earlier, giving implicit ordering context. However, no sibling is named and there is no explicit when-not guidance (e.g. use plan_dns_batch first, or that this is the only path that mutates).

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely useful context beyond that: this is a bounded configuration check with a defined finding set, so an agent knows not to treat a clean result as a full security clearance. It still says nothing about live-vs-cached lookups or failure behavior on unresolvable domains.

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, zero filler, with the concrete finding list front-loaded and the scope caveat trailing as a qualifier. Nothing repeats the tool name or the annotations.

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 read-only, single-parameter diagnostic tool with an output schema, the description covers purpose and the critical interpretive caveat about audit breadth. The remaining gaps (domain must exist / belongs to the account, behavior on invalid input) are minor for this tool class.

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% and the description adds no parameter-level information. The single required 'domain' parameter is largely self-documenting by name, but the schema's anyOf (string OR positive integer) is unexplained, so the description misses a real chance to disambiguate whether an ID is accepted. With only one obvious parameter the damage is limited, hence a mid score rather than a low one.

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 (inspect) and resource (DNS/email configuration) and enumerates the exact findings it produces: duplicate records, CNAME collisions, multiple SPF and DMARC. This is functionally distinct from every sibling (list_dns_records, get_dns_record, export_zone), which simply retrieve data rather than check for misconfiguration. The scope-boundary sentence further sharpens what kind of inspection this is.

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 gives a scope exclusion ('not a complete email or DNS security audit'), which tells the agent not to over-trust the output, but it never states when to call this versus list_dns_records or get_domain, nor any prerequisite (e.g., domain must exist in the account). Usage is implied rather than routed.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real semantics beyond that: add-only behavior, skipping exact duplicates, and preserving absolute target names—plus implicit confirmation that this is a preview, not an applied mutation. It omits permission requirements and what the preview response contains.

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?

Very short and front-loaded: the preview action and scope come first, followed by the behavioral constraints. The semicolon-fragmented second sentence is slightly clipped but conveys three distinct rules without waste.

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?

An output schema exists, so return values need no explanation, and annotations cover safety. What is missing is the workflow context—whether the preview's result must be fed to apply_plan, how it relates to plan_dns_batch, and whether the target domain must already exist.

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 and only partially does: 'optionally selected hosts' clarifies the hosts parameter, and 'another domain' distinguishes source from target. The fact that source_domain/target_domain accept either a name string or a numeric domain ID is left entirely unexplained.

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 (preview copying) and resource (DNS records) with target-domain scope, so the agent knows exactly what it does. It does not explicitly differentiate itself from siblings like plan_dns_batch or apply_plan, which also deal with deferred DNS changes.

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?

'Preview' implies a dry-run that precedes an apply step, which weakly hints at the plan-then-apply workflow. However, it never names apply_plan/plan_dns_batch or states when to use this instead of creating records directly with create_dns_record.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real value beyond them: it discloses that identical records are a no-op and that this tool only previews while apply_plan commits the change. This clarifies the surprising 'create' name without contradicting the safety annotations.

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 short sentences, both front-loaded and waste-free. The preview/write distinction and the routing instruction come first, which is exactly what an agent needs.

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?

Output schema exists, so return values need not be explained, and the preview/apply_plan workflow is conveyed. The gap is the input: with a large nested DNSRecord schema at 0% description coverage, the description is thin on how to build a valid record, leaving notable ambiguity for a 2-parameter tool with a complex payload.

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% and the description says nothing about either parameter (domain or the nested DNSRecord). For a record with many type-specific fields (MX priority, SRV weight/port, TLSA usage/selector), the description provides no guidance on how to populate them; defaults and enums in the schema must carry the entire burden.

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 specific action and resource: 'Preview adding one record,' which usefully corrects the misleading 'create_' name by revealing it is a preview, not a write. It also names the sibling that actually performs the write (apply_plan), letting an agent disambiguate without opening schemas.

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 states the context of use (previewing a single record addition) and routes the agent explicitly to 'apply_plan to write.' No explicit when-not beyond that, but the alternative is named with the condition that selects it.

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?

readOnlyHint=true already tells the agent nothing is mutated, and 'preview' agrees with that, so there is no contradiction. The description adds the DNS collision check, which is real context beyond the annotations, but it does not say whether collisions cause an error or are merely reported, nor what the preview response contains.

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?

A single short sentence, front-loaded with the verb and resource, with no wasted words. It is arguably terse to the point of under-specification, but as a structural matter it is efficient.

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?

The presence of an output schema means return values need not be explained, and readOnlyHint covers the safety profile. However, the tool's role in the broader forward lifecycle and the meaning of its two parameters remain unexplained, leaving gaps for a two-parameter preview that performs collision analysis.

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% for two required parameters, including a nested Forward object with url/host/frame and a domain that accepts either a name string or a numeric ID. The description supplies no parameter meaning at all, so this is well below the baseline for a documented 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?

The description states a specific verb (preview) plus resource (HTTP forward) and adds a distinctive behavior (DNS collision checks), and it usefully resolves the tension between the name 'create_forward' and the read-only nature of the operation. It does not differentiate itself from siblings such as get_forward, list_forwards or plan_dns_batch, so the agent must still infer where it fits.

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?

There is no guidance on when to use this versus get_forward, list_forwards, or the plan/apply pair. Crucially, it never says how a previewed forward actually gets persisted, so an agent cannot tell whether this replaces create semantics or merely validates.

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?

Annotations declare readOnlyHint=true and destructiveHint=false, which a bare 'delete' name would seem to contradict; the description resolves that by explaining this is a preview that shows current contents. It adds the reason behind the safety hints, though it omits whether the preview expires, what the output contains, or how the real deletion is triggered.

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?

A single front-loaded sentence with no filler; the critical 'Preview' qualifier comes first. Brevity here shades into under-specification rather than being genuinely efficient.

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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. However, with 0% parameter coverage and no pointer to how the deletion is actually applied, an agent lacks enough to use this confidently in a workflow.

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% for both parameters, so the description carries the burden. 'Exact DNS record' hints that record_id selects a single record, but it never explains whether 'domain' is a name or an ID, nor the accepted string/integer duality.

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: previewing deletion of a DNS record, with the qualifier 'exact' implying record_id-level targeting. It is distinguishable from list_dns_records/get_dns_record/update_dns_record, though it never names which sibling performs the actual deletion.

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?

No when-to-use or when-not-to-use guidance, and no indication of what to do after previewing (e.g., apply_plan or a confirm step). The word 'Preview' implies a read-only inspection step but the workflow is left to inference.

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?

Annotations declare readOnlyHint=true and destructiveHint=false, and 'Preview' correctly reinforces that this does not mutate state. However, the description adds nothing about what the preview returns, whether a confirmation/apply step follows, or any permission requirements, so it goes only modestly beyond the annotations.

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?

A single front-loaded sentence with no filler, which is appropriate. It is arguably too terse for the workflow it implies, but nothing in the sentence is wasted.

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?

An output schema exists so return values need not be explained, but with 0% parameter coverage and no usage guidance, the definition is too thin for a tool whose name misleadingly suggests immediate destruction. The critical preview-vs-apply workflow is left unstated.

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% for both required parameters, and the description never mentions 'domain' or 'host'. In particular, its silence on the domain parameter's dual string/integer type leaves the agent with no guidance beyond the raw 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?

States a specific verb and resource ('preview deletion of a specific HTTP forward') and usefully disambiguates the misleading name, which says 'delete' but the operation is a preview. It does not differentiate from any sibling (e.g. apply_plan), but the purpose itself is unambiguous.

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?

No when-to-use guidance, no mention of the follow-up step needed to actually perform the deletion, and no comparison to siblings such as apply_plan or list_forwards. The agent must infer the workflow entirely.

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?

The annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered; the description adds the useful blast-radius detail that replace_rrsets wipes ALL records for each supplied host/type while other sets stay, plus the default add-missing-only mode. However, it uses active mutation language ('adds', 'replaces') that sits uneasily with readOnlyHint=true and never states plainly that the call is a dry-run that applies nothing, so the apply-vs-preview question is left for the agent to resolve.

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 short clauses, zero filler, with the key behavioral fork (default vs replace_rrsets) front-loaded right after the purpose statement. The trailing fragment 'other sets stay' is terse but carries real information; nothing is padded.

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?

Return values need not be covered since an output schema exists, and annotations carry the safety profile. But for a batch tool accepting up to 100 records with a rich, type-dependent nested record shape at 0% schema coverage, the description leaves the record-field semantics, the domain parameter format, and whether anything is actually applied versus merely previewed unresolved.

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%, and the description compensates for only one of three top-level parameters: replace_rrsets is explained well ('replaces ALL records of each supplied host/type; other sets stay'). 'domain' is never explained (string vs positive integer ID), and the 14-field DNSRecord objects in 'records' (type-dependent fields such as priority/weight/port for SRV, usage/selector/digest for TLSA, flags/tag for CAA) are entirely undocumented in both schema and description.

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 names a specific action (preview of idempotent DNS setup/import) and the resource (DNS records), and the second sentence pins down the record-level behavior. It is clearly a bulk/ensure-style record tool rather than a single-record CRUD tool, but it never names a sibling (create_dns_record, plan_dns_batch, apply_plan) to draw the boundary explicitly.

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 contrasts two modes (default 'only adds missing exact records' vs replace_rrsets=true), but that is behavior of a flag rather than guidance on when to choose this tool over create_dns_record/update_dns_record/plan_dns_batch/apply_plan. No prerequisites (domain must exist, zone ownership) or when-not-to-use conditions are given.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered structurally. The description usefully adds that output is returned rather than written to disk and that the snapshot is 'complete' (DNS plus forwards), which is real information beyond the annotations, but it says nothing about size, rate limits, or scope boundaries.

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?

One front-loaded sentence that delivers the verb, the resource, the payload contents, and the key constraint with zero filler. Nothing to trim.

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?

An output schema exists, so return-value detail is not required, and annotations cover the safety profile. Still, for a tool with an ambiguous single parameter and several plausible sibling alternatives, the definition leaves the agent guessing about parameter form and selection context.

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?

The single parameter has 0% schema description coverage, so the description carries the burden and fails to clarify it. It never explains whether 'domain' is a domain name string or a numeric domain id, despite the schema's ambiguous anyOf(string, integer) union — exactly the ambiguity the description should resolve.

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 (Export) and resource (a complete JSON snapshot of DNS and forwards), so the agent knows exactly what the tool produces. It does not, however, distinguish itself from adjacent read tools such as audit_dns, list_dns_records, or restore_dns_backup, which a domain-export tool arguably should.

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?

There is no when-to-use guidance and no named alternative. The agent is not told whether this is for backup purposes, migration, or inspection, nor how it relates to restore_dns_backup (its obvious counterpart) or audit_dns. Only the 'no filesystem write' constraint gives any usage context.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no behavior for a nonexistent record ID, no auth/scope requirements, no rate-limit or error 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?

A single short sentence, front-loaded with the verb and resource, with no filler. It is efficient, though the terseness contributes to the specification gaps noted elsewhere.

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?

An output schema exists, so return values need not be described. However, for a 2-parameter lookup with 0% schema description coverage and rich sibling competition, the description omits the domain-argument semantics and any failure behavior, leaving the agent under-informed.

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 carries the burden and largely fails: 'within a domain' only loosely gestures at the domain parameter and never explains that it accepts a name or numeric ID, nor that record_id is a positive integer scoped to that domain.

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 clear verb (Read) and a specific resource (DNS record identified by its exact ID within a domain), which distinguishes it from list_dns_records and get_domain. The phrasing is slightly ambiguous about whether the returned payload is the record or just its ID, but the intent to fetch a single record by ID is legible.

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?

No when-to-use guidance and no named alternatives; the agent is left to infer that this requires an already-known record ID and that list_dns_records is the discovery path. 'Exact ... ID' weakly implies a prerequisite but no exclusion or routing to siblings is stated.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds only the returned field set; it does not say what happens for an unknown domain, whether the lookup is live/registrar-sourced, or whether it can be rate-limited.

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?

One efficient sentence, front-loaded with the verb and resource; the returned fields are listed compactly with no filler. It is a touch terse, but 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?

An output schema exists, so return values need not be explained, and annotations cover the behavioral profile. What is missing for a correct call is parameter guidance (domain name vs. numeric ID) and any error semantics; adequate but with a clear gap.

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% for the single parameter, and the schema's anyOf (string OR positive integer) is genuinely ambiguous — it implies a domain name or possibly a numeric domain ID. The description adds nothing to disambiguate name vs. ID format, so it fails to compensate for the coverage gap.

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?

Specific verb+resource ('Get domain') plus the concrete fields returned (registration, expiry, nameservers, enabled services), so the agent knows exactly what data comes back. It does not, however, distinguish itself from the sibling list_domains or explain the singular-vs-plural relationship.

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?

No when-to-use guidance, no mention of alternatives such as list_domains for enumeration, and no prerequisites (e.g., whether the domain must already exist in the account or whether this triggers a live registrar lookup). Usage must be inferred entirely from the name.

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?

Annotations already declare the full safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the safety burden is largely lifted. The description adds nothing behavioral beyond that—no mention of what happens when no forward exists or of lookup scope—so it neither helps nor contradicts.

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?

A single front-loaded sentence that names the resource first and annotates it with a concrete example; there is no filler. Its brevity is appropriate in form, though it shades into under-specification rather than true economy.

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?

An output schema exists, so return values need not be described, but with 0% parameter coverage the description should carry parameter meaning and it does not cover 'domain' at all. For a tool with two required, undocumented parameters it leaves the agent guessing about the domain argument's type and format.

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% for both parameters, so the description must compensate. It partially clarifies 'host' via the 'www or @' example, but says nothing about 'domain'—notably the schema permits either a string or a positive integer for it, an ambiguity the description leaves entirely unexplained.

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 ('Get the forward') and clarifies what a relative host looks like with the 'www or @' example. It is distinguishable from list_forwards (single lookup vs. list) and create_forward/update_forward by the verb, though it never explicitly contrasts itself with those siblings.

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?

There is no statement of when to use this tool versus list_forwards or get_domain, no prerequisites (must the domain exist? must the forward exist?), and no exclusions. Usage is only inferable from the name and the sibling set, which falls short of even implied guidance.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds nothing beyond that: no error behavior for a missing invoice, no auth/scope requirement, no rate-limit or caching context. It simply restates the read.

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?

One sentence, no filler, with the resource and lookup key front-loaded. Nothing can be trimmed without losing information.

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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. What remains missing for a lookup tool is failure behavior (invoice not found, unauthorized) and any routing hint toward list_invoices, leaving the definition adequate but thin.

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% for the single parameter, so the description must carry the load. 'By invoice number' does clarify that invoice_id is the human-facing invoice number rather than an internal surrogate key, which is a small but real gain over the schema's bare 'Invoice Id'. It gives no format, range, or example beyond the schema's exclusiveMinimum constraint.

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 ('Get a single account invoice') and the lookup key ('by invoice number'). The word 'single' implicitly separates it from the sibling list_invoices, but the description never names that alternative explicitly, so it stops short of full sibling differentiation.

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?

Usage is only implied: an agent can infer this is the tool to use when it already holds one invoice identifier, versus list_invoices for browsing. There is no explicit when-to-use, when-not-to-use, or prerequisite (e.g. permission scope) stated.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the tool may return either a preview or a previously stored execution result, which is useful state-dependent behavior, but it doesn't say how that state is determined.

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?

A single front-loaded sentence with no filler. It is tight, though the space saved comes partly from omitting needed parameter and usage detail rather than from good prioritization.

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?

An output schema exists, so return values need not be spelled out, and the dual preview/result nature is mentioned. However, for a tool with a required undocumented parameter and no routing guidance to its siblings, the description leaves gaps an agent would have to guess around.

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% for the single required plan_id parameter, and the description supplies no information about its format, origin, or validity (e.g., how to obtain a plan id from plan_dns_batch/apply_plan). With one required undocumented param, the description fails to compensate.

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: read a plan preview or stored execution result. It's distinguishable from the mutation sibling apply_plan, but the phrase 'in this process' is vague and never clarifies what a 'plan' object actually is or how it relates to plan_dns_batch/apply_plan.

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 implicitly names two usage modes ('plan preview' vs 'stored execution result'), implying it can be called before or after apply_plan, but it never explicitly says when to call this vs apply_plan or plan_dns_batch, nor how the caller knows which mode will be returned.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no pagination behavior, no result-count or scoping notes — so it earns a baseline 3 rather than credit for extra 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?

A single front-loaded sentence with no filler; every clause (verb, resource, filter dimensions) 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. The remaining gap is the unexplained dual typing of the required 'domain' parameter and any pagination/limit behavior for a list operation, leaving it adequate but incomplete.

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 has to carry parameter meaning; it does add real value for 'host' by explaining it is a relative host with examples (@, www) and identifies record_type as a filter. However, it says nothing about 'domain' being either a domain string or a numeric ID, which is the required parameter and the most consequential ambiguity.

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 clear verb+resource ('List DNS') plus the optional filter dimensions, so an agent immediately knows this is a read-many operation. It doesn't explicitly contrast with the sibling get_dns_record (single-record fetch), but 'List' versus 'get' is unambiguous enough to route correctly.

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 word 'optionally' hints that filters are discretionary, but there is no statement of when to use this versus get_dns_record or list_domains, and no prerequisites. Usage must be inferred from the name alone.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds one behavioral fact beyond them — that the returned count is deterministic — but says nothing about result volume, pagination, or ordering.

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 compact clauses, front-loaded with the primary action and with zero filler. The trailing 'Returns deterministic count' is slightly cryptic but does carry information, so no sentence is wasted.

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?

An output schema exists, so return values need not be described, and the safety profile is covered by annotations. For a simple single-parameter list tool the description is nearly sufficient, with only filtering scope and any result limits left unstated.

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% and the single 'query' parameter carries no description, so the description must compensate. 'optional substring search' does meaningfully clarify that query is a substring match rather than an exact-name filter and that it is optional, which is real added meaning over the bare 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?

States a specific verb and resource ('List account domains') and adds the scope of the listing plus the search capability. It is distinguishable from the singular get_domain sibling by the plural resource, but it never explicitly contrasts itself with the other list-style siblings (list_dns_records, list_forwards, list_invoices).

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?

'optional substring search' implies that the query parameter exists for filtering and that calling without it returns the full list, so usage is inferable. However, there is no explicit when-to-use vs. alternative (e.g. get_domain for a single domain) and no note on result limits or paging.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that — no note on pagination, result volume, or whether the domain must already exist.

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?

A single short, front-loaded sentence with no filler. It is efficient, though arguably too terse to be maximally useful.

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?

An output schema exists so return values need not be described, and annotations cover the safety profile. However, the ambiguous anyOf domain parameter and the absence of any scoping/pagination context leave gaps for a listing tool.

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 0% and the parameter accepts either a string or a positive integer (anyOf), which is ambiguous without documentation. The phrase 'for a domain' hints at the parameter's meaning but does not clarify whether a name, ID, or both are accepted.

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?

Specific verb + resource: 'List HTTP/WWW forwards', with the scoping qualifier 'for a domain'. It is clearly distinct from mutations like create_forward/update_forward, though it does not explicitly contrast with get_forward or list_dns_records.

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?

No when-to-use guidance and no named alternatives. An agent cannot tell from the text whether to call this versus get_forward for a single forward, or how it relates to the DNS record listing 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds two things the annotations do not: the hard three-year lookback window and a security warning that invoice URLs grant access to private invoice content.

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 short sentences, zero waste, with the scope limit and filter front-loaded and the privacy caveat placed after. Every clause carries information an agent can act on.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description supplies the scope, filter semantics and a privacy warning; the remaining gap is the absence of any routing hint toward get_invoice and no note on result volume/pagination for a three-year window.

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 0% and the single 'status' parameter is only named in the schema, not described. The description compensates by clarifying that it filters by payment status and is optional, which is the essential semantics for this lone parameter; the enum values themselves are already in the 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?

States a specific verb (List) plus resource (invoices) and even bounds the scope to 'the past three years' with an optional filter. It does not, however, explicitly differentiate itself from the sibling get_invoice, leaving the list-vs-single distinction to inference.

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?

'Optionally by payment status' implies how to narrow results, so the usage is somewhat legible. But there is no explicit statement of when to use this instead of get_invoice, or of any prerequisites/preconditions; usage is only implied.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description still adds real value by disclosing that batch execution is non-atomic and that the batch is capped at 100 — a genuine behavioral caveat an agent would not learn from the annotations alone.

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 short sentences with zero filler; the scope and limit come first and the non-atomic caveat second. Every clause carries information an agent needs.

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?

An output schema exists, so return values need not be described. However, for a plan tool sitting next to apply_plan and get_plan, the description omits the critical lifecycle detail of how the produced plan is subsequently executed or referenced, and never explains the 'domain' argument — gaps for a tool of this complexity.

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. It usefully conveys the action vocabulary (creates/updates/deletes), the maxItems=100 limit, and that ordering of the changes array is significant, but it says nothing about the 'domain' parameter or the nested DNSRecord fields, leaving a substantial gap.

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 gives a specific verb ('Preview') plus the resource ('ordered creates/updates/deletes') and the batch limit of 100, so the agent knows this is a dry-run planner rather than an executor. It implies the read-only nature that separates it from apply_plan but never names that sibling, so differentiation is left to inference.

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?

There is no explicit when-to-use, when-not-to-use, or alternative. The word 'Preview' hints that this precedes execution, and the sibling list contains apply_plan, but the description never states the relationship (e.g. 'call apply_plan to execute the returned plan'), leaving the plan/apply workflow to be guessed.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered, and the description usefully confirms the dry-run nature. It adds real behavioral context beyond annotations: it touches matching mail hosts, preserves TTL, and leaves unrelated records untouched. It does not address idempotentHint=false or openWorldHint=true, keeping it from 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?

Three short sentences, each carrying distinct information, with the core action front-loaded and the preservation guarantees following. No filler or 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. What is missing is the workflow linkage to apply_plan and the scope limits on the domains argument, leaving an agent able to call it but unsure what to do with the preview.

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 carries the full burden, and it only partially compensates. 'Exact A/AAAA address' clarifies old_ip/new_ip are IPs, and 'explicitly selected domains' hints at domains, but it does not explain the string-or-integer domain identifier form, the 100-item cap, or whether matching is by address value.

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: previewing replacement of an exact A/AAAA address across selected domains. 'Preview' clearly signals a dry-run rather than a mutation, distinguishing it from update_dns_record. However, it never names apply_plan or otherwise differentiates itself from the plan_dns_batch sibling, so an agent can't fully place it in the workflow.

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?

No explicit when-to-use, when-not-to-use, or alternative is given. The word 'Preview' implies a dry-run workflow but the description never says the result must be committed via apply_plan, which is the single most important routing decision for this tool. Usage is left almost entirely to inference.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered. The description adds genuinely new context beyond that: recreated records receive new IDs, and forwards are excluded and need separate changes — both important behavioral facts for planning a restore.

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 short, front-loaded statements with no filler. The preview framing comes first, then the ID-churn consequence, then the forwards caveat — each sentence carries distinct information.

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?

An output schema exists, so return values need not be described. The description covers the operation, the backup/plan ID equivalence, and a key limitation, leaving only the unexplained 'domain' parameter and the unnamed apply alternative as 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?

Schema coverage is 0% for both parameters, so the description must compensate. It usefully clarifies that backup_id is this server's pre-change backup ID and is equivalent to a plan ID, but 'domain' is left completely unexplained (including its string-or-integer union type).

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: previewing a restore of DNS content from a backup ID. The parenthetical '(= plan ID)' ties it to the plan family, giving partial sibling differentiation, but it never names apply_plan as the tool that actually performs the restore, so an agent must infer the preview/apply split.

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 word 'Preview' implies this is a dry-run step used before committing changes, and the note that forwards require separate explicit changes scopes what this call will not cover. However, no alternative tool is named and there is no explicit when-to-use/when-not-to-use statement.

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?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds real semantics beyond that: replacement of supplied host/type sets, preservation of an omitted address family, and the conflict-resolution requirement for www records. It does not restate the annotation hints, which is correct.

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 short sentences with no filler, and the core purpose is front-loaded before the behavioral caveats. Efficient, though the sentence fragments are slightly telegraphic.

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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile. What is missing is parameter-level meaning and any explicit routing to apply_plan, which matters for a 5-parameter planning tool.

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% and none of the five parameters (ttl, www, ipv4, ipv6, domain) are documented in the schema. The description only gestures at the www/ipv4/ipv6 family semantics; ttl, domain, and the type of the domain field are left entirely unexplained, so it does not compensate for the coverage gap.

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 opens with a specific verb and resource: preview apex A/AAAA and optional www CNAME records. That is enough to tell it apart from sibling tools like create_dns_record or ensure_dns_records. It stops short of naming the natural companion (apply_plan), so it is clear but not fully differentiated.

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?

"Preview" implies this is a non-committing step before an apply, and the note about conflicting www records needing explicit resolution hints at prerequisites. However, no sibling is named and there is no explicit when-to-use/when-not guidance. Usage is only implied.

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?

Annotations declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds the crucial nuance that this is a preview of a replacement (not an actual write) and that the record ID is preserved. It does not mention the idempotentHint=false behavior or what triggers an actual apply, but it meaningfully exceeds the annotations.

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?

A single front-loaded sentence with no filler; the preview nature and ID preservation are both stated immediately. Every clause carries signal.

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?

An output schema exists so return values need not be described, but for a tool that replaces an entire record payload with a complex schema (0% parameter coverage, enum type field, defaults for ttl/host) the description should clarify replacement/reset semantics and the domain parameter. As written, an agent lacks enough to call it correctly.

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% and there are three parameters including a 13-property nested DNSRecord object. The description only gestures at record_id ("preserving its ID") and never explains the domain parameter or what "full payload" replacement means for omitted record fields, so it fails to compensate for the coverage gap.

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 names a specific operation (preview a replacement), the resource (a specific DNS record), and the scope (full payload, ID preserved). It implicitly separates itself from create_dns_record and delete_dns_record by stating it preserves the existing ID, but it never names a sibling tool outright.

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 word "Preview" implies this is a dry-run step rather than a mutation, which hints at when to use it. However, it never states the alternative (e.g., apply_plan, ensure_dns_records) or what to do with the preview afterward, leaving the workflow to inference.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond them: that use_request_ip mode relies on the server's egress IP and therefore cannot verify the intended client IP.

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 tight sentences with the core verb leading and the caveat following. Minor formatting noise (an unclosed leading quote) but no wasted content.

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 annotations covering safety and an output schema covering return values, the description only needs to resolve behavior and the required conditional, which it does. Fully documenting the 0%-coverage parameters would make it complete.

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 carry the load. It does explain the ips/use_request_ip conditional and characterizes hostnames as fully qualified, but leaves the remaining semantics (list sizes, ip list format, hostname/IP pairing) undocumented.

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 specific verb+resource ('Preview DDNS for fully qualified hostnames'), which importantly clarifies that despite the 'update_dynamic_dns' name this is a read-only preview operation. It does not explicitly distinguish itself from the update_dns_record/update_forward siblings that would otherwise seem related.

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 explains a conditional: omitting IPs requires use_request_ip=true, and warns that this mode cannot verify the intended client IP. However, there is no guidance on when to choose this preview tool over the actual update tools or plan_dns_batch/plan_dns_batch-style siblings.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds two useful pieces of context: that this is a 'preview' (produces a plan rather than applying) and that 'Host cannot be renamed'. It does not, however, explain what the preview returns or how it relates to apply_plan.

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 short sentences, front-loaded with the action and immediately followed by the key constraint. No filler, though it could still fit one more clarifying clause without bloat.

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?

An output schema is present so return values needn't be re-described, but for a tool wrapping a nested Forward object with 0% schema coverage the description is thin: it covers only the host constraint and omits the meaning of domain, url, and frame, leaving an agent needing the schema plus guesswork.

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 carry parameter meaning. It only addresses the host field (via 'forward.host' and the no-rename rule) and leaves 'domain', the forward 'url', and 'frame' completely unexplained.

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 ('Preview updating') and resource ('the existing forward'), and identifies which field ('forward.host') is being addressed. It distinguishes itself from create_forward/delete_forward siblings, though 'forward.host' is slightly awkward notation.

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 word 'Preview' implies this is the non-mutating first step of a plan/apply flow, which matches the apply_plan/get_plan siblings, but the description never names an alternative or states an explicit when-to-use condition. Usage is only implied.

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