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

No annotations are provided, so the description must carry the behavioral load. 'List' does convey a read-only, non-mutating operation and names the returned fields, but it says nothing about auth scope, pagination, result limits, or whether results are account-wide or zone-scoped.

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

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

A single front-loaded sentence with zero filler; the resource leads and the parenthetical detail is optional enrichment. Every clause 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 read-only listing with an output schema that already documents the return shape, the description covers the essentials. Only the missing auth/pagination context keeps it from a 5.

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 tool takes no parameters, which is the baseline-4 case under the rubric. There is nothing for the description to explain beyond the absence of filters, which the schema already establishes.

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

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

States a specific verb ('List') and a precisely named resource ('Cloudflare Access protected applications'), then enumerates what those apps contain (domains, session durations, identity provider bindings). No sibling tool touches Access applications, so there is no ambiguity to resolve.

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 resource name implies the use case (inspecting Access-protected apps), but the description never states when to reach for this tool, whether a prerequisite account/zone context is needed, or what alternative to use. With zero parameters the usage is largely self-evident, which keeps it at 'implied' rather than absent.

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 carries the full burden, and it discloses that results are model metadata plus capabilities (a read-only listing), which is useful. It does not mention pagination, result limits, or auth requirements, and its brevity limits how much behavioral context an agent gains.

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

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

Two compact sentences, with the primary action front-loaded before the examples. The parenthetical is somewhat dense but every element adds discriminating information, so there is little waste.

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

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

An output schema exists, so return values need not be described, and the description correctly covers purpose and output nature. However, with zero annotation coverage and an undocumented search parameter, it leaves gaps around search semantics and result set behavior.

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

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

Schema description coverage is 0% for the single 'search' parameter, so the description must compensate. The verb 'search' plus concrete example tokens ('@cf/meta/llama-3', 'embeddings', 'text generation', 'vision') convey what can be matched, giving more meaning than the bare default-empty string schema.

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

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

States a specific verb and resource ('List or search Cloudflare Workers AI models') and the parenthetical enumerates model categories (llama-3, embeddings, text generation, vision), making the tool's scope unambiguous. No sibling tool covers AI models, so differentiation is inherent.

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?

'List or search' implies the two modes (browse vs. filter via the search parameter), but the description never states when to prefer one, nor any prerequisites or alternatives. Usage is implied rather than spelled out.

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 behavioral burden. It discloses what the output contains (ids, creation timestamps, wrangler bindings), which is useful, but says nothing about read-only nature, pagination, rate limits, or account-scope/auth requirements for a list operation.

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

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

A single efficient sentence, front-loaded with the resource and account scope. Every clause earns its place by naming the resource and the returned fields; no filler.

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

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

With an output schema present, return values needn't be explained, and with zero parameters the schema side is trivial. The description covers scope and payload composition adequately, though it omits any pagination or scope caveats an agent might want.

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 tool takes zero parameters, so the baseline is 4 per the rubric. The description adds nothing that could be misread as a parameter requirement, which is correct for a parameterless listing tool.

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

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

The description gives a specific verb+resource ('List all D1 (serverless SQLite) databases in the account') and even enumerates the returned fields (ids, timestamps, wrangler bindings). It is clearly distinguishable from cf_d1_query and cf_d1_schema, though it doesn't explicitly name those siblings. Strong but not sibling-differentiating.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named despite siblings like cf_d1_query and cf_d1_schema existing. Usage is only loosely implied by the word 'List'. No prerequisites or account/auth context are stated.

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

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

With no annotations, the description carries the full burden. It discloses the return fields (columns, rows, rows_affected, duration) and notes positional parameter binding 'on the REST path', and names DDL/UPDATE/INSERT so the agent can infer mutation. It does not state permission requirements, reversibility, or error behavior for a destructive-capable tool, so it is only partially transparent.

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 tight sentences with zero filler; the core action and target lead, with the return shape and binding note following. Every sentence earns its place.

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

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

An output schema exists, so return values need not be restated, and the description nevertheless names them. Params are covered despite 0% schema coverage. The remaining gap is the absence of any safety/permission context for a tool that accepts INSERT/UPDATE/DDL.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that 'database' accepts a name or an id and that 'params' performs positional binding on the REST path, adding meaning beyond the bare schema for two of three parameters (the third, 'sql', is self-evident).

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

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

States a specific verb (Execute) and resource (a SQL statement against a named D1 database or database id), and enumerates the statement classes (SELECT/INSERT/UPDATE/DDL). An agent can distinguish this from cf_d1_list_databases and cf_d1_schema without opening the 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?

Usage is implied by the verb and statement types but there is no explicit when-to-use guidance, no exclusions, and no pointer to siblings like cf_d1_schema for introspection or cf_d1_list_databases for discovery. Nothing misleading, but nothing routing either.

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 burden. 'Inspect' reasonably conveys a read-only operation and the 'without a full schema dump' phrasing signals a scoped, lightweight call, but it discloses nothing about permissions, rate limits, or whether the scope is capped.

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

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

A single front-loaded sentence that names the core action and scope first, then the outcome. No wasted words, though it packs the rationale and scope into one clause.

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 two-parameter read tool with an output schema, the description covers purpose, scope, and the optional table narrowing. Return format is handled by the output schema, so the remaining gap is only the unexplained required database parameter.

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

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

Schema description coverage is 0%, so the schema documents neither parameter. The description compensates for the optional 'table' param by stating it narrows inspection to a single table, but the required 'database' parameter's meaning is left entirely to its name.

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

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

States a specific verb (inspect) and resource (table and view DDL of a D1 database), with the optional single-table scope. It is clear what the tool returns, though it does not name the sibling cf_d1_query or cf_d1_list_databases to distinguish itself explicitly.

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

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

The clause 'so an agent can write valid SQL without a full schema dump' implies the usage context (pre-query schema discovery), but there is no explicit when-to-use or when-not-to-use guidance and no routing against cf_d1_query or cf_d1_list_databases.

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. It discloses output content and the zone-to-id mapping via CLOUDFLARE_ZONE_MAP, which is genuinely useful, but omits pagination behavior despite a 'limit' parameter, and says nothing about auth or rate limits.

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

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

Two tightly written sentences with the core action front-loaded and zero filler. Every clause adds information.

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

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

An output schema exists so return values need not be described, and the description nonetheless adds the zone-mapping detail. The only real gap for a list tool is the undocumented limit/pagination parameter.

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

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

Schema coverage is 0%, so the description must compensate. It explains the zone parameter can be a domain or an id in CLOUDFLARE_ZONE_MAP and covers type/name as filters, adding real meaning beyond the bare schema, but 'limit' (default 100) is entirely undocumented.

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

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

States a specific verb+resource ('List DNS records of a zone') and names the return fields (content, TTL, proxy status). This clearly contrasts with the cf_dns_upsert sibling, though it never explicitly names the alternative it is not.

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?

Notes that type/name are optional filters, which implies some usage, but gives no explicit when-to-use, when-not-to-use, or alternative (e.g., cf_dns_upsert) guidance. The agent must infer the context.

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

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

With no annotations, the description carries the full behavioral burden and it does disclose the important idempotency contract (keyed on type + name, so repeat calls are safe). However it says nothing about required token permissions, whether updating an existing record replaces or merges unspecified fields, or the destructive effect of overwriting content on a live record.

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

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

Two tight sentences with the verb and idempotency guarantee front-loaded; the parameter enumeration in sentence two is slightly redundant with the schema but costs little and orients the caller.

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

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

An output schema exists, so return values need not be described, and the idempotency semantics cover the biggest ambiguity. Still, for a 7-parameter mutation tool with zero annotations, the description omits permissions, overwrite/merge behavior, and value formats, so an agent could invoke it correctly but not confidently.

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

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

Schema description coverage is 0%, so the description must compensate. It names type, name, content plus the optional ttl, proxied and comment, and adds the genuinely useful '1=automatic' meaning for ttl that the schema lacks. It does not explain zone semantics or the expected name/content format per record type, leaving three parameters only labeled, not explained.

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

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

States a specific verb pair (create or update) and resource (DNS record in a zone), and the idempotency key (type + name) makes the semantics precise. It is easy to distinguish from the only DNS sibling, cf_dns_list, without opening either schema, though no sibling is named explicitly.

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

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

The idempotency note implies this is the single call to use for both creation and update, which is useful routing guidance, but there is no explicit when-to-use statement, no mention of cf_dns_list for reads, and no stated prerequisites.

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 behavioral burden. 'List' implies a read-only operation and 'verified' hints at a filtered subset, but there is no disclosure of pagination, permission requirements, or whether unverified destinations are excluded. Useful but incomplete for a zero-annotation 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?

A single front-loaded sentence with no filler; verb, resource, and scope appear in order of importance. 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 an output schema, the description covers the essentials and the return shape is documented elsewhere. Missing only secondary details like pagination or result limits, which are minor here.

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 tool takes no parameters, so the baseline of 4 applies. The phrase 'under the active account' implicitly clarifies the implicit account scoping, which is the only input dimension that exists.

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

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

Specific verb (List) plus a precise resource (verified destination email addresses for Cloudflare Email Routing) and a scope qualifier (active account). It is clearly distinguishable from siblings like cf_email_routing_rules, though it does not explicitly name that sibling to sharpen the contrast.

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 what the tool returns but gives no when-to-use guidance: no prerequisites, no indication of when to call this versus cf_email_routing_rules, and no mention of alternatives. The only contextual hint is 'under the active account'.

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. 'List' implies a read-only, non-mutating operation and the parenthetical enumerates the returned data shape, which is genuinely helpful. However, it omits the zone identifier format, pagination behavior, and any auth/permission requirements 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.

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

One front-loaded sentence plus a short usefulness clause; nothing is padded and the resource is named first. The trailing sentence is slightly filler but still earns its place as usage context.

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

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

With a read-only list tool, an output schema already present, and no nested objects, the description covers purpose and return content adequately. The remaining gap is the zone parameter's expected format, which the schema also fails to document.

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

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

The single 'zone' parameter has 0% schema description coverage, so the description must compensate. 'For a zone' restates the parameter name without clarifying whether it expects a zone ID or name, or noting that it is optional (required=false with default ''). Adds minimal meaning beyond the schema.

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

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

States a specific verb (List) and resource (Cloudflare Email Routing rules for a zone), and even enumerates the returned content (matchers, forward actions, enabled status, priorities). It is clearly distinguishable in name and content from the closest sibling cf_email_destinations, though it never explicitly contrasts them.

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?

'Useful to inspect inbound routing for domains' implies the use case but gives no when-to-use/when-not conditions and no alternative tools to prefer over this one. The guidance is inferable rather than stated.

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

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

With no annotations, the description carries the full burden, and it discloses the salient behavioral fact that the return includes value, metadata, and expiration. However it says nothing about permissions, error semantics for a missing key, or read-only safety, leaving meaningful gaps for an unannotated 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?

A single front-loaded sentence with no filler; the verb, scope, return contents, and addressing modes are all packed efficiently without redundancy.

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

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

For a simple single-key get with an output schema already documenting the return shape, the description covers purpose, target resource, and namespace addressing adequately. Only usage guidance relative to cf_kv_set is missing, which is a minor gap for this low-complexity tool.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully clarifies that the namespace argument accepts either an id or a title, which the schema does not convey, but it adds nothing about the required 'key' parameter beyond the obvious.

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

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

States a specific verb (Read) and resource (one key from a Workers KV namespace), and enumerates what is returned (value + metadata + expiration). It implicitly contrasts with the write sibling cf_kv_set via the 'read one' framing, though it does not name any alternative explicitly.

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

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

No when-to-use or when-not-to-use guidance and no reference to the cf_kv_set sibling that would be the obvious alternative for writing. The description says what the tool does but not when an agent should reach for it over other KV operations.

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. It does disclose the ttl ceiling (604800 seconds) and that is_json triggers pre-write validation, which is genuine behavioral context. However, it omits overwrite semantics for an existing key, permission/namespace prerequisites, and any failure modes — meaningful gaps for a mutation 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?

Two dense sentences with no filler, front-loading the core action before the optional parameters. Every clause carries information; nothing is repeated from the schema titles.

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

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

An output schema exists, so return values need not be described. For a mutation tool with no annotations and a fully undocumented schema, the description covers the value/ttl/metadata surface but leaves the overwrite and authorization story unstated. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies ttl units and maximum, that metadata is JSON, and the exact meaning of is_json; key, value, and namespace remain undocumented but are largely self-evident. Partial compensation for a 6-parameter, zero-coverage schema, hence a mid-range score rather than higher.

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

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

The description names a specific verb and resource: 'Write one key/value pair into a Workers KV namespace.' An agent can immediately distinguish it from the read-oriented cf_kv_get and unrelated siblings. It stops short of explicitly naming the counterpart tool, so it is clear but not sibling-differentiating in the strongest sense.

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

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

Usage is implied ('set is_json when the value is a JSON document that should be validated before write') rather than stated as a when-to-use rule. There is no guidance on prerequisites such as the namespace existing or on when to prefer this over other write paths. The is_json conditional is useful but is parameter-level, not tool-selection 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, the description carries the full behavioral burden. It implies a read-only listing and names the data categories surfaced, but says nothing about pagination, result limits, authentication/permission requirements, or whether the list is truncated.

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

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

A single front-loaded sentence that identifies the action first and the returned payload second. No filler, though the trailing field list is somewhat redundant with the output 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 simple, read-only, zero-required-parameter list tool with an output schema that already documents return shape, the description is largely sufficient. The only real gap is the unexplained include_routes flag.

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

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

Schema description coverage is 0%, so the description must compensate for the single include_routes parameter. It mentions "routes" among the returned fields but never explains that include_routes toggles route data or what its default (true) means. The parameter remains undocumented.

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

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

The description states a specific verb ("List") and resource ("Cloudflare Workers") and enumerates the data categories returned (environments, routes, deployment history, modified dates). No sibling tool covers Workers, so differentiation isn't needed, but the purpose is unambiguous.

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

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

There is no indication of when to use this tool, what prerequisites exist, or how it relates to other listing tools like cf_dns_list or cf_tunnels_list. Usage is only implied by the word "List".

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 exist, so the description carries the full behavioral burden. It discloses the shape of returned records and the cursor-based paging mechanism, but says nothing about permissions required, default page size behavior, or whether 'limit' caps the total result set.

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

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

A single tight sentence with the core purpose front-loaded and pagination guidance appended. No filler, though the paging note is somewhat terse.

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

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

An output schema exists, so return values need not be described. For a simple two-parameter list tool this is close to adequate, but the undocumented 'limit' parameter and absent behavioral details leave gaps.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It partially explains 'cursor' as the next-page token, but 'limit' (default 100) is never mentioned or defined, leaving half the parameter surface undocumented.

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

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

States a specific verb and resource ('List R2 buckets') plus the account scope and the fields returned (creation time, location, storage class). It is unambiguous, though it does not need to distinguish itself from siblings, which all belong to other Cloudflare services.

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 explains the pagination flow ('Pass cursor for the next page'), which implies iterative use, but gives no explicit when-to-use guidance or prerequisites for the listing operation.

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 full burden. It discloses that output is limited to targeted snippets and code samples, and 'search' implies a read-only operation, but it does not state auth requirements, rate limits, or explicitly confirm read-only safety.

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 tightly written sentences with zero waste. The purpose is front-loaded before the usage recommendation, making it easy to parse.

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?

It gives a clear purpose and usage hint, and return values are covered by the output schema. However, with no annotations and 0% schema description coverage, the description omits essential parameter guidance and behavioral safety details, leaving significant gaps 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?

Schema description coverage is 0%, and the description does not mention either parameter. It provides no meaning for 'query' (e.g., acceptable format, natural language vs. keywords) or 'limit' (e.g., max results, default behavior).

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

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

States a specific verb ('search') and resource ('Cloudflare configuration/architecture guidance'), and clarifies it returns targeted snippets and code samples only. This distinguishes it from sibling API-action tools without needing to name them.

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?

Explicitly says to use this instead of loading manuals or guessing wrangler/wrangler-free API syntax, giving clear context for when to invoke it. No exclusions or named alternative sibling tools are provided, but the guidance is strong.

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 carries the full burden, and it does useful work: it signals a read-only diagnostic by enumerating observable state rather than actions, and discloses that the token is reported in masked form, which is non-obvious behavior. It does not explicitly state that it performs no mutations, but nothing suggests side effects and the output schema covers the response shape.

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

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

A single dense sentence with the action front-loaded and five enumerated checks in a compact list. No filler, no repetition of the tool name, nothing to trim.

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

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

Zero parameters, an output schema present to describe return values, and no annotations to compensate for. The description adequately covers what the tool inspects. A sentence on when it is warranted (e.g., first call in a session) would make it fully complete.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter discussion, and the empty schema is consistent with the free-form diagnostic framing.

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

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

States a specific verb (verify) plus a concrete set of resources it inspects: API authentication, account id, token state, zone mapping, and reachable capabilities. Clearly distinguishable from the sibling tools, which are all resource-specific operations. It stops just short of 5 because 'verify' is a slightly soft verb for what is essentially a diagnostic read.

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

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

Usage is implied rather than stated: an agent can infer this is a preflight/diagnostic check to run before other Cloudflare calls or when auth/account questions arise. There is no explicit when-to-use, when-not-to-use, or named alternative among the siblings. Adequate but leaves the routing decision to inference.

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

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

With no annotations, the description must carry the behavioral burden. 'List' strongly implies a read-only, non-destructive operation, and an output schema covers the return shape. However, it says nothing about permissions, pagination, rate limits, or whether the default result includes or excludes deleted tunnels.

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

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

A single tightly written sentence that front-loads the operation and resource. Every clause earns its place by clarifying what the tool returns; there is no filler.

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 one-parameter list tool with an output schema, the description covers purpose and returned fields adequately. It falls short on the undocumented is_deleted parameter and any usage context, leaving meaningful gaps despite the low complexity.

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

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

The single parameter is_deleted has 0% schema description coverage, so the description must compensate, but it never mentions the parameter or its effect. An agent cannot tell from the description what is_deleted=false (the default) actually filters out.

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 (Cloudflare Zero Trust Tunnels / cloudflared connectors), and even enumerates the returned fields (active status, tunnel id, connectors, configuration). It does not need to differentiate from siblings because no other tunnel-listing tool exists in the sibling set, but it never states scope (all vs. filtered) explicitly.

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

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

There is no when-to-use guidance, no mention of when not to use it, and no named alternative. The sibling list contains no other tunnel tool, so an alternative may not exist, but the definition still gives the agent nothing about appropriate context or prerequisites.

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 carries the full burden. It implies a safe read operation and names the returned fields, but says nothing about pagination, auth requirements, or whether results are scoped to an account.

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

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

A single front-loaded sentence with zero filler; the parenthetical lists the payload concisely.

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

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

An output schema exists so return values need not be explained, and a zero-parameter list tool is low complexity. The only minor omission is any note on pagination or scope.

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 tool takes zero parameters, so there is nothing for the description to clarify beyond the schema. Baseline of 4 applies.

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

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

States a specific verb ('List') and resource ('Cloudflare Vectorize vector database indexes'), and even enumerates the returned attributes. It is unambiguous, though there is no sibling with a similar name to differentiate against.

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

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

No when-to-use or when-not-to-use guidance is given. For a straightforward list tool the usage is largely implied by the name, but the description offers no context about prerequisites or alternatives.

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