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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the '[READ]' tag is largely redundant. The description does add the useful context of the official API endpoint mapping, but says nothing about return format or what happens when the domain is not activated.

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, front-loaded fragments with little waste. The endpoint string is mildly extraneous but not harmful.

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 read tool with no output schema, the description is near-adequate, but 'indicate activation' is never clarified and no notion of the result is given, leaving an agent to guess what a useful outcome looks like.

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

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

Schema description coverage is 0% for the single required 'domain' parameter, and the description adds no meaning about the parameter beyond the API path placeholder. The description does not compensate for the coverage 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 (check) and resource (domain NS keys) with a stated purpose (activation status). It distinguishes from siblings like set_domain_nameservers and use_optional_nameservers by being the read-only check counterpart, though 'indicate activation' is somewhat cryptic.

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

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

There is no when-to-use context, no prerequisite information, and no named alternative. The agent must infer that this is the verification step after setting nameservers, which is never 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?

Annotations already declare readOnlyHint=false and openWorldHint=true, so the '[WRITE]' prefix merely duplicates structured data. Nothing is said about global bucket-name uniqueness, required permissions, or side effects of creation, which is where added value would lie for a create tool.

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

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

Very short and front-loaded with the '[WRITE] S3 CreateBucket' core, but the middle sentence about official docs is filler that doesn't earn 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 write tool with no output schema and minimal annotations, the description omits bucket naming constraints, uniqueness semantics, and permission requirements an agent needs to invoke it correctly. It is materially under-specified.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, yet it only repeats the ACL enum values (private|public-read) already present in the schema. The required 'bucket' parameter gets no naming/format constraints at all.

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

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

States a specific verb+resource ('S3 CreateBucket') and flags it as a write, which is enough to separate it from list_buckets, head_bucket, and delete_bucket. However, the trailing references to 'curl + SDK docs' add no purpose information and no explicit sibling differentiation.

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

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

No indication of when to use this versus list_buckets/put_object_text or any prerequisites, region choice, or naming rules. The only implied usage ('S3 CreateBucket') is the tool's own name restated.

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 and openWorldHint=true, so the write and open-world nature is covered structurally. The '[WRITE]' prefix reinforces mutation but adds nothing beyond the annotation. The description does add the useful constraint that values must come from list_database_flavors rather than being invented, but it says nothing about side effects, idempotency, or what happens on failure.

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 compact sentence (despite the bracket tag) front-loads the write marker and endpoint, then gives the parameter sourcing rule. No filler, though the OpenAPI/spec reference is somewhat technical noise for an agent.

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 3-required-parameter write tool with no output schema and only 33% schema coverage, the description is thin. It identifies the endpoint and points to a sibling for valid values, which is genuinely helpful, but omits what the call returns, error conditions, region format specifics (left to schema), and consequences of creation.

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 only 33% (only region has a description), so the description must compensate. It specifies that datastoreType and flavorRef should be obtained from list_database_flavors, which adds sourcing guidance for two otherwise undocumented parameters. This partially compensates but leaves the actual formats, allowed values, and constraints for both parameters unexplained.

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+resource: 'CreateDatabaseRequest: POST /regions/{region}/databases' and the '[WRITE]' marker makes the operation type unambiguous. It doesn't differentiate itself from siblings by name, but the verb+resource pairing is clear enough for an agent to identify the tool.

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 implies prerequisites ('datastoreType + flavorRef from list_database_flavors — do not invent values'), which is a useful directive to consult a sibling first. However, it doesn't state when to use this tool vs. alternatives or what conditions warrant creating a database; the guidance is limited to parameter sourcing rather than usage context.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the agent knows this is a mutating but non-destructive external-facing write. The description adds that value shape depends on type and references docs, plus a duplicate-avoidance workflow. However, it doesn't disclose auth requirements, success/failure semantics, or what the response contains for a complex mutation tool.

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

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

Three short, front-loaded clauses: a write marker, endpoint, and a usage hint. No wasted words, though the docs reference is somewhat terse. Efficient for the space given.

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

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

For a mutation tool with 11 params, nested objects, no output schema, and a 9% schema description coverage, the description is far too sparse. It fails to explain the excluded/mutually-exclusive nature of parameters, type-specific value requirements, or return behavior, leaving the agent underinformed to call it 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 description coverage is only 9% for 11 parameters, so the description must compensate. It only addresses 'value shape depends on type' and omits any meaning for the many undocumented parameters (ttl, cloud, usage, selector, matching_type, ip_filter_mode, upstream_https) and even the base ones. Most parameters remain opaque to the agent.

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

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

States a specific verb+resource ('Create a DNS record'), names the exact API endpoint, and is clearly distinguishable from siblings like update_dns_record, delete_dns_record, and set_dns_record_cloud. The '[WRITE]' tag and endpoint make the operation 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?

Gives a clear directive ('Inspect current records before creating duplicates') which implies using list_dns_records first, and points to docs for value shape. It provides usage context but doesn't explicitly name the sibling tools or state when NOT to use this (e.g., use update_dns_record for existing records).

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 and openWorldHint=true, and the [WRITE] tag is consistent with that. The description adds the HTTP method/endpoint and the required fields, but says nothing about permissions, side effects, or what happens to an existing route on the same domain.

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

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

A single dense sentence with the [WRITE] signal front-loaded and no filler. It is efficient, though the telegraphic OpenAPI-style phrasing borders on under-explanation rather than 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?

For a 4-required-param write tool with no output schema and only partial schema descriptions, the description gives the endpoint and required fields but leaves auth, error behavior, and the role of edge_compute_id unaddressed. It is adequate but not complete for a mutation 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?

Schema coverage is only 25%, so the description must compensate, and it partially does by naming three of the four required parameters (domain, url, status) and the status enum values. However, it omits edge_compute_id, and the url path-pattern format is already supplied by the schema, so it adds only moderate value.

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 (create) and resource (Edge Computing route) and pins it to the concrete endpoint POST /edge-computes/{edgeComputeId}/routes, so it is clearly distinguishable from update_edge_route, delete_edge_route, and list_edge_routes by name alone. It stops short of explicitly naming those siblings, so it is clear but not maximally differentiated.

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 [WRITE] tag signals a mutation, but there is no when-to-use guidance, no prerequisites (e.g. the edge compute must already exist), and no mention of the update/delete alternatives. An agent must infer usage purely from the name and endpoint.

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 and openWorldHint=true, so the write and open-world nature is known. The description adds the HTTP method and endpoint path, plus the action enum values, but does not disclose permissions, side effects, idempotency, or conflict 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 compact and front-loads the write method and endpoint before listing sample fields. 'Official FA samples' is cryptic, but the overall structure is efficient and not 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?

This is a mutation tool with 7 parameters, 4 required, low schema coverage, no output schema, and minimal annotations. The description omits required-parameter guidance, detailed parameter semantics, side effects, and error or return behavior, leaving significant gaps for correct invocation.

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 only 14%, so the description must compensate. It lists several field names—name, note, is_enabled, action, action_details, filter_expr—and implies domain via the URL, but does not explain filter_expr syntax, action_details structure, required status, or the meaning of most fields.

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 [WRITE] tag and POST /domains/{domain}/firewall/rules endpoint make it clear this creates a firewall rule. The resource path is specific, though the description does not explicitly distinguish it from update_firewall_rule or delete_firewall_rule beyond the verb/path.

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

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

There is no guidance on when to use this tool versus alternatives such as update_firewall_rule, nor any prerequisites or conditions. The endpoint alone implies creation but does not tell the agent when creation is appropriate.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the '[WRITE]' tag is redundant with structured data. Beyond that the description adds nothing about side effects, idempotency, permission requirements, whether the rule takes effect immediately, or interaction with existing rules — meaningful gaps for a mutating tool.

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

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

Two short sentences, front-loaded with the operation type and endpoint, with no filler. The brevity is efficient even though the content is thin.

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 12-parameter mutation tool with a nested object (action_details), zero schema descriptions, and no output schema, the description is far too sparse. It names fields but never equips the agent to supply valid values, and it omits any indication of what the call returns or what happens on success.

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

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

Schema description coverage is 0% across 12 parameters, so the description carries the full burden — and it only recites parameter names ('Official samples include url_pattern, rate, time_duration...') without any semantics. Units for rate/time_duration/burst/block_duration, the meaning of action and action_details, and the format of exclude_sources/allowed_methods are all unexplained.

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 identifies a write operation against a specific REST endpoint (POST /domains/{domain}/rate-limit/rules), which does convey the resource and the mutation intent. However, it never explains what a rate-limit rule is or what creating one accomplishes, so it largely restates the tool name plus the URL. The create_ prefix in the name already does most of the sibling differentiation.

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

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

There is no statement of when to use this tool versus update_rate_limit_rule, list_rate_limit_rules, or update_rate_limit_settings, nor any prerequisites (domain existence, plan limits, ordering relative to reprioritize_rate_limit_rules). The agent is left to infer usage entirely from the name.

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 [WRITE] tag and the guidance to never invent UUIDs add useful behavioral context. Annotations already declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is partly covered. The description does not disclose whether creation requires elevated permissions, what happens if the name already exists, or what the response returns.

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?

Single compact sentence with the operation marker front-loaded and the endpoint and parameters in one line. Dense but readable, 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?

No output schema, no annotations covering return format, and only 22% schema coverage. The description covers the call well enough to invoke it, but for a write operation creating a server with 9 parameters, it omits success criteria, error behavior, and any response shape an agent would need to confirm the result.

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 low (22%), with only the region and security_groups parameters having descriptions. The description lists the parameters inline (name, network_id, flavor_id, image_id, security_groups[{name}], ssh_key, key_name, count), which maps the names to the API call but adds no syntax or format details beyond the schema. It does compensate a bit for the low coverage by enumerating parameters, but not enough to reach 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?

States a specific verb (create) and resource (Cloud Server instance) and even the exact HTTP endpoint, POST /ecc/v1/regions/{region}/servers. It is clearly distinguishable from sibling read tools like list_servers, get_server, and power_on_server.

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

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

Explicitly says to obtain IDs from list tools and never invent UUIDs, which is strong guidance for required params. It doesn't spell out when-not-to-use or reference specific sibling list tools by name, but the context 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 declare a non-read-only, non-destructive, open-world operation. The description reinforces the write nature with '[WRITE]' and adds important behavioral context that body fields are undocumented, so the agent should send an empty object unless fields are verified.

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?

Extremely concise and front-loaded: the write nature, action, endpoint, and body caveat are all stated without filler. Every sentence carries actionable 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 write tool with annotations covering safety and no output schema, the description is largely complete: it identifies the action, endpoint, required domain path, and undocumented body behavior. It could be slightly richer by noting how to retrieve the resulting troubleshoot, but that is partly covered by sibling tools.

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 50%, and the description compensates by clarifying that the official endpoint takes the domain in the path and that the optional body is effectively unknown beyond an empty object. This adds meaningful constraint beyond the schema's generic body description.

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 ('Start a new troubleshoot for a domain') and gives the official endpoint. It clearly distinguishes creation from sibling read operations like list_troubleshoots and get_latest_troubleshoot.

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 by saying it starts a new troubleshoot, but it does not explicitly name alternatives or when-not to use it. The body guidance ('send empty object unless you have verified fields') is useful invocation guidance rather than selection guidance.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the [WRITE] tag is largely redundant. Beyond that the description says nothing about side effects, permissions required, or what happens on partial field sets, leaving the mutation profile mostly uncovered.

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, front-loaded with the [WRITE] tag and the operation, then the field list. The 'Official FA/EN API Usage + OpenAPI' preamble is boilerplate that consumes space without adding 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?

A write tool with 8 parameters at 0% schema coverage and no output schema needs substantially more: field semantics, required-vs-optional cues, and any post-creation behavior. The description is far too thin for the complexity.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It only enumerates field names (title, description, secure_link_*, ads_enabled, present_type, campaign_id) without explaining types, allowed values, defaults, or the interaction between secure_link_key/enabled/with_ip. Naming is not 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 [WRITE] marker plus the endpoint POST /vod/2.0/channels make it clear this creates a VOD channel, and the name matches. It implicitly distinguishes itself from the read siblings (get_vod_channel, list_vod_channels) by being the write variant, though it never states the differentiation explicitly.

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

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

No guidance on when to use this versus list_vod_channels, get_vod_channel, or the generic invoke_vod_api sibling. No prerequisites, no notes on what makes a channel valid, no mention of alternatives.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the danger profile is carried by structured data. The description adds a genuinely useful operational constraint (bucket must be empty), but says nothing about irreversibility, required permissions, or the error surfaced on a non-empty bucket.

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, front-loaded sentences with the destructive flag first and the precondition second. The 'FA SDK delete-bucket' parenthetical is mildly redundant with the tool name but costs little.

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 with full annotation coverage and no output schema, the precondition note is the key addition. Still missing are failure behavior (non-empty bucket), confirmation/permission expectations, and any hint about the identifier the agent must supply.

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?

Only one parameter and schema description coverage is 0%, so the description must compensate and it does not — no indication of the identifier format, naming rules, or whether it is a name or an ID. The parameter name 'bucket' is self-evident, keeping this at the minimum-viable 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?

States a specific verb and resource ('Delete Object Storage bucket') and pins the underlying operation ('S3 DeleteBucket'). The bucket-level scope cleanly separates it from the object-level sibling delete_object without the reader needing either schema.

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

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

It gives a precondition ('Bucket must be empty per product docs'), which implies when the call will succeed, but offers no explicit when-to-use vs alternatives guidance and never points at delete_object for the empty-the-bucket-first workflow.

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 readOnlyHint=false, so the safety profile is covered; the description reinforces it with '[DESTRUCTIVE] Permanently delete'. It adds genuinely new behavioral context by forbidding inference of record_id and forbidding multi-delete, which no annotation conveys. It does not describe failure modes or post-delete effects on CDN 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?

Three short, front-loaded fragments: destructive flag first, action second, constraint third. No filler and every clause carries operational value.

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 mutation with annotations and no output schema, the description covers the safety profile, the id precondition, and the endpoint. It is nearly complete; only edge behavior (irreversibility confirmation, effect on related records/domain resolution) is left implicit.

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 50% (record_id documented, domain only constrained by pattern), so the schema carries part of the load. The description adds meaning for record_id ('exact... never infer'), but says nothing about the domain parameter or id format beyond that. Baseline 3 fits a 2-param tool where the schema does most of the work.

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 (permanently delete one DNS record), flags it as destructive up front, and gives the exact API endpoint. It is trivially distinguishable from the sibling DNS tools (list/get/create/update_dns_record) without opening any schema.

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

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

Provides a clear guardrail — 'Requires exact record_id — never infer or delete multiple' — plus the note that the id comes from list/get_dns_record (in the schema). It does not explicitly name a sibling tool or describe prerequisites/escalation paths, so it stops short of full when/when-not guidance.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the '[DESTRUCTIVE]' tag merely repeats structured data with no added value. The description does not disclose irreversibility, permission requirements, or downstream effects on live traffic — the context an agent needs for a delete operation.

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

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

A single compact line with the destructive marker front-loaded. Nothing is wasted, though the 'OpenAPI:' prefix is largely noise for an agent that already has the tool name and schema.

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

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

For a destructive, open-world delete with no output schema and zero parameter documentation, the description is far too thin. It should at minimum state whether deletion is irreversible, what state/impact results, and how to identify the correct route and edge compute.

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

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

Schema description coverage is 0%, so both required parameters are undocumented anywhere. The OpenAPI path template does map edgeComputeId and route_id to their positions, which is marginally useful, but it adds no format, constraint, or lookup guidance to compensate for the coverage 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?

The description states a specific verb and resource (DELETE edge route) and the exact REST path, so the operation identity is clear. However, it offers no differentiation from siblings like update_edge_route beyond the verb, and never explains what an edge route is or what its removal implies.

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

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

No guidance on when to use this versus update_edge_route, list_edge_routes, or whether prerequisites exist (e.g., route must be detached from a deployment). Context is left entirely 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 declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the "[DESTRUCTIVE]" tag is largely redundant. The description does add a genuine behavioral constraint — one rule per call, exact id required — but says nothing about reversibility, error behavior for a nonexistent id, or permission requirements. With annotations carrying the safety profile, this is an adequate but not rich addition.

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 clauses, front-loaded with the destructive warning and the endpoint, with no filler. The bracketed tag duplicates the annotation rather than adding information, which is the only minor 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 destructive mutation with no output schema, the annotations cover the safety profile and the description covers the id requirement, but it omits whether the deletion is irreversible, what happens when the id does not exist, and which tool to use to obtain the id. An agent can call it correctly but must infer the surrounding workflow.

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 50%: rule_id is documented in the schema ("Exact rule id from list/get — never invent") and the description reinforces it with "Requires exact rule_id", but the domain parameter has only a regex pattern and no prose anywhere. The description compensates for the documented half but adds nothing for domain.

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 (DELETE a CDN firewall rule) and even gives the exact endpoint path, which is more than the tool name alone conveys. It is distinguishable from list_firewall_rules, get_firewall_rule, create_firewall_rule and update_firewall_rule, though the differentiation comes mostly from the name rather than from the description explicitly contrasting them.

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

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

"Requires exact rule_id" and "never delete multiple" imply the caller must first resolve the id via list/get, which is useful usage guidance. However, it never names the alternative tools (e.g. update_firewall_rule to modify, list_firewall_rules to find the id) or states when-not to use it, leaving 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 declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, and the '[DESTRUCTIVE]' tag merely restates that. The description adds nothing beyond annotations and schema: no note on overwrite/recoverability, permission requirements, or behavior when the key does not exist.

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?

Very compact and front-loaded: the destructive tag, the operation, and the key constraint come in one line with no filler. It is efficient, though its terseness is partly under-specification rather than pure 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?

For a simple two-parameter delete with annotations covering the safety profile, this is minimally viable. However, with 0% schema description coverage and no output schema, the agent gets no bucket naming rules, key path format, or post-deletion/error semantics from anywhere.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It names both parameters (bucket, key) and adds the semantic that matching must be exact (no prefix/pattern), but supplies no format, naming constraints, or examples for either required 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?

States a specific verb+resource (S3 DeleteObject on an object) and maps it to the SDK operation 'delete-object', which distinguishes it from sibling deletes like delete_bucket or delete_edge_route. It doesn't explicitly contrast with list_objects/put_object_text, 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?

No when-to-use or when-not-to-use guidance, no alternatives named (delete_bucket, put_object_text, head_object are all adjacent siblings). The only conditional information is the precondition 'requires exact bucket+key', which is a requirement, not usage 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?

The '[DESTRUCTIVE]' tag merely restates the already-declared destructiveHint=true annotation, adding no new information. The description does not disclose consequences (permanent removal, effect on live rate-limiting traffic), required permissions, or reversibility, which is the kind of context that would earn credit 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 short line that is front-loaded with the destructive marker and the endpoint, with zero filler. It is efficient, though its brevity borders on under-specification rather than 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?

For a destructive mutation tool with no output schema, the description is far too thin: it omits irreversibility warnings, permission requirements, and any behavioral detail beyond what the annotations already state. An agent can guess the action but has no basis to confirm side effects.

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?

With 50% schema description coverage, the rule_id parameter is well documented in the schema ('Exact rule id from list/get — never invent'), while domain is only implicitly specified. The path template shows where each parameter is placed, which is modest added value, but no format or sourcing guidance is given for domain, so the description neither compensates nor detracts.

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 (DELETE) and resource (rate-limit rule) via the REST path, so the basic action is unambiguous. However, it adds nothing beyond the tool name and does not distinguish this tool from its close siblings delete_firewall_rule, delete_dns_record, or delete_edge_route, which follow the same pattern.

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

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

There is no guidance on when to delete a rule versus disabling, updating, or reprioritizing it, nor any mention of prerequisites such as obtaining the rule id first. The agent is left to infer usage purely from the name and path template.

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 and openWorldHint=true, consistent with the [WRITE] tag, so no annotation is contradicted. But the description adds nothing about deployment behavior - whether it is synchronous, what side effects occur, whether redeployment replaces an existing compute, or what auth is needed - which is a gap for an open-world write tool.

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

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

A single front-loaded line with the [WRITE] marker and endpoint first, then parameters. There is no filler, though the terse API-doc style sacrifices explanatory value for brevity.

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 mutating, open-world tool with no output schema and 0% schema description coverage, the description is too thin - it omits deployment semantics, side effects, and return expectations. It conveys only the endpoint shape and parameter 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?

Schema description coverage is 0%, so the description must compensate, and it does enumerate all four parameters with required (name, bundled_code) vs optional (namespace, tag) marked. That said, the required/optional split duplicates the schema's 'required' array, and it gives no meaning for what bundled_code or namespace represent, so it only partially fills the 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?

The verb 'deploy' plus the resource 'edge compute' identifies the operation, and the [WRITE] marker plus the POST endpoint are useful. However, it never explains what deploying an edge compute actually is or how it differs from siblings like create_edge_route, list_edge_computes, or get_edge_deployment, so the purpose is only minimally distinguished.

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

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

There is no when-to-use guidance at all, no prerequisites, and no reference to alternatives despite a large sibling set containing list_edge_computes, get_edge_compute, and various create_* tools. The description reads as an endpoint stub rather than a usage instruction.

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, openWorldHint, and destructiveHint. The description adds only the [READ] tag, which echoes readOnlyHint, and a confusing sentence about PATCH bodies that does not clarify behavior of this read operation (e.g., return format, pagination).

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

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

Two sentences, front-loaded with the essential HTTP method and endpoint. The second sentence about offline FA documents is cryptic and does not clearly earn its place, making the structure slightly noisy.

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 GET tool with annotations and no output schema, the description gives the endpoint and a hint that the settings relate to CSS/JS optimization. However, it lacks parameter semantics and does not describe what the response contains, leaving some gaps for an agent to fill.

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

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

Schema description coverage is 0% and the single domain parameter has no description. The path template GET /domains/{domain}/acceleration implies the parameter is the domain name, but no format details or constraints are added beyond what the schema pattern already 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 states a specific verb and resource with the [READ] tag and GET /domains/{domain}/acceleration, making it clear this retrieves CDN acceleration settings for a domain. It implicitly distinguishes from the sibling update_acceleration by being read-only, but does not explicitly name the alternative.

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

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

No when-to-use guidance, prerequisites, or alternatives are given. The only contextual hint is a cryptic mention of offline FA documents for PATCH bodies, which does not tell the agent when to select this tool over siblings like get_caching_settings.

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 [READ] marker and GET path restate readOnlyHint=true rather than adding behavioral context. Nothing is said about permissions, error behavior (e.g. what happens with an unknown or unauthorized endpoint_id), or the response shape, so the description adds no value beyond the existing 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?

It is a single short line with no waste and the read tag is front-loaded, but the brevity reflects under-specification rather than disciplined concision.

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, no parameter documentation, and annotations covering only read-only/open-world safety, the description leaves an agent without what an AI endpoint is or what the call returns. For a single-resource getter it is barely adequate.

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 exactly one parameter, endpoint_id, with 0% schema description coverage, so the description carries the burden. The path template hints that endpoint_id identifies the resource, but no format, origin, or lookup semantics are given.

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 essentially restates the name and title: "OpenAPI: GET /endpoints/{endpoint_id}" with a [READ] tag. It confirms a single-resource read, but "endpoints" is generic and it never explains what an AI endpoint is or how it differs from list_ai_endpoints or get_ai_model beyond the HTTP verb and path.

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

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

No guidance on when to call this versus list_ai_endpoints or other get_* siblings is given. An agent must infer that a single endpoint_id lookup is the distinguishing condition, which is never 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, and the bracketed "[READ]" merely repeats that safety profile. No additional behavior is disclosed: no auth requirements, rate limits, error semantics, or meaning of the returned model.

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

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

The single line is maximally brief and front-loaded, with no wasted words, but that brevity stems from under-specification rather than disciplined editing.

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 and a bare one-line description, an agent gets no picture of what an AI model object contains or what a successful call returns. Deferring entirely to the external "OpenAPI" spec leaves the definition inadequate.

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

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

Schema description coverage is 0%, so the schema alone leaves model_id undocumented. The path template /models/{model_id} does tie the parameter to the resource identifier, adding marginal meaning, but no format or sourcing guidance is given.

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 essentially a restatement of the name and title ("Get AI model") plus the raw HTTP verb and path. It conveys retrieval of a model by ID only implicitly, and does not distinguish this tool from the sibling list_ai_models.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of the alternative list_ai_models. The only hint is the GET verb, which an agent must infer means read-one rather than read-many.

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 openWorldHint=true, and the '[READ]' tag merely repeats that. The description adds only the API base URL and version, which is mildly useful for endpoint context but says nothing about what metrics are returned, time ranges, authentication, or rate limits. 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?

A single compact line with no filler, and the read/endpoint information is front-loaded. However, brevity here reflects under-specification rather than disciplined 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 and 0% parameter coverage, the description should explain what metrics are returned and what the bucket parameter expects; it does neither. For a metrics retrieval endpoint, the return-value semantics are the single most important thing an agent needs, and they are absent.

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

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

Schema description coverage is 0%, so the schema only says 'bucket' is a non-empty string. The URL template '{bucketName}' is the sole hint that the parameter is a bucket name, with no format, example, or namespace/account qualification. This barely compensates for the coverage 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?

The description is essentially a restatement of the tool name in URL form ('GET .../buckets/{bucketName}/metrics'), with no statement of what the metrics actually are or what they measure. It identifies the resource and verb only implicitly through the endpoint path, and does nothing to distinguish it from siblings like get_storage_report or list_storage_api_buckets.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as get_storage_report. The endpoint reference implies this returns metrics for one bucket, but nothing tells the agent when this is the right tool versus other storage reporting 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 openWorldHint=true, so the safety profile is covered. The '[READ]' prefix is redundant with readOnlyHint and the description adds no further context such as required permissions, error behavior for missing deployments, or return characteristics.

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?

It is a single terse line with no filler, which satisfies conciseness. But brevity here reflects under-specification rather than efficient communication, since the single sentence is essentially a raw API reference.

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 tool with no output schema, the description should carry more: what the deployment represents, whether the response is a single object, and any scoping constraints. None of that is present, leaving the definition only marginally usable.

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 only 67%; zone and namespace carry their own schema descriptions, but 'name' has no description and the tool description does not explain what the deployment name is or how it relates to namespace. The description adds zero parameter 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 conveys a read of a single deployment resource via the raw HTTP path GET .../deployments/{name}, which implies verb+resource. However it relies entirely on the REST path rather than stating in plain terms what a 'CaaS deployment' is or how it differs from the sibling list_caas_deployments (the get/list distinction is only inferable from the path shape).

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

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

There is no guidance on when to use this tool versus list_caas_deployments, get_caas_pod, list_caas_services, or the generic invoke_caas_api sibling. The agent must infer that this fetches one deployment by namespace+name from the path alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description's only contribution is the redundant [READ] tag — it adds no context about what is returned, whether the zone must be reachable, or any failure/auth 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?

It is a single line with no wasted words and the resource is front-loaded, which is structurally clean. However, the brevity is under-specification rather than genuine conciseness, so it cannot score higher.

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 and no explanatory prose, the description leaves the agent without any sense of what a pod retrieval returns or what 'CaaS pod' means in this API surface. For a three-required-parameter read tool this is substantially incomplete, even though the operation itself is simple.

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 67%: zone and namespace are documented in the schema but name is not. The description adds no parameter meaning at all — it only echoes the path template, leaving the bare 'name' parameter unexplained.

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 line names a verb (GET) and a resource (pods/{name} under a namespace), so an agent can infer it fetches a single pod. But it is framed as a raw OpenAPI path rather than a plain-language statement of purpose, and it does nothing to distinguish itself from siblings like list_caas_pods or get_caas_pod_logs.

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

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

There is no when-to-use guidance whatsoever: no mention of when to call this instead of list_caas_pods, get_caas_pod_logs, or invoke_caas_api, and no prerequisites or context. The only cue is the bracketed [READ] tag, which is not usage 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 declare readOnlyHint=true and openWorldHint=true, so the '[READ]' prefix adds nothing. The description discloses nothing beyond the annotations — no note on log retention, container selection, tail/since behavior, or what happens when the pod has multiple containers.

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?

It is short, but that brevity is under-specification rather than conciseness — the single fragment carries no actionable content beyond the endpoint string, so no sentence earns its place in a useful way.

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 log-retrieval tool with no output schema and only two annotations, the description should at minimum say what is returned (raw log text, which container, how much history). None of that is present, leaving the agent unable to predict the call's result.

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 67% (zone and namespace documented, name not). The description contributes no parameter meaning beyond echoing the path template, so it fails to compensate for the uncovered parameter or to explain log-specific options (container, tailLines, sinceSeconds) that a logs endpoint typically needs.

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 only an endpoint reference plus a redundant '[READ]' tag; it never states in prose that it retrieves logs for a named pod. The GET path does imply the resource (pod log under a namespace), so it is slightly more than a pure restatement of the title, but it is essentially a tautology with the tool name.

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

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

No when-to-use guidance at all. With close siblings like get_caas_pod, list_caas_pods, and invoke_caas_api, the agent gets no help deciding which one applies, nor any prerequisite (e.g. pod must exist/running) for fetching logs.

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 cover readOnlyHint and destructiveHint so safety is clear. The [READ] tag and official GET endpoint add routing context but don't explain auth, output format, or rate limits beyond structured 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?

Two precise sentences with no waste, front-loaded with the key verb and resource followed by the official endpoint for reference.

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 1-param read tool with annotations covering safety, the description is adequately complete, though it could briefly note the response returns caching configuration details.

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

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

Schema coverage is 0% for the single domain parameter, but the required domain is clearly indicated in both schema and endpoint path. The description doesn't significantly enrich meaning beyond what the schema enforces, making baseline 3 appropriate for 1 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?

States a specific verb (Get) and resource (caching settings for a domain), clear enough to distinguish from update_caching_settings and purge_cache among 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 [READ] prefix and GET endpoint imply usage contexts but no explicit when-to-use guidance or named alternatives beyond what the description states.

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 openWorldHint=true; the '[READ]' tag merely echoes readOnlyHint rather than adding new behavioral context. There is no disclosure of return shape, pagination, aggregation granularity, or auth/rate-limit considerations for this report endpoint.

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?

It is a single compact line with no wasted words and front-loads the [READ] marker, but its brevity stems from under-specification rather than efficiency. Every word is 'used' but little useful information is conveyed.

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 report tool with no output schema, the description should describe what the report returns (geo traffic distribution over a period). Instead it gives only the HTTP route, leaving the agent unable to know what data or aggregation to expect.

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 only 50%: 'period' is documented in the schema (including the METRICS_PERIOD note), but 'domain' carries only a pattern with no description. The description's endpoint string mentions {domain} and ?period= but adds no semantic meaning (e.g., what a geo map aggregation returns per period) 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 is essentially a raw endpoint reference ('GET /domains/{domain}/reports/traffics/map?period='), restating technical routing rather than stating in plain language what the tool produces. Only the name/title ('CDN geo traffic map report') convey the geo/map scope, and the description does not differentiate it from siblings like get_cdn_traffic_report, get_cdn_visitors_report, or get_cdn_response_time_report.

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

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

No when-to-use, when-not, or alternative guidance is given. With several sibling CDN report tools (traffic, visitors, response-time, status), the description offers no signal about when the geo/map report is the right choice versus those.

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 openWorldHint=true, so the '[READ]' tag adds nothing. The description does contribute one piece of behavioral context beyond annotations: the plan-tier gate (Professional+). It says nothing about data source freshness, cardinality of returned IPs, or rate limits.

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

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

A single front-loaded line that opens with the [READ] marker and packs endpoint, parameter, and plan gate without filler. It is efficient, though the API-jargon framing ('OpenAPI + ar-prometheus-exporter') costs a little clarity for the space it uses.

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 report tool with annotations covering the safety profile and no output schema, the essentials are present (what it fetches, plan gate). It is still thin on what the report actually contains (top IPs, ordering, counts) and on how it relates to the other CDN report siblings, leaving an agent to infer 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?

Schema coverage is 50%: 'period' is fully documented in the schema (enum, default, description), while 'domain' has no description but a self-explanatory name and pattern. The description merely echoes the period query string and adds no format or semantics beyond the schema, 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 endpoint path '/domains/{domain}/reports/high-request-ips' plus the title state a specific resource (a report of IPs generating high request volume) for a specific domain. It is clear what the tool retrieves, but the description never contrasts itself with the many sibling CDN report tools (traffic, visitors, geo, response-time).

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 only usage-relevant content is the '(Professional+ plans)' prerequisite, which is useful. There is no statement of when to prefer this report over get_cdn_traffic_report or the other CDN reports, and no exclusions or context for the period parameter's intended use.

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 openWorldHint=true, and the description's '[READ]' tag merely repeats that. It adds the upstream source (ar-prometheus-exporter) and the METRICS_PERIOD reference, but says nothing about response shape, latency units, or aggregation that would go 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?

It is a single terse line with the read tag front-loaded, so there is no padding. But it is under-specified rather than genuinely concise, reading as an internal API note instead of an agent-facing definition.

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 should carry more of the burden of explaining what a response-time report returns (metrics, units, time bucketing). Instead it only restates the HTTP route, leaving the agent without enough to know what it will get back.

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

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

Schema description coverage is only 50%: 'domain' has a regex but no prose, while 'period' is documented. The endpoint notation implies domain is a path parameter and period a query parameter, but it adds no meaning about what a domain must be or how period affects the output, so it fails to compensate for the coverage 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?

The title and endpoint string convey that this retrieves a CDN response-time report for a domain, so the verb+resource is inferable. However, it is expressed as a raw REST path dump rather than a statement of purpose, and it does nothing to distinguish itself from siblings like get_cdn_traffic_report or get_cdn_status_report.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the many sibling CDN report tools. An agent must guess whether this or get_cdn_traffic_report / get_cdn_geo_report is the right report for a given need.

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 openWorldHint=true, so '[READ]' is redundant. The only extra information is the underlying data source ('ar-prometheus-exporter') and the literal API path, which is structural rather than behavioral. No details on auth needs, rate limits, report latency, or output shape are provided.

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 text is short, but it is front-loaded with a redundant '[READ]' tag and then a raw endpoint notation rather than a meaningful statement of purpose. The one line is under-specified rather than concise: it omits what the tool does and how the returned report should be interpreted.

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 report tool with no output schema and only minimal annotations, the description is far too thin. It does not explain what the status-code report contains, how the required domain is validated, or how the period affects results, leaving an agent unable to confidently select or invoke it among many similar report tools.

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 50%: the period parameter is documented in the schema, but the required domain parameter has no description. The description references '?period=' but adds no semantics beyond what the schema already says; it does nothing to compensate for the missing domain documentation. The agent learns nothing new about parameter behavior from the description.

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 essentially an API path notation ('GET /domains/{domain}/reports/status') with a source tag, which restates the tool name/title rather than stating the purpose in agent-facing terms. It does not distinguish this status-code report from sibling CDN reports like get_cdn_traffic_report or get_cdn_response_time_report. An agent gets only a hint from the title, not from the description itself.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The description provides no context for choosing this report over the other CDN report siblings. The '[READ]' tag is a static marker, not usage 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 declare readOnlyHint=true and openWorldHint=true, and the '[READ]' tag merely repeats the read-only annotation. The 'ar-prometheus-exporter' note hints at the data source but adds nothing about return shape, aggregation, or freshness. Little value beyond structured 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?

A single front-loaded line with no padding or redundancy. It is efficient, though the terseness reflects under-specification rather than deliberate economy.

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 report tool sitting in a dense family of near-identical CDN report siblings with no output schema, the description is inadequate: it neither disambiguates nor describes the returned data. An agent would struggle to pick it over adjacent report tools.

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 only 50%: 'period' is fully documented by the schema (enum + default + description) while 'domain' has no description. The '?period=' hint adds nothing beyond the schema enum, and the undocumented domain param is left unexplained.

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 conveys a read of a CDN traffic/requests report via a specific endpoint, so the verb+resource is inferable, but it is largely a raw endpoint dump rather than a stated purpose. It gives no differentiation from the many sibling report tools (get_cdn_visitors_report, get_cdn_geo_report, get_cdn_response_time_report, get_cdn_status_report).

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

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

There is no indication of when to use this report versus the other CDN report siblings. No prerequisites, no context, no alternatives are 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 cover readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds essentially no behavioral context beyond the annotations: it discloses nothing about pagination, default period behavior, or what unique-visitor metrics are returned. For a report tool with no output schema, this leaves the return shape undocumented.

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?

It is a single terse line with no padding, so it is concise. But it is not front-loaded with a purpose statement – it leads with an API-notation string that would not read well to an agent, and it is arguably under-specified rather than efficiently concise.

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 report tool with no output schema, no annotations describing return format, and a sibling list full of similar report tools, the description is too thin. It does not explain what the report returns, its dimensions, or how it differs from neighboring report endpoints.

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 50%: 'period' is documented in the schema with its enum and default, while 'domain' has only a pattern and no textual description. The description's 'GET /domains/{domain}/reports/visitors?period=' loosely maps both parameters to their API locations, but adds no meaning beyond the schema. Baseline 3 fits.

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 title 'CDN unique visitors report' and the tool name establish that this returns CDN visitor/analytics data, and the '[READ]' tag signals a read operation. However, the description itself is just an API-path notation ('GET /domains/{domain}/reports/visitors?period=') that restates the tool rather than describing what a 'visitors report' contains. It doesn't distinguish this from siblings like get_cdn_traffic_report or get_cdn_geo_report.

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

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

There is no guidance on when to use this tool versus the numerous other CDN report tools (traffic, geo, response time, status). The description provides no context, exclusions, or alternatives, leaving an agent to infer usage purely from the name.

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=true, destructiveHint=false, openWorldHint=true), so the [READ] tag is largely redundant. What the description does add beyond structured data is the anti-hallucination rule for record_id and the exact upstream endpoint, which is genuinely useful for an agent. It omits error behavior (e.g., what happens on an unknown id), keeping it short of a 5.

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, zero filler, and the core operation is front-loaded before the endpoint and the id-sourcing caveat. Every sentence carries actionable information for the caller.

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

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

For a simple two-parameter read tool with no output schema, the description covers the operation, the upstream endpoint, and the id prerequisite. It leaves a small gap by not characterizing the returned record fields (relevant since no output schema exists) and by not explaining the domain parameter.

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

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

Schema description coverage is 50%: record_id is documented in the schema, while domain carries only a pattern and no description. The description adds sourcing guidance for record_id ("obtain from list_dns_records") but says nothing about what domain means or how it relates to the record_id. With half the parameters undocumented, the description only partially compensates.

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?

"Get one DNS record by id" states a specific verb (get), resource (DNS record), and scope (single record by id), which cleanly separates it from list_dns_records, update_dns_record, and delete_dns_record. The [READ] tag and the concrete REST endpoint (GET /cdn/4.0/domains/{domain}/dns-records/{id}) reinforce the operation and its cardinality.

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 prerequisite and names the sibling that supplies it: "Never invent record_id — obtain from list_dns_records." That tells the agent when this tool is callable and how to prepare for it. It stops short of explicitly stating when to prefer this over list_dns_records for retrieval, but the by-id framing implies that condition.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the underlying endpoint (GET /domains/{domain}/dns-records/dnssec), which is mild extra context, but says nothing about error behavior or what the status payload contains.

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, front-loaded sentences with the read tag and purpose first. The SDK/offline-FA references are somewhat extraneous but do not bury the core statement.

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 tool with annotations covering safety, this is close to adequate, but the dangling mention of 'update actions' on a read-only tool invites confusion and no return-shape information is offered in the absence of 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?

Schema description coverage is 0% and the single 'domain' property carries only a regex pattern and length bounds. The embedded path template '{domain}' at least identifies it as the target domain in the URL, but adds no format or sourcing guidance beyond the schema constraints.

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

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

States a specific verb+resource ('Get DNSSEC status') that maps cleanly onto the sibling update_dnssec pair. However, the trailing clause 'Offline FA also documents update actions' muddies a pure read tool by gesturing at mutation without naming update_dnssec as the route for 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?

The '[READ]' tag implies read-only usage, but there is no explicit when-to-use guidance and no routing to update_dnssec for the modification case it hints at. The agent must infer the read/write split from the 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the '[READ]' tag is redundant. The description does add one piece of non-structured context - the exact upstream route GET /cdn/4.0/domains/{domain} - useful for agents deciding whether to fall back to invoke_cdn_api, but it says nothing about error behavior (e.g. unknown domain) or what data comes back.

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 clauses, front-loaded with the action and resource, with no filler. The '[READ]' prefix is mildly redundant against readOnlyHint=true, but it costs almost nothing.

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-resource lookup with no output schema, the description should ideally sketch what is returned (domain status, configuration, timestamps). It does not, leaving the agent to discover the response shape empirically; the endpoint pointer partially 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?

Schema coverage is 100%: the single 'domain' parameter carries a format example, a length bound and a regex pattern. The description only echoes the path placeholder {domain} and adds no syntax or normalization detail beyond the schema, 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?

States a specific verb and resource ('Get information for one CDN domain'), and the 'CDN' qualifier distinguishes it from the similarly named get_vod_domain, get_live_domain and get_vads_domain siblings. It does not, however, explicitly contrast itself with list_domains, so the differentiation is only implicit.

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: retrieving 'one CDN domain' by name suggests single-resource lookup versus list_domains, but no when-to-use condition, prerequisite, or alternative tool is named. The official endpoint reference hints at the underlying API contract but adds no routing 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?

The annotations already declare readOnlyHint=true and openWorldHint=true, and the description's '[READ]' prefix simply repeats that safety profile without adding anything. It discloses nothing beyond the annotations—no error behavior for missing IDs, no auth/permission notes, no response characteristics.

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 short line, so it is not bloated, but the space is spent on a redundant '[READ]' tag and a path restatement rather than on useful content. Concise but under-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 read tool with no output schema and only safety annotations, the description leaves the agent without resource meaning, parameter semantics, or relationship to sibling tools. It is too thin to call correctly with confidence.

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

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

Schema description coverage is 0% for the single required parameter, so the description must compensate and does not. It implicitly names the path parameter but provides no format, source, or validation guidance for edge_compute_id beyond the schema's minLength constraint.

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 restates the tool name and title as an HTTP endpoint ('GET /edge-computes/{edgeComputeId}') without explaining what an edge compute is or what the returned resource represents. It offers no differentiation from the sibling list_edge_computes or deploy_edge_compute beyond the singular-vs-list convention. This is essentially a tautology of the name.

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

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

There is no when-to-use guidance, no mention of the alternative list_edge_computes, and no stated prerequisites or context for choosing this tool. The agent must infer everything from the name.

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 openWorldHint=true; the description's "[READ]" and "GET" add no behavioral detail beyond them. It does not mention auth, rate limits, return shape, or idempotency, and 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?

The description is a single concise fragment and is front-loaded with the operation and endpoint. However, it is so terse that it lacks any explanatory structure, making it minimally viable rather than well-formed.

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 and no parameters, the description should at least clarify what namespace settings are returned or how the tool relates to other Edge endpoints. It provides no such context, leaving the agent to infer from the name 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?

There are no parameters and schema description coverage is 100%, so the baseline is 4. The description adds no parameter semantics, but none are 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 "[READ] OpenAPI: GET /namespace" essentially restates the tool name and title ("Get Edge namespace settings") without explaining what an Edge namespace is or which settings are returned. It provides no differentiation from the 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?

No when-to-use guidance is given; the description does not mention alternatives such as get_edge_compute, list_edge_routes, or invoke_edge_api, nor any prerequisites. The only hint is the [READ] tag, which is redundant with annotations.

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 openWorldHint=true; the '[READ]' tag merely echoes the read-only hint and adds no new context such as auth requirements, error behavior for unknown ids, or rate limits. It does not contradict the annotations, but adds minimal value beyond 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?

It is very short with no padding, which is good, but what space it uses is spent on a REST path rather than on information the agent needs. Concise without being 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 read-only retrieval tool with no output schema, the description should at least signal what is returned (rule fields, ordering, not-found behavior). Neither the description nor an output schema covers returns, leaving the agent under-informed.

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?

With schema description coverage at 50% (only rule_id is documented, and only with 'never invent'), the description should compensate by clarifying the domain/rule_id contract, but it provides no parameter meaning at all. It leaves the undocumented domain parameter entirely to 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 text is essentially a restatement of the name plus the REST path: 'GET /domains/{domain}/firewall/rules/{id}' tells the agent nothing the name 'get_firewall_rule' didn't already convey. It does not distinguish this tool from siblings like list_firewall_rules or get_firewall_settings.

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

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

No when-to-use guidance, no prerequisites, no alternatives named. The agent must infer that this retrieves a single rule versus list_firewall_rules purely from the name.

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 openWorldHint=true, so the agent knows the safety profile. The description just repeats '[READ]' and provides the raw endpoint, adding no behavioral context like auth requirements, rate limits, or return characteristics.

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 line with the read indicator and endpoint front-loaded, and it contains no filler text. However, its extreme terseness comes at the cost of overall clarity and completeness.

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 tool with no output schema and 0% parameter description coverage, the description is almost entirely endpoint notation. It omits what settings are returned, prerequisites, and any explanation of the required domain parameter, leaving meaningful gaps for an agent.

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

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

Schema description coverage is 0% for the single required domain parameter. The description only shows the {domain} placeholder in the path template, which minimally confirms it is a path parameter but does not explain its format, constraints, or meaning beyond what the schema pattern already implies.

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 GET endpoint for firewall settings, which clearly identifies a read operation on a specific resource. However, it does not explicitly distinguish this settings endpoint from sibling tools like get_firewall_rule or list_firewall_rules beyond the URL path.

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

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

There is no guidance on when to use this tool versus alternatives such as update_firewall_settings or list_firewall_rules. The only implied usage is that it retrieves settings, which is already evident from the name.

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, destructiveHint=false and openWorldHint=true, so the safety and network profile are covered. The description redundantly echoes the read-only nature with the '[READ]' tag and pins the description to a concrete endpoint, which is mildly useful but adds little 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?

Two short clauses, front-loaded with the action, then the API mapping. Nothing wasted, though the '[READ]' tag duplicates the annotation.

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?

No output schema exists, so the description carries the burden of conveying what a 'troubleshoot' contains (status, findings, timestamps) and whether one may not exist for a domain. It does neither, though the endpoint mapping partially compensates for a tool this simple.

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?

Single parameter with 0% schema description coverage — the schema only supplies a regex pattern and length bounds, not meaning. The description implies a domain identifier via the endpoint template '/domains/{domain}/...', which adds a little semantics, but does not clarify the required format or whether a subdomain is acceptable.

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 ('Get') and resource ('latest troubleshoot for a domain'), and the word 'latest' distinguishes it from list_troubleshoots. It stops short of explicitly naming that sibling or create_troubleshoot as the alternative, but the purpose is unambiguous.

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

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

No statement of when to use this versus list_troubleshoots (all troubleshoots) or create_troubleshoot (generate a new one). The 'latest' qualifier implies the selection condition, but the agent must infer 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 and openWorldHint=true. The description adds only a redundant '[READ]' tag and HTTP path; it supplies no new behavioral context such as authentication requirements, rate limits, or what the read returns.

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

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

The description is extremely terse, consisting of a tag and an API path. While it is not verbose, it is under-specified for an agent to understand the purpose, similar to a minimal placeholder definition.

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 and no parameter schema, the description should at least explain what 'LIVE domain settings' are and what the caller receives. It does not, so an agent lacks the context needed to invoke it confidently.

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

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

The tool takes zero parameters, so the schema baseline of 4 applies. There are no parameter semantics for the description to clarify.

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 effectively '[READ] OpenAPI: GET /domain', which restates the HTTP method and path rather than explaining what LIVE domain settings are. It does not distinguish this tool from siblings like get_domain or get_vod_domain, leaving the resource scope ambiguous.

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

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

There is no guidance on when to use this tool versus alternatives such as get_domain, get_vod_domain, or list_domains. No prerequisites or exclusions are mentioned.

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 and openWorldHint=true, and the description's '[READ]' tag merely duplicates that read-only hint without adding anything. It says nothing about auth requirements, error behavior (e.g., what happens for an unknown stream), or return shape, so it contributes no behavior beyond the structured fields.

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?

It is very short and front-loaded with no filler, which is structurally clean, but the brevity comes at the cost of substance rather than from efficient information density. It reads as an auto-generated stub rather than a deliberately trimmed 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 simple single-parameter read tool with no output schema this could be adequate, but the description supplies no parameter meaning, no error/edge-case context, and no relation to the sibling listing tool, leaving the agent with only the endpoint path to work from.

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

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

Schema description coverage is 0% and the single required parameter 'stream_id' is undocumented in both schema and description. The description does not clarify whether 'stream_id' is a UUID, a slug, or a name, nor give format constraints, so it fails to compensate for the coverage 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?

The description is essentially a restatement of the tool name plus the underlying HTTP method and path ('GET /streams/{stream}'). It does convey the resource is a single live stream, but it does not add a specific verb/scope beyond what the name 'get_live_stream' already says, and it does not differentiate from the adjacent 'list_live_streams' sibling.

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

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

There is no when-to-use guidance, no prerequisite conditions, and no mention of alternatives such as list_live_streams for discovering streams. The agent must infer usage entirely from the name.

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 readOnly and openWorld, so the bar is lower. The description adds genuinely useful behavior: a default cap of 256KiB and the rationale of protecting agent context from large binaries. It stops short of saying what happens on truncation.

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 the [READ] marker front-loaded and the cap rationale stated early. Nothing is wasted, though the trailing 'Official API Usage getObject' is low-value 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?

No output schema, so return values need not be explained. For a read tool whose safety profile is covered by annotations, the definition is adequate, but it omits the key edge case: whether content over max_bytes is truncated or errors, and whether binary content is rejected.

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

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

Schema coverage is 0%, so the description should carry the load. It documents max_bytes only partially — the 256KiB default is added value absent from the schema — but leaves bucket/key and the exact truncation semantics of max_bytes unexplained.

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 action and resource: S3 GetObject returning text-ish content. The 'text' qualifier and cap behavior distinguish it from a generic object fetch and from the write-side sibling put_object_text, though no sibling is named directly.

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 text-ish/binary-avoidance framing implies when to use it, but it never names an alternative (e.g., a raw binary get) or states exclusions explicitly. Usage is inferable rather than prescribed.

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 openWorldHint=true; the description's '[READ]' marker merely duplicates readOnlyHint. No additional behavioral context is provided, such as what happens on unknown IDs or the shape of the response. 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?

The single line is compact and front-loaded with no wasted words. However, its brevity reflects under-specification rather than disciplined conciseness, so it earns only a middling score.

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 and a 50%-covered input schema, the description carries most of the burden but supplies only a route echo. An agent gets no information about return value, error behavior, or how this differs from sibling rate-limit tools.

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 only 50% (rule_id documented, domain not), so the description should compensate, but it adds nothing beyond the route template. It does not explain the domain vs rule_id relationship or expected formats.

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 essentially a restatement of the tool name plus an HTTP route: '[READ] GET /domains/{domain}/rate-limit/rules/{id}'. It does not add a specific verb+resource framing beyond what the name 'get_rate_limit_rule' already communicates, and it gives no differentiation from siblings like list_rate_limit_rules or update_rate_limit_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?

There is no guidance about when to use this tool versus alternatives such as list_rate_limit_rules or get_rate_limit_settings. The '[READ]' tag hints at read-only use but does not state conditions, prerequisites, or 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?

The annotations already state readOnlyHint=true and openWorldHint=true, so the [READ] marker and GET path mostly repeat structured data. The description does not add behavioral context such as authentication requirements, whether the endpoint returns all settings, or any side effects.

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, which is concise. However, the parenthetical '(CDN Go SDK; EN/FA rate-limit API table)' is cryptic and likely irrelevant to an agent selecting or invoking the tool, reducing the value of the limited 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 and no parameter description, the definition leaves the agent without an understanding of what rate-limit settings are returned. For a simple read tool this is a notable gap, though the low parameter count limits the damage.

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

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

Schema description coverage is 0%, and the only parameter, domain, is undocumented in both schema and description. The endpoint template shows {domain}, but the description adds no meaning about valid values, format, or domain scoping beyond what the schema pattern already enforces.

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

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

The description gives a specific HTTP verb and resource path: GET /domains/{domain}/rate-limit/settings. This clearly identifies a read operation for rate-limit settings, though it does not explicitly distinguish itself from siblings such as update_rate_limit_settings or list_rate_limit_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?

There is no guidance on when to use this tool versus update_rate_limit_settings, list_rate_limit_rules, or get_rate_limit_rule. The [READ] marker implies a read-only operation, but no conditions, prerequisites, or alternatives are stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the '[READ]' tag adds nothing new. The description discloses nothing about error behavior, required permissions, or what a successful retrieval returns, leaving the behavioral burden entirely on 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?

It is a single short line with the operation type front-loaded, so nothing is wasted. But the brevity here is under-specification rather than efficiency — the terse endpoint notation leaves real gaps that a few more words could have closed.

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 is the only place return values could be described, and it says nothing about the server object returned. For a read tool with an undocumented required parameter, the definition is too thin to let an agent call it confidently.

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

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

Schema description coverage is only 50% (server_id is undocumented), so the description should compensate. Instead it merely echoes the path template '{region}/servers/{id}', adding no format, source, or validation meaning beyond what the schema already shows for region.

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 resource (server) and operation (GET by id within a region), which is more than a restatement of the name. However, it is written as a raw endpoint string rather than plain language, and it does nothing to distinguish itself from siblings like list_servers, list_servers_v3, or the generic invoke_iaas_v1_api, which an agent could otherwise confuse it with.

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

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

There is no when-to-use guidance, no mention of prerequisites (auth, region validity), and no reference to alternative tools. The agent must infer from the name alone that this fetches one existing server rather than listing or invoking the API generically.

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 safety is covered. The description adds only the official endpoint reference and a redundant [READ] tag; it says nothing about auth requirements, response contents, or caching. With annotations carrying the safety profile, this modest addition warrants a 3.

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 front-loaded sentences with no filler; the purpose and the underlying endpoint are both stated immediately. Slightly terse but not wasteful.

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 tool with a single parameter, no output schema, and full annotation coverage, the description is minimally adequate. It omits any hint of what the SSL settings payload contains, which is a minor gap given no output schema exists to document it.

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

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

Schema description coverage is 0% and the sole parameter (domain) has a regex pattern but no prose explanation. The description adds no meaning beyond the name 'domain' — no format, no example, no note on which domain identifier forms are acceptable.

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 clear verb+resource: get SSL settings for a domain, and maps it to a concrete REST endpoint (GET /cdn/4.0/domains/{domain}/ssl). It does not explicitly differentiate from the sibling update_ssl_settings, but the read/mutation split is obvious from the verb.

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

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

There is no when-to-use guidance and no mention of the sibling update_ssl_settings or any prerequisite/context. The only implicit cue is the [READ] tag, which leaves the agent to infer that this is the inspection counterpart to the update 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds nothing beyond them: no indication of what the report covers, its time window, granularity, or whether it requires a specific plan/permission.

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?

It is short and non-redundant, but that brevity is under-specification rather than economy. Front-loading the HTTP verb and path is of limited value to an agent choosing between tools.

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 carries the burden of explaining what the report returns, yet it says nothing about contents, metrics, or period. For a report-generation tool competing with several other report siblings, this is incomplete.

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 are zero parameters, so per the rubric the baseline is 4. The description does not need to compensate for any parameter documentation 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?

The description is essentially a REST route restatement: '[READ] OpenAPI: GET /v1/reports/storage on storage.arvanapis.ir'. It names the resource (storage report) but adds no articulation of subnet or scope, and gives no differentiation from the many other report siblings (get_cdn_status_report, get_cdn_traffic_report, get_bucket_metrics).

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

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

There is no when-to-use guidance, no excluded cases, and no named alternative among the report/metrics tools. An agent must infer usage purely from the tool name.

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 openWorldHint=true, and the "[READ]" tag merely duplicates readOnlyHint. Nothing is said about authentication requirements, behavior when the campaign ID does not exist, or whether the response is a single object. It adds no behavioral context beyond the structured fields.

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?

It is a single short fragment with no wasted words and the read-only nature is front-loaded. However, brevity here reflects under-specification rather than tight editing.

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 tool with no output schema, the description should at least state what the call returns and the expected ID form. It leaves both the parameter meaning and the response shape entirely undocumented, so an agent cannot confidently construct or interpret the call.

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 one required parameter at 0% schema description coverage, and the description only surfaces the path placeholder "{campaign}" without clarifying that it maps to campaign_id, what format an ID takes, or whether it accepts a slug or name. The schema's minLength:1 constraint is the only real specification.

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 essentially the name restated as an HTTP call ("[READ] OpenAPI: GET /campaigns/{campaign}"). It says nothing about what a VADS campaign is or how this differs from siblings like list_vads_channel_campaigns or get_vads_channel. The title carries all the actual meaning.

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

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

No guidance on when to use this tool versus list_vads_channel_campaigns (to enumerate campaigns) or get_vads_channel (to fetch the parent). No prerequisites, no conditions, no alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description's '[READ]' tag merely duplicates readOnlyHint and adds no information about error conditions, ID format expectations, or any limits — nothing beyond what annotations already say.

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 text is only one short line with no filler, so nothing is wasted, but it is under-specified rather than concise — brevity here reflects missing content, not efficient communication.

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

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

For a simple single-parameter read tool with no output schema, the description should at minimum explain what a channel object is and what identifier the agent must supply. None of that is present, and no return-value context exists to offset the 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 0% and the single required parameter channel_id carries no description, minLength constraint documentation, or format hint. The path template {channel} only loosely implies the parameter is a channel identifier, leaving the description failing to compensate for the coverage 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?

The description reduces to "OpenAPI: GET /channels/{channel}", which restates the tool name as a raw HTTP endpoint rather than describing what a Video Ads channel is or what retrieval returns. It signals the operation is a read, but an agent cannot distinguish it from siblings like get_vod_channel, get_vads_domain, or get_vads_campaign based on this text.

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

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

There is no when-to-use guidance, no stated prerequisites, and no mention of any alternative sibling tool. The only implicit signal is that it is a GET against a channels path.

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 openWorldHint=true, so the '[READ]' tag adds nothing beyond structured data. No behavioral context is supplied about what the domain resource contains, whether the read is scoped to an account, or what the response shape is.

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?

It is a single short token string with no filler, so there is nothing to trim. However, the extreme brevity reflects under-specification rather than disciplined conciseness, since no informative content 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?

The operation is simple (no params, no output schema), which lowers the bar, but the description still leaves the agent unable to tell what resource is fetched or how it differs from the many sibling domain getters. Even one clause describing the returned VADS domain object would close the 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 tool takes zero parameters and the schema is fully covered at 100%, so there are no parameter semantics for the description to clarify. Baseline 4 applies for a parameterless operation.

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 essentially restates the name and title, mapping them to an HTTP method and path ('[READ] OpenAPI: GET /domain'), without explaining what a VADS domain is or what the call returns. It gives no basis for distinguishing this from sibling reads like get_vod_domain, get_live_domain, or get_domain.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no reference to any alternative sibling tool. The agent is given nothing to decide when this call is appropriate.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the [READ] tag in the description is purely redundant. Nothing is disclosed about auth requirements, 404 behavior for unknown channel IDs, or rate limits, so the description adds no behavioral context beyond the structured fields.

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?

It is a single terse fragment with zero padding and the resource path is front-loaded, which is structurally fine. But the brevity is under-specification rather than economy, since the line carries almost no decision-relevant 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 get-by-identifier tool with no output schema, the description should at minimum identify what the returned channel represents and the ID format. Instead it supplies only an OpenAPI path reference, which is not enough for an agent to call it confidently against its many siblings.

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?

One required parameter with 0% schema description coverage. The path template '/channels/{channel}' hints that channel_id is a path segment, but the description never clarifies whether it expects an opaque ID, a slug, or a name, leaving the agent to guess the accepted format.

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 essentially a restatement of the tool name in HTTP form: get_vod_channel -> 'GET /channels/{channel}'. It adds only an API version tag and a redundant [READ] marker, and it never says what a VOD channel is or how it differs from sibling get_vod_video / list_vod_channels.

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

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

There is no when-to-use guidance, no prerequisites, and no routing to alternatives such as list_vod_channels (for enumeration) or get_vod_video (for a single asset). The only weak signal is the [READ] tag implying a fetch rather than a mutation.

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 openWorldHint=true; the '[READ]' tag merely duplicates the readOnly hint and adds no new behavioral context. Nothing is said about what the endpoint returns, authentication needs, or side effects beyond what annotations provide.

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 short fragment with no wasted text, so it is technically concise, but its brevity reflects under-specification rather than a well-front-loaded message. It reads as a machine-generated stub rather than a purposeful tool 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 0-parameter read tool with no output schema, the description still should say what domain settings it retrieves and how the result differs from sibling domain reads. It conveys neither, leaving the agent unable to judge whether the return value is useful for its task.

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 and the schema is empty, so the baseline for this dimension is 4 per the rubric. There is no parameter syntax or format the description could usefully add.

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 essentially '[READ] OpenAPI: GET /domain', which restates the tool name and gives an HTTP path rather than explaining what VOD domain settings are returned. It does not distinguish this tool from siblings like get_domain, get_live_domain, or get_vads_domain, which all read domain-related settings.

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

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

There is no explicit statement of when to use this tool versus the many other get_* domain/config tools. The '[READ]' prefix only loosely implies a read context, leaving the agent to infer usage entirely from the name.

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 openWorldHint=true; the description's "[READ]" merely duplicates the annotation. No permission requirements, error behavior, or lookup semantics are disclosed beyond what structured fields provide.

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?

It is short and front-loaded, but brevity here stems from under-specification rather than efficiency. The single fragment carries no actionable content for an agent.

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?

A read tool with one undocumented required parameter, no output schema, and no guidance is left entirely to inference. The description does not supply the semantics that the missing schema coverage and context demand.

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 video_id has 0% schema description coverage, and the description only implies it via the URL template /videos/{video}. No format, ID source, or validation meaning is added, leaving the only parameter effectively undocumented.

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

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

The description is essentially a restatement of the tool name plus the raw HTTP method and path ("[READ] OpenAPI: GET /videos/{video}"). It conveys only that a video is fetched, without stating scope, return content, or how it differs from siblings like list_vod_videos or get_vod_channel — a near-tautology.

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

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

There is no when-to-use guidance, no exclusions, and no mention of alternative tools. An agent gets no signal about choosing this over list_vod_videos or invoke_vod_api.

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 openWorldHint=true, and the description's '[READ]' tag merely restates that. It adds no non-duplicative behavior: it omits the key trait of a HeadBucket call (success/failure signaling when the bucket is absent) and says nothing about permissions or error responses.

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?

It is a single short line and front-loaded, so it is not verbose. But it is under-specified rather than genuinely concise — the brevity comes from omission of substance, not from economy.

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?

No output schema exists, so the description must explain what a caller gets back from a 'check exists' call, and it does not. For an existence-check tool the success/failure contract is exactly the missing piece, making the definition incomplete despite its simplicity.

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

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

Schema description coverage is 0% and the single 'bucket' parameter is undocumented in both schema and description. Baseline is softened only because the lone parameter is self-evident from the tool name, but the description contributes no format, naming, or scope detail.

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 concrete operation (S3 HeadBucket) and flags it as a read, and the title supplies 'check bucket exists'. However, the description text itself is a bare identifier plus an SDK reference, so the actual purpose is carried mostly by the title rather than the description, and it never distinguishes itself from the sibling list_buckets or head_object.

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

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

There is no when-to-use guidance at all. The agent is not told when to prefer head_bucket over list_buckets (which would also reveal existence) or how to interpret the result, and no prerequisite or failure condition is mentioned.

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 openWorldHint=true, and the description's '[READ]' prefix merely restates that. It adds nothing beyond annotations: no mention of what is returned (headers/metadata, not content), no error behavior for a missing bucket/key, and no authorization context.

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?

It is a single compact sentence-fragment with no filler, so it wastes little space, but the brevity comes at the cost of clarity rather than being front-loaded informative 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?

For a two-parameter tool with 0% schema coverage, no output schema, and no annotations covering returns, the description should at minimum explain the bucket/key inputs and the metadata-only return. It does none of this, leaving the definition substantially incomplete.

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

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

Schema description coverage is 0% and both required parameters (bucket, key) are undocumented in the schema. The description supplies no meaning, format, or constraint for either, leaving the two most essential inputs entirely unexplained.

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 operation (S3 HeadObject) and the underlying SDK call, and the [READ] tag signals it is a read. However, it never states in plain terms that this retrieves an object's metadata/headers without downloading the body, which is the actual behavior an agent needs to distinguish it from get_object_text or list_objects.

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

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

There is no when-to-use guidance and no mention of alternatives such as get_object_text (to read content) or list_objects (to enumerate keys), even though those siblings exist. An agent must infer the choice purely from the tool name.

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 openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral facts beyond that: the 43-op allowlist, prefix-stripping normalization, and the explicit guarantee that unknown paths are rejected rather than invented. It does not say what a rejected call returns or whether destructive ops require confirmation, but the added constraints are substantive.

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 dense sentences, front-loaded with the [OPENAPI] marker and the scope, then the path rule, then the allowlist/rejection guarantee. Telegraphic but every sentence carries distinct information; 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 destructive, open-world proxy with no output schema, the description covers scope, allowlist size, path handling, and rejection behavior, which is the core an agent needs. It is silent on the shape of error responses, how the 43 allowed operations map to the sibling tools, and any auth expectations, leaving gaps for a tool this broad.

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 only 25% across 4 params; only 'path' carries a schema description. The description partially compensates by explaining path normalization ('/ai/v1 prefix is stripped') and acceptable path forms, which is real meaning beyond the schema. But 'body' is an untyped empty schema and 'query'/'method' semantics get no treatment, so the coverage gap is not fully closed.

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 mechanism and resource: a passthrough OpenAPI proxy exposing 'Full ai-ml-backend 1.0 on /ai/v1' with a 43-op allowlist. An agent understands what the tool is. However, it does not distinguish itself from the many dedicated sibling tools (list_ai_endpoints, list_ai_models, get_ai_dataset) that cover the same AI domain, so an agent cannot tell from this text alone when the proxy is preferred over them.

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

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

Gives operational conditions ('paths may be /endpoints or /ai/v1/datasets', 'prefix is stripped when present') that help an agent form a call, but offers no when-to-use guidance relative to the dedicated list_ai_*/get_ai_* siblings or the other invoke_* proxies. Usage is implied by the resource scope rather than stated.

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

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

Annotations already declare openWorldHint=true and destructiveHint=true. The description usefully adds that the tool is bounded to an allowlist and 'rejects unknown paths — does not invent APIs', which is real behavioral context. However it never warns that POST/PUT/PATCH/DELETE mutate cluster state or notes auth requirements, so it leaves meaningful gaps for a destructive open-world tool.

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

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

Three short sentences, front-loaded with the resource scope, then the concrete-path guidance, then the allowlist boundary. Dense and waste-free, though the allowlist detail could be tightened.

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 an open-world destructive proxy with no output schema, the description covers scope and the allowlist constraint but omits auth expectations, response shape, and error semantics. Adequate to attempt a call, incomplete for calling it confidently.

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

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

Schema description coverage is only 40%, so the description must compensate. It partially does for path (concrete-path example) and zone (embedded in the base path), but says nothing about the body or query objects, leaving half the parameters undocumented. Marginal value over the schema.

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

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

States a specific verb+resource (invoke the Arvan CaaS 1.25 Kubernetes-style OpenAPI) and anchors it to the caas/v2/zones/{zone} base path, which distinguishes it from the other invoke_*_api siblings by domain. It stops short of explicitly naming which sibling to prefer over, but 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?

Implies usage (call CaaS OpenAPI operations) and adds the constraint that only 299 allowlisted ops are accepted, but never states when to reach for this generic invoker versus a dedicated sibling like list_caas_pods or get_caas_pod. No exclusions or alternatives are 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 declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, so the safety profile is covered structurally. The description adds real value beyond them: a 238-op allowlist, a hard reject on unknown paths, and a 'does not invent APIs' guarantee, which tells the agent it will fail rather than hallucinate a route.

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?

Four short clauses, zero filler, with the identity of the tool front-loaded and the routing caveat placed before the allowlist 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 spec-passthrough tool with no output schema, the description supplies the key operational facts an agent needs: which spec, how many operations, that it is a fallback, and that invalid paths are rejected. Only body/query semantics remain thin, which is defensible when the OpenAPI document itself is the reference.

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 only 25%, so method/path are documented (and method has an enum) while body and query are not. The description compensates partially by constraining 'path' to the cdn-4.0.yml spec and mentioning template locations, but says nothing about how body or query values are interpreted for the 238 operations.

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 ('Call any path from CDN OpenAPI 4.181.3') and pins the exact API surface (napi.../cdn/4.0) with an operation count, so it is clearly distinguishable from the sibling invoke_* passthrough tools (storage/iaas/vod/live).

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 routes the agent: 'Prefer named CDN tools when available,' which tells it this is the fallback. It stops short of naming precisely when the escape hatch is unavoidable (i.e., no named tool covers the operation), but the preference ordering is stated plainly.

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=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior — a hard allowlist of 25 ops and rejection of unknown paths — which tells the agent calls can fail on unmatched paths, but says nothing about auth requirements, side effects, or how requests are dispatched.

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 clauses, front-loaded with the API surface and immediately followed by the allowlist constraint. No filler or repeated structured data, though the parenthetical API version is restated near-verbatim.

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, open-world generic invoker with a nested body object, 25% schema coverage and no output schema, the description leaves major gaps: the allowlisted operations are never enumerated or pointed to, no auth/permission guidance, and no hint of what a successful response contains.

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 only 25% (only 'path' is documented), so the description needs to compensate and does not. It never explains the meaning of 'method', 'body' or 'query', nor the shape/field expectations of body for the underlying OpenAPI operations.

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?

It names a specific verb+resource ('Full Edge Computing 1.8.1 surface on edge-computing/v1') and scopes it to 25 allowlisted ops, which distinguishes it from sibling pass-throughs like invoke_cdn_api or invoke_storage_api. It stops short of saying what the Edge Computing surface operationally covers, but an agent can tell which API family it targets.

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 'allowlist: 25 ops' plus 'rejects unknown paths — does not invent APIs' implies usage is bounded to known ec-1.0.yaml operations, which partially routes the agent. However it never says when to prefer this generic invoker over the many typed siblings (create_edge_route, list_edge_computes, deploy_edge_compute), so the choice remains inferential.

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, openWorldHint=true, destructiveHint=true, so the agent knows this is a write-capable, open-world, destructive tool. The description adds the allowlist bound and that unknown paths are rejected, which is useful. It doesn't describe auth requirements, rate limits, or what happens on a partial-batch failure.

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 compact clauses: scope, example, and allowlist constraint. Front-loaded and no filler. Slightly dense with metadata (allowlist count) but still efficient.

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