ArvanCloud MCP Server

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

The description describes a read operation, but the annotation readOnlyHint is false, creating a contradiction. Additionally, the description does not disclose any behavioral traits beyond the operation itself.

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, clear sentence with no unnecessary words. It is well-front-loaded and 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?

The description is adequate for a simple info retrieval tool, but it does not specify what details are returned, and there is no output schema to compensate. More detail would improve completeness.

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

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

The tool has no parameters, and schema coverage is 100%. The description adds no parameter information, but the baseline for zero parameters is 4.

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

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

The description clearly states the tool retrieves current account/project details for Cloud Server, using a specific verb and resource. It distinguishes itself from sibling tools which focus on creating, listing, or managing specific resources.

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

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

The description implies this tool is for account-level information, but it does not explicitly state when to use it versus other tools or provide any exclusion criteria or 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 flag this as a mutation tool (readOnlyHint=false). The description adds that host-key checking is disabled and that auth defaults to SSH settings. It does not disclose error handling, output format, or failure behavior, which are important for a playbook executor.

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 brief and gets the main point across in two sentences plus a note. It is front-loaded but could be slightly more structured to separate prerequisites from behavior.

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

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

Given 9 parameters, no output schema, and no parameter descriptions in the schema, the description is too sparse. It omits critical details such as return values, idempotency, and parameter constraints (e.g., playbook format 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%, so the description must explain parameters. It clarifies that 'playbook' is YAML content and hints at SSH defaults for auth, but does not describe other parameters like 'become', 'extra_vars', or 'timeout'. This leaves significant gaps.

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

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

The description clearly states the action ('Run an Ansible playbook against a host') and specifies the required external dependency. It uniquely identifies this tool among siblings as the only Ansible playbook runner, but lacks explicit mention of the ArvanCloud context.

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

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

The description implies usage for SSH-accessible hosts and notes that host-key checking is disabled for fresh servers, offering some context. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, leaving the decision partially ambiguous.

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 indicate mutation (readOnlyHint=false), but beyond the verb 'attach', the description doesn't disclose behavioral traits (e.g., replaces existing association, error handling, or idempotency). No added value over the implicit action.

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 sentence is efficient and front-loaded. However, it may be too brief, sacrificing completeness 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?

Given no output schema and 5 parameters, the description lacks critical details about return values, success/failure signals, and how parameters interact. Insufficient for an agent to reliably use the tool.

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

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

With 0% schema description coverage, the description adds no meaning to any of the 5 parameters. It doesn't clarify that server_id or port_id may be required, nor explain region or subnet_id context.

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

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

The description uses a specific verb ('Attach') and specific resource ('floating IP') with target ('server/port'), clearly distinguishing it from sibling tools like arvan_detach_floating_ip or arvan_create_floating_ip.

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 alternatives. It doesn't mention prerequisites (e.g., need existing floating IP and server/port) or exclusion cases like when floating IP already attached.

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

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

Annotations already indicate readOnlyHint=false, so the description's mention of 'attach' is consistent but adds no extra behavioral context (e.g., effects on existing network attachments, permission requirements).

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 sentence that efficiently conveys the core action without unnecessary words.

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

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

Despite having 5 parameters and no output schema, the description covers only the fixed IP option; it omits context on region, port security, prerequisites, or return values.

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 0% schema description coverage, the description only partially explains the 'ip' parameter via 'optionally with a fixed IP', but fails to document network_id, server_id, region, or enable_port_security.

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 specifies the action 'attach' and the resource 'network to a server', clearly distinguishing it from sibling tools like 'arvan_attach_volume' or 'arvan_attach_floating_ip'.

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 is provided on when to use this tool versus alternatives; the description lacks any 'when-to-use' or 'when-not-to-use' 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?

The description only says 'attach' but does not disclose behavior beyond annotations. No info on idempotency, side effects, or failure cases.

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 concise (one sentence) and front-loaded. Every word adds value, but it could convey more information without losing 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?

No output schema exists, but the description does not explain return values or outcomes. For a modification tool, it lacks details on success indication, error handling, or post-attach state.

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

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

Schema description coverage is 0% and the description does not explain any parameters. The agent cannot infer the meaning or format of server_id, security_group_id, or 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 clearly states the action (attach) and the objects (security group to a server), distinguishing it from the detach sibling. However, it does not differentiate from other attach tools like attach_floating_ip.

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 usage guidelines provided. It does not specify when to use this tool vs. alternatives, nor any prerequisites or conditions.

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 indicate this is a mutation (readOnlyHint=false) but description adds minimal behavioral context beyond that, only specifying the resource type example.

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, front-loaded sentence with no unnecessary words; very 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?

Lacks details on return value, error conditions, parameter relationships, or prerequisites, making it incomplete for a 4-parameter tool with no 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 coverage is 0% and description does not explain the four parameters; only loosely hints at instance_type via the example 'server'.

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

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

The description clearly states the action ('attach a tag') and the target ('a resource (e.g. a server)'), distinguishing it from sibling tools like arvan_detach_tag and arvan_list_tags.

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 alternatives (e.g., when to use arvan_create_tag first), nor 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?

Annotations already indicate mutability (readOnlyHint=false) and non-destructive nature. The description aligns with annotations but does not add additional behavioral context, such as whether the volume must be unattached or if the server must be running.

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, clear sentence that is straightforward and front-loaded. It is concise but could include more information without becoming verbose.

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

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

Given the tool has three parameters, no output schema, and no parameter descriptions, the description fails to provide sufficient context about return values, side effects, or prerequisites, making it incomplete for effective use.

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

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

With 0% schema description coverage, the description should provide parameter details, but it does not. The parameter names (volume_id, server_id, region) are somewhat self-explanatory, but the description adds no value beyond the schema.

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

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

The description uses a specific verb ('Attach') and clearly identifies the resource ('a volume') and the target ('to a server'). It distinguishes well from sibling tools like arvan_detach_volume and arvan_create_volume.

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 is provided on when to use this tool versus alternatives, such as arvan_detach_volume or arvan_create_volume. There is no mention of prerequisites or conditions for attachment.

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

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

Annotations already indicate readOnlyHint=true, so the description is not required to disclose read-only behavior. It adds that the tool returns 'mutating tool calls' and 'newest last', but does not describe pagination, rate limits, or truncation behavior. Basic transparency is achieved but lacks deeper details.

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 sentence with no unnecessary words. It effectively communicates the core functionality without redundancy.

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

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

Given the simple tool (one optional parameter, no output schema), the description should at least hint at the return format or the effect of the limit parameter. It does not mention what fields are returned or how ordering works with the limit. This leaves significant gaps for an AI agent to interpret correctly.

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

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

The description does not mention the limit_entries parameter at all. With 0% schema description coverage, the burden falls on the description to explain the parameter, but it fails to do so. The parameter name is somewhat self-explanatory, but no additional semantic guidance is provided.

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

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

The description clearly states the tool returns the most recent mutating tool calls with a specific ordering (newest last). It uses a specific verb 'Return' and a specific resource 'most recent mutating tool calls', distinguishing it from sibling tools that list other resources.

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

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

The description implies usage for retrieving mutating audit logs but does not explicitly provide guidance on when to use this tool versus alternatives like arvan_task_list or other monitoring tools. No when-not-to-use or alternative context is given.

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

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

Annotations already indicate readOnlyHint=true. The description adds that calling without arguments returns a compact overview, and with a key returns endpoints with request-body hints. This goes beyond annotations by detailing the two distinct behaviors.

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

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

Two concise paragraphs. First sentence states purpose, second paragraph explains usage. No wasted words, front-loaded with key 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?

Given the tool's simplicity (one optional parameter, read-only) and presence of an output schema, the description is fully complete. It explains both call variants and the relation to arvan_request.

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 description carries full burden. It explains the optional 'service' parameter well, listing valid keys (compute, network, storage, cdn, dns, vod, live) and the effect of omitting vs. providing it. This adds significant meaning.

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

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

The description clearly states the tool discovers ArvanCloud products and API endpoints. It distinguishes two usage modes: without arguments for a compact overview, and with a service key for detailed endpoint lists. This differentiates it from siblings like arvan_list_servers and arvan_request.

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 guides when to call without arguments (overview) and when to pass a service key (full endpoint list). It also mentions the output can be fed to arvan_request, providing clear direction for the agent.

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

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

Annotations indicate a write operation (readOnlyHint=false) with no destructive or idempotent behavior. Description confirms creation but adds no additional behavioral context (e.g., overwrite behavior, idempotency, 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?

Single concise sentence with front-loaded key information. No wasted words, but may be too sparse. Structure is effective for a simple tool.

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

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

Lacks details on domain parameter, output, error conditions, and differentiation from sibling tools. Without output schema, response expectations are unclear. Tool complexity is moderate, but description is not complete.

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

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

Description adds meaning for two of five parameters (name, ips) by explaining they are linked, but does not describe domain, ttl, or cloud. With 0% schema coverage, this partial coverage is moderately helpful but insufficient.

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

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

Description clearly states it creates an A record, specifying the resource type (A record) and action (create). It mentions name and IPs, distinguishing from CNAME or generic DNS record tools. Lacks explicit differentiation from arvan_create_dns_record, but the type specificity is strong.

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 alternatives like arvan_create_dns_record. The word 'Convenience' suggests a simplified use case, but no explicit context for selection.

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

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

Annotations indicate readOnlyHint=false, confirm it's a mutating operation, but the description adds no extra behavioral context beyond stating 'Create'. It does not disclose potential side effects, idempotency, or what happens if the app already exists for the domain. With annotations already present, the description contributes minimal additional transparency.

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

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

The description is a single, direct sentence with no redundant information. It is appropriately brief and front-loaded with the core purpose.

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

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

Given the complexity of the nested 'app' parameter and the absence of an output schema, the description is insufficient for complete understanding. It does not clarify the configuration format for the app object or any constraints on the domain. Related sibling tools exist, but no guidance links them together.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that 'domain' is the target for the app, but provides no information about the 'app' parameter, which is a complex object with additionalProperties: true. The agent lacks details on what keys or values the object should contain, making it hard to invoke correctly.

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

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

The description clearly states the tool creates a CDN app (edge application) and specifies it's for a domain. The action and resource are unambiguous, and the tool name matches. Among siblings, this is the only tool for creating a CDN app, so differentiation is clear.

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 is provided on when to use this tool versus alternatives like arvan_update_cdn_app, arvan_list_cdn_apps, or arvan_delete_cdn_app. The description does not mention prerequisites, such as requiring an existing domain, or conditions that would make other tools more 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 indicate it's a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description aligns with these and adds no extra behavioral context beyond the basic creation action.

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 that efficiently states the core action. However, it sacrifices completeness for brevity, missing important parameter details.

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

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

Given 5 parameters, no output schema, and low schema coverage, the description is incomplete. It does not explain the domain parameter or optional fields, nor does it describe the return value or behaviors.

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 0% schema coverage, the description partially explains 'name' and 'target' but omits required parameter 'domain' and optional parameters 'ttl' and 'cloud'. This leaves parameters underspecified for an 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?

The description clearly states the tool creates a CNAME record from name to target. The purpose is specific and distinct from sibling tools like arvan_create_a_record, but it does not explicitly contrast 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?

No guidance on when to use this tool over alternatives such as arvan_create_dns_record or arvan_create_a_record. The agent is left to infer usage context without explicit direction.

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

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

The description adds minimal behavioral context beyond the annotations. Annotations already indicate a write operation (readOnlyHint=false), and the description's 'Create' confirms that. No additional traits like idempotency, side effects, or requirements are disclosed.

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 concise and well-structured: a one-line purpose, a note about value shapes, then a bulleted args list. Every sentence adds value without redundancy. It is front-loaded with the core action.

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 create tool with 8 parameters and no output schema, the description covers all parameters but lacks return value clues. It also does not address how the tool interacts with sibling specialized tools. Overall, it is nearly complete but missing post-invocation expectations.

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

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

With 0% schema description coverage, the description provides rich explanations for all 8 parameters, including the complex 'value' parameter type-specific advisory. It explains domain, type (with enum list), name, ttl, cloud, upstream_https, and ip_filter_mode in clear natural language, significantly enhancing the raw schema.

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

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

The description clearly states 'Create a DNS record' with a specific verb and resource. However, it does not differentiate from sibling tools like arvan_create_a_record or arvan_create_cname_record, which are redundant specialized versions. The tool's purpose is clear but lacks guidance on when to use this generic version.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that specialized record creation tools exist or any context about prerequisites or conflicts. An agent would have to infer from the tool name alone.

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

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

Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds 'Add' (creation) context but no further behavioral details like required permissions, side effects, or error states. It does not go beyond what annotations already convey.

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

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

Two sentences plus arg list, front-loaded with purpose. Every sentence is informative and 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?

No output schema is present, but the description does not mention return values, success/failure indicators, or idempotency (though annotations cover the latter). For a simple creation tool, it is adequate but could be more complete with expected output.

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 0% schema description coverage, the description adds meaningful examples: 'domain' gets an example 'example.com', and 'extra' is explained as 'Additional fields to merge into the request body (e.g. plan)'. This compensates for the schema gap well.

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

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

The description clearly states 'Add a domain to the CDN / Cloud DNS', specifying the verb, resource, and context. It distinguishes from sibling tools like arvan_create_dns_record (adds records to existing domain) and arvan_get_domain (retrieves details).

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

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

The description calls this an 'onboarding call', implying it's a first step, but does not explicitly explain when to use it versus alternatives (e.g., arvan_import_dns_zone for zone import). No exclusions or prerequisites are given.

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 provide minimal safety info (not read-only, not destructive, not idempotent). Description does not add behavioral details such as whether rule creation is immediate, what happens on duplicate, or side effects beyond creation.

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?

Concise one-line summary and parameter list. No unnecessary text, but could be slightly improved by front-loading the action word.

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 and description does not mention return value, error conditions, or rate limits. Incomplete for a creation tool with 5 parameters.

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 0% schema description coverage, the description adds basic meaning for 5 parameters (domain, name, action with examples, filters, extra). However, lacks format constraints or examples for filters 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?

Clearly states 'Create a firewall (WAF) rule' which is a specific verb+resource, distinguishing it from sibling tools like list or delete firewall 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?

No explicit guidance on when to use this tool vs alternatives, nor prerequisites like domain existence. Implied purpose, but no exclusions or 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 indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false), but description adds no behavioral details like region defaults, limits, or idempotency.

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 sentence is concise but lacks structure; could include parameter details or usage notes without becoming verbose.

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 creation tool with no output schema and undocumented parameters, description is too minimal; missing information about region requirements, defaults, or return behavior.

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

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

Schema has 0% description coverage; description fails to explain either parameter (description, region), leaving agents without meaning beyond name/type.

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

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

Description clearly states verb 'Allocate' and resource 'floating (public) IP address', distinguishing it from sibling tools like list, delete, attach, detach.

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 vs alternatives, no prerequisites or context about selecting region or description.

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

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

The description claims a create/write operation, but the annotation says readOnlyHint: true, which is a contradiction. No additional behavioral context is provided (e.g., side effects, required permissions).

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 very short (one sentence) and to the point, but it could be slightly expanded without losing 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?

No output schema, only 2 params but both required and one is a complex object. The description lacks details on the sink configuration, making it insufficient 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 0%, and the description does not explain the 'domain' or 'config' parameters. The context says the config is an object with additionalProperties: true, but no guidance on required fields or 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 clearly states the action ('Create') and resource ('log forwarder'), and provides a clarifying parenthetical explaining it ships access logs to an external sink. It distinguishes from sibling tools like arvan_list_log_forwarders or arvan_delete_log_forwarder.

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 alternatives, no prerequisites (e.g., need an external sink endpoint), and no mention of when not to use it.

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

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

Annotations indicate this is not read-only, not destructive, and not idempotent. The description only says 'create', implying mutation but without additional context such as whether creating a duplicate exporter is allowed or what the side effects are. More behavioral detail is needed.

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

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

The description is a single sentence, which is concise, but it lacks essential details about the parameters and usage, leading to a trade-off between brevity and informativeness.

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

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

Given the complexity of the tool (two required parameters, one being a nested object) and the lack of output schema or parameter descriptions, the description is severely incomplete. It fails to explain what a metric exporter is, what the config should contain, or what the tool returns.

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 0% schema description coverage, the description must compensate. It does not explain the meaning of 'domain' or 'config'. The 'config' parameter is an opaque object with additionalProperties true, making the description incomplete for tool selection.

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

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

The description clearly states the action 'create' and the resource 'metric exporter' scoped to 'a domain'. It distinguishes the tool from sibling tools that create other resources (e.g., DNS records, servers). However, it does not explain what a metric exporter is, which could add clarity.

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 is provided on when to use this tool versus alternatives, such as other create tools or related metric tools like arvan_list_metric_exporters or arvan_metrics. There is no mention of prerequisites or scenarios to avoid.

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 indicate it is a write operation (readOnlyHint=false) and non-destructive. Description adds 'Create' but no extra behavioral details like idempotency, error handling, or 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?

Short and to the point, with arg list structured. No redundant information. Could be slightly more detailed without losing 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 creation tool with no output schema, description is sparse. Does not mention return value, success behavior, or what happens if rule already exists. Lacks completeness for an agent to use 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 coverage is 0%, so description partially compensates by explaining domain as 'CDN domain', url with an example, and actions as a map with an example. Lacks detailed descriptions but adds some 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?

The description clearly states 'Create a page rule' with a verb and resource. It is distinct from siblings like arvan_list_page_rules and arvan_delete_page_rule, though it does not explicitly differentiate 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?

No guidance on when to use this tool versus alternatives. No prerequisites, context, or conditions are provided. Usage is only implied by the action 'Create'.

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 declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, indicating it is a non-read, non-destructive, non-idempotent mutation. The description adds parameter details but does not elaborate on behavioral traits like idempotency or consequences of using it. 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?

Description is concise with a clear purpose statement followed by bullet-pointed argument list. Front-loaded and efficient: every sentence adds value without redundancy.

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

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

While all 9 parameters are described, the description omits return value information (e.g., what is returned upon success) and does not mention behavior on duplicate names or prerequisites. For a network creation tool, this is a minor gap, but overall fairly complete.

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

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

Schema coverage is 0%, requiring the description to provide meaning. It does so thoroughly: explains each parameter (e.g., subnet_ip: 'CIDR for the subnet, e.g. 192.168.0.0/24', dhcp_start/dhcp_end: 'Optional DHCP allocation range'). Adds significant value beyond titles and types.

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

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

The description clearly states 'Create a private network (subnet)', which is a specific verb+resource combination. It distinguishes from sibling tools like create_server, create_volume, etc., by focusing on network creation.

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

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

The description provides no guidance on when to use this tool vs alternatives (e.g., arvan_update_subnet, arvan_list_networks). It lacks explicit context on prerequisites or scenarios where this tool 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?

The description accurately indicates a write operation (Create), consistent with annotations. However, it does not add behavioral details beyond what annotations provide, such as authentication requirements or effects on existing records.

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 sentence that front-loads the action and resource. There is no extraneous 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 simple creation tool, the description is adequate but lacks details on the return value or side effects. Without an output schema, agents may not know how to interpret 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?

The description adds context for 'ip' and 'domain' by stating the mapping purpose, but it does not explain the optional 'region' parameter. With 0% schema description coverage, the description partially compensates but is incomplete.

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

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

The description clearly states the action (Create), the specific resource (reverse-DNS PTR record), and the purpose (mapping IP to domain). It effectively distinguishes this tool from sibling DNS record tools like arvan_create_dns_record.

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

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

The description implies the tool is used when a PTR record is needed, but it does not provide explicit guidance on when to choose this tool over alternatives (e.g., other DNS record creates) or mention any preconditions 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?

Annotations indicate the tool is not read-only and not destructive, which is consistent with a create operation. However, the description adds no further behavioral context, such as side effects, idempotency, or prerequisites.

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 concise, consisting of one sentence and a list of examples. It is front-loaded with the core purpose. No unnecessary words, though the formatting could be slightly improved.

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

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

Given the tool's complexity (2 parameters, one nested object) and the lack of output schema, the description is somewhat incomplete. It does not clarify that the domain is the target for the rule or describe the expected result 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?

The description provides example fields for the 'rule' object (url, method, count, duration, action), compensating for the schema's low coverage (0% description). However, it does not explain the 'domain' parameter, leaving its semantics partially ambiguous.

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 'Create a rate-limit rule' which clearly identifies the action (create) and resource (rate-limit rule). It differentiates from sibling tools like list and delete, but lacks explicit mention that the rule is associated with a domain, though the domain parameter implies 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?

No guidance is provided on when to use this tool versus alternatives. Siblings like 'arvan_delete_rate_limit_rule' and 'arvan_list_rate_limit_rules' exist, but the description does not help the agent choose between them.

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 indicate it is not read-only, not destructive, and not idempotent. The description adds no additional behavioral context, such as whether it overwrites existing groups, requires specific permissions, or what happens on name conflict.

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 concise (single sentence) but lacks necessary detail. It is front-loaded but fails to provide value beyond the name.

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

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

For a creation tool with 3 parameters and no output schema, the description is incomplete. It does not explain the return value, validation rules, or how the tool fits into the broader workflow (e.g., attach security group to server).

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%, meaning no parameter descriptions in the schema. The description does not explain the meaning of 'name', 'description', or 'region', leaving the agent to guess their purpose.

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 'Create a security group' clearly states the verb and resource, but it is vague and does not differentiate from other create tools like arvan_create_firewall_rule or arvan_create_server. It lacks specificity about what a security group is in this context.

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 alternatives (e.g., arvan_create_firewall_rule, arvan_list_security_groups). There is no mention of prerequisites, contexts, or when not to use it.

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

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

Annotations already indicate it's not read-only, not destructive, and not idempotent. The description adds no additional behavioral context, such as whether creating a rule can fail, side effects, or permission requirements.

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?

Description is concise with a clear purpose sentence followed by a bulleted list of parameters. It's well-structured and front-loaded. Slightly verbose due to the list format, but still efficient.

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 create tool with 8 parameters and 0% schema coverage, the description covers most but misses region. No output schema means return value is unknown. Annotations are minimal. Lacks mention of prerequisites like existing security group.

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 has 0% description coverage, but the description explains most parameters (direction, protocol, port range, ips, description) with helpful details like enum values and default behavior. However, 'region' is not explained, so not all parameters are covered.

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

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

Description clearly states 'Add a rule to a security group', which is a specific verb-resource combination. It clearly differentiates from sibling tools like 'arvan_create_security_group' which creates the group itself, and other create 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 guidance on when to use this tool versus alternatives, such as when to create a firewall rule vs security rule. The description only explains parameters without context on prerequisites or scenarios.

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 indicate it is not readonly and not idempotent, but the description adds no further behavioral details beyond creation. It does not contradict 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 front-loaded with the purpose and structured as a clear list of parameters. Every sentence adds value, and the length is appropriate for the parameter count.

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

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

Given the complexity (13 parameters, no output schema), the description covers parameters well but omits expected return values or failure behavior. It is adequate but not fully complete 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%, so the description compensates well. Each parameter is explained briefly, with cross-references to related tools (e.g., arvan_list_plans) and specific behaviors (e.g., numeric suffix for name when count>1). Some parameters like 'extra' are vague.

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

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

The description clearly states 'Create one or more cloud servers' with a specific verb and resource. It distinguishes from sibling tools like arvan_provision_server by focusing on initial creation. The mention of 'one or more' directly references the count parameter.

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 explicit guidance on when to use this tool versus alternatives like arvan_provision_server or arvan_rebuild_server. It references other tools for listing plans/images/ssh keys but does not define usage context 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?

Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool is a write operation but not destructive. The description adds minimal behavioral context beyond this, only explaining the key's purpose. It does not mention side effects, idempotency, or error conditions like duplicate keys.

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, clear sentence with no wasted words. It is concise but could benefit from additional details without becoming verbose.

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

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

Given the lack of output schema, the description should indicate what the tool returns (e.g., confirmation). It also fails to address idempotency (annotation says false) or error handling. The description is incomplete for a creation tool with multiple parameters and no return value documentation.

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% with no descriptions on parameters. The description does not explain any parameter semantics, such as the required format for 'public_key' or the role of 'region'. This is a significant gap for a 3-parameter tool.

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

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

The description clearly states the action ('Register') and the resource ('SSH public key') and explains its purpose (injection into servers at create). It distinguishes from sibling tools like arvan_delete_ssh_key or arvan_list_ssh_keys, though it doesn't explicitly differentiate 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing to generate a keypair first, or that this key should be used with arvan_create_server. No exclusions or alternative tools are referenced.

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

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

The description adds no behavioral context beyond what annotations already provide (all hints false). It does not disclose any side effects, auth requirements, or return behavior, which is critical for a creation 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?

The description is a single sentence, making it concise, but it sacrifices informative content. It is not overlong, but the brevity limits its 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?

Given the complexity (3 parameters, sibling tools), the description is incomplete. It fails to differentiate from 'arvan_attach_tag' and provides no output schema info. The lack of detail undermines its completeness.

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 0% schema description coverage, the description must explain parameters, but it does not mention any of the three parameters (name, region, color). The agent gets no additional meaning beyond the raw 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 'Create a resource tag' clearly states the action (create) and the resource (tag), making it easy to understand the tool's purpose. It distinguishes from siblings like 'arvan_delete_tag' but does not elaborate on what constitutes a 'resource tag' in the Arvan ecosystem.

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 is provided on when to use this tool versus alternatives such as 'arvan_attach_tag' or 'arvan_create_server'. There is no mention of prerequisites or context, leaving the agent without decision support.

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

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

The description only states it creates a volume. It does not disclose if the operation is synchronous, what happens if a volume with the same name exists, or any side effects. Annotations (readOnlyHint=false, destructiveHint=false) confirm it's a mutation but no additional behavioral context is 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 description is extremely concise: one sentence followed by a compact parameter list. Every sentence adds value, with no redundant or irrelevant information. It is front-loaded and well-structured.

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 create tool, coverage is adequate but not thorough. Missing details about return value, success/error handling, and any prerequisites. No reference to related tools like arvan_get_volume_limits or arvan_list_volumes.

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

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

Schema coverage is 0%, so the description must compensate. It adds brief but useful info: name='Volume name', size='Size in GB', region with default, description 'Optional description.' This is adequate but lacks details like allowed values or constraints (e.g., size range).

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

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

The description explicitly states 'Create a block-storage volume,' using a specific verb and resource. It clearly distinguishes from sibling create tools for other resources (e.g., arvan_create_server) and volume management tools like arvan_snapshot_volume.

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 alternatives. It does not mention prerequisites, constraints (e.g., size limits), or when to prefer other volume operations like arvan_update_volume or arvan_attach_volume.

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

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

The description only states the action 'Delete', which is consistent with the destructiveHint annotation. It adds no additional behavioral context beyond what annotations already provide, such as reversibility, permissions, or 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, concise sentence with no redundant information. It could be slightly expanded to include parameter context, but it remains appropriately brief.

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 delete operation with two required parameters and no output schema, the description is minimally adequate. However, it lacks details on how to obtain the app_id or domain, and any potential consequences, which would make it more complete.

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

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

With 0% schema description coverage, the description fails to explain the meaning or source of the two required parameters. Mentioning 'by id' only hints at app_id, leaving domain completely unexplained, which is insufficient for correct invocation.

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

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

The description clearly states the action (delete) and the resource (CDN app), and mentions identification 'by id', which aligns with the app_id parameter. However, it fails to mention the required domain parameter, making it slightly incomplete.

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 is provided on when to use this tool versus alternatives like other delete tools (e.g., arvan_delete_dns_record). There are no prerequisites or contextual hints for appropriate usage.

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

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

Annotations already set destructiveHint=true and idempotentHint=true. The description confirms deletion but adds no extra behavioral context (e.g., cascade effects, error handling). Does not contradict 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?

Very concise single sentence. Acceptable for a simple deletion tool, but could include more detail without being verbose.

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

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

For a straightforward delete operation with two required parameters, the description covers the core functionality. No output schema is needed. Adequate given the tool's 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 coverage is 0% and the description does not explain the parameters 'domain' or 'record_id' beyond implying record_id is the identifier. Minimal added 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?

The description clearly states the action ('Delete'), the resource ('DNS record'), and the identifier method ('by id'). It is distinct from sibling tools like create, update, or list DNS records.

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 alternatives like arvan_update_dns_record or arvan_toggle_dns_cloud. No prerequisites or context are provided.

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

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

Annotations already indicate destructive and idempotent behavior. The description adds value by explaining the automatic lookup of domain_id if not supplied, which is useful beyond annotations. However, it lacks details on error handling or effects of idempotency.

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

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

The description is two sentences, no fluff. The first sentence states the main purpose, and the second adds key behavioral detail. Perfectly concise and 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?

Given the simple two-parameter schema and annotations covering destructiveness and idempotency, the description covers purpose and key behavior. However, it lacks details on return values, error scenarios, or prerequisites, making it adequate but not thorough.

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 0% schema description coverage, the description must compensate. It clarifies that domain_id is optional and auto-looked up, and implies domain is the domain name, but does not fully define each parameter's meaning or 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 clearly states the tool removes a domain from the CDN. The verb 'remove' and resource 'domain' are specific, and 'from the CDN' adds scope, distinguishing it from other delete tools like arvan_delete_dns_record.

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

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

The description implies usage through the name and purpose, but does not explicitly state when to use this tool versus alternatives like arvan_delete_server or arvan_delete_dns_record. No exclusions or context for selection are provided.

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

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

The description repeats the destructive nature already indicated by destructiveHint=true in annotations, but adds no extra context about side effects, reversibility, or permissions beyond what annotations already 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?

A single sentence that is to the point with no wasted words, but might be too terse for complete clarity.

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 delete operation with no output schema, the description lacks information about confirmation, success/failure indicators, or behavior when the rule is not found. Annotations cover safety but not operational 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 description coverage is 0%, and the description only implies 'rule_id' as the identifier ('by id'), but fails to explain the 'domain' parameter or any parameter formats, constraints, or examples.

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

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

The description clearly states the verb 'Delete', resource 'firewall (WAF) rule', and method 'by id'. It distinguishes from sibling tools like arvan_list_firewall_rules and arvan_create_firewall_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?

No guidance on when to use this tool versus alternatives like arvan_list_firewall_rules or arvan_create_firewall_rule. No prerequisites or context provided.

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

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

Annotations already indicate destructive and idempotent behavior. The description adds no additional context about side effects, reversibility, or required permissions. It does not contradict 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 short sentence, which is concise but lacks necessary detail. It could be expanded slightly without losing 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?

Given the tool's simplicity (2 parameters, no output schema), the description is insufficient. It does not mention error conditions, success confirmation, or prerequisite actions like detaching the IP.

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

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

Schema description coverage is 0%, and the description fails to explain either parameter beyond the implied 'by id'. The 'region' parameter is completely unaddressed.

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

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

The description clearly states the action (release/delete), resource (floating IP), and method (by ID). It distinguishes the tool from siblings like arvan_detach_floating_ip and other delete 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 guidance on when to use this tool versus alternatives such as arvan_detach_floating_ip or arvan_list_floating_ips. Does not mention prerequisites like detaching the IP before deletion.

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

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

The description claims 'Delete', which is a destructive mutation, but annotations set readOnlyHint=true and destructiveHint=false, creating a contradiction. No additional behavioral context is provided beyond the contradictory claim.

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 very short but under-specified, lacking structure and failing to earn its place. It is not an example of helpful 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?

Given the lack of output schema and the need to coordinate with list/create siblings, the description fails to explain prerequisites, effects, or how to obtain the forwarder_id, making it 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 parameter descriptions are all empty (0% coverage). The description adds no meaning to the 'domain' or 'forwarder_id' parameters, merely stating 'by id' which only addresses forwarder_id.

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

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

The description clearly states the action ('Delete') and resource ('log forwarder'), distinguishing it from creation and listing siblings. However, it could be more specific about the domain context.

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 alternatives, no prerequisites (e.g., needing to list forwarders first), and no mention of required domain or forwarder ID source.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds no extra behavioral context beyond 'delete', such as irreversibility, authorization needs, or 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 extremely concise but underinformative. It lacks essential details, making it borderline insufficient for effective tool selection.

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

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

Given the tool's simplicity (two required params, no output schema), the description is incomplete. It fails to mention prerequisites (like listing page rules), error conditions, or expected outcomes.

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

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

Schema description coverage is 0%, and the description does not explain the domain or rule_id parameters. The phrase 'by id' vaguely references rule_id but doesn't clarify its origin (e.g., from list tools) or the role of 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?

The description clearly states the action (delete) and the resource (page rule by id). It directly tells what the tool does with a specific verb and resource, distinguishing it from other delete tools by specifying 'page 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?

No guidance is provided on when to use this tool versus alternatives like arvan_list_page_rules to find the ID, or prerequisites. The description lacks any usage context 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?

Annotations already indicate destructive and idempotent behavior; description merely restates 'Delete' without adding context like irreversibility or error handling.

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, clear sentence with no redundancy; efficient for a simple delete operation.

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?

Lacks output schema and fails to mention return values or success/error behavior, though adequate for a straightforward delete action.

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 0% schema description coverage, description fails to explain ptr_id format or region role, offering no added 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?

Description clearly states the action (delete), the resource (PTR record), and identifier (by id), distinguishing it from siblings like create or list.

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

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

No guidance on when to use this tool versus alternatives such as arvan_list_ptr_records or what prerequisites are needed.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds no additional behavioral context, such as side effects, required permissions, or post-deletion 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 extremely short (one sentence), but it fails to provide enough informative content. It sacrifices completeness for brevity, resulting in under-specification.

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

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

Given the absence of an output schema and zero parameter coverage, the description is grossly incomplete. It omits any discussion of return values, error conditions, prerequisites, or expected behavior.

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

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

Schema description coverage is 0%, and the description does not explain the purpose of the required parameters (domain, rule_id) beyond implying rule_id is the identifier. No details on formats or 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?

The description clearly states the action (delete) and the resource (rate-limit rule) with the identifier method (by id). It is specific enough to differentiate from other delete tools, though it relies on the tool name for resource identification.

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 is provided on when to use this tool versus alternatives, such as update or list rate-limit rules. The description simply restates the obvious action without providing context for use cases or prerequisites.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds no behavioral context beyond the name, such as whether deletion is reversible, impacts on attached resources, or required permissions. It fails to elaborate on the idempotent nature or potential 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 sentence, concise and to the point. Every word contributes to understanding the action. However, it could be slightly more informative without losing conciseness, earning a 4 instead of 5.

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 delete tool with two parameters and no output schema, the description is incomplete. It omits crucial information like the effect of the region parameter, behavior when the group doesn't exist, or post-deletion state. Annotations help but don't fill all gaps.

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

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

Schema coverage is 0%, meaning the schema provides no descriptions. The description only says 'by id', which hints at the group_id parameter but does not define it or the optional region parameter. It adds no semantic value over the parameter names or types.

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

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

The description clearly states the verb 'Delete' and the resource 'security group', making the action unambiguous. It distinguishes from sibling tools like arvan_delete_security_rule or arvan_create_security_group, which target different resources or actions.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., when to delete a security group vs. detaching it). It lacks context on prerequisites, consequences, or context-specific usage cues.

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 provide destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds no additional behavioral context; it simply states the deletion action, which aligns 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 sentence that is front-loaded and to the point. However, it could be more informative without sacrificing 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?

The tool is simple with two parameters and no output schema. The description minimally covers the core purpose but lacks context about which security group the rule belongs to or any return value. Adequate but not thorough.

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 shows two parameters (rule_id, region) with 0% description coverage. The description only mentions 'by id', leaving region's purpose unclear. No elaboration on parameter semantics beyond the obvious.

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

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

The description clearly states the action (delete), the resource (security-group rule), and the method (by id). It distinguishes from sibling tools like arvan_delete_security_group and arvan_create_security_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?

No explicit guidance on when to use this tool versus alternatives. The description only states what it does, not the context or conditions for 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 label the tool as destructive (destructiveHint=true). The description adds minimal behavioral detail beyond that, only noting that force_delete_floating_ips releases IPs. No mention of irreversibility or data loss consequences.

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 concise: one sentence for purpose and one for a parameter hint. No extraneous words, and the main action is frontloaded.

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 destructive tool, the description covers the basic action and one parameter. However, it lacks information on return value or post-deletion state, which could help an agent confirm success. Annotations fill some gaps but not all.

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%, placing the burden on the description. Only force_delete_floating_ips is explained ('also release IPs'), while server_id and region lack any semantic clarification.

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

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

The description clearly states the verb 'delete' and the resource 'cloud server', making the tool's purpose immediately clear. It is distinct from sibling tools like arvan_rebuild_server or arvan_rename_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?

The description mentions the optional parameter force_delete_floating_ips but does not provide guidance on when to use this tool versus alternatives (e.g., arvan_rebuild_server). No context for when to delete vs. other server actions.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds no additional behavioral context (e.g., prerequisites, error conditions, or side effects) beyond what annotations provide. It merely repeats the delete action.

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

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

The description is a single sentence with no wasted words. However, it could include more critical information without becoming verbose.

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 operation with no output schema and 0% schema description coverage, the description should explain what happens on success/failure, prerequisites, and the role of the 'region' parameter. It falls short, providing only the bare minimum.

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 0% schema description coverage, the description must explain parameters. It only mentions 'by name,' leaving the 'region' parameter unexplained. The description adds minimal value over the schema structure.

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

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

The description clearly states the action ('Delete'), the resource ('registered SSH key'), and the identifier ('by name'). It distinguishes this tool from sibling tools like arvan_create_ssh_key and arvan_list_ssh_keys.

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

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

The description implies usage for deleting SSH keys but lacks explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or context are provided.

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

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

Annotations already provide destructiveHint=true and idempotentHint=true, indicating destructive but idempotent behavior. The description adds the fact that deletion is by ID, but does not elaborate on consequences (e.g., dependency checks, what happens if subnet doesn't exist). No contradiction with annotations.

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

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

The description is a single concise sentence with no wasted words. It is front-loaded with the action and resource. However, it could be more informative without being verbose.

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

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

Given the simplicity of the tool (2 params, no output schema), the description is incomplete. It lacks prerequisites, error handling, or return value information. Annotations provide destructive hint, but more context on usage in workflow would be beneficial.

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

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

Schema description coverage is 0%, so the description must compensate. It only mentions deletion 'by id' for the required parameter, but does not describe the optional 'region' parameter at all. The description adds minimal value 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 clearly states the verb 'Delete' and the resource 'private-network subnet', and specifies 'by id', which distinguishes it from other delete tools for different resources.

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 vs alternatives like arvan_get_subnet, arvan_update_subnet, or arvan_list_subnets. The description simply says what it does without providing context for selection.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true, so the description's 'Delete' aligns with the destructive nature. However, the description adds no further behavioral details (e.g., whether deletion cascades to resources, if it requires permissions). Given the annotations, the description meets minimal requirements but doesn't supplement them.

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

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

The description is a single sentence with no waste, qualifying as concise. However, it is overly terse, omitting critical details that could be included without sacrificing brevity. The structure is adequate but lacks front-loading of key 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 simple delete tool with two parameters, the description is incomplete. It does not explain the effect of deletion (e.g., whether the tag is permanently removed or can be recovered), the role of the 'region' parameter, or error behavior (e.g., if tag not found). The absence of an output schema further increases the need for description clarity, which is unmet.

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%, meaning parameters have no schema descriptions. The tool description does not explain the purpose of 'tag_id' (though obvious) or 'region' (ambiguous). It fails to add any meaning beyond the parameter names, which is insufficient to guide correct usage.

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 'Delete a resource tag by id.' which clearly indicates the action (delete) and the resource (tag). While it doesn't explicitly differentiate from similar sibling tools like arvan_detach_tag, the verb 'delete' vs 'detach' implies removal of the tag itself, not just disassociation. 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 guidance is provided on when to use this tool versus alternatives (e.g., arvan_detach_tag or arvan_create_tag). There is no mention of prerequisites, such as whether the tag must exist or be unattached before deletion. The description lacks any 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 convey destructiveHint=true and idempotentHint=true, matching 'Delete'. No additional behavioral context is added (e.g., irreversibility, failure conditions if attached). The description neither contradicts nor enriches annotations.

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

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

A single, front-loaded sentence efficiently communicates the core action. No unnecessary words.

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

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

Given the tool has 2 parameters and no output schema, the description lacks details about region relevance, return values, or post-deletion state. For a destructive action, more completeness is expected.

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 should compensate. It mentions 'by id' for volume_id, adding minimal meaning. The region parameter is not described at all. The description adds little beyond the schema structure.

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

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

The description clearly states the action 'Delete', the resource 'block-storage volume', and the method 'by id'. This distinguishes it from related tools like create, update, get, list, detach, and snapshot.

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 is provided on when to use this tool versus alternatives (e.g., arvan_detach_volume first) or prerequisites like ensuring the volume is not attached. The description is minimal and does not help the agent decide correct 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 indicate destructiveHint=true and idempotentHint=true. The description aligns with these traits but adds no extra behavioral context, such as prerequisites or effects. It relies entirely on annotations for behavior disclosure.

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 sentence that directly states the tool's action. No extraneous information is present, making it efficient for an agent to parse.

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

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

The description lacks context on how the floating IP is identified (implicitly via port?), prerequisites, or return behavior. Without output schema, the agent misses what to expect after detachment. The description is functional but not fully complete for informed 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 description coverage is 0%, and the description does not explain what port_id or region mean beyond the generic schema. The phrase 'from the given port' hints at port_id's role but is insufficient for clear parameter understanding.

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 'Detach a floating IP from the given port' clearly states the action (detach), the resource (floating IP), and the target (port). This distinguishes it from sibling tools like arvan_attach_floating_ip and arvan_list_floating_ips.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. Usage is implied from the action, but no context or exclusions are given. Sibling tools are present but not referenced.

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 provide destructiveHint=true and idempotentHint=true, so the description does not need to reiterate safety. However, the description does not add additional behavioral context beyond the annotations, such as potential impact on connectivity or reversibility.

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 sentence of 5 words. It is efficiently front-loaded with the action and resource, but it could be slightly more informative without losing 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?

Given the absence of an output schema and parameter descriptions, the description does not explain return values, side effects, or the role of the optional region parameter. It is incomplete for a tool with three parameters.

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 parameter descriptions are missing (0% coverage), and the description does not explain what network_id, server_id, or region represent. The parameter names are somewhat self-explanatory, but the description fails to add meaning or clarify their roles.

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

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

The description uses a specific verb 'Detach' and clearly identifies the resource 'network from a server'. It directly states the action, which is distinct from sibling tools like arvan_attach_network.

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 alternatives, such as arvan_attach_network. No prerequisites or context about the network needing to be attached first are mentioned. The description lacks any 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 indicate destructiveHint=true and idempotentHint=true. The description does not add behavioral context beyond that, e.g., effects on connectivity. It is consistent but minimal.

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 sentence, very concise and front-loaded. However, it is perhaps too minimal missing critical details.

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 detach operation, the description lacks context about what happens after detach, any prerequisites (server must exist, security group attached), and no output schema is provided.

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

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

Schema description coverage is 0% and the description does not explain any parameters. The user gets no guidance on the meaning of server_id, security_group_id, or region 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 clearly states the action (detach) and the resource (security group from a server). It distinguishes from sibling tools like attach_security_group_to_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?

No usage guidelines provided. Does not indicate when to use this tool vs alternatives like attaching or listing, nor any prerequisites.

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

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

Annotations indicate destructive and idempotent behavior, but the description adds no additional behavioral context. It does not explain potential side effects or safety considerations beyond what annotations already state.

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 very concise (one sentence), but this conciseness comes at the cost of completeness. It is front-loaded but lacks necessary details.

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

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

Given the complexity (4 parameters, no descriptions) and moderate annotations, the description is severely incomplete. It fails to explain resource types, default values, or required permissions, making it difficult for an agent to use correctly.

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

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

The input schema has 4 parameters with 0% description coverage, and the description provides no explanation of these parameters. The agent receives no guidance on what 'tag_id', 'instance_id', 'instance_type', or 'region' mean or how to use them.

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

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

The description clearly states the action (detach) and objects (tag, resource). However, it is generic and does not specify which resource types are supported, limiting its helpfulness in distinguishing from sibling detach tools like arvan_detach_floating_ip.

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 is provided on when to use this tool versus alternatives (e.g., arvan_attach_tag for attaching). There is no mention of prerequisites or context for 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 indicate destructiveHint=true and idempotentHint=true. The description adds no behavioral details beyond 'detach', such as side effects on the server or volume, required server state, or reversibility. It does not enhance transparency beyond the annotations.

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

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

The description is very short (one sentence) and front-loaded. However, it omits necessary detail, so it is under-specified rather than properly concise. Every sentence earns its place, but a bit more context would improve utility without losing 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?

Given the lack of output schema and 0% parameter description coverage, the description is incomplete. It does not explain return values, required permissions, or confirmation of success. While the tool is simple, the description leaves significant gaps for an agent to infer.

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 0%, the description must compensate but fails to explain any parameter. The description only names the action, not the required IDs for volume and server, nor the optional region. The schema itself provides minimal info (no descriptions), so more parameter context is needed.

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

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

The description clearly states the action 'detach' and the resources 'volume' and 'server'. It is specific and easily distinguishes from sibling tools like 'arvan_attach_volume' and 'arvan_detach_floating_ip'.

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

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

The description provides no guidance on when to use this tool vs alternatives. It does not mention prerequisites, state requirements, or when not to use. Among siblings, there are related attach/detach tools but no comparative 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 do not contradict the description. The description adds the allowed domain restriction. However, it does not disclose potential side effects, authentication needs, or error handling beyond the constraint.

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 concise with two sentences, no redundant information, and easy to parse.

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

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

The description covers the main function and output format. However, it lacks details on error scenarios, rate limits, or how to handle invalid URLs, which could be useful for a fetch 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 0%, and the description does not explain the `url` or `max_chars` parameters. The agent receives no guidance on URL format or the behavior of max_chars.

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

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

The description clearly states the tool fetches an ArvanCloud documentation page and returns plain text. It specifies allowed domains, distinguishing it from sibling tools like arvan_docs_search and arvan_docs_topics.

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 alternatives like arvan_docs_search or arvan_docs_topics. Only a domain constraint is provided, but no context for decision-making.

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 provide no behavioral hints (readOnlyHint, destructiveHint, idempotentHint are all false), and the description does not add any behavioral details such as pagination, query syntax, or rate limits. The agent learns nothing beyond the basic action.

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 sentence that efficiently conveys the core purpose. It is front-loaded and easy to parse, but lacks any additional structure (e.g., parameter hints, examples) that would improve usability.

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

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

Given the tool's complexity (2 parameters, no output schema, no annotations), the description is too sparse. It omits essential context about input syntax, expected output, and behavior, leaving the tool under-documented for effective agent use.

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

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

Schema coverage is 0% — neither 'query' nor 'limit' have descriptions in the schema. The description only mentions 'query' indirectly via 'for a query,' and omits 'limit' entirely. It fails to explain parameter meaning, constraints, or usage, forcing the agent to guess.

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

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

The description clearly states the action ('Search') and the specific resource ('curated ArvanCloud documentation index'). It distinguishes from sibling tools like arvan_docs_fetch (retrieve a document) and arvan_docs_topics (list topics), making the tool's purpose unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., arvan_docs_fetch, arvan_docs_topics). It lacks instructions on when to use or avoid it, leaving the agent to infer 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?

The description implies a read-only operation by listing content, but this is not explicitly stated. Annotations do not provide readOnlyHint, so the description could be more transparent about the tool's side effects and safety. However, it does not contradict any 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 sentence of 8 words, perfectly concise. It front-loads the action and resource, with no wasted words.

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

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

Given no output schema, the description adequately explains the return value. It is complete for a simple list tool, but could benefit from mentioning that it provides an overview of available documentation topics.

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

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

The input schema has no parameters, so the description's role is to explain what the tool returns. It adds meaning by specifying 'curated ArvanCloud documentation topics and their URLs', which is clear and helpful. With zero parameters, the baseline is 4.

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

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

The description clearly states the tool lists curated ArvanCloud documentation topics with their URLs. It uses a specific verb ('list') and resource ('curated ArvanCloud documentation topics'). However, it does not explicitly distinguish it from sibling tools like arvan_docs_fetch and arvan_docs_search, which could cause confusion.

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 is provided on when to use this tool versus alternatives. Sibling tools arvan_docs_fetch and arvan_docs_search exist, but the description does not mention them or clarify their different purposes.

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

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

Annotations already indicate readOnlyHint=true, and the description elaborates on what the tool checks (API key, CLI tools, Object Storage, SSH config). It adds value beyond annotations without contradiction.

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

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

The description is concise, front-loading the main purpose, followed by a bulleted-style list of checks. Every sentence adds value with no redundancy.

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

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

Given the tool's simplicity (no parameters, read-only, has output schema), the description fully covers its purpose, checks, and recommended usage. It is complete for an agent to decide to call 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?

The tool has no parameters, so the schema coverage is trivially 100%. The description does not need to provide parameter details, earning a baseline score of 4.

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

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

The description clearly states 'Diagnose the server's configuration and connectivity' with a specific verb and resource. It distinguishes itself from sibling tools (e.g., CRUD operations) by being a diagnostic readiness check.

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

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

The description explicitly advises 'Run this first to see what's ready to use', providing clear context for when to use this tool. However, it does not mention when not to use or list alternatives, so a 4 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?

The description implies a read-only search operation by stating 'search' and 'returns', yet annotations set readOnlyHint=false, contradicting the implication. This is a serious inconsistency.

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 purpose, no unnecessary words. Efficient and well-structured.

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 search tool with output schema (assumed present), the description covers core functionality, return format, and ranking. Minor missing parameter details are compensated by schema.

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