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

Annotations already indicate this is a non-read-only, non-idempotent write operation. The description adds valuable behavioral context by disclosing that the response contains bunny.net nameservers and instructing the user to update registrar nameservers afterward.

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

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

The description is two concise sentences, front-loading the main purpose and then providing the essential follow-up action. Every sentence adds meaningful information without waste.

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

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

For a one-parameter create tool with no output schema, the description covers the key follow-up requirement: using the returned nameservers at the registrar. It could mention other likely response fields like zone ID, but the critical post-creation behavior is clearly conveyed.

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

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

The schema description for the single 'domain' parameter is complete and includes an example. The tool description does not add further parameter semantics, but with 100% schema coverage this is acceptable per baseline.

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

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

The description states a specific action, 'Create a new DNS zone for a domain,' with a clear resource and scope. It is immediately distinguishable from sibling tools like bunny_list_dns_zones, bunny_update_dns_zone, and bunny_delete_dns_zone.

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

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

The description implies when to use the tool: when a new DNS zone needs to be created. However, it does not explicitly mention alternatives or conditions for using related tools, such as bunny_update_dns_zone for existing zones.

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

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

Annotations already signal the write nature (reaOnlyHint=false) and non-idempotency (idempotentHint=false), and the description adds context about the default hostname and the caching relationship to origin — a small but real contribution. It does not disclose what happens on name collision, whether the call returns the new zone ID, or that repeated calls create duplicate zones, which are the meaningful unspecified behaviors for a createop. No contradiction with annotations.

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

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

Three short sentences, each earning its keep: the first states the action, the second explains the default hostname and caching output, the third covers the alternative origin mode. The core purpose is front-loaded and there is zero fluff or repetition of schema text.

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 no output schema, the description does not say what the tool returns (e.g., the created zone ID or full hostname), which an agent invoking a create op typically needs. Parameters are fully covered by the schema and safety traits by annotations, so the main remaining gap is the response/confirmation behavior and post-create verification. Reasonably adequate for a low-complexity 4-parameter tool, but not complete.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description's mention that the pullzone 'caches content from the specified origin_url' and that storage_zone_id serves as an alternative origin adds a mild clarification of the either/or relationship between the two origin parameters — but most parameter meaning (name subdomain, type default, origin role) already lives in the schema. The type parameter is not surfaced in the description atall.

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

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

The description opens with 'Create a new CDN pull zone' — a specific verb (create) plus a concrete resource, and the create verb cleanly distinguishes it from the sibling family (update_pull_zone, deete_pull_zone, list_pull_zones, get_pull_zone, purge_pull_zone_cache). It also adds useful specifics — default hostname name.b-cdn.net and origin caching — so aagent has a solid mental model of what the operation produces.

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

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

The description implies usage via the create verb and gives internal guidance on choosing between origin_url and storage_zone_id ('Alternatively… to use a bunny.net storage zone as origin'). However, it never explicitly states when to prefer this tool over bunny_create_video_library or bunny_create_storage_zone, nor does it name the siblings for updating /deleting an existing pull zone. The usage guidance is implied rather than explicit.

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

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

Annotations already indicate this is a mutating (not read-only) operation and not marked destructive. The description adds useful context about optional replication for geo-redundancy and the default primary region, but it does not disclose side effects like billing, propagation, or duplicate-name behavior.

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

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

The description is three sentences with no filler. The primary action is front-loaded, and the region guidance is concise and directly actionable.

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

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

The description plus schema fully cover the required name and optional region/replication parameters. With no output schema, the description could mention what the created zone returns, but for a create tool the main calling context is sufficiently complete.

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

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

Schema description coverage is 100%, so the description does not need to document parameters. It does add some semantic value by explaining that replication regions are for geo-redundancy and stating the default region, but this mostly mirrors the schema's parameter descriptions.

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

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

The description opens with 'Create a new Edge Storage zone,' a specific verb and resource that cleanly distinguishes it from sibling tools like bunny_list_storage_zones and bunny_create_video_library. It also explains the purpose of the region parameters, so an agent immediately understands what this tool is for.

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 clearly implies this tool is for creating a new storage zone and gives guidance on region selection, but it does not explicitly contrast it with list/get storage zone tools or other create tools. However, the resource-specific wording and sibling names make the intended use unambiguous.

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

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

Annotations already convey that this is a non-read-only mutation and is not idempotent. The description adds the product scope and replication purpose but does not disclose deeper behavioral traits such as cost implications, required billing status, or whether the returned object contains credentials/IDs. No contradiction with annotations.

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

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

Two sentences with no filler: the first front-loads the action and resource, and the second cleanly covers the optional parameter. 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 two-parameter create with fully documented schema and mutation annotations, this is mostly adequate. However, there is no output schema and the description never mentions what the call returns (e.g., library ID/credentials), which is an important gap for an agent that must use the created library afterward. It also does not mention prerequisites such as billing or region availability.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by labeling replication_regions as optional and linking them to 'geo-redundant storage', which goes beyond the schema's bare listing of region codes; it also frames 'name' as the video library name via context.

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

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

The description states a specific verb and resource ('Create a new Bunny Stream video library') and adds a purpose clause ('for hosting, encoding, and delivering videos'). This distinguishes it from sibling creation tools like bunny_create_storage_zone and bunny_create_pull_zone, whose names alone could be confused with it.

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

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

It provides clear context: use when you need a new video library with optional geo-redundant replication. It does not explicitly name alternatives or exclusions, but the 'Bunny Stream video library' qualifier is enough to route the agent away from storage, DNS, or pull-zone creation siblings.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds crucial context beyond that: records are deleted, DNS resolution stops if nameservers are active. This fully discloses the behavioral impact without contradicting annotations.

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

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

Two sentences with zero waste. The purpose is stated first, followed by the critical consequence. Every sentence earns its place and is immediately scannable.

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

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

For a single-parameter destructive tool, the description, schema, and annotations together provide everything an agent needs: what it does, consequences, and the required parameter. No output schema exists, so nothing is missing.

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

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

Schema description coverage is 100% with a clear 'DNS Zone ID' description. The tool description does not add additional parameter meaning, but the schema already documents it fully, so baseline 3 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?

The description states a specific verb (delete) and resource (DNS zone) with scope (all its records). It clearly distinguishes from sibling tools like bunny_create_dns_zone, bunny_list_dns_zones, and bunny_update_dns_zone by its irreversible nature.

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 provides clear context on consequences (irreversible, stops DNS resolution) and implies it is for permanent deletion. It does not explicitly name alternatives but the warning makes it clear when not to use it (if the zone is needed).

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?

Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds critical behavioral context: the action is irreversible, deletes all configuration, and immediately stops content delivery on all associated hostnames. This meaningfully exceeds what the annotations alone convey.

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 focused sentences with no filler. The core action is front-loaded, followed by scope and consequences. 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?

For a simple one-parameter delete operation, the description is complete. The parameter is fully described in the schema, the destructive and irreversible nature is clearly stated, and no output schema exists, so return-value documentation is not required.

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

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

Schema description coverage is 100% — the single 'id' parameter is documented as 'Pull Zone ID'. The description adds no new parameter-level detail, but the schema already carries the burden, so the baseline of 3 is appropriate.

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 ('delete') and resource ('CDN pull zone') with the full scope of what is removed (hostnames, edge rules, cache). It is unambiguous and clearly distinct from sibling operations like update_pull_zone or purge_pull_zone_cache.

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 does not provide when-to-use guidance or mention alternatives. It explains consequences but never tells the agent when this tool is appropriate versus a non-destructive alternative such as updating or purging the pull zone.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds value by specifying what data will be returned and signaling current-state semantics. No contradiction with annotations.

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

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

Two sentences with no wasted words: the first states the action and payload fields, the second states a concrete use case. Information is front-loaded.

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 getter whose annotations cover safety and whose description enumerates the returned fields, nothing essential is missing. The lack of an output schema is mitigated by the field list.

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 has zero parameters, so parameter explanations are unnecessary; the schema coverage is trivially 100%. The zero-parameter 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?

Description uses a specific verb and resource: 'Retrieve the current bunny.net account details' and enumerates the returned fields (email, name, balance, billing type, features, flags). It is clearly distinct from the many sibling tools that target pull zones, DNS, storage, video, or edge scripts.

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

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

The description explicitly says to use it to check account status or remaining balance before provisioning resources. It does not name alternatives or when-not-to-use, but no sibling is a better fit for account-level overview, so the guidance is sufficient.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no safety contradiction exists. The description adds value by specifying exactly what data is returned, including current balance and per-service breakdown, which is useful behavioral context beyond the annotations.

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

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

The description is a single well-structured sentence that immediately states the action and resource, followed by concise examples of the returned content. There is no filler or redundant wording.

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 billing summary tool, the description fully covers what the agent needs to know: what the tool does and what data it returns. No output schema exists, but the listed summary components provide sufficient expectation-setting.

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 has zero parameters and schema coverage is 100%, so the schema imposes no burden and the description does not need to explain parameters. The baseline of 4 applies here.

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 ('Retrieve'), a clear resource ('billing summary for the account'), and enumerates the key contents: current balance, this month's charges, and per-service usage breakdown. It is unambiguous and distinguishes this tool from the many get_* siblings by focusing on billing-specific data.

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 makes the intended use clear: any time an agent needs account-level billing information rather than generic statistics or account details. It does not explicitly name alternatives or exclusions, but the billing-specific scope gives sufficient context among siblings.

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

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

Annotations already convey readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds value beyond these by explaining the conditional dual-mode behavior and giving examples of what a settings update covers ('enable/disable bot categories, adjust thresholds'). It does not describe merge vs. replace semantics, but this is not a glaring omission given the annotations.

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

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

The description is a single, tightly worded sentence pair with no filler. It front-loads the core action and then explains the conditional behavior. Every phrase 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 two parameters, one optional nested object, and no output schema, the description provides enough to make a correct call: the required zone ID, the optional settings, and the difference between update and retrieval. Some detail about the returned configuration shape or the exact allowed settings keys is absent, but the description is reasonably complete given the open-ended schema.

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

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

Schema description coverage is 100%, so both shield_zone_id and settings are already documented. The description adds useful examples about bot categories and thresholds but does not define the internal structure of the settings object. This meets the baseline for schema-covered parameters without significantly extending the semantics.

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 is specific: it names the resource ('bot detection settings for a shield zone') and the two possible verbs ('Retrieve or update'). It clearly differentiates the tool from general zone getters like bunny_get_shield_zone by focusing on bot detection configuration.

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

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

The description gives a clear conditional: if settings are provided, update; otherwise, retrieve current configuration. This tells the agent how to choose behavior with the optional parameter, though it does not explicitly discuss alternatives or when not to use the tool.

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

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

The readOnlyHint annotation already covers the safety profile, so the description does not need to restate that this is a read operation. It adds useful context about the returned statistics, but it does not disclose behavioral details such as date inclusivity, timezone handling, or any limits on the date range.

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

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

The description is a single, well-structured sentence with no filler. It front-loads the action and resource, then adds the key output dimensions, making it easy to scan and understand quickly.

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

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

For a read-only statistics tool with three clearly documented parameters and no output schema, this description is nearly complete. It explains what the caller gets back and clarifies the zone and date-range scope. A note about whether the date range is optional or how defaults behave 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 input schema already documents all parameters: id is the DNS Zone ID, date_from and date_to have format and meaning. The description merely restates the date-range concept and does not add significant new meaning beyond what the schema provides, so the baseline 3 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?

The description uses a specific verb and resource: retrieve DNS query statistics for a zone over a date range. It also names the returned dimensions (total queries, queries by record type, response code distribution), which clearly differentiates it from sibling tools like bunny_get_dns_zone or bunny_get_statistics.

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

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

The description gives clear usage context: it is for DNS query statistics scoped to a zone and a date range. It does not explicitly name alternatives or exclusions, but the zone and date-range scoping is sufficient for an agent to select this tool over account-level or storage-zone statistics tools.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond annotations by disclosing the scope of the returned data (records, nameserver config, SOA, DNSSEC status), which is meaningful context for a tool with no output schema. It does not contradict the annotations — 'Retrieve' aligns with the read-only hints.

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 sentence that front-loads the primary action and retrieval key, then appends the payload scope in one efficient clause. There is zero wasted wording and every segment 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 one-parameter read-only tool with robust annotations, the description is nearly complete: it states the resource, the key, and the response composition. Minor gaps are the absence of not-found/error semantics and not pointing to bunny_list_dns_zones as the source for obtaining the ID.

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

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

Schema description coverage is 100%: the id parameter is already documented as 'DNS Zone ID' with an exclusiveMinimum of 0. The description's 'by ID' adds no new semantic information about the parameter beyond what the schema provides, so the baseline 3 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?

The description uses a specific verb ('Retrieve'), resource ('DNS zone'), and retrieval key ('by ID'), then enumerates the returned payload (DNS records, nameserver configuration, SOA settings, DNSSEC status). This clearly distinguishes it from siblings like bunny_list_dns_zones (which enumerates zones without an ID) and bunny_get_dns_statistics (which returns metrics, not zone configuration).

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

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

The description implies clear usage context: call this when you hold a DNS zone ID and want the full zone configuration. The enumerated return contents signal what kind of requests this tool serves, but it never explicitly names alternatives (e.g., 'use bunny_list_dns_zones to find the ID first') or states when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering safety. The description adds value by enumerating the specific response fields, which is useful behavioral context beyond the annotations. Minor gaps like error behavior are not disclosed, but the bar is lower given the strong 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?

A single, dense sentence that front-loads the action and resource, then lists the returned content categories. There is zero filler or redundant restating of the tool name, making it efficient and 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?

For a simple read-only get-by-ID operation with one required parameter and robust annotations, the description covers the essential behavior and return content. Since there is no output schema, it helpfully names the included detail categories, though it does not specify response structure or error cases, which are minor for this operation.

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

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

The only parameter 'id' is already fully documented in the schema with type, exclusivity, and description. With 100% schema description coverage, the description does not need to add parameter details, and it doesn't—it only implies the ID is used for lookup. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Retrieve') and resource ('edge script details by ID'), and enumerates the exact content returned (configuration, linked pull zones, deployment status, integration type, release history). This clearly distinguishes it from sibling tools like bunny_list_edge_scripts (list vs. get-by-ID) and bunny_get_edge_script_code (code only vs. full details).

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 context of when to use this tool is implied: when you already have an edge script ID and need its full details. However, there is no explicit guidance about when to prefer this over siblings such as bunny_list_edge_scripts or bunny_get_edge_script_code, and no stated exclusion.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the payload is JavaScript source code, but it discloses no further behavior such as response shape or whether unpublished scripts are retrievable. It does not contradict the annotations.

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

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

One sentence with a clear verb, direct object, and no filler. The core information is front-loaded, 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.

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

For a one-parameter, read-only getter, the description and schema together are almost sufficient. A note on the exact return format would be helpful because there is no output schema, but the intended payload 'source code' is clear enough. Minor gap is the lack of contrast with the sibling get_edge_script 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?

The schema documents the single id parameter as an Edge Script ID with exclusiveMinimum >0, so description coverage is 100%. The description adds no extra meaning beyond what the schema already provides, meriting the baseline score.

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 (retrieve) and resource (JavaScript source code of an edge script), making its purpose immediately clear. It distinguishes itself from sibling bunny_get_edge_script by targeting the code payload rather than general script metadata.

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 wording implies this tool is for reading an edge script's source code, but it does not explicitly say when to use it over bunny_get_edge_script or set_edge_script_code. Guidance is only implied, not 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the response contents by listing what details are returned, but it does not describe possible errors, missing-resource behavior, or any other behavioral nuance. This is adequate but not richly 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?

The description is a single, compact sentence with zero filler. It front-loads the primary action and resource, then adds a focused list of relevant detail categories. Every element contributes to the agent's understanding.

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 get-by-id tool with one well-documented parameter, the description is largely sufficient. It specifies the main purpose and the categories of data returned. However, since there is no output schema, a bit more detail about the response shape, not-found behavior, or how this differs from the overview tool 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?

There is only one parameter, and the input schema already documents it fully as 'Application ID' with a required constraint. The description adds no further meaning about the parameter format, scope, or special values. With 100% schema description coverage, the baseline of 3 is appropriate.

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 clearly states the tool retrieves Magic Container application details and enumerates the specific categories included (configuration, endpoints, deployment status, env vars, volumes, regions). It is not a tautology and the verb 'Retrieve' plus resource makes the purpose clear, though it does not explicitly distinguish itself from the very similar sibling bunny_get_mc_app_overview.

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

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

The description gives no explicit guidance about when to use this tool versus alternatives like bunny_list_mc_apps or bunny_get_mc_app_overview. Usage is only implied by the name and the word 'details', which is not sufficient to route an agent confidently among nearly identical sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only behavior is established. The description adds valuable context by specifying that metrics are 'real-time' and by enumerating what the returned overview includes, which goes beyond the structured annotations without contradicting them.

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

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

The description is a single sentence that front-loads the core action and resource, then efficiently lists the key metrics. Every element earns its place, and there is no redundant or filler language.

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

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

For a single-parameter read-only retrieval tool with comprehensive annotations and schema coverage, the description is complete. It tells the agent exactly what the tool returns and includes the notable 'estimated cost breakdown' detail, which would not be obvious from the tool name or schema alone.

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

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

Schema description coverage is 100%, and the sole parameter 'id' is already described as 'Application ID'. The description does not add extra meaning about the parameter beyond what the schema provides, so 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.

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

States the specific verb 'Retrieve' with the resource 'application overview' and enumerates the exact metrics returned: latency, CPU/RAM usage, active instance count across regions, and estimated cost breakdown. This clearly differentiates it from sibling tools like bunny_get_mc_app or bunny_list_mc_apps by focusing on overview metrics rather than app details or list operations.

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 does not mention when to use this tool versus alternatives such as bunny_get_mc_app or bunny_get_account. While the metric list implies a monitoring/overview use case, there is no explicit guidance on selecting this tool over others or any exclusion criteria.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no safety contradiction exists. The description adds useful context about what data is included, but does not disclose additional behavioral traits such as aggregation granularity, timezone handling, date range limits, or 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?

The description is a single, well-structured sentence. It front-loads the action and resource, then provides a concise metric list that adds real value without repetition or noise.

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 straightforward read-only statistics tool, the description and schema cover the essential aspects: what data is returned, the required ID, and the optional date range. An output schema is absent, so more explicit return-format detail could be helpful, but the metric list largely compensates.

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

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

The input schema covers 100% of the parameters with descriptions, including 'Application ID' and date format hints. The description does not add parameter-level semantics beyond framing the date range and the metrics, so the baseline of 3 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?

The description starts with a specific verb ('Retrieve') and identifies the exact resource: historical application statistics. It also enumerates the covered metrics (CPU, RAM, network traffic, latency, volume storage) and limits scope with 'over a date range', making the purpose unambiguous even among many sibling tools.

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 clearly implies when to use this tool: when historical application statistics for CPU, RAM, network, latency, or volume are needed over a date range. It does not explicitly name alternatives or exclusion conditions, but the context is evident from the metric list and date-range wording.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and mutability. The description adds value beyond this by listing the exact error codes that will appear in the logs and stating the tool 'shows exactly why origin requests failed'. This provides concrete behavioral insight into the output content without contradicting annotations.

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

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

The description is three sentences: the primary purpose, a list of returned error codes, and a use-case note. It is front-loaded with the main action, includes essential details, and has no superfluous content. 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?

For a tool with only two fully documented parameters and no output schema, the description is nearly complete. It outlines the nature of the data (error logs with specific error codes) and the primary use case (debugging 502/504). It does not describe the response format or potential pagination, but for a read-only, idempotent call with simple inputs, this is a minor gap.

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

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

Schema description coverage is 100%, with both parameters already documented (date format and pull_zone_id). The description repeats this scope ('for a pull zone on a specific date') but does not add new semantic information about the parameters. At baseline 3 for full coverage, the description's contribution is minimal but not misleading.

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 clearly states the verb 'Retrieve', the resource 'origin error logs', and the scope ('for a pull zone on a specific date'). It also enumerates the specific error codes returned, which differentiates it from generic pull zone or statistics tools. This makes the tool's purpose unambiguous and distinguishable from siblings.

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

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

The description provides explicit usage context by stating 'Essential for debugging 502/504 errors', which tells the agent when to use this tool. It does not explicitly contrast with alternatives or give when-not-to-use scenarios, but the specified use case is strong enough to guide selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description aligns with these by saying 'Retrieve.' The description adds value by specifying what kind of data will be returned (origin URL, hostnames, caching settings, security options, edge rules, optimizer config), which goes beyond the annotations alone.

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

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

The description is a single efficient sentence that front-loads the action and resource before listing the configuration categories. Every phrase earns its place, and there is no redundant or filler wording.

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 getter, the description plus annotations are largely sufficient: the safety profile is covered by annotations, the parameter is fully documented, and the description enumerates the major returned sections. However, there is no output schema and the description does not mention not-found behavior or how to obtain the ID, leaving minor 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?

The input schema already fully documents the only parameter, 'id', including its type, description, and constraint. The description simply refers to 'by ID' without adding additional semantic meaning, so the baseline of 3 applies given 100% schema description coverage.

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

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

The description uses a specific verb ('Retrieve') and a specific resource ('full configuration of a CDN pull zone by ID'), and enumerates the kinds of configuration included. This clearly distinguishes it from list, create, update, and delete operations among the sibling tools.

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 context is only implied: the tool is for retrieving a single pull zone's configuration by ID, while list_pull_zones would be for enumerating zones. There is no explicit statement about when to prefer this over alternatives or when not to use it, but the verb and 'by ID' scope provide reasonable implicit guidance.

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

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

Annotations already carry readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the metric categories returned, but gives no behavioral caveats such as date-range defaults, response aggregation, or relationship to the more specific security rule tools.

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 states the action, resource, scope, and the key returned categories with no redundant words. Every phrase 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 simple read-only metrics retrieval call, the description plus fully documented schema is adequate: required parameter, optional dates, and return categories are all inferable. It would benefit from explicitly noting optional date-range behavior or pointing to sibling tools for details, hence not 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?

Schema description coverage is 100% and the schema already documents shield_zone_id, date_from, and date_to. The description only restates the idea of a date range, adding no 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?

The description names a specific verb ('Retrieve'), a specific resource ('security metrics overview for a shield zone'), and enumerates the metric types (WAF blocks, rate limit triggers, bot detections, DDoS mitigation), making it easy to distinguish from generic shield-zone or WAF-rule tools.

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

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

The phrase 'security metrics overview for a shield zone over a date range' gives clear context for when to call this tool, but it does not explicitly name alternatives or state when not to use it, even though siblings like get_waf_rules and get_bot_detection overlap.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral detail by listing the returned content categories: WAF settings, rate limit rules, bot detection config, and DDoS protection status, which is useful beyond the annotations.

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

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

A single, well-structured sentence that front-loads the action and resource, then provides lookup methods and return scope. No wasted words or redundant repetition of the title.

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 lookup tool with rich annotations and a small, self-explanatory input schema, the description covers the essential information: what it returns and how to identify the resource. It does not explain the exactly-one-ID requirement, but the parameter descriptions already convey the OR constraint.

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?

Both parameters are already documented in the input schema with descriptions clarifying the OR relationship between pull_zone_id and shield_zone_id. The description reinforces that either ID can be used but does not add meaning beyond what the schema provides.

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 ('Retrieve') and resource ('shield zone configuration'), and states the two valid lookup keys (shield zone ID or pull zone ID). It clearly distinguishes this from sibling tools like bunny_list_shield_zones by focusing on a single zone lookup.

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

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

The description implies the correct usage context: call when you need a single shield zone's configuration and have either its shield zone ID or its pull zone ID. It does not explicitly mention using bunny_list_shield_zones when IDs are unknown, but the lookup-by-ID framing gives clear context without needing exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds behavioral detail by specifying time-series output, the included metrics, and the hourly data option. No contradiction with annotations.

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

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

Three sentences, front-loaded with the core purpose, then returning useful detail about output metrics and granularity. Every sentence earns its place with no filler or redundancy.

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

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

Despite lacking an output schema, the description covers the main things an agent needs: scope, date range, return metrics, and granularity. It does not spell out exact response shape or default date behavior, but the optional parameters and full schema descriptions mitigate that gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by framing the tool as account-wide or per-pull-zone, which maps to the pull_zone parameter, and by clarifying that hourly=true produces granular data.

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 ('Retrieve'), a clear resource ('CDN statistics'), and scope ('account-wide or per-pull-zone'). It also lists the returned metric categories, making the tool's purpose concrete and distinguishable from sibling statistics tools like origin errors or billing.

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

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

The description gives useful context: CDN statistics over a date range, with an hourly granularity option. However, it does not explicitly tell the agent when to prefer this tool over related siblings such as bunny_get_mc_app_statistics, bunny_get_origin_errors, or bunny_get_dns_statistics, nor does it state any exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds no further behavioral traits such as auth requirements, rate limits, or side effects, but it does contribute useful context about the response payload (e.g., storage used, file count) which is not present in the schema. Given the annotations already handle the key behavior, this is adequate without being exceptional.

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

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

The description is a single, focused sentence that leads with the action and resource, then lists the key returned attributes. There is no redundancy or filler; every word earns its place. It is an excellent model of conciseness.

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 no output schema, the description compensates by itemizing the expected response fields (primary region, replication regions, connected pull zones, storage used, file count). This gives an agent a good sense of the data returned. It does not cover error cases or edge conditions, but for a simple get-by-ID operation, the essential information is provided. A score of 4 reflects strong completeness given the simplicity and existing annotations.

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 only parameter 'id' is fully described in the schema as 'Storage Zone ID' with exclusiveMinimum 0, so schema coverage is 100%. The description does not add any new details about the parameter itself, but it does indicate that the ID is used to retrieve a specific zone, which is implicit. Baseline of 3 is appropriate since the schema carries the load.

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

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

The description uses a specific verb ('Retrieve'), names the exact resource ('storage zone details by ID'), and enumerates the key fields returned. It clearly distinguishes from sibling tools like bunny_list_storage_zones (collective retrieval) and bunny_get_storage_zone_statistics (metrics) by focusing on a single entity's configuration and usage.

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

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

The description implies usage when you have a specific storage zone ID, but it does not explicitly mention alternatives or exclusions (e.g., 'use bunny_list_storage_zones to enumerate zones'). The context is inferable from the tool name and description but not stated directly, so an agent might not be fully routed to the correct sibling.

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds meaningful behavioral context by specifying the date-range input and the metrics returned, which goes beyond the structured annotation data.

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

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

The description is a single, well-structured sentence that leads with the action and resource, then immediately lists the returned metrics. No filler or redundant phrasing is present.

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 statistics tool with only three parameters, the description adequately covers the purpose and returned data. There is no output schema, so listing the specific metrics is valuable; however, it does not explain behavior when date_from/date_to are omitted, which is a minor gap.

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

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

Schema description coverage is 100%, with every parameter already described meaningfully (Storage Zone ID, end date, start date). The description adds the high-level context of 'usage statistics over a date range' but does not provide additional parameter-level detail 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?

The description uses a specific verb ('Retrieve') with a clear resource ('storage zone usage statistics') and enumerates exactly what metrics are returned: storage space used, file count, and bandwidth consumed. This clearly distinguishes it from sibling tools like bunny_get_dns_statistics or bunny_get_statistics.

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 makes the tool's scope explicit: it is for storage zone usage statistics over a date range. It does not explicitly name alternatives or exclusions, but the resource-specific wording provides clear context for when an agent should select this tool among the many siblings.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds a useful list of returned settings but no new behavioral traits such as auth requirements, rate limits, or side effects; it also does not contradict the annotations.

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

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

The description is a single front-loaded sentence: the core action ('Retrieve video library details by ID') comes first, followed by a compact enumeration of what is returned. No filler or tautology is present.

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 GET with fully documented parameters and strong annotations, the description is complete: it states the needed identifier, the optional access-key flag is in the schema, and the 'including...' list tells the agent what content to expect even without an output schema.

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?

Both parameters are already described fully in the schema: id has type and minimum constraints, include_access_key has a direct boolean description. The tool description adds no parameter-level meaning beyond the schema, so the 100% coverage baseline of 3 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?

The description opens with a specific verb and resource ('Retrieve video library details'), narrows the scope by ID, and then lists the configuration categories returned. This clearly distinguishes it from bunny_list_video_libraries (enumerating libraries) and create/update siblings.

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

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

The 'by ID' phrasing gives a clear contextual trigger: use this when you have a specific library ID and need its full configuration. It does not explicitly name alternatives or say when not to use it, so it misses the strongest possible guidance, but the intended usage is clear.

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

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

The annotations already communicate read-only, idempotent, non-destructive behavior, so the description needs little safety disclosure. It adds useful content scope ('including managed rulessets and custom rules') but no operational behavior such as response format, pagination, error conditions, or authorization needs. No contradiction with annotations.

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

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

One tightly worded sentence that front-loads the action and scope. The mention of managed vs. custom rules is valuable, not redundant, and there is no filler or duplicated schema 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?

For a single-parameter, read-only, idempotent tool with strong annotations, this description is sufficient to invoke it correctly and understand the returned entity category. No output schema exists, so a bit more detail on response shape could have helped, but the simplicity of the operation keeps this gap minor.

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

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

The schema already fully documents the single required parameter shield_zone_id with type and lower bound, so schema coverage is 100%. The description only restates that these rules belong to a shield zone, adding no new detail about how the parameter is interpreted or formatted.

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

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

The description uses a specific verb ('Retrieve') targeting a clear resource ('WAF rules and profiles') scoped to a shield zone. It further clarifies the contents by naming managed rulessets and custom rules, making the tool's purpose immediately distinguishable from sibling management tools like bunny_manage_waf_custom_rule.

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

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

It provides clear contextual framing: this is the read-oriented endpoint for all WAF rules on a shield zone, and the 'manage' siblings imply the alternative for modifications. However, it never explicitly says when to prefer this tool over bunny_manage_waf_custom_rule or when not to use it, leaving the routing to inference.

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

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

Annotations already carry the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), lowering the burden on the description. The description adds behavioral context beyond annotations by specifying what the search covers (five resource types) and that matching is keyword/partial-name based. No contradiction with annotations.

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

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

Three sentences with zero wasted words: first gives the core function, second states what is returned, third gives the use case. The most important information is front-loaded.

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 one-parameter, read-only search tool with rich annotations, the description adequately covers input semantics, resource scope, and return types. It omits minor details such as result limits, case sensitivity, or how results are grouped, but none are critical for an agent to invoke this tool correctly.

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

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

Schema coverage is 100%, but the schema only describes the parameter as 'Search query'. The description adds meaning beyond that by clarifying the query is matched as a keyword or partial name against resource names, which is useful semantic content the schema alone does not convey.

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 ('Search across all bunny.net resources by keyword') and enumerates the five resource types covered. This clearly distinguishes it from per-resource sibling list/get tools like bunny_list_pull_zones, bunny_list_dns_zones, and bunny_list_storege_zones.

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

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

'Use this to find a resource when you only know part of its name' gives an explicit trigger condition that routes the agent to this tool instead of the resource-specific list tools. It does not name exclusion cases or alternatives explicitly, but the stated condition is specific enough to guide selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by specifying that it lists all countries with ISO 2-letter codes and frames the data as static reference material. This is beyond what the annotations alone convey.

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

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

Two concise sentences, each earning its place: the first states exactly what the tool does, the second explains why an agent would need this data. The core action is front-loaded and there is no unnecessary verbosity or repetition of the tool name.

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

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

This is a simple zero-parameter, read-only reference lookup with no output schema. The description tells the agent the data content (countries and ISO codes) and the practical scenarios where that data is used. Nothing essential for correct invocation is missing.

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 has zero parameters and the schema confirms an empty properties object, so there is no parameter behavior to clarify. The description naturally cannot add parameter semantics, but per the rubric the baseline for zero params is 4.

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

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

The description uses a specific verb and resource: 'List all countries with their ISO 2-letter codes.' This is clear and unambiguous. It does not explicitly name or contrast sibling tools like bunny_list_regions, but the country-specific scope is enough to differentiate it for most agents.

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 second sentence explicitly states the use case: reference data for geo-blocking, routing filters, and allowed/blocked country lists on pull zones. This gives clear context for when to invoke the tool, though it does not explicitly mention alternatives or say when not to use it.

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

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

Annotations already declare readOnlyHint=true, so the safe read-only nature is covered. The description adds account-level scope and optional search/pagination, but does not disclose response format, edge cases, or any further behavioral details. This is adequate but not rich.

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 no filler. The action and scope are front-loaded, and the second sentence adds useful domain context about DNS zones corresponding to managed domains.

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 low-complexity, read-only list tool, the description covers the core scope and domain semantics, while the schema handles parameter details. The lack of response format details is slightly noticeable because there is no output schema, but it is not critical for invoking this tool correctly.

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

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

The input schema already fully documents all three parameters with descriptions, defaults, and constraints. The description merely summarizes them as 'optional search and pagination' and adds no additional semantic 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?

The description uses a specific verb ('List'), names the exact resource ('all Bunny DNS zones in the account'), and clarifies optional search/pagination. This clearly distinguishes it from collection-specific tools like get_dns_zone or record management tools.

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 makes the collection-level intent explicit ('all...in the account') and implies use for enumeration/search rather than fetching a single zone. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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

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

Annotations already establish the read-only, idempotent, non-destructive safety profile. The description adds account-wide scope and domain context, but does not disclose behavioral details such as pagination, ordering, or response shape. This matches the lowered bar for annotations but adds limited behavioral information.

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

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

Two sentences with the operative instruction and scope front-loaded. The second sentence provides only a brief, useful definition of the resource, and there is no filler or repetition of schema/annotation 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?

For a zero-parameter, read-only list operation with robust annotations, the description provides all necessary orientation: account-level enumeration and what an edge script is. No output schema exists, but the purpose of the tool makes the list-shaped return value obvious, so nothing critical is missing.

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

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

The schema has zero parameters and 100% description coverage, so the baseline is 4. The description correctly avoids inventing parameter behavior and needs no parameter-level documentation.

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

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

The description uses a specific verb ('List'), names the resource ('Bunny Edge Scripts'), and scopes the operation to 'the account'. This clearly distinguishes it from sibling single-resource tools like bunny_get_edge_script and bunny_manage_edge_script, and the added explanation clarifies what edge scripts are.

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 all … in the account' gives a clear context for when to use this tool: when the agent needs to enumerate edge scripts across the account rather than retrieve, publish, or manage a specific one. However, it does not explicitly name alternatives or state when-not-to-use this tool, stopping short of a 5.

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

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

Annotations (readOnlyHint=true, idemotentHint=true, destructiveHint=false) already carry the safety profile, so the description's burden is lower. It adds the account-wide scope and frames the resource as Docker-image deployments at the edge, but it does not disclose return format or pagination. No contradiction with annotations.

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

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

Two short sentences with the action front-loaded. The second sentence defining Magic Containers is helpful context for placing this tool among 50+ bunnny.net siblings, though it is tangential to actually invoking the call.

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 list tool whose safety profile is covered by annotations, the definition is nearly complete: it states exactly what is listed and at what scope. The response shape is not described and there is no output schema, but 'List' reasonably implies an enumeration of applications.

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

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

The input schema has zero properties and 100% coverage, so the baseline of 4 applies; there is no parameter detail for the description to add. It correctly avoids inventing parameter noise.

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

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

Names a specific verb, resource, and scope: 'List all Magic Container applications in the account'. The resource noun 'applications' distinguishes it from siblings like bunny_list_mc_registries and bunnny_list_mc_regions, and the account scope separates it from per-app tools like bunnny_get_mc_app and bunnny_get_mc_app_oview.

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: it is a zero-parameter list operation, and the Magic Containers explanation helps an agent recognize when the domain applies. However, it never names alternatives or says when to prefer this over the per-app siblings (bunnny_get_mc_app, bunnny_manage_mc_app, bunnny_get_mc_app_oview).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context by specifying what kind of region data is returned (anycast support and capacity status), which supports the listing behavior without contradicting annotations.

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

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

A single front-loaded sentence states the resource, the data included, and the intended use. Every word contributes value and there is no 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?

Given zero parameters, rich annotations, and a simple list-regions operation, the description is complete. It explains what the tool returns, why to use it, and the annotations already communicate safety and idempotency.

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 has zero parameters, so the baseline is 4. The description adds no parameter-level details, but none are needed. It clearly communicates what the listing covers.

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 ('List'), a specific resource ('Magic Container deployment regions'), and the distinguishing content (anycast support, capacity status). It is also clearly differentiated from the sibling bunny_list_regions by specifying 'Magic Container' regions.

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

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

The description explicitly states when to use this tool: 'Use this to choose where to deploy applications.' It gives clear context for selection, though it does not explicitly name alternative tools or state when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only behavior is established. The description adds context about the role of registry credentials but does not disclose response behavior, pagination, errors, or auth requirements beyond what annotations supply.

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

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

Two sentences with no filler. The first sentence front-loads the action and resource, and the second sentence adds meaningful deployment context 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 zero-parameter, safely read-only list tool, the description is sufficient: it identifies the resource, gives examples, and explains practical relevance. It does not describe the exact output shape, but the list-oriented purpose and openWorldHint make this a minor gap.

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

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

The input schema has no parameters, so there is nothing for the description to elaborate on. The zero-parameter baseline of 4 applies, and the description still usefully clarifies what kind of registries are listed.

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 ('List'), a specific resource ('container registries configured for pulling Docker images'), and gives concrete examples (Docker Hub, GHCR, custom registries). This clearly separates it from sibling list tools such as bunny_list_mc_apps or bunny_list_regions.

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 statement that registry credentials are used when deploying private container images implies a use case, but it does not explicitly say when to use this tool versus alternatives or when not to use it. No sibling comparison or exclusionary guidance is provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that results are CDN endpoints with origins, but reveals no additional behavioral nuances such as default pagination behavior, response shape, or side effects of include_certificate. That is acceptable but not exceptional given annotations.

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

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

Two sentences with zero waste. The action and scope are front-loaded, and the explanatory second sentence adds useful domain context without redundancy. It is appropriately sized for a simple list endpoint.

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 low-complexity read-only listing tool, the description plus fully documented schema and safety annotations provide enough information for an agent to call it correctly. The minor gap is lack of explicit feedback about response shape, but no output schema exists and such details are not strictly required.

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?

All four parameters already have descriptive text in the schema, yielding 100% coverage. The description only rephrases that search and pagination are available without adding new meaning beyond the schema. The baseline of 3 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?

The description clearly states the action ('List'), the resource ('all CDN pull zones in the account'), and the scope. It adds a clarifying definition of a pull zone, which helps an agent understand the returned entities. This distinguishes it from get_pull_zone, create_pull_zone, and other pull-zone mutation tools visible in the sibling list.

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 makes it clear that this is the tool for retrieving multiple pull zones, with optional search and pagination. It does not explicitly name when-not-to-use or alternatives like bunny_get_pull_zone for single-zone lookups, but the context is unambiguous enough for a list op.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds conceptual context ('Rate limit rules restrict the number of requests per second from matching clients') but does not disclose additional operational behavior such as pagination, ordering, or response structure. Given the annotation coverage, this is adequate without being rich.

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

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

Two concise sentences. The primary action is front-loaded in the first sentence, and the second sentence gives useful domain context. No wasted words or redundant restatements of the tool name.

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

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

The tool is simple: one parameter, no output schema, and annotations cover the safety profile. The description fully explains what the tool does and the required scope. Minor missing details like return format or relationship to bunny_manage_rate_limit_rule are not critical for a straightforward list operation, so only a small gap remains.

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

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

Schema description coverage is 100% for the only parameter, shield_zone_id, with its own description 'Shield Zone ID'. The tool description reinforces that this belongs to 'a shield zone', but does not add meaningful detail beyond the schema. Baseline 3 is appropriate since the schema already carries the parameter semantics.

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

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

The description uses a specific verb ('List'), a clear resource ('rate limiting rules'), and scopes it to 'a shield zone'. This clearly distinguishes it from sibling tools like bunny_manage_rate_limit_rule (which implies create/update/delete) and other list operations.

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 provides a clear context: use this to list rate limiting rules for a shield zone. It does not explicitly state when to use alternatives like bunny_manage_rate_limit_rule, but the list vs. manage distinction is evident from the tool names and description. No misleading or conflicting usage guidance is present.

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

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

Annotations already convey readOnly, idempotent, and non-destructive behavior. The description adds transparency about the returned fields (IDs, names, pricing tiers, geographic coordinates), which tells the agent what to expect from the call.

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

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

Two concise sentences with no waste. The primary action and resource are front-loaded, and the use-case sentence is brief but informative.

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 list operation, this description is complete: it names the resource, the fields returned, and common use cases. No output schema exists, but the description adequately sets expectations.

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 no parameter meaning to convey. The schema is empty and descriptions need not compensate for any parameter gap.

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

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

States a specific verb ('List all') and a specific resource ('bunny.net CDN edge server regions'), and enumerates the data fields returned. This clearly distinguishes it from sibling tools like bunny_list_countries or bunny_list_pull_zones.

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

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

Provides the intended use cases: choosing routing filters and understanding geo-distribution. Does not explicitly name alternaties or when-not-to-use, but the purpose is narrow enough that little ambiguity remains.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds domain context by explaining what shield zones do, which is useful beyond the structured hints. No additional caveats (pagination, auth, rate limits) are necessary for a zero-parameter 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?

Two succinct sentences with the core action front-loaded. The second sentence adds value by explaining what shield zones encompass, without any fluff or repetition.

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 read-only annotations and no output schema, the description fully conveys what the tool does and why it exists. Nothing essential is missing.

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 has zero parameters, so schema coverage is trivially 100% and there is nothing to document. Baseline for 0 params is 4; the description adds no parameter info, but none is needed.

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 ('Bunny Shield security zones'), and further clarifies that each zone provides WAF, rate limiting, bot detection, and DDoS protection. This clearly differentiates from sibling tools like bunny_get_shield_zone (which retrieves a single zone) and bunny_list_pull_zones (which lists pull zones).

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

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

The purpose is self-evident: use this tool to list all shield zones. The description implies usage without explicit exclusions or alternatives. It does not mention that a single-zone getter exists, but the simple list-all intent is clear enough for the agent.

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

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

Annotations already convey read-only, idempotent, non-destructive behavior, so the description doesn't need to repeat those. The description adds account-level scope and domain context about storage zones being containers with regions/replication that can act as origins. It could mention pagination or deleted-zone handling, but annotations lower the burden.

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 concise sentences with no filler. The action is front-loaded, and the two explanatory sentences about storage zones add useful context without bloating the description.

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

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

The description and schema together cover the tool's purpose, optional parameters, and safety profile. It lacks an explicit statement of return shape or how pagination interacts with 'all', but for a simple read-only list tool with no output schema, this is still adequate for an agent.

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

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

The schema covers all three parameters with descriptions and defaults, so the description need not elaborate. It adds no special meaning beyond what the parameter descriptions already provide, but it also doesn't conflict.

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

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

The description states a specific action ('List'), a clear resource ('all Edge Storage zones'), and the scope ('in the account'). It is easy to distinguish from single-zone retrieval tools like bunny_get_storage_zone because 'all' signals a collection operation.

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

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

The description implies this tool is for enumerating storage zones, and the note about zones serving as origins gives a use case. However, it never explicitly says when to prefer this over bunny_get_storage_zone or how pagination behavior should inform usage.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is well covered. The description adds useful conceptual context by explaining that each library is an isolated container with its own player settings, encoding config, API keys, and DRM/watermark options, which helps the agent understand the domain without contradicting annotations.

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

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

The description is two sentences with no wasted words. The primary purpose is front-loaded in the first sentence, and the second sentence provides concise domain context that helps the agent understand what a video library is. 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?

For a straightforward read-only list operation, the description combined with the schema and annotations is largely complete: it identifies the resource, scope, safety profile, and parameters. It does not describe the response structure, but there is no output schema and the lack is not critical for a simple listing tool.

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

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

The input schema has 100% description coverage and all four parameters (page, search, per_page, include_access_key) are already documented with clear semantics. The tool description adds no parameter-specific meaning beyond the schema, so 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.

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

The description states a specific action ('List all Bunny Stream video libraries in the account') with a clear resource and scope, and it distinguishes this from related video-library tools like bunny_get_video_library, bunny_create_video_library, and bunny_update_video_library. The additional detail about what a library contains further clarifies what this tool operates on.

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 clearly conveys that this tool is for listing all libraries in the account, which makes the primary use case obvious. It does not explicitly name alternatives or exclusion conditions, but the contrast with get/create/update siblings is reasonably inferable from 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?

Annotations already signal readOnlyHint=false and destructiveHint=true, and the description's 'delete' operation aligns with that. It adds useful behavioral detail by requiring a record object for add/update and listing record types, but it does not disclose side effects, whether update/delete require a record ID, or any irreversible consequences beyond what the annotation already implies.

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

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

The description is two sentences with no padding. It leads with the core action, packs the type map into a compact reference, and closes with the object fields. Every word serves a purpose.

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 is adequate for add operations, given annotations cover destructive behavior, but it does not state how update/delete identify the target record or whether a separate record ID is needed. There is no output schema and no mention of return/response behavior, which is a meaningful gap for a mutation tool.

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

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

Schema description coverage is 100%, so this is above baseline. The description adds real value by mapping numeric Type codes to human-readable record types, clarifying the Name field (subdomain or empty for root), specifying Ttl in seconds, and noting that Priority applies to MX/SRV. It does not fully explain when priority/weight/port are required or how update identifies an existing record.

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

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

The description opens with a clear verb-resource pair: Add, update, or delete a DNS record within a zone. It explicitly enumerates the record types and the fields needed for add/update, making its domain unmistakable. This differentiates it from sibling zone-level tools like bunny_create_dns_zone or bunny_get_stonzage_zone.

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 provides clear context: this tool manages DNS records inside a zone, implying use when the target is a record rather than a zone. It does not explicitly name alternatives or give when-not-to-use conditions, so it stops short of a perfect 5.

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

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

Annotations already carry the mutation profile (readOnlyHint=false, destructiveHint=true, idempotentHint=false), so the bar is lower. The description adds the specific mutation semantics — 'delete' removes a rule, 'enable'/'disable' toggles it — which clarifies what gets destroyed. But it says nothing about authentication needs, live-traffic side effects, conflict behavior, or what happens on repeated calls, so it meets the baseline without going further.

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

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

The opening sentences are well-structured and front-loaded, but the ActionType enumeration balloons to well over 200 entries, dominated by UnitTestValidate noise, and then degenerates into corrupted tokens ('253=UnitTestValidate…', 'and more', 'etc...'). The tail bloads the definition to thousands of tokens and degrades trust; the whole definition is not appropriately sized despite its strong lead.

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 four-action tool with a nested open object and no output schema, the description covers action selection and the main upsert payload fields well. It omits the Triggers item shape (array of what — TriggerType/Pattern fields), any result or confirmation format, and error semantics, which an agent will need on the first real upsert. This is adequate but has clear, nameable 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?

The schema describes edge_rule only as an open bag (additionalProperties: {}), so without the description an agent would have zero structure for the tool's most complex parameter. The description supplies the full field contract — ActionType, TriggerMatchingType (0=MatchAny, 1=MatchAll), Triggers, ActionParameter1/2, Description, Enabled — plus a numbered ActionType catalog (0 and up). This is precisely the semantics the schema fails to provide.

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

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

The description opens with a specific verb-resource pairing — 'Manage edge rules on a CDN pull zone' — and grounds it by explaining what edge rules control (redirects, headers, caching, origin routing). It enumerates all four operation modes (upsert, delete, enable/disable), making the scope concrete and clearly distinct from nearby siblings like bunny_manage_edge_script, bunny_manage_waf_custom_rule, and bunny_manage_rate_limit_rule. The corrupt tail of the ActionTypes list does not affect the core purpose statement.

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?

Operational usage guidance is explicit: it maps the upsert action to its parameter contract ('For upsert, provide edge_rule with…') and names what the other three actions do, with edge_rule_id required for them in the schema. However, no alternatives or when-not conditions are stated — the tool relies on its 'edge rules' subject to self-select against the 50+ siblings rather than exclusions or alternative routing.

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

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

Annotations already signal destructive behavior (destructiveHint=true, readOnlyHint=false), so the bar is lower. The description adds the detail about script types and field naming conventions, which goes beyond the schema. It does not disclose potential side effects of update (e.g., full replacement) or constraints, but given annotations cover the destructive nature, a 3 is appropriate.

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

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

The description is two sentences, front-loaded with the main action, then script types, then usage hints. Every sentence serves a purpose: it states the operation, defines an enum-like distinction, and gives field-specific guidance. No fluff or redundancy.

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

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

Given the 5-parameter schema with 100% coverage and no output schema, the description covers the essential context: what actions are possible, what fields are needed per action, and the type meanings. It does not explain the response format, but that is not required without an output schema. The only minor gap is not discussing prerequisites (e.g., that id is needed for update/delete), but the schema already states that. Overall sufficient for an agent to safely invoke.

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

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

Schema coverage is 100%, so each parameter already has a description. The description adds the specific guidance that 'settings' uses BunnyCDN PascalCase field names, which is not in the schema. However, most parameter meaning is already conveyed by the schema, so the description provides marginal added value. Baseline 3 is correct.

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 explicitly states the tool creates, updates, or deletes an edge script, with a specific resource and verb. It also clarifies script types (0=Standalone, 1=Middleware) with their purposes, which distinguishes the core functionality from siblings like code management tools. The scope 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?

The description gives some usage direction (provide name/type for create, settings with PascalCase for update) but does not explicitly contrast this tool with alternatives such as bunny_set_edge_script_code or bunny_manage_edge_script_variables. It implies when to use it (for CRUD operations) but lacks when-not-to-use guidance. The distinction between create and update is clear, but alternatives are not named.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds real behavioral detail: variables are plaintext key-value pairs, secrets are encrypted and 'never returned in plaintext after creation', and the available actions include destructive operations. This goes beyond what the annotations alone convey.

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

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

The description is compact, well-ordered, and every sentence earns its place: resource and purpose, semantic distinction, and action list. It is easily scannable with 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 multi-action management tool, the description covers the essential behavioral distinctions and action set. It does not describe output/responses, but there is no output schema and the annotation context provides the safety profile; the remaining details are adequately handled by the input schema and enums.

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

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

Schema coverage is 100%, so parameter meanings like id, name, value, action, and resource are already documented. The description adds some extra meaning by explaining variable/secret semantics and the upsert behavior, but it does not substantially enrich the schema's parameter descriptions.

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

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

The description clearly identifies the resource ('environment variables or encrypted secrets for an edge script') and enumerates the concrete actions: list, add, update, delete, upsert. This distinguishes it from sibling tools like bunny_manage_edge_script and bunny_set_edge_script_code, making the tool's purpose unambiguous.

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

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

The description implies when to use it: when managing variables or secrets for an edge script. However, it does not explicitly contrast with sibling tools such as bunny_manage_edge_script or bunny_get_edge_script_code, nor does it provide when-not-to-use guidance.

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

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

Annotations already mark destructiveHint=true and readOnly=false, and the description adds a concrete consequence: 'Deleting removes the application and all associated resources.' This goes beyond the boolean annotation and is consistent with the declared destructive nature.

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

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

Three short sentences front-load the action, then the config fields, then the casing convention. Every sentence adds useful information with 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 three- parameter CRUD tool with a nested config object and no output schema, it covers the essential invocation details: actions, required id context via schema, config fields, and destructive deletion behavior. Minor gaps are explicit required config fields and return values, but they do not block correct use.

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

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

The schema already describes all three parameters, so the baseline is 3. The description adds meaning by enumerating config fields (name, dockerImage, port, environmentVariables, regions, autoscaling settings) and the create/update casing distinction, pushing it above the schema alone.

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 starts with a clear action-resource statement: 'Create, update, or delete a Magic Container application.' It also lists the key config fields, making the scope concrete and distinguishing it from read-only siblings like bunny_get_mc_app and bunny_list_mc_apps.

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

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

It provides explicit usage context for each action, including the important format rule ('For create use PascalCase, for update use camelCase'). It does not explicitly name alternative tools or exclusions, but the action scope is clear enough to route an agent correctly.

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

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

The description discloses that this is a mutating operation (add/remove), which aligns with readOnlyHint=false. It adds useful behavioral details beyond annotations: automatic SSL certificate provisioning and the required CNAME setup. No annotation contradiction is present.

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 no filler. The main action is front-loaded, and the operational details (CNAME, SSL) follow naturally. 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?

For a simple tool with three required parameters and no output schema, the description covers the essential before/after behavior: what the action is, what follow-up step is needed, and a notable automatic side effect. It could mention removal-specific implications, but the low complexity and strong schema coverage make this a minor gap.

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

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

The schema already documents id and action with 100% coverage, so the baseline is 3. The description adds value by giving a concrete hostname example and explaining the CNAME relationship, which helps an agent understand what hostname means in context even though the schema already labels the parameter.

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

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

The description opens with a specific verb pair, 'Add or remove', a concrete object, 'custom hostname', and the scope, 'on a CDN pull zone'. The example cdn.example.com makes the resource concrete, and this clearly distinguishes the tool from sibling pull-zone tools like bunny_update_pull_zone or bunny_delete_pull_zone.

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

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

It gives practical context: after adding a hostname, point a CNAME record to the pull zone's b-cdn.net hostname, and notes that SSL is provisioned automatically. It does not explicitly name alternatives or state when not to use this tool, but the intended use case is clear.

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

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

Annotations already provide readOnlyHint=false and destructiveHint=true, and the description aligns by including 'delete.' It adds contextual value by explaining that rate limits block clients over a configured threshold, but it does not disclose side effects such as propagation timing, rule replacement behavior on update, or required permissions. This is adequate but not rich.

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

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

Two sentences with no filler: the action is front-loaded, followed directly by the relevant rule-object fields and a one-line behavioral context. 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?

The description gives enough context for an agent to select and call the tool for create, update, or delete operations. Per-action prerequisites are already documented in the schema (rule required for create/update, rule_id for update/delete, shield_zone_id for create). It could mention response behavior or change propagation, but that is not critical for tool selection.

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?

Top-level parameter descriptions in the schema cover 100% of parameters, but the nested rule object is opaque with additionalProperties: {}. The description compensates by enumerating the rule object fields such as shieldZoneId, requestsPerSecond, and matchValue. It adds meaningful payload guidance beyond the schema, though it does not explain the semantics of each field.

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

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

The description opens with a specific, multi-verb action on a concrete resource: 'Create, update, or delete a rate limit rule.' This clearly distinguishes it from sibling tools such as bunny_list_rate_limit_rules or bunny_manage_waf_custom_rule, which involve different resources or read-only behavior.

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 first sentence makes the tool's intended use clear: call this when an agent needs to mutate a rate limit rule via create, update, or delete. It does not explicitly name alternatives or state when not to use the tool, so it falls short of the strongest guidance, but the mutation scope is immediately obvious from the description.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description's create/update/delete actions are consistent with those. The description adds useful context (the rule object structure and the purpose of custom WAF rules) butdoes not disclose consequences such as whether update replaces or merges the rule or whether delete is permanent/immediate.

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

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

The description is three sentences, front-loaded with the action and resource. The rule-field enumeration is dense but earns its place given the opaque schema. Only the final sentence is mildly explanatory rather than functional, but it is brief and does not bloat the description.

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

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

For a destructive multi-action tool with a nested object and no output schema, the description covers the core operation and rule fields but omits whatthe tool returns on success, prerequisites (shield zone existence) and any propagation/permanence notes. The schema carries the action/parameter relationships, so this is adequate but with identifiable gapps.

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

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

Schema coverage is 100%, so the baseline is 3; the ract that the description enumerates the nested rule object fields (ruleName, ruleDescription, ruleConfiguration with phases, variables, operators, transformations, actionType) provides real value beyond the schema, since the rule parameter is an opaque additionalProperties: {} blob. It partially compensetes for the nested object'slack of structured schema.

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

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

The description states specific verbs (create, update, delete) and a precise resource (custom WAF rule on a shield zone), making the operation unambiguous. It is clearly distinguishable from siblings like bunny_get_waf_rules (read-only) and bunny_manage_rate_limit_rule (a different ruletype), though it does not explicitly name those alternatives.

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: an agent would inferto use this tool when managing custom WAF rules on a shield zone, reinforcedby the explanatory sentence about blocking/allowing traffic based on request attributes. However, there is no explicit when-to-use vs. alternative guidance, no exclusion, and no mention that fetching rules should go through bunny_get_waf_rules.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is known. The description adds behavioral details like 'rolling restart of all pods' and 'stops all running instances', which go beyond the annotations by specifying the exact operational effect. However, it does not disclose timing (e.g., async vs sync), potential errors, or prerequisites, which would enrich transparency.

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

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

The description is a single sentence that front-loads the core purpose and then efficiently lists the three actions with their meanings. It contains no filler or redundant phrasing, and every clause contributes to understanding.

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 two-parameter tool, the description covers the main usage context well. However, it does not mention any prerequisites (e.g., the app must already exist), the nature of the response (even without an output schema, an agent might benefit from knowing if a status object is returned), or whether operations are synchronous. These gaps make it adequate but not 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?

Both parameters have schema descriptions (id: 'Application ID', action: 'Lifecycle action: deploy, undeploy, or restart'), giving 100% coverage. The tool description adds further meaning by explaining what each action actually does (e.g., deploy initiates across regions). This extra context helps an agent choose the correct action without opening the schema.

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

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

The description clearly states the tool's purpose: controlling the lifecycle of a Magic Container application. It enumerates the specific actions (deploy, undeploy, restart) and their effects, which distinguishes it from sibling tools like bunny_get_mc_app (read-only) and bunny_manage_mc_app (likely broader management). The verb-resource pair is specific and unambiguous.

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

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

The description explains what each action does (e.g., 'deploy starts the application across configured regions'), giving context on when to use it. However, it does not explicitly mention alternatives or when not to use this tool, such as 'for other management operations use bunny_manage_mc_app'. The usage guidance is implied but not explicit.

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

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

Annotations already mark this as non-readonly, non-destructive, and idempotent. The description adds meaningful behavioral context by stating that deployment targets all edge servers globally and that either the current or a specified code version can be published. No contradiction with annotations.

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

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

The description is a single concise, front-loaded sentence that states the purpose and scope without filler. The optional release note is the only extra detail and it 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 simple three-parameter operation with full schema coverage and no nested objects, the description covers the core behavior and global deployment side effect. It does not describe return values, but no output schema exists and the operation is straightforward enough that this is a minor omission.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description lightly refers to the optional release note and the ability to choose a version, but it does not add meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description opens with a specific action verb ('Publish a release'), names the resource ('edge script'), and specifies the effect (deploying code to all edge servers globally). This clearly differentiates it from siblings like bunny_set_edge_script_code or bunny_manage_edge_script.

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

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

The description gives clear context for when the operation is appropriate—publishing/deploying a script release—but does not explicitly state when to prefer it over alternatives or mention any exclusions. Usage is implied rather than explicitly guided.

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

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

Annotations already cover non-read-only, non-destructive, and idempotent behavior. The description adds useful context beyond them: it does not delete origin files and forces all edge servers to refetch from origin on the next request, clarifying the exact blast radius.

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

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

Two sentences with no filler. The primary action and scope lead the description, followed by a key non-destructive clarification and a concise pointer to the sibling tool.

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 one-parameter cache purge action, the description covers what it does, what it affects, what it does not affect, and which sibling to use for a different scope. Annotations and schema already supply the remaining operational information.

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 id is already fully described in the schema as 'Pull Zone ID', so schema coverage is effectively 100%. The description adds no additional parameter detail, but none is needed for this simple one-argument 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?

States a specific verb and resource: purge the entire CDN cache for a pull zone. It clearly distinguishes itself from bunny_purge_url by noting it is for the full zone, not a single URL.

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 names the alternative bunny_purge_url and gives the decisive condition: use that tool for single-URL purges. This gives an agent clear routing guidance with no inference required.

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

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

The annotations include destructiveHint=false, indicating the tool is not destructive. The description adds context that origin files remain untouched, which clarifies that cache purging is the only effect. It also explains the wildcard behavior and the fresh-content consequence, going beyond the schema's bare parameter types.

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 concise sentences front-load the core action and outcome, then a relevant usage hint and one clarifying safety note. Every sentence earns its place without extraneous detail.

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, no-output-schema tool, the description covers the purpose, the path-wildcard behavior, and a critical non-destructive guarantee. An agent has enough context to decide when to call it and what to pass, and the absence of return-value details is acceptable since no output schema exists.

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

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

Schema description coverage is 100%, so the baseline is 3; the description earns a 4 by reinforcing the wildcard usage and clarifying that the operation affects only cache, not origin storage. The async parameter is described in the schema and not repeated in the tool description, so no extra meaning is lost.

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 the specific verb 'Purge', the resource 'a specific URL from the global CDN cache', and the expected outcome: 'the next request fetches fresh content from the origin.' The description also distinguishes this from the sibling bunny_purge_pull_zone_cache by focusing on a URL rather than a whole pull zone.

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

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

The description gives practical guidance on when to use the wildcard append for path purges and explicitly says it does not delete origin files. It does not explicitly name alternatives, but the sibling list reveals bunny_purge_pull_zone_cache as the coarser-grained alternative; the URL-level description implies this tool is for targeted URLs rather than whole-zone cache clearing.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, and the description is consistent with all three — it describes a write operation that saves a draft rather than altering live code. The description adds genuinely valuable context beyond annotations: the draft-vs-live behavior, informing the agent that the change is not active until published. No annotation contradiction.

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

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

Two sentences totaling roughly 30 words, with the core action front-loaded and the crucial draft/publish caveat in the second sentence. Every word earns its place — no filler, no restating of the title.

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

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

The main complexity of this workflow — that the update is saved only as a draft and requires a subsequent publish step — is fully covered, and the responsible sibling tool is named. Since no output schema exists, a brief hint about the response shape would add value, but for a simple two-parameter set operation with annotations covering the safety profile, the description is nearly complete.

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

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

Schema coverage is 100%, with both parameters (id and code) already described in the input schema. The description only echoes that the code is JavaScript source, adding no param-level meaning beyond what the schema provides. Baseline 3 applies because the schema carries the semantic load.

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

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

The description states a specific action ('Upload or replace the JavaScript source code') on a clearly identified resource ('an edge script'), matching the tool name directly. It also distinguishes this tool from its siblings — bunny_get_edge_script_code handles the read counterpart, and bunny_publish_edge_script handles deployment — so an agent can tell them apart without inspecting schemas.

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

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

The description maps the workflow explicitly: this tool saves a draft, and the agent is directed to bunny_publish_edge_script to deploy it live, naming an alternative and the condition that selects it. It does not enumerate every when-not-to-use case against other edge-script siblings like bunny_manage_edge_script, but the draft-vs-live distinction covers the primary routing decision.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds a little context by enumerating which settings are common, but it does not reveal update semantics such as whether the settings object is merged or replaces existing values, nor does it mention response behavior.

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

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

The description is a single focused sentence with a compact, front-loaded field list. Every part contributes: the verb, the resource, and the key parameter vocabulary. There is no filler or irrelevant detail.

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 update tool with annotations covering safety and idempotence, the description is mostly adequate. However, it lacks a crucial behavioral detail: whether providing a partial settings object updates only those fields or clears absent ones. It also does not mention what response to expect, though no output schema exists to fill that gap.

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

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

The schema only describes 'id' as a DNS Zone ID and 'settings' as a generic settings object. The description adds meaningful parameter semantics by listing concrete PascalCase field names (CustomNameserversEnabled, Nameserver1, etc.), which helps an agent construct the settings object more accurately.

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 clearly identifies the verb ('Update') and resource ('DNS zone settings'), and it narrows the purpose by listing example settings. It is not as sharp as explicitly distinguishing the tool from sibling DNS operations like bunny_create_dns_zone or bunny_manage_dns_record, but the resource scope 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?

The description provides no guidance on when to use this tool versus alternatives such as creating, deleting, or managing DNS records. It implies that you use it to change an existing zone's settings, but it never states prerequisites, exclusions, or better-suited sibling tools.

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

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

Annotations already establish the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description's job is to add behavioral context, which it does: it discloses the PascalCase field-name convention required by the BunnyCDN API and enumerates the specific updatable fields (OriginUrl, EnableGeoZoneUS, EnableCacheSlice, etc.). This tells the agent what the request payload must look like beyond what the annotations convey. No contradiction with annotations exists — an update is a write, non-destructive, and idempotent.

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

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

The purpose is front-loaded in the first sentence, the encoding convention follows in the second, and the field list is compact — a bare enumeration of names with no fluff. Every sentence earns its place. The 14-item list is the longest element, but it is the primary value the agent needs, so the length is justified rather than padded.

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

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

The definition adequately covers the main usage risk — building a valid settings payload — but it has notable gaps: there is no output schema and the description never states what the tool returns, nor does it clarify whether this is a partial (patch-like) update or a full replace of the settings object. For a mutation tool with a free-form settings object and no output schema, these omissions leave an agent guessing about response handling and update semantics.

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

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

Schema coverage is 100%, but the schema's settings parameter description explicitly defers to the tool description ("See description for common fields"), and the description delivers: it lists 14 concrete BunnyCDN API field names the agent can use to construct a payload. It does not, however, describe types or value formats for those fields (e.g., that Enable* fields take booleans and CacheControlMaxAgeOverride takes an integer), which is why it stops short of a 5.

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

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

The description states a specific verb and resource — "Update pull zone settings" — which clearly distinguishes it from sibling tools like bunny_create_pull_zone, bunny_delete_pull_zone, bunny_get_pull_zone, and importantly bunny_manage_pull_zone_hostnames and bunny_manage_edge_rules, which manage other aspects of a pull zone. The addition of "settings" is meaningful, not a tautology, because it scopes the operation to the settings object rather than hostnames or edge rules.

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: the verb "Update" and the settings-object parameter make it clear this is the tool for modifying existing pull zone settings, but the description never explicitly says when to use it versus alternatives like bunny_create_pull_zone or bunny_manage_pull_zone_hostnames. There are no exclusions or routing conditions, leaving the agent to infer scope from the operation name and sibling 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?

The description adds little behavioral context beyond the annotations. It does not disclose whether settings is a partial merge or full replacement, what the response looks like, error behavior, or the effect of omitting fields. The 'Common fields (PascalCase)' note hints at the API naming convention, but that is more parameter-related than behavioral. No contradiction with annotations (readOnlyHint=false aligns with 'Update'), but the description fails to carry its share of the burden for a write 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?

The description is a single sentence with the purpose front-loaded and no filler. The field enumeration is long but every item is information-bearing, since these are the only documented keys for the open-ended settings object. Each part 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 two-parameter update tool with no output schema, the description covers the most critical need — the accepted field vocabulary — but leaves gaps: it does not state whether settings replaces or merges with existing configuration, what the response contains, or how invalid/unknown fields are handled. The 'Common fields' wording is also vague about whether more fields exist. Adequate but not complete.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds genuine value by enumerating roughly 25 known valid PascalCase field names for the settings object. This is especially useful because the schema declares settings as additionalProperties:{} with no property constraints, so the field vocabulary in the description is the only thing telling the agent what keys are accepted.

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

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

The description opens with a specific verb+resource pair, 'Update video library settings', which precisely identifies the operation. The enumerated field list (Name, CustomHTML, PlayerKeyColor, etc.) further scopes what the tool does and distinguishes it from sibling tools like bunny_update_pull_zone, bunny_create_video_library, and bunny_get_video_library.

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