Server Quality Checklist

Tool Scores

• cf_dns_createC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a DNS record' implies a write operation but lacks details on permissions required, rate limits, whether the operation is idempotent, what happens on conflicts, or what the response contains. For a mutation tool with zero annotation coverage, this is insufficient.

  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 with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information without redundancy.

  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 this is a mutation tool (creating DNS records) with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, authentication needs, or response format. For a tool with 6 parameters and critical write operations, more context is needed to ensure safe and effective use.

  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 100%, so the schema fully documents all 6 parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples of valid 'type' values beyond those implied, no clarification on 'ttl=1' meaning 'auto'). Baseline 3 is appropriate when the schema does the heavy lifting.

  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 ('Create') and resource ('a DNS record'), making the purpose immediately understandable. It distinguishes from siblings like cf_dns_delete and cf_dns_list by specifying creation rather than deletion or listing. However, it doesn't explicitly mention Cloudflare context or differentiate from other DNS-related tools beyond the name prefix.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing a zoneId from cf_zones), when not to use it (e.g., for updates vs. creation), or how it differs from other DNS operations. Sibling tools like cf_dns_delete and cf_dns_list exist, but no comparison is offered.

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

• cf_dns_deleteC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. 'Delete' implies a destructive mutation, but it doesn't disclose critical behaviors: whether deletion is permanent, requires specific permissions, has rate limits, or what happens on success/failure. This is a significant gap for a destructive tool with zero annotation coverage.

  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 with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.

  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 this is a destructive tool with no annotations and no output schema, the description is incomplete. It lacks behavioral context (e.g., permanence, permissions), usage guidelines, and output expectations, making it inadequate for safe and effective use by an AI agent.

  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 100%, with clear parameter descriptions (zoneId, recordId). The description doesn't add any meaning beyond the schema, such as how to obtain these IDs or their format. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 'Delete a DNS record' clearly states the action (delete) and resource (DNS record). It distinguishes from siblings like cf_dns_create (create) and cf_dns_list (list), but doesn't specify Cloudflare context or differentiate from other delete tools like cf_kv_delete or cf_worker_delete.

  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?

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing zoneId and recordId from cf_dns_list), exclusions, or comparisons with sibling tools like cf_dns_create for updates or cf_cache_purge for related operations.

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

• cf_dns_listC
  2.9/5.0
  Behavior2/5

  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 states it's a list operation, implying read-only behavior, but doesn't mention pagination details (implied by 'page' and 'perPage' parameters), rate limits, authentication requirements, or error handling, which are critical for safe and effective use.

  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 directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy to parse quickly.

  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 the complexity of a list operation with pagination and no output schema, the description is incomplete. It lacks details on return values (e.g., record format), error cases, or how to handle multiple pages, which are essential for an agent to use the tool correctly in a real-world context.

  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 100%, so the schema fully documents parameters like 'zoneId', 'page', and 'perPage'. The description adds no additional meaning beyond the schema, such as explaining what a 'zoneId' represents or how pagination works in practice, resulting in a baseline score.

  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 ('List') and resource ('DNS records for a zone'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'cf_dns_create' or 'cf_dns_delete' beyond the basic verb, which would require more specificity for a perfect score.

  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?

  The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't mention when to choose this over 'cf_kv_keys' for key-value operations or 'cf_zones' for zone management, leaving the agent to infer usage from tool names alone.

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

• cf_kv_deleteC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the basic action without disclosing critical behavioral traits. It doesn't mention whether deletion is permanent, requires specific permissions, has rate limits, or what happens on success/failure (e.g., error if key doesn't exist). This is inadequate for a destructive operation.

  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 with zero waste, clearly front-loading the core action. It's appropriately sized for a simple operation, though it could benefit from additional context.

  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?

  For a destructive tool with no annotations and no output schema, the description is incomplete. It fails to address behavioral aspects like permanence, error handling, or return values, leaving significant gaps for an AI agent to understand the tool's full context.

  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 100%, so the schema already documents all three parameters (namespaceId, key, accountId). The description adds no additional meaning beyond implying 'key' is the target for deletion, which is redundant with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

  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 resource ('a key from KV'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like cf_kv_put (create/update) or cf_kv_get (read), which would require explicit comparison for a score of 5.

  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?

  No guidance is provided on when to use this tool versus alternatives like cf_kv_put for updates or cf_kv_get for reads. The description lacks context about prerequisites, such as needing an existing key, or exclusions, such as not being suitable for bulk deletions.

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

• cf_kv_getC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. 'Get a value' implies a read operation, but it doesn't specify whether this requires authentication, has rate limits, returns errors for missing keys, or what format the value returns. This is inadequate for a tool with zero annotation coverage.

  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 with zero wasted words. It's appropriately sized for a simple retrieval operation and gets straight to the point without unnecessary elaboration.

  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 no annotations, no output schema, and a read operation that likely returns data, the description is incomplete. It doesn't explain what happens if the key doesn't exist, the format of returned values, or authentication requirements, leaving significant gaps for agent understanding.

  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 100%, so the schema already documents all three parameters (namespaceId, key, accountId). The description adds no additional meaning about parameter usage, relationships, or constraints beyond what's in the schema, meeting the baseline for high coverage.

  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 ('Get') and resource ('a value from KV'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like cf_kv_keys (lists keys) or cf_kv_put (stores values), which would require a more specific description to earn a 5.

  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?

  The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (like needing a namespace), when not to use it, or how it differs from related KV operations like cf_kv_keys or cf_kv_put.

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

• cf_kv_keysC
  2.9/5.0
  Behavior2/5

  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 the action ('List keys') but doesn't describe behavioral traits such as pagination, rate limits, authentication requirements, or what the output looks like (e.g., list format, error handling). For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

  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 directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized for a simple listing operation, making it easy to parse quickly.

  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 the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is incomplete. It lacks information on output format, error conditions, authentication needs, and usage context. While the schema covers parameters, the description doesn't provide enough context for an agent to fully understand how to invoke and interpret results effectively.

  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 100%, meaning all parameters are documented in the schema. The description adds no additional meaning beyond what the schema provides—it doesn't explain parameter interactions, default behaviors, or usage examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.

  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 verb ('List') and resource ('keys in a KV namespace'), making the purpose immediately understandable. It distinguishes this tool from siblings like cf_kv_get (retrieve values) and cf_kv_put (store values), though it doesn't explicitly mention these distinctions. The description is specific but lacks explicit sibling differentiation.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a namespace ID), when not to use it, or direct alternatives like cf_kv_namespaces (which might list namespaces rather than keys). Usage is implied by the action but not explicitly contextualized.

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

• cf_kv_namespacesC
  2.9/5.0
  Behavior2/5

  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. 'List KV namespaces' implies a read-only operation, but it doesn't specify whether this requires authentication, returns paginated results, includes metadata, or has rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

  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 extremely concise with just three words, front-loading the core action and resource without any wasted text. It efficiently communicates the essential purpose in a minimal format.

  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 the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like authentication needs, response format, or error handling. For a tool that likely interacts with a cloud service (Cloudflare KV), more context on usage and expected outcomes would be beneficial.

  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?

  The input schema has 100% description coverage, with the single parameter 'accountId' documented as 'Account ID'. The description adds no additional meaning beyond this, such as explaining where to find the account ID or if it's optional. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.

  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 'List KV namespaces' clearly states the verb ('List') and resource ('KV namespaces'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'cf_kv_keys' or 'cf_kv_get', which also involve KV operations but serve different purposes.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an account ID), exclusions, or how it relates to sibling tools like 'cf_kv_keys' (which lists keys within a namespace) or 'cf_workers_list' (which might involve KV namespaces in context).

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

• cf_kv_putC
  2.9/5.0
  Behavior2/5

  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 states 'write' which implies a mutation, but doesn't cover critical aspects like whether this overwrites existing values, requires specific permissions, has rate limits, or what happens on success/failure. This leaves significant gaps for safe tool invocation.

  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 extremely concise at just four words, with zero wasted language. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place.

  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 the complexity of a write operation to a key-value store with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, or behavioral traits like idempotency. For a mutation tool with 4 parameters, more context is needed for reliable use.

  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 100%, so the schema fully documents all parameters (namespaceId, key, value, accountId). The description adds no additional meaning beyond the schema, such as explaining parameter relationships or constraints. The baseline of 3 is appropriate since the schema does the heavy lifting.

  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 'Write a value to KV' clearly states the action (write) and resource (KV/key-value store), distinguishing it from sibling tools like cf_kv_get (read) and cf_kv_delete (remove). However, it doesn't specify that this is for Cloudflare KV specifically, which could help differentiate from generic KV tools.

  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?

  The description provides no guidance on when to use this tool versus alternatives like cf_kv_get or cf_kv_delete, nor does it mention prerequisites such as needing a namespace ID or account ID. It lacks context about typical use cases or constraints.

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

• cf_r2_bucketsC
  2.9/5.0
  Behavior2/5

  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. 'List' implies a read-only operation, but it doesn't specify whether this requires authentication, returns paginated results, includes metadata, or has rate limits. For a tool with zero annotation coverage, this is a significant gap in describing how it behaves.

  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 extremely concise at three words, front-loading the key information ('List R2 buckets') with zero wasted text. It efficiently communicates the core purpose without unnecessary elaboration, making it easy for an agent to parse quickly.

  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 the tool's simplicity (one parameter, no output schema, no annotations), the description is incomplete. It lacks context on usage, behavioral traits, or output format, which are crucial for an agent to invoke it correctly. While concise, it doesn't provide enough information to compensate for the missing structured data.

  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?

  The input schema has 100% description coverage, with the 'accountId' parameter documented as 'Account ID'. The description adds no additional meaning beyond this, such as explaining where to find the account ID or if it's optional. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

  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 ('List') and resource ('R2 buckets'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'cf_kv_namespaces' or 'cf_workers_list' which also list resources, missing an opportunity to clarify this is specifically for R2 storage buckets versus other Cloudflare resources.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an account ID), exclusions, or how it compares to sibling tools like 'cf_kv_namespaces' for listing other resource types. This leaves the agent without context for tool selection.

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

• cf_workers_listC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden for behavioral disclosure. 'List Workers scripts' implies a read-only operation but doesn't specify whether it returns all scripts, paginated results, error conditions, or authentication requirements. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

  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 extremely concise ('List Workers scripts') - just three words that directly convey the core functionality. There's zero wasted language, and it's perfectly front-loaded. This is an excellent example of efficient communication.

  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 no annotations, no output schema, and a simple single-parameter tool, the description is insufficiently complete. It doesn't explain what 'Workers scripts' are, what format the listing returns, or any behavioral aspects. While the tool is simple, the description should provide more context for proper agent understanding.

  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 100%, so the schema already documents the single parameter (accountId) with its description. The tool description adds no additional parameter information beyond what's in the schema. This meets the baseline of 3 when schema coverage is high.

  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 verb ('List') and resource ('Workers scripts'), making the purpose immediately understandable. It distinguishes from siblings like cf_worker_delete (deletion) and cf_kv_keys (different resource type). However, it doesn't specify scope (e.g., all scripts vs filtered) which prevents a perfect score.

  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?

  The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this should be preferred over other listing tools (like cf_dns_list or cf_kv_namespaces), or any contextual constraints. The agent must infer usage 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.

• cf_zonesC
  2.9/5.0
  Behavior2/5

  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 states this is a listing operation, implying it's read-only and non-destructive, but doesn't mention authentication requirements, rate limits, pagination behavior beyond the schema, or what the output looks like. This leaves significant gaps for a tool with no annotation coverage.

  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 directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.

  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 the complexity of listing Cloudflare zones, no annotations, and no output schema, the description is insufficient. It doesn't explain what information is returned, how zones are filtered or sorted, or any operational constraints. For a tool with no structured output documentation, more descriptive context is needed.

  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?

  The schema description coverage is 100%, with both parameters ('page' and 'perPage') fully documented in the schema. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without compensating value.

  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 verb ('List') and resource ('Cloudflare zones (domains)'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'cf_dns_list' or 'cf_workers_list' that also list resources, missing full sibling distinction.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'cf_zones' instead of other listing tools like 'cf_dns_list' or 'cf_workers_list', nor does it specify any prerequisites or context for usage.

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

• cf_cache_purgeB
  3.2/5.0
  Behavior2/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 mentions 'all or specific URLs' but lacks critical behavioral details like required permissions, rate limits, side effects (e.g., temporary performance impact), or response format. The 'use with caution' warning is in the schema, not the description.

  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 front-loads the core action ('Purge Cloudflare cache') and specifies scope ('all or specific URLs') without unnecessary words. Every part earns its place.

  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 no annotations, no output schema, and a mutation tool with potential side effects, the description is inadequate. It lacks details on permissions, consequences, error handling, or return values, leaving significant gaps for an AI agent to use it safely and effectively.

  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 100%, so the schema fully documents parameters. The description adds minimal value by hinting at 'all or specific URLs', which aligns with purgeAll and urls parameters but doesn't provide additional syntax or format details beyond the schema.

  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 verb ('Purge') and resource ('Cloudflare cache'), specifying it can target 'all or specific URLs'. It distinguishes from siblings like DNS or KV tools by focusing on cache operations, though it doesn't explicitly contrast with them.

  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 cache purging but provides no explicit guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It mentions 'use with caution' in the schema but not in the description itself.

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

• cf_worker_deleteB
  3.2/5.0
  Behavior2/5

  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. 'Delete' implies a destructive mutation, but the description doesn't specify whether deletion is permanent, requires specific permissions, affects associated resources, or has rate limits. For a destructive tool with zero annotation coverage, this is a significant gap 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 with zero waste. It is appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.

  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 this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks crucial behavioral details (e.g., permanence, permissions) and doesn't explain what happens upon deletion (e.g., success/failure response). For a tool with such complexity and minimal structured data, the description should do more.

  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 100%, with both parameters (scriptName, accountId) documented in the schema. The description adds no additional meaning beyond the schema's parameter descriptions, so it meets the baseline of 3 where the schema does the heavy lifting.

  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 'Delete a Workers script' clearly states the action (Delete) and the resource (Workers script) with a specific verb+resource combination. It distinguishes from siblings like cf_workers_list (list operation) and cf_kv_delete (deletes KV data, not Workers scripts).

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing script), exclusions (e.g., cannot delete active scripts), or relationships to siblings like cf_workers_list (which might help identify scripts to delete).

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