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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the success return shape and the diagnostic context. It does not disclose failure behavior (e.g., whether it returns false, throws, or exits non-zero), which is a minor gap given the tool's diagnostic purpose.

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

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

Two sentences with no wasted words. Purpose, success return, and usage guidance are all included 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?

For a zero-parameter auth check with no output schema, the description covers the core purpose, success return, and primary use case. The only missing detail is the failure response format, which would be useful when diagnosing 401 errors but is not critical for invoking 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?

The tool has zero parameters, so the description carries no parameter burden. The baseline of 4 applies because there is nothing for the schema or description to clarify.

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

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

States a specific verb ('Verify') and resource ('Websupport API key and secret'), and defines the success outcome ('Returns {verified: true} on success'). This clearly distinguishes it from the sibling get/list tools, which retrieve data rather than test authentication.

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

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

Explicitly says 'Use this first when diagnosing 401 errors,' giving a clear trigger condition. It does not mention exclusions or alternative tools, but no sibling performs auth verification, so the guidance is sufficient.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only that it returns connection details, which could be sensitive, but no warning or additional behavioral context is provided. This is acceptable given the strong annotations but not exceptional.

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

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

A single, front-loaded sentence with zero waste. It clearly states the action, resource, and returned fields without redundancy.

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

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

For a simple get-by-id tool with strong annotations and fully documented parameters, the description adequately conveys what the tool does and what it returns. It does not mention error behavior or prerequisites, but these are not critical for this straightforward 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 description coverage is 100%, so the schema already documents all three parameters (userId, hostingId, databaseId). The description does not add any parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (Get), a specific resource (one database by id), and what it returns (name, type, connection details). This clearly distinguishes it from sibling tools like ws_db_list (list all) and ws_db_stats (statistics).

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

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

The description implies use when you have a databaseId and need details, but it does not explicitly state when to use this over ws_db_list or other database tools. No exclusions or alternatives are mentioned, so guidance is implicit rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds no extra behavioral details (e.g., pagination, sorting, or potential side effects), but given the annotations, the bar is lower and the basic function is clear.

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 is front-loaded with the action ('List') and clearly states the target resource, making it efficient and easy to parse.

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

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

For a simple list operation, the description is adequate. It conveys the action and scope, and the required hostingId parameter is indicated in the schema. While it does not specify the exact nature of the returned list (e.g., names vs. details), that is not critical given the lack of an output schema and the simplicity of the operation.

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

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

The input schema provides descriptions for both parameters (userId and hostingId) with 100% coverage. The tool description itself does not elaborate on parameter usage, but the schema's built-in descriptions are sufficient, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('List') and identifies the resource ('databases') with a clear scope ('on a hosting service'). It is easily distinguished from sibling tools like ws_db_get (which retrieves a single database) and ws_db_stats (which provides statistics).

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

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

The description implies usage for listing all databases but does not explicitly contrast with alternatives such as ws_db_get or ws_db_users_list. The context of sibling tools makes the purpose clear, but the description itself lacks explicit when-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context by defining size as 'storage used' and cpu as 'query load,' but it does not disclose response shape, units, or time range.

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

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

Two sentences with no filler. The core scope is front-loaded, and the `kind` explanation is concise and directly useful.

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

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

For a simple read-only stats tool, required parameters and series options are clear. However, with no output schema, the description does not mention what the returned statistics look like (units, format, or time window), leaving a moderate gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds genuine value for `kind` by clarifying that size means storage used and cpu means query load, which the schema's generic 'Which statistics series to return' does not convey.

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

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

The description clearly states the resource ('one database') and the data category ('usage statistics'), and it explains that `kind` selects the size or cpu series. It is distinguishable from sibling stats tools by the 'one database' scope, though it does not explicitly name alternatives.

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

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

There is no explicit guidance on when to use this tool versus alternatives like ws_db_get, ws_hosting_stats, or ws_vps_stats. The phrase 'for one database' implies scope, but no exclusions, prerequisites, or alternative routing 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 adds no behavioral detail beyond the annotations, which already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. It does not mention pagination, output shape, authentication, or any side effects, so it provides no extra 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?

A single sentence that is front-loaded with the action and resource, with no filler or redundancy. Every word earns its place.

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

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

For a simple list tool with rich annotations and full schema coverage, the description is minimally adequate. However, with no output schema, it does not describe what the returned list contains, and it offers no usage context to help an agent decide between this and sibling list tools.

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

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

Schema description coverage is 100%, so the schema already documents both userId and hostingId. The description adds no parameter-level meaning, but the baseline of 3 applies because the schema carries the full semantic load.

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

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

The description uses a specific verb ('List') and a specific resource ('database users on a hosting service'), which makes the tool's purpose clear. It is implicitly distinct from sibling tools like ws_db_list, but it does not explicitly contrast with 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 is provided about when to use this tool versus alternatives such as ws_db_list, ws_db_get, or ws_db_stats. The phrase 'on a hosting service' hints at the hostingId parameter but does not explain selection criteria 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 cover safety (readOnlyHint, idempotentHint, destructiveHint=false), so the description's job is to add behavioral context. It does so by noting 'Returns the API pagination envelope unflattened,' which discloses the response structure, and by mentioning paging and server-side filtering, which are operational behaviors. This goes beyond the annotations and provides useful expectations for the agent.

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

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

The description is a single, well-structured sentence that front-loads the core purpose, then adds relevant operational details (paging, filtering) and a note on the response envelope. Every word contributes value; there is no redundancy or filler.

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

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

For a listing tool with a complex nested filters object and six parameters, the description, combined with a fully documented schema, covers the essential context. It mentions paging and filtering, and the response envelope note helps set expectations. However, it does not explain the filter structure or prerequisites like obtaining a service/zone ID, though the required 'service' parameter is self-descriptive. Overall, it is nearly complete for the agent's needs.

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

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

Schema description coverage is 100%, with each parameter already documented (e.g., '1-based page number', 'Field name to sort by'). The description adds minimal parameter-level detail, only broadly referencing paging and filtering, which are already evident from the schema. It does not explain semantics beyond what the schema provides, so a baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'List DNS records in a service zone.' This clearly distinguishes it from sibling tools like ws_zone_list (which lists zones) and ws_dns_zone_get (which retrieves a single zone). The inclusion of 'in a service zone' narrows the scope precisely, leaving no ambiguity about what the tool does.

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 context by mentioning 'in a service zone' and paging/filtering, but it does not explicitly state when to use this tool versus alternatives. There is no mention of when not to use it or references to sibling tools like ws_dns_zone_get for zone details. Guidance is implicit rather than explicit, so it scores below the threshold for clear routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral details beyond the basic 'Get' action; it doesn't disclose pagination, return shape, or any side effects. Since the annotations carry the burden, a neutral score is appropriate.

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

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

The description is a single, efficient sentence that states the action and the scoping. No unnecessary words or repetition. It is front-loaded with the core purpose and avoids fluff.

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

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

For a simple get operation with one well-documented parameter, the description is sufficient for an agent to invoke it correctly. It identifies the required service identifier and its source. It lacks an explicit distinction from the sibling ws_zone_get, but the service-scoping is a key differentiator. The absence of an output schema means the description doesn't need to explain return values. Overall, it's complete enough for typical use.

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

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

The schema fully describes the 'service' parameter with a pointer to ws_service_list, achieving 100% schema description coverage. The description adds no additional semantic meaning beyond what the schema provides. The baseline of 3 applies because the schema already handles the parameter documentation.

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

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

The description clearly states the verb ('Get') and resource ('DNS zone attached to a service'), making the purpose unambiguous. It doesn't explicitly differentiate from the sibling ws_zone_get, but the 'attached to a service' scoping is a meaningful distinction. The purpose is clear enough for an agent to know what it does, though it could name the alternative for completeness.

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 context: use this to retrieve a DNS zone associated with a service, rather than a standalone zone. However, it doesn't explicitly state when to choose this over ws_zone_get or ws_dns_record_list, nor does it mention any exclusion criteria. The guidance is implicit from the wording but not spelled out.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which are consistent with the description. The description adds a valuable behavioral note that the password is never returned, which is not in annotations and is important for agent expectations. 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?

Two short sentences with no filler. The primary action is front-loaded, and the critical security caveat is appended efficiently. Every word earns its place.

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

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

For a simple get-by-id tool with 100% schema coverage and annotations covering safety, the description is sufficient. It specifies the resource, the lookup key, and a key behavior (password omission). It does not mention return format or error cases, but these are not required given the tool's simplicity and the lack of an output schema.

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

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

Schema description coverage is 100%, with both parameters (service and ftpAccount) having clear descriptions. The tool description adds no parameter-level detail beyond the schema, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Get'), names the resource ('FTP account'), and specifies the key by 'id', which clearly distinguishes it from ws_ftp_account_list and other sibling tools. It also adds a critical detail (password never returned) that further clarifies its purpose.

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

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

The description clearly indicates the tool is for retrieving a single FTP account by ID, and the sibling ws_ftp_account_list exists for listing, so usage context is implied. However, it does not explicitly state when to choose this over alternatives or any prerequisites, though the need for a 'service' identifier is visible in the schema.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a meaningful behavioral guarantee—'Passwords are never returned'—which is not inferable from annotations and is important for an FTP account listing 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 two sentences with no filler. The core purpose is front-loaded, and the password caveat is a valuable behavioral warning that earns its place.

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

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

For a straightforward read-only list tool with fully documented parameters and safety annotations, the description covers the essential purpose and a key output constraint. It does not describe the full return shape or pagination behavior, but those are largely inferable from the schema and list semantics.

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

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

Schema description coverage is 100%, so all five parameters (service, page, sortBy, descending, rowsPerPage) are already documented in the schema. The description adds no parameter-level detail beyond the hosting-service context, so the baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'List FTP accounts on a hosting service,' which clearly identifies the operation and scopes it to a hosting service. This also distinguishes it from the singular sibling ws_ftp_account_get, and the password caveat further clarifies what the operation does not return.

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

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

The description gives no explicit guidance on when to use this tool versus ws_ftp_account_get or other list tools. It does not mention that a service identifier is required or how to obtain one, even though the schema references ws_service_list; an agent must infer usage from the name and schema.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds what the response includes (package, limits, usage), which is useful and does not contradict the annotations.

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

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

A single, efficient sentence that front-loads the action and key identifiers, with no redundant wording. Every word contributes to the 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?

For a simple read operation with two parameters and annotations covering safety, the description fully conveys what the tool does and what it returns. Nothing essential is missing for an agent to call it correctly.

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

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

Schema description coverage is 100% for both parameters, with clear descriptions for userId and hostingId. The description's mention of 'by id or uuid' aligns with the hostingId parameter but adds no new parameter-level detail, so a baseline of 3 is appropriate.

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

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

The description states a clear verb ('Get'), a specific resource ('one hosting service'), the lookup key ('by id or uuid'), and the response content ('including its package, limits and current usage'). It distinguishes this from siblings like ws_hosting_list (list) and ws_hosting_vhost_get (vhost) without ambiguity.

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 for retrieving a single hosting service by identifier, which is the natural use case. It does not explicitly name alternatives or say 'use ws_hosting_list to get an id', but the id-or-uuid phrasing and the sibling set make the intended usage clear.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds no additional behavioral context such as pagination behavior, response format, or filtering options, which is acceptable given the annotations but offers no extra value beyond them.

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

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

The description is a single, clear sentence with no filler or redundancy. It front-loads the core purpose and is perfectly concise for a simple list 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?

Given that the tool is a straightforward list operation with all parameters documented and annotations covering safety, the description is largely adequate. However, it does not mention what the response contains (e.g., a paginated array of hosting services) or any edge cases, and since there is no output schema, this information is left to inference. This is a minor gap but not critical for a list tool.

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

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

Schema description coverage is 100%, meaning all three parameters (page, userId, pagesize) are fully documented in the schema. The description does not add any further parameter-specific information, so it earns the baseline score of 3; it neither improves nor detracts from what the schema already provides.

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

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

The description 'List the hosting services on the account' uses a specific verb ('List') and resource ('hosting services') with clear scope ('on the account'). It distinguishes from siblings like ws_hosting_get (single hosting) and ws_hosting_vhost_list (vhosts), so an agent can readily identify what this tool does.

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 its usage—when you need a list of hosting services—but it does not explicitly state when to use it versus alternatives like ws_service_list or ws_vps_list, nor does it mention exclusions. The purpose is self-evident, but no guidance on selection among similar list tools is provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds context by explaining what each `kind` value maps to (size=disk usage, domain=per-domain traffic, ftp=FTP activity), which enriches understanding beyond the schema enum labels. 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, well-structured sentence. It front-loads the purpose and then explains the `kind` parameter without unnecessary fluff. Every word earns its place.

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

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

For a simple read-only stats tool with three parameters and strong annotations, the description is fairly complete. It covers purpose and key parameter semantics, but does not mention the return format or any error conditions. Given the absence of an output schema, a brief note on what the response contains would improve completeness, but it is not severely lacking.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description adds semantic value by detailing what each `kind` enum value represents, which the schema only labels as 'Which statistics series to return'. This extra context justifies a score above the baseline of 3.

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 usage statistics for a hosting service, with `kind` selecting the series (size, domain, ftp). This specific verb-resource pairing distinguishes it from siblings like ws_hosting_get (configuration) and ws_db_stats/ws_mail_stats/ws_vps_stats (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 the tool is for statistics via the phrase 'Usage statistics', but does not explicitly state when to use it versus alternatives, nor any exclusions. Context from sibling names suggests it, but no direct guidance 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 declare read-only, idempotent, open-world, and non-destructive behavior, so the safety profile is covered. The description adds that the result includes document root and domain configuration, which is useful context, but it does not disclose other behaviors (e.g., error conditions, authorization requirements). 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 sentence that front-loads the core purpose and includes the key detail about the return content. There is no wasted text or redundancy; it is appropriately concise for a simple get-by-id 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?

For a simple read-only retrieval tool with well-documented parameters and safety annotations, the description is complete. It explains what the tool does, what it returns (document root and domain configuration), and relies on the schema for parameters and annotations for safety. An agent has enough information to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (userId, vhostId, hostingId) with meaningful descriptions. The tool description adds no additional parameter-level semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a specific verb ('Get') and resource ('one virtual host by id'), and distinguishes it from likely siblings like list or get by hosting. It adds detail about the return contents (document root and domain configuration), 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 clearly implies the tool is for retrieving a single virtual host by id, but it does not explicitly state when to use it over alternatives such as ws_hosting_vhost_list or ws_hosting_get. No exclusion or alternative guidance is provided, only the implied use case.

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

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

Annotations already cover readOnlyHint, idempotentHint, and openWorldHint, so the agent knows this is a safe, non-destructive, possibly partial listing. The description adds only the scope 'served by a hosting service', which is a slight enhancement. No additional behavioral context like pagination, ordering, or return format is given, but the annotations mitigate the need.

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 is front-loaded with the action and resource. There is no filler or redundancy, and every word earns its place. It is an exemplary model of brevity.

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

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

For a simple listing tool with rich annotations (read-only, idempotent, open-world), the description is adequate. It specifies the scope and required input context. The lack of an output schema is not a description deficiency, and the agent can reasonably expect a list of domain names. Slightly more detail about the return format would improve completeness, but it is not critical.

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

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

The input schema has 100% description coverage: both userId and hostingId have clear descriptions. The tool description adds no extra parameter information, so it does not go beyond what the schema already provides. The baseline for high schema coverage is 3, and no additional semantics are offered.

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 'List' and the resource 'virtual hosts', scoped to a hosting service. It distinguishes itself implicitly from sibling tools like ws_hosting_vhost_get (which retrieves a single vhost) and ws_hosting_list (which lists hosting services), but does not explicitly name those alternatives. The purpose is unambiguous and specific.

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

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

Usage is implied: to list virtual hosts for a given hosting service, this tool is used. However, there is no explicit guidance on when to choose this over ws_hosting_vhost_get or when not to use it, nor any mention of alternatives. The context is clear enough for an agent to infer, but no exclusions or comparisons 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value by stating what the response includes (line items, totals, payment status), but it does not disclose error behavior, authorization nuances, or whether the invoice data is fully hydrated. This is adequate but not rich.

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

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

Two short sentences, no filler. The core action and return contents are front-loaded, and the alternative-tool guidance is placed in the second sentence without unnecessary elaboration.

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

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

For a simple read-only getter with fully documented parameters and safe annotations, the description covers the essential return contents and points to the PDF sibling. It does not describe error cases or the full invoice object shape, but with no output schema and a straightforward operation, the description is sufficiently complete 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 100%, so the schema already documents both parameters thoroughly. The description reinforces that lookup is by id but adds no new parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Get one invoice by id') and enumerates the key returned data (line items, totals, payment status). It also distinguishes itself from ws_invoice_pdf by clarifying that the PDF is a separate tool, so an agent can select this tool correctly without ambiguity.

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 names the alternative tool for a related but different need: 'Use ws_invoice_pdf for the document itself.' This provides clear routing guidance and prevents an agent from using this tool when the actual goal is to obtain the PDF document.

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 read-only nature by saying 'List' and explicitly mentions what it does not do (paying). Combined with the readOnlyHint annotation, it is very transparent. It also specifies the information returned.

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 two sentences. It front-loads the primary purpose and then adds a relevant boundary note, with no filler.

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

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

For a simple list operation, the description covers the core functionality and the return fields. It lacks details on pagination or error handling, but these are implied by the parameters and the nature of the operation. Overall, it is complete enough 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 parameter descriptions in the schema are self-explanatory, and the main description does not add additional meaning to the parameters. Since schema coverage is 100%, the description adds no extra parameter semantics, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action: 'List the account's invoices' and specifies the returned fields (amounts, dates, payment status). It also distinguishes the tool's boundary by noting that paying an invoice is out of scope.

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

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

The description gives a clear indication of when to use the tool (to list invoices) and explicitly mentions a non-goal (paying invoices). However, it does not explicitly contrast with other invoice-related tools like ws_invoice_get, though the name and context make it 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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description adds genuine behavioral context beyond annotations: it discloses that raw PDF bytes are deliberately never inlined into a tool result because they 'would flood the conversation without being usable,' and explains what each format actually returns. This is a meaningful design-behavior disclosure, not just a restatement of the schema.

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, roughly 45 words, with the primary purpose front-loaded before the format details. Every clause earns its place; there is no filler, and the behavioral note is folded into the format explanation rather than stated redundantly.

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

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

For a read-only fetch tool with three parameters fully documented in the schema and no output schema, the description covers the key decision point (format behavior) and return semantics for both modes. The userId and invoiceId params are fully covered by the schema. Minor gap: it doesn't explain what happens if no invoice is found for the given id, but for a simple fetch tool with strong annotations this is a small omission.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value on top of the schema for the format parameter: it explains the caller intent ('will decode and save it') and reinforces the binary behavior ('reports the size and type only') beyond the schema's terse 'returns metadata and a byte count only.' The rationale about flooding the conversation clarifies how the response should be handled.

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?

Opens with a specific verb+resource+format — "Fetch an invoice as a PDF" — which immediately distinguishes it from sibling ws_invoice_get (JSON data) and ws_invoice_list. Not a tautology of the title; it states the exact deliverable and the two concrete return modes.

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

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

The description gives solid guidance on choosing base64 vs binary for the format parameter, explaining that base64 is for a caller that will decode and save, while binary returns only metadata. However, it never explicitly routes the agent to/from sibling alternatives (e.g., when to prefer ws_invoice_get or ws_invoice_list over this PDF tool); that selection is left implied by the phrase 'as a PDF'.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying exactly what is returned (address, quota, forwarding configuration), which is not in the annotations. No 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?

A single, front-loaded sentence with zero filler. It communicates the action, scope, and return content efficiently.

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

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

For a simple read-only get tool, the description fully covers what it returns and the operation is simple. Annotations handle safety and idempotency, and schema covers parameter details. Nothing essential is missing.

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

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

Schema description coverage is 100% for all three parameters, so the schema already documents them. The description adds no additional parameter meaning, staying at the baseline.

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

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

States a specific verb 'Get' and resource 'one mailbox by id', and lists the returned fields (address, quota, forwarding configuration). This clearly distinguishes it from ws_mailbox_list, which enumerates mailboxes.

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 (needs an id) but does not explicitly mention when to use this vs. ws_mailbox_list or any exclusions. No alternative is named, so the agent must infer that list is for enumeration.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds no further behavioral context (e.g., pagination, ordering, or error conditions), so it meets the minimum but adds no extra 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, front-loaded sentence with no redundant words. It efficiently communicates the operation without any filler.

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

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

For a simple list tool with two well-documented parameters and read-only annotations, the description is adequate. However, it omits any mention of the return format or potential pagination, which could be helpful but is not strictly required for such a basic list 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 description coverage is 100%, so both parameters are fully documented in the schema. The description does not add any parameter-specific semantics beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description states a clear verb ('List'), a specific resource ('mailboxes'), and a scope ('on a hosting service'). It distinguishes this from sibling ws_mailbox_get by implying a collection operation, and the name itself is unambiguous.

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

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

The description implies usage: to list mailboxes for a hosting. It does not explicitly mention alternatives or exclusions (e.g., 'use ws_mailbox_get for a single mailbox'), leaving the routing decision to inference from the name and sibling list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the domain scoping behavior, which is useful context beyond annotations, but it does not describe what the statistics include (e.g., storage used per mailbox, counts) or pagination. It adds modest value but not rich behavioral detail.

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

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

Two sentences with no filler. The purpose is front-loaded, and the scoping instruction is immediately actionable. Every word earns its place.

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

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

For a simple read-only stats tool with 3 well-documented parameters and no output schema, the description covers the essential aspects: what it does, how to scope, and the required hostingId. It could mention what metrics are returned, but given the simplicity and annotation coverage, it is sufficiently complete.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description repeats the domain scoping and adds the overall purpose, but it does not provide additional parameter-level insight beyond what the schema already states. Baseline 3 is appropriate.

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

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

States a specific verb ('statistics') and resource ('mail storage') for a hosting service, clearly distinguishing it from sibling stats tools like ws_hosting_stats or ws_db_stats. It also mentions the domain scoping option, which clarifies the tool's scope precisely.

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

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

The description gives context on when to use the tool (for mail storage statistics) and explains the domain parameter's effect, but it does not explicitly mention alternatives or when not to use this tool versus other stats tools. Usage is implied but not contrasted with siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context about what the response includes (type, status, expiry), which goes beyond the annotations. It doesn't describe error behaviors or side effects, but given the read-only nature, the description is adequate.

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

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

Two concise sentences with no redundancy. The core action is stated first, followed by a practical pointer to the prerequisite list call. Every word earns its place.

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

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

The tool is simple with one required parameter and no output schema. The description explains what fields are returned, which is helpful. It doesn't mention potential errors or edge cases, but for a read-only get-by-id operation, this level of detail is sufficient. The annotations cover the read-only and idempotent aspects.

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

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

Schema coverage is 100% for both parameters. The description adds value by telling the agent where to obtain the serviceId (from ws_service_list), which is not in the schema. The userId parameter is fully documented in the schema with its default and meaning, so the description's hint about serviceId origin is a meaningful addition.

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 a specific verb ('Get') and resource ('one service by id'), and further specifies the returned fields (type, status, expiry). It distinguishes itself from the sibling ws_service_list by explicitly noting the difference between listing and getting a single item.

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

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

The description provides explicit usage guidance: 'Use ws_service_list first to find the id.' This tells the agent the correct prerequisite and ordering. It doesn't explicitly contrast with other get tools (e.g., ws_user_get), but the resource name and clarity make the use case clear enough.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds the v1 envelope format ({items, pager}) and the relationship to v2 tools, which is beyond the annotations. No contradictions.

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, no fluff, and the core purpose is front-loaded. The cross-tool hint is placed efficiently at the end.

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 list tool with one optional parameter and no output schema, the description covers what the agent needs: what it returns, how it relates to other tools, and the parameter is self-explanatory in the schema.

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

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

Schema description coverage is 100%, so the userId parameter is fully documented in the schema. The description does not add any extra meaning beyond that, which is acceptable but doesn't raise the score above the baseline.

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

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

The description clearly states the tool lists the account's services with concrete examples (hosting, domains, VPS), and distinguishes it from the sibling ws_service_get by being the list version. It also specifies the output envelope, making the 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?

It provides clear context by noting that service ids from this list are candidates for the v2 tools' 'service' argument, which guides when to use it. However, it doesn't explicitly contrast with more specific list tools like ws_hosting_list or ws_vps_list, so no exclusions 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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds critical behavioral context beyond that: it warns that the response includes sensitive data (billing address, email, phone, verifyUrl with a live key) and instructs not to echo or store the full response. This goes beyond annotations and is valuable for safe usage, though it doesn't describe other behaviors like pagination 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?

The description is extremely concise: two sentences. The first states the purpose and key fields, the second delivers the sensitive-data warning. There is no filler or redundant information. The most critical information (purpose) is front-loaded, and the warning follows logically.

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 getter with one optional parameter and no output schema. It lists the main response fields and highlights the sensitive nature, which is essential for proper handling. It does not detail the structure of nested objects like billing profiles, but that is likely covered by the response schema (not provided). Given the simplicity and the annotations covering safety, this is sufficiently complete.

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

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

The input schema has 100% coverage for the single parameter userId, which is fully described with a default and explanation. The description does not add any additional parameter semantics beyond listing the fields in the response, which is not tied to the parameter. Since the schema already documents the parameter adequately, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: retrieving the account record and lists specific fields (id, contact details, billing profiles, market, currency). The verb 'get' plus the resource 'account' distinguishes it from sibling tools like ws_auth_check, which checks authentication, and other ws_*_get 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?

The description does not explicitly name an alternative or state 'use this when...', but the context is clear: this is the only tool for retrieving account data. It does provide handling guidance for the sensitive response, which is a form of usage instruction. There is no explicit exclusion of other tools, but the domain makes it obvious, so it earns a 4 rather than 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds value by specifying what information is returned (specification, IPs, power state), which helps the agent set expectations for the response. No additional behavioral quirks are disclosed, but this is adequate given the annotations.

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

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

The description is a single, compact sentence that front-loads the primary purpose (getting a VPS by id/name) and then lists the included data. No filler or redundancy; every word contributes to the agent's understanding.

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

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

For a simple read-only get operation with full parameter documentation in the schema and safety covered by annotations, the description provides sufficient context. It states what the tool returns, which is the main missing piece beyond the schema. No output schema is needed for this level of tool.

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

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

Schema coverage is 100%, so both vpsId and userId are already documented in the input schema. The description's mention of 'by id or name' aligns with the vpsId schema description but adds no new meaning beyond it. Baseline of 3 is appropriate when the schema fully documents parameters.

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 'Get', the resource 'VPS', and the scope 'by id or name', and enumerates the returned data (specification, IP addresses, power state). This distinguishes it from sibling tools like ws_vps_list (which lists multiple VPSs) and ws_vps_stats (which provides statistics).

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

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

The description implies use when a single VPS's details are needed, and the 'by id or name' qualifier signals that a known identifier is required. However, it does not explicitly name alternatives or exclusion conditions, though the purpose is clear enough that an agent can infer when to call this tool versus list/stats tools.

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

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is fully covered. The description adds no behavioral context such as pagination behavior, sorting, or whether it returns only VPS metadata or includes details. It is consistent with annotations but adds minimal value beyond them.

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

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

The description is a single, focused sentence that front-loads the verb and resource. Every word is meaningful, with no filler or redundancy. It is appropriately sized for a simple listing 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?

For a straightforward list tool with all parameters documented and a safe read annotation, the description is adequate. It could mention that results are paginated (given the page and pagesize parameters) or that it returns a list of VPS summaries, but these are minor omissions. The lack of an output schema means the return format is not specified, yet the tool is simple enough that this is not a critical gap.

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

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

The input schema documents all three parameters (page, userId, pagesize) with descriptions, achieving 100% schema coverage. The description does not mention any parameters, so it adds no additional meaning. Since the schema already provides sufficient documentation, the baseline of 3 applies.

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

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

The description clearly states the verb 'List' and the resource 'VPS instances', making the purpose unambiguous. However, it does not differentiate from sibling tools like ws_vps_get, ws_vps_stats, or ws_vps_snapshot_list, so while the action is clear, the scope of what 'list' returns (e.g., summaries vs. full details) is not distinguished.

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

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

There is no guidance on when to use this tool versus alternatives. It does not mention that ws_vps_get is for a single instance or that ws_vps_stats provides performance data, nor does it state any prerequisites or exclusions. The agent must infer that this is the generic list operation.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds value by mentioning the returned fields (names and creation times), which is useful context, but it does not disclose other behaviors like pagination, ordering, or error handling. Given the annotations, the bar is lower, and the description adds a modest amount of context beyond them.

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

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

The description is a single, efficient sentence that front-loads the action and key output details. There is zero redundancy or wasted words, making it highly concise 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 list tool with no output schema, the description provides the essential information: what it lists, for which VPS, and what fields it returns. However, it omits details like whether the list is paginated, ordered, or if it returns an array or object. Given the tool's simplicity and the thorough schema, these gaps are minor, but the description could be slightly more explicit about the response shape.

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

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

Schema description coverage is 100%, and the schema itself thoroughly documents both parameters (vpsId with source reference, userId with default and meaning). The tool description adds no additional parameter semantics beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'List' and the resource 'snapshots taken of a VPS', and specifies the output fields (names and creation times). It distinguishes itself from sibling tools like ws_vps_list (lists VPSs) and ws_vps_get (gets VPS details) by focusing on snapshots specifically.

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, nor any exclusions or prerequisites. It does not mention that it operates on a specific VPS identified by vpsId, nor that it is read-only. The usage context is only implied by the tool name and parameters.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds semantic context for the kind parameter (processor load vs network transfer) but does not disclose behavior such as return format, time range, or aggregation. Given the strong annotation coverage, this is acceptable 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 two sentences, front-loaded with the core purpose and immediately followed by the parameter explanation. Every word earns its place, with no redundant information or padding.

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 stats tool with three parameters and clear annotations, the description is adequate but does not explain the output format (e.g., time series vs. aggregate). With no output schema, some guidance on the return structure would be beneficial. However, the tool's simplicity and the siblings' patterns partially compensate. A short note on what the statistics look like 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?

The schema covers all parameters with descriptions (100% coverage), but the description adds meaning beyond the schema by clarifying that kind selects the series and providing concrete meanings for 'cpu' (processor load) and 'traffic' (network transfer). This helps the agent understand the enum values more intuitively. The vpsId and userId parameters are adequately described in the schema and don't need additional explanation.

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

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

The description clearly states the tool's function: it returns usage statistics for a VPS, and specifies the two series (cpu and traffic) via the kind parameter. This distinguishes it from other stats tools like ws_hosting_stats or ws_db_stats by the resource type, and from ws_vps_get which retrieves VPS details rather than statistics.

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

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

The description implies usage for VPS statistics, but does not explicitly state when to use it over alternatives or provide exclusions. It doesn't mention that other stats tools exist for other resources, though the resource specificity makes the intended use clear. No direct guidance on selecting this tool vs. siblings.

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

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

The description discloses sensitive behavioral traits beyond the annotations: it warns that the response may contain a one-time console URL or session credential, instructs the agent to hand it only to the requesting user, forbids logging or repeating it, and notes that it expires. This is critical security context that annotations (readOnlyHint, idempotentHint) do not cover. It adds significant value and does not contradict any annotation.

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: a single sentence stating the purpose, followed by a necessary security warning. It is front-loaded with the core function and the sensitive warning earns its place. No unnecessary words or redundancy.

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

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

The description covers the purpose and the key security behavior (sensitive, expiring credential). Given the simple two-parameter schema and no output schema, it is fairly complete. It doesn't describe the response format or error conditions, but these are not critical for an agent to invoke the tool correctly, especially since annotations already confirm it is read-only and idempotent.

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 provides full descriptions for both parameters (vpsId and userId) with 100% coverage. The description itself adds no parameter-specific details. Since the schema already handles parameter semantics, a baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Get VNC console access details for a VPS'. This clearly distinguishes it from sibling tools like ws_vps_list, ws_vps_get, and ws_vps_stats, which serve different purposes. The agent can immediately identify what this tool does and how it differs from the others.

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

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

The description clearly communicates the tool's purpose but does not explicitly compare it to alternatives or state when not to use it. However, the context is unambiguous: it's about VNC console access, which is unique among the siblings. The absence of explicit exclusions is a minor gap, but the tool's function is obvious enough that an agent can infer when to call it.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only the 'by domain name' selection detail and does not disclose additional behavior such as not-found handling or response shape.

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

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

A single sentence with no filler. The verb, object, and key selection criterion are all front-loaded and scannable.

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

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

The simple schema and strong annotations make a short description mostly adequate, but the near-identical sibling ws_dns_zone_get creates real ambiguity that this description does not resolve. There is also no output schema and no statement about what the response will contain, though that is partially mitigated by annotations.

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

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

Schema description coverage is 100%, so both domain and userId are already fully documented. The description's 'by domain name' phrase merely restates the schema's domain parameter rather than adding new 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 states a clear verb and resource: 'Get one DNS zone by domain name.' It is specific about the lookup key, but it does not explicitly differentiate itself from the near-identically named sibling ws_dns_zone_get, so it stops short of a 5.

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

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

There is no guidance about when to choose this tool instead of alternatives such as ws_dns_zone_get or ws_zone_list. The description implies only that it fetches a single zone by domain, with no mention of prerequisites, fallbacks, 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 declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds the deprecation context about record CRUD, but that concerns a sibling tool, not this one. No additional behavioral details (e.g., pagination behavior, defaults) are disclosed beyond what annotations and schema cover.

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

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

Two sentences with zero waste. The main purpose is front-loaded, followed by the sibling routing note. No redundant phrases.

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 list operation with three optional parameters fully documented in the schema and a read-only annotation, the description is sufficient. It lacks return-format details, but no output schema exists, and the tool's simplicity makes that acceptable. The sibling note adds practical 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?

Schema description coverage is 100%, with all three parameters (page, userId, pagesize) clearly described. The description does not add any parameter-specific meaning beyond the schema, so baseline 3 applies.

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

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

The description states a specific verb ('List'), resource ('DNS zones'), and scope ('on the account'). It clearly distinguishes from the sibling ws_dns_record_list by noting that tool handles records inside a zone, while this one lists zones. The purpose is immediately 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?

The description explicitly directs users to ws_dns_record_list for records, and notes that v1 record CRUD is deprecated and deliberately not exposed. This provides a clear when-to-use versus alternative guidance, preventing misuse.

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