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

With no annotations, the description carries the burden and does explain what each action does (e.g., get_resources returns limits and usage, get_server_info returns PHP/MySQL/OS). It also discloses the optional pick/filter behavior. However, it omits important behavioral details like whether delete is irreversible, what happens on conflict, or any permission prerequisites, which is a notable gap for a management 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 efficiently structured with a brief opening, a bullet-style list of actions, and a concise explanation of optional parameters. Every sentence adds value, with no filler or repetition of schema 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 tool's multi-action complexity and the absence of an output schema or annotations, the description covers the action list and high-level purpose but omits critical information about the 'params' object (required fields for create/update/delete). It also does not describe return values or error behavior, leaving users to guess at crucial usage 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?

The description adds meaning to the action enum by explaining each value and provides examples/use for pick and filter. However, 'params' is left entirely unexplained both in the schema and the description, and schema coverage is only 50%. The description does not fully compensate for this missing parameter semantics.

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

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

The description uses a specific verb 'Manage' combined with a clear resource 'KAS accounts and settings' and enumerates specific actions (list, get_resources, get_settings, create, update, delete). It clearly differentiates from sibling tools (kas_ssl, kas_dns, etc.) by focusing on account-level operations.

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

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

The description provides clear context on what the tool is for (account and settings management), and the action list implies when to use it for tasks like listing accounts or retrieving resource usage. However, it does not explicitly state exclusions or point to alternatives (e.g., 'use kas_dns for DNS tasks'), so it misses the top tier.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It adds useful behavior details: protocol must be 'https' or 'http', http_url is without a protocol prefix, and time values follow crontab syntax. It also explains that 'pick' reduces tokens and 'filter' returns only matching entries. However, it does not mention side effects, auth requirements, rate limits, or what happens on update/delete (e.g., partial vs. full update, error cases). This is adequate but not rich.

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

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

The description is well-structured as a bulleted list, front-loading the purpose ('Manage cronjobs') followed by concise action definitions. Every line adds value—parameter lists, format notes, and optional param behavior—without unnecessary fluff. The use of placeholders like '...fields' keeps it compact while conveying the pattern.

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 CRUD tool with no output schema, the description covers the main usage and parameter rules but lacks information about return values or result structures (e.g., does list return an array? what does create return?). It also doesn't address edge cases like cronjob_id validation or error handling. Given the moderate complexity, the description is functional but incomplete for an agent needing to anticipate outputs and failures.

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 definition significantly expands on the schema, which only describes 'pick' and 'filter' but leaves 'action' and 'params' as opaque. The description explains the action enum implicitly and details the create params (protocol, http_url, time fields) with constraints such as protocol values and crontab semantics. It doesn't enumerate all update fields, but it adds substantial meaning beyond the schema's minimal coverage.

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

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

The description explicitly states 'Manage cronjobs' and enumerates four actions (list, create, update, delete) with distinct params, making the tool's purpose clear. The resource (cronjobs) is distinct from sibling tools like kas_dns or kas_domain, though the verb 'manage' is generic, so it doesn't fully differentiate beyond the resource name.

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

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

The action breakdown implicitly tells when to use each operation (e.g., 'create' for new cronjobs, 'delete' for removing). It doesn't explicitly mention when not to use this tool or name alternatives, but the context of sibling tools and the focused resource make the usage context clear. There are no explicit exclusions, so it falls just short of a 5.

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

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

With no annotations, the description carries the full burden. It discloses important behaviors like auto-generated database names, required database_login equality, and pick/filter side effects. Yet it omits consequences of delete, update semantics, permissions, and return/error behavior, leaving significant gaps.

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 efficiently structured: a one-line summary, per-action bullet points, and optional parameter notes. It is front-loaded with the resource type and every line adds operational value without unnecessary filler.

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

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

Given the moderate complexity of four actions and no annotations or output schema, the description covers action-specific parameters and optional pick/filter well. However, it lacks return format details and permission requirements, making it not fully complete.

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

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

The schema only provides a generic 'params' object with additionalProperties: true. The description supplies all parameter names and constraints per action, including the auto-generated name for create and the required database_login equality for update/delete. This is essential meaning beyond the schema.

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

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

The description opens with 'Manage MySQL databases' and then lists four specific actions (list, create, update, delete) with distinct parameter requirements. This clearly identifies the tool's function and differentiates it from sibling tools like kas_dns or kas_mail.

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 action list and explicit parameter constraints (e.g., 'database_login required (same value as database_name)') make it clear when to use each action. However, it does not explicitly contrast this tool with alternatives or state when not to use it, stopping short of full guidance.

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

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

Key behavioral constraints are disclosed: the trailing dot requirement for zone_host, the string requirement for record_aux, and the need to obtain record_id from list before update/delete. The note that reset restores defaults also implies destructive behavior. No annotations are present, so the text carries the full burden and does so effectively.

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 well-structured with a concise header, an IMPORTANT note, and a bulleted action list. It front-loads the core purpose and uses examples to illustrate constraints, ensuring every sentence contributes 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?

With no output schema, the description is not obligated to explain return values, but it covers all five actions and their required parameters. It is mostly complete, though the update action's '...fields' is vague and could specify which fields are editable. Overall, it provides sufficient context for correct tool 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?

The schema only documents pick and filter (50% coverage), leaving action and params generic. The description adds meaning by specifying exact parameter names and formats for each action (e.g., zone_host, record_aux: "0", record_name="" for root) and clarifying the optional pick/filter behavior. This goes well beyond the schema's structured data.

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

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

The description opens with 'Manage DNS records (A, AAAA, CNAME, MX, TXT, SRV...)' which clearly states the verb and resource. The explicit list of record types and DNS-specific scope distinguish it from sibling tools like kas_domain or kas_ssl.

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 organizes usage by action (list, create, update, delete, reset) with required params for each, providing clear context on when to invoke each action. It does not explicitly state alternatives or when not to use the tool, but the DNS-specific scope makes that unnecessary.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists action names and parameters but does not explain side effects (e.g., delete is destructive, move changes ownership), permissions, reversibility, or return values. The pick/filter option is helpful but not behavioral.

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

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

The description is compact and well-structured with a bulleted action list, making it easy to scan. Every sentence/line adds relevant information, and the optional params are explained in one concise sentence 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?

Given the tool has 6 actions and no output schema or annotations, the description should provide more context about return values, errors, or prerequisites. The update action is vague, and there is no mention of what each action returns or potential side effects, leaving significant gaps 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?

The description supplements the generic 'params' object in the schema by listing domain-specific parameters for create and move (e.g., domain_tld, domain_path, ssl_proxy, target_kas_login). However, update uses vague ellipsis ('...fields') and no types or constraints are given, leaving some parameters undefined.

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 'Manage domains' and enumerates specific actions (list, list_tlds, create, update, delete, move), identifying the resource and operations. This distinguishes it from sibling tools like kas_ssl, kas_dns, and kas_database that manage 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?

No explicit guidance is provided on when to use this tool versus sibling tools or how to choose among actions. The description only says 'Manage domains' without discussing prerequisites, alternatives, or exclusions, leaving usage entirely implicit.

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

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

With no annotations provided, the description carries the full burden. It discloses important behavioral details: create_forward may fail with 'fetch failed' on first attempt, update_forward may fail with 'in_progress' after creation, and explains retry guidance. This goes beyond the basic action list, though it omits information about auth, rate limits, or destruction warnings.

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 moderately long but well-structured with action bullets and concrete examples. Every sentence adds value, and the front-loaded purpose statement makes it easy to parse. The length is justified by the tool's many actions.

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 there is no output schema and the tool has many actions, the description provides a solid overview, including param formats and failure/retry notes. It does not cover params for lists/filters, but the overall picture is sufficiently complete for an agent to select and invoke the tool correctly in most cases.

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

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

Schema coverage is only 50%, so the description compensates by explaining key parameters: mail_login/mail_password for mailboxes, target_0/target_1 for create_forward, and mail_forward as the full address for update/delete. It also clarifies the optional pick and filter parameters, adding meaning beyond the bare 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 'Manage email: mailboxes, forwards, mailing lists, filters' which is a specific verb+resource, and enumerates concrete actions. It distinguishes from sibling tools (ssl, cronjob, dns, etc.) by explicitly focusing on email management.

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

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

The description provides clear context (email-related operations) but does not explicitly mention when not to use this tool or name alternative tools. The list of actions implies usage scenarios, but there are no exclusions or comparative guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'update' without describing side effects, permissions, reversibility, or response behavior. This is a significant gap for a mutation tool.

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

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

The description is concise and starts with the core purpose. The bullet-like listing of action and params is efficient, though the generic pick/filter note could be considered repetitive with the schema. Overall, it earns its place.

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

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

With no output schema, no annotations, and only a bare list of parameters without descriptions, the description is incomplete. It fails to specify what the update does, required inputs beyond the parameter names, or any behavioral context. The tool needs more elaboration for an agent to invoke it correctly.

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

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

The input schema only shows a generic 'params' object with no inner fields. The description lists the actual parameter names (domain_name, ssl_certificate_sni_crt, etc.), which adds value beyond the schema. However, it does not explain the meaning or format of these parameters, so compensation is partial.

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 'Manage SSL certificates' which is a verb+resource, and further specifies 'Action: update', making it clear this tool handles SSL certificate updates. It distinguishes from sibling tools by its focus on SSL, though 'manage' is somewhat generic.

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 updating SSL certificates via the 'action: update' directive, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria. The generic pick/filter note applies to all tools but doesn't help differentiate 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?

The description discloses the 'in_progress' failure mode for updates after creation and explains the optional pick/filter parameters. However, with no annotations, it does not address the safety/destructive nature of delete, permissions, or return value behavior beyond filtering.

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

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

The description is compact and front-loaded, using a bulleted action list with inline parameter examples. Every sentence adds operational value with no filler.

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

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

The tool is complex (5 actions, nested params) and has no output schema or annotations. The description gives an operational overview but omits return values, required fields for update, and when-to-use guidance. It is sufficient for basic invocation but leaves 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 50% (pick and filter have descriptions), but the description adds concrete examples for create (subdomain_name, domain_name) and move (target_kas_login), and explains pick/filter behavior. The 'params' catch-all remains under-specified, and the update fields token is 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 'Manage subdomains' and enumerates five concrete actions (list, create, update, delete, move), making the tool's purpose specific. This distinguishes it from sibling tools like kas_domain and kas_dns by focusing on the subdomain resource.

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 is provided on when to use this tool versus alternatives. It does not mention kas_domain or other siblings as alternatives for domain-level operations. The description implies subdomain management but lacks decision rules 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions the shared 'pick' and 'filter' behavior, which is useful, but it does not indicate which actions have side effects (e.g., create_session vs get_space) or what security/permissions are needed. This is a notable gap for a tool that mixes a write action with read actions.

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 front-loaded with a high-level summary before listing actions. The optional params explanation is concise and actionable. It could be better structured with separate sections for each action, but it is efficient and free of filler.

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

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

The tool has no output schema and no annotations, so the description should explain what each action returns and how they differ. It fails to distinguish between 'get_space' and 'get_space_usage' or describe the output format of any action. For a multi-action tool with creating and reading capabilities, this is a significant gap.

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

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

The description adds value for 'pick' and 'filter' by explaining their purpose (token reduction, result filtering) and giving a filter example. However, it does not clarify the 'params' object, which is still opaque. Schema coverage is 50%, and the description partially compensates but not completely.

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

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

The description opens with 'Sessions, disk space, traffic' and lists action names, making the domain clear. It distinguishes from sibling tools (ssl, dns, domain, etc.) by focusing on system-level operations. However, each action is not individually described, so the purpose of actions like 'get_space' vs 'get_space_usage' is only inferred from their names.

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 is given on when to use this tool versus alternatives. The description does not mention when to choose kas_system over kas_dns or kas_database, nor does it state any prerequisites or exclusions. The only context is the tool name and domain summary, which indirectly imply usage but do not provide clear direction.

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