Server Quality Checklist

Tool Scores

• delete_dns_recordC
  2.7/5.0
  Behavior3/5

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

  With no annotations provided, the description must fully disclose behavior. It does warn that the operation is irreversible, which is critical for a delete operation. However, it omits other behavioral aspects like whether it requires special permissions, what happens if the record doesn't exist, or if it affects dependent resources. The irreversibility warning earns partial credit, but the description falls short of full transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely brief with two sentences, which is concise, but it suffers from under-specification. The second sentence about irreversibility is useful, but the overall content is too minimal to be considered well-structured. It lacks necessary detail and fails to earn a higher score for conciseness because it omits critical information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that an output schema exists, return values are covered elsewhere, but the description still lacks guidance on usage context, prerequisites, and error handling. The irreversibility warning is the only contextual element. For a destructive operation with no annotations, the description should provide more completeness, such as noting the necessity of correct zone and record IDs, or possible side effects. It is not sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage for parameters, and the description does not compensate. It only refers to 'a DNS record' and 'a zone' without explaining that zone_id and dns_record_id are required identifiers or how they are used. While the parameter names are self-explanatory, the description adds no value beyond the schema's bare field names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (delete) and the resource (DNS record within a zone). It is distinct from sibling tools like create, update, get, and list. However, it doesn't explicitly differentiate from a hypothetical zone deletion, though no such sibling exists. The specificity is adequate for an agent to understand the core function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 tool versus alternatives, such as when to use update instead of delete, or any conditions for calling it. The description simply states the action without providing context about prerequisites, error cases, or alternatives. An agent receives no routing information.

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

• update_dns_recordA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the partial-update behavior and that unspecified fields remain unchanged, which is useful. However, it does not mention what happens if the record does not exist, whether the operation is idempotent, or any error conditions, leaving gaps in behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that immediately states the action and key behavior. No filler or redundancy; it earns its place and is appropriately sized for the tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 9 parameters and no annotations, the description is minimal. It covers the core purpose and partial-update semantics, but does not address prerequisites (e.g., record must exist), potential error scenarios, or any additional context. An output schema exists, so return values are covered, but for a mutation tool with this complexity, the description could provide more guidance.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 adds the critical insight that all non-required parameters are optional fields for partial update ('Only the fields you pass are changed'), which clarifies the semantics of the many nullable parameters. However, it does not explain individual parameters, relying on self-evident titles like 'Ttl' and 'Content'. This provides marginal value over the schema but does not fully compensate for zero coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb ('update') and resource ('DNS record'), and highlights a key differentiator: 'Only the fields you pass are changed' — distinguishing it from full-replace or create operations. It clearly identifies the tool's function without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Partially update an existing DNS record' implies usage when the record already exists and only specific fields need modification, which is clear context. However, it does not explicitly name alternatives like create_dns_record or mention when to prefer get_dns_record before updating, so it lacks explicit exclusions.

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

• get_dns_recordA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It clearly indicates a read-only operation ('Fetch') with no side effects, but does not mention potential error responses or authentication requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that conveys the essential information without redundancy or filler. It is perfectly sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the straightforward nature of a get-by-ID operation, the description is sufficient for an agent to understand what the tool does and what parameters are needed. The presence of an output schema further reduces the need for return-value explanation, though no mention of typical use cases or limitations is made.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Parameter names 'zone_id' and 'dns_record_id' are self-explanatory, and the description provides context ('within a zone' and 'by its ID'). However, there is no explicit definition of each parameter or constraints (e.g., format, requiredness), as schema coverage is 0%.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the action ('Fetch') and the resource ('DNS record') with a specific scope ('by its ID within a zone'). It is easily distinguishable from sibling tools like list_dns_records (bulk retrieval) and create/update/delete (mutations).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a specific record ID is known, but it does not explicitly state when to prefer this over list_dns_records or other alternatives. No guidance is given for edge cases or prerequisites.

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

• list_dns_recordsA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. The verb 'List' implies a read-only operation, but the description does not explicitly state that it has no side effects, nor does it mention pagination, rate limits, or any edge cases. It adds minimal behavioral context beyond the verb itself.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core action and followed by concise parameter explanations. There is no redundancy or fluff; every sentence adds value. The structure is ideal for quick agent parsing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With an output schema present, return values need no explanation. The description covers all parameters and the core behavior. The only gap is lack of mention of pagination or result limits, but for a simple list tool this is not a critical omission. Overall, the description is complete enough for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description fully compensates. It explains each optional filter (type, name, content) with examples and clarifies that 'name' is an exact match. zone_id is not explained but is self-evident from context. The description adds significant meaning beyond the bare schema properties.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb ('List'), a specific resource ('DNS records'), and a scope ('in a zone'). It also lists optional filters, distinguishing it from sibling tools like get_dns_record (single record) and create/update/delete mutations. The purpose is unambiguous and well-separated from related operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for listing multiple records with optional filtering, but it does not explicitly state when to prefer this over get_dns_record or list_zones, nor does it mention any exclusions (e.g., use get_dns_record for a single record). Usage context is clear but not explicitly routed.

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

• get_zoneA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It says 'Fetch' which implies a read operation, but does not disclose error handling, authentication requirements, or what 'details' specifically includes. The output schema covers return shape, but the description adds little beyond the basic read semantics.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One concise sentence, front-loaded with the verb and resource, with no filler. Every word contributes to the core meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read tool with one parameter and an output schema, the description is largely sufficient. It does not cover error cases or explicit usage exclusions, but the tool's simplicity and the presence of an output schema mitigate the gap. The missing guidance about list_zones is a minor deficiency.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides only a title ('Zone Id') with 0% description coverage. The description clarifies that the parameter is specifically the Cloudflare zone ID, which disambiguates from other ID types. This is meaningful added value for the single parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states a clear verb ('Fetch'), a specific resource ('one zone's details'), and the identifying mechanism ('by its Cloudflare zone ID'). It clearly differentiates from siblings like list_zones (which lists zones) and DNS record tools by specifying it targets a single zone.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly indicates this is for fetching a single zone when an ID is known, as opposed to list_zones for enumeration. However, it does not explicitly name the alternative or state when NOT to use it, leaving some inference to the agent.

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

• create_dns_recordA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It explains the proxied behavior (traffic routing through Cloudflare's proxy), the ttl=1 automatic semantics, and record-type-specific constraints. It omits permission or duplicate-handling details, but covers the most impactful behavior for an agent deciding to call it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a compact, front-loaded paragraph that leads with the purpose and then clarifies each parameter in a logical order. No filler or repetition; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an 8-parameter tool with zero schema coverage, the description covers all critical parameters and usage nuances. It does not discuss error conditions or authorization, but given the presence of an output schema and the detail provided, it is sufficiently complete for an agent to call correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must explain all parameters. It does so thoroughly: type enumerates examples, name explains '@' apex, content gives per-type meanings, ttl explains 1=automatic, proxied clarifies validity, and priority notes requirement. This adds substantial meaning beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear verb and resource: 'Create a DNS record in a zone.' It then enumerates the key fields and their roles, making the tool's purpose unmistakable and differentiating it from siblings like update_dns_record or delete_dns_record.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies this is for creation and gives contextual constraints (e.g., proxied only valid for A/AAAA/CNAME, priority required for MX). It does not explicitly state when not to use it or name alternatives, but the verb and scope make the usage obvious.

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

• list_zonesA
  4.5/5.0
  Behavior4/5

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

  The description indicates a read-only operation by saying 'visible to this API token' and listing zones, which implies no side effects. It does not explicitly mention that it does not modify data, but the nature of a list operation makes this clear.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, using only two sentences to convey the main purpose, filter semantics, and environment scoping. No redundant or extraneous information is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the essential information needed to call the tool: what it does, how filters work, and the automatic scoping. It does not mention pagination or output format, but the output schema is provided separately, so this is not a significant gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are explained with examples: name filters to an exact zone name, status filters by zone status (e.g., 'active', 'pending'). This provides clear meaning beyond the raw schema, which only defines them as optional strings.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists zones (domains) visible to the API token, using a specific verb and resource. It distinguishes itself from sibling tools like get_zone by implying this is for listing all zones, while get_zone is for a specific one.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explains the purpose of the optional filters (name and status) and mentions automatic scoping to CLOUDFLARE_ACCOUNT_ID. It does not explicitly contrast with get_zone or other siblings, but the listing vs. single-zone distinction is implied.

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