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

No annotations are provided, so the description must carry the behavioral disclosure burden. It only states the core mutation ('Create a new DNS record') and the zone_id resolution step. It does not mention permissions, idempotency, duplicate handling, required zone context, side effects, or what happens after creation. This is a significant gap for a mutation tool with no 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 concise sentences with no filler. The primary action is front-loaded, and the practical prerequisite guidance is delivered immediately after. 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?

Given the 7 parameters and no output schema, the description is somewhat thin. It covers the primary action and the most important prerequisite, but it does not clarify expected behavior, constraints, or return values. The schema fills parameter details, but the description alone leaves an agent without enough behavioral context for a create operation.

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 already provides 100% parameter coverage, so the baseline is 3. The description adds extra value by explaining how to obtain a zone_id via list_zones, which clarifies the relationship between the zone_id parameter and the user's domain-name intent. This goes beyond the schema's field-level descriptions.

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 uses a specific verb and resource: 'Create a new DNS record.' This clearly distinguishes the tool from its siblings (list_dns_records, update_dns_record, delete_dns_record, etc.). The action and object are 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?

The description gives concrete usage context by instructing the agent to 'Call list_zones first to resolve a domain name to a zone_id if needed.' This is clear procedural guidance for a common prerequisite, though it does not explicitly mention when create should be avoided or when an alternative like update_dns_record would be more appropriate.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states only that a record is deleted, but does not mention that deletion is destructive or irreversible, any permission requirements, or what happens after deletion.

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 extremely concise and front-loaded, with no redundant words. It is appropriately short for a simple tool, though it contributes little beyond restating the operation implied by the name.

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 destructive tool with no annotations and no output schema, the description is incomplete. It does not explain the destructive consequence, how the optional zone_id interacts with the required recordId, or what a successful deletion returns.

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 parameters are already fully documented in the schema. The description itself adds no parameter-level meaning, which is acceptable given the high schema coverage.

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 uses a specific verb ('Delete') and a clear resource ('a DNS record'), which unambiguously distinguishes it from sibling tools like create_dns_record, update_dns_record, and get_dns_record. An agent can immediately determine the tool's core function.

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 no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of how it relates to sibling operations. The agent is left to infer from the tool 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the output shape (JSON array), the full-scope behavior ('all DNS records'), and the prerequisite workflow, and the verb 'export' strongly implies a non-destructive read. It does not explicitly state read-only/no side effects, nor how large zones or pagination are handled, which is a meaningful gap for a tool intended for backups.

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 earning its place: the first delivers the core purpose, the second the use case, and the third the prerequisite workflow. The most important scoping information is front-loaded, and nothing is repeated from the schema.

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 tool with a single optional parameter and no output schema, the description covers the action, scope, output format, use case, and how to source the parameter. The one notable omission is guidance on when list_dns_records would be the better choice over this bulk-export tool, though this is minor given the tool's simplicity.

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% and the zone_id property already documents the env-var fallback. The description adds value beyond the schema by instructing the agent how to obtain a valid zone_id ('Call list_zones first to resolve a domain name to a zone_id'), which is dynamic guidance the static schema cannot provide. That elevates it above the baseline of 3.

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 first sentence names a specific verb (export), a specific resource (all DNS records for a zone), and the output format (JSON array), which is far more specific than a generic phrase. The 'all records' scope and the backup/bulk use case implicitly distinguish it from siblings like list_dns_records, and it is clearly the inverse of import_dns_zone, so an agent can select it without opening any schema.

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 states an explicit use case ('Useful for backups and bulk operations') and gives a concrete prerequisite workflow ('Call list_zones first to resolve a domain name to a zone_id if needed'). It does not name alternatives or state when not to use it (e.g., when to prefer list_dns_records for interactive inspection), so it provides clear context but no exclusions.

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?

With no annotations provided, the description must carry the behavioral disclosure burden. 'Get' signals a read-only retrieval operation with no mutation, which is useful, but the description does not disclose error behavior, missing-record handling, or what fields are returned. It is minimally transparent but lacks behavioral depth.

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 a single, tightly worded sentence with no filler and the core operation front-loaded. It is appropriately concise for a simple getter, though it does not attempt to add any additional guidance.

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 simple 2-parameter getter the description is mostly adequate, but the absence of an output schema and any annotations leaves the return shape and error behavior unspecified. The description tells the agent what the tool does but not enough about what the agent should expect back.

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%, with both 'zone_id' and 'recordId' already documented, including the 'CLOUDFLARE_ZONE_ID' fallback for 'zone_id'. The description itself adds no parameter-level meaning, so it stays at the schema-driven baseline.

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 uses the specific verb 'Get' and identifies the resource as 'a specific DNS record by ID', clearly distinguishing it from 'list_dns_records' and other sibling operations. An agent can immediately understand the tool's scope and that it targets a single record rather than a collection.

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 phrase 'specific ... by ID' implies that this tool is for fetching a known single record, but it does not explicitly state when to use this tool versus 'list_dns_records' or when to avoid it. The usage context is present but only implied, not explicitly routed against alternatives.

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?

With no annotations, the description must carry behavioral disclosure, and it does add a valuable trait: returns a success/failure summary with partial failure handling, implying non-atomic behavior. However, it does not disclose duplicate handling, whether imports are additive, batch limits, or authentication/zone requirements beyond what the schema states.

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, front-loaded with the action and scope, and no filler or repetition. The outcome is stated compactly.

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 description covers the core operation and return style (summary with partial failures), but no output schema exists, and the description omits details such as duplicate behavior, idempotency, import limits, or how to target a zone (though the schema mentions the env var fallback). This is adequate but leaves several operational questions open.

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 schema already documents records and zone_id. The description adds no parameter-level detail beyond 'JSON array', which is already reflected 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?

The description states a specific verb ('Import') and resource ('DNS records from a JSON array, creating each record in the zone'), making the batch-create purpose unambiguous. It also contrasts with sibling create_dns_record (single record) and export_dns_zone (opposite direction).

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 implies batch import usage through 'from a JSON array' and 'each record', but it never explicitly says when to choose this over create_dns_record or when not to use it. No exclusions or alternative tool names are 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It honestly discloses the 'all records' scope, which implies an unbounded result set, and hints at the zone_id configuration workflow. However, it does not describe return format, pagination, or potential response-size implications, which are relevant for an 'all' query with no annotation safety net.

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 with zero waste: the primary action is front-loaded in the first sentence, and the second sentence provides the prerequisite workflow that earns its place. No redundant restatement of the name or schema fields.

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 simple list tool with three optional parameters and no output schema, the description covers the core action and the zone_id acquisition flow adequately. It omits only minor behavioral notes like pagination expectations for large zones, which are not essential for correctly selecting or invoking the 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 100%, so the baseline is 3. The description adds value beyond the schema by explaining how to obtain zone_id via list_zones, supplementing the schema's note about the CLOUDFLARE_ZONE_ID env var. The name/type filters are already fully documented in the schema and need no repetition.

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 and resource — 'List all DNS records for a zone' — which clearly scopes the operation to zone-level enumeration. This distinguishes it from siblings by action (create/update/delete are mutations), by granularity (get_dns_record is singular), and by object type (list_zones lists zones, not 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?

The description gives an explicit usage prerequisite: 'Call list_zones first to resolve a domain name to a zone_id if needed,' which tells the agent how to prepare the required context for this tool. However, it does not explicitly state when to prefer this over get_dns_record or mention exclusions, stopping short of full when/when-not 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read-only listing operation with account-wide scope, but it does not mention pagination, response structure, or ordering behavior, which are minor for such a simple tool.

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 two concise sentences with no filler. The primary action and resource are front-loaded, followed by a clear usage hint. 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?

For a zero-parameter list tool with no output schema, the description adequately explains what the tool returns (zones with IDs) and when to use it. The only small gap is lack of detail on the exact response shape, but the stated purpose makes the output predictable enough for an agent.

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 input schema has zero parameters and 100% schema description coverage, so there is no parameter information to add. Per the rubric, a zero-parameter tool earns a baseline of 4, and the description correctly does not invent parameter guidance.

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 ('List') and resource ('all Cloudflare zones (domains) on the account'), making the tool's scope immediately clear. It also explains its main purpose—discovering zone IDs from a domain name—which distinguishes it from the sibling DNS record tools that operate on records, not zones.

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 explicitly gives a usage condition: use this when the user refers to a domain by name and you need its zone ID. It does not mention when not to use it or name alternative tools, but the provided guidance is clear enough for routing.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the update is a full replacement or a partial patch, whether changing 'type' may reset or invalidate 'content', whether updates are immediately propagated, or what authorization is required. For a mutation tool, these are significant unaddressed behavioral questions.

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 single sentence 'Update an existing DNS record' is front-loaded and contains zero wasted words. However, it is so minimal that it borders on under-specification rather than genuine conciseness, providing only the barest framing.

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 mutation tool with 8 parameters, no output schema, and no annotations, this description is incomplete. An agent does not learn update semantics (patch vs replace), which fields are optional versus required beyond recordIds, side effects of changing type or proxied, or what the response contains after a successful update.

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 input schema already documents all 8 parameters, including special notes like 'Omit to use CLOUDFLARE_ZONE_ID env var.' The description adds nothing beyond the schema, but the schema carries the weight, meriting the baseline score of 3.

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 uses a specific verb ('update') and resource ('DNS record'), and the word 'existing' signals that it operates on previously created records. This implicitly distinguishes it from create_dns_record and delete_dns_record, though it does not explicitly name any 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?

No guidance is given on when to use this tool versus create_dns_record, delete_dns_record, or get_dns_record. There are no prerequisites, exclusions, or mention of when an update is appropriate versus a delete-and-recreate approach.

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