timeweb-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.8
Disambiguation2/5
With 245 tools, several groups have ambiguous boundaries: list_all_project_servers vs list_project_servers, v1/v2 pairs like list_mailboxes/list_mailboxes_v1, and create_database vs create_database_instance. Despite descriptions, the sheer scale and near-identical names make misselection likely.
Naming Consistency3/5
Most tools follow verb_noun, but inconsistencies exist: get_vpcs (a list), edit_api_key instead of update_, and preset getters mix get_ and list_ (get_allowed_presets vs list_balancer_presets). The pattern is readable but not uniform.
Tool Count1/5
245 tools is extreme and far beyond typical MCP servers. Many are redundant (v1/v2, list_all_project vs list_project), inflating the count without adding distinct capability.
Completeness4/5
The toolset covers the lifecycle of most resource types (servers, DB, K8s, S3, domains, mail, networking). Minor gaps exist (e.g., delete_database_instance, reinstall server, get_dns_record singular), but core workflows are largely supported.
Average 3.7/5 across 245 of 245 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on July 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description 'Список' (list) implies a read-only operation, but the annotation readOnlyHint is false, creating a direct contradiction. Additionally, no other behavioral aspects are disclosed, such as pagination, return format, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
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. It earns a high score for efficiency, though it could have included more useful context without much added bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description lacks critical context such as differentiation from list_all_project_dedicated and any information about the response. The missing sibling differentiation makes it incomplete for an agent to decide correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers project_id with 100% description coverage, so the baseline is 3. The description's 'в указанном проекте' only reaffirms the schema's meaning without adding any new semantic nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'list' and the resource 'dedicated servers' scoped to the specified project. It is specific but does not distinguish from the sibling tool list_all_project_dedicated, so it loses a point for lack of sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 list_all_project_dedicated or other list tools. There is no mention of exclusions, prerequisites, or alternative tools, leaving the agent without enough context for proper selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds no additional behavioral context, such as provisioning time, cost implications, or whether it returns an identifier. No contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant content. It is front-loaded and concise, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and many sibling database-related tools, the description is too sparse. It does not explain what kind of database object is created (cluster vs. instance), nor how this fits into the broader workflow (e.g., relation to list_project_databases or add_database_to_project).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 9 parameters documented and required fields clearly marked. The description merely says 'with specified parameters' and does not add meaning beyond what the schema already 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Creates' and the resource 'new database in Timeweb Cloud', making the basic purpose evident. However, it does not distinguish from sibling tools like create_database_instance or create_database_admin, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_database_instance or create_database_admin. It also lacks any prerequisites or contextual hints about when this operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation nature is disclosed. The description adds 'automatic determination of project parameters,' implying some parameters are inferred, but it does not elaborate on side effects, required permissions, or what happens on creation. Since the description carries little behavioral detail beyond the annotation baseline, it earns a low score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. Every word contributes to the core message: what the tool creates and where. It is perfectly concise for a tool whose parameter details are already fully specified in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the high complexity (16 parameters, 11 required, no output schema), the description omits essential contextual information: what the tool returns, preconditions (e.g., existing project or provider), and how 'automatic determination' affects the parameters. The schema covers parameter semantics but does not compensate for the lack of integration-level guidance, leaving the description incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having detailed Russian descriptions (e.g., 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ - переменные окружения. Пользователь должен указать их самостоятельно' and framework guidance). The description itself adds no parameter-specific meaning beyond the vague 'automatic determination.' Baseline of 3 is appropriate when the schema does the heavy lifting, and the description does not compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Создает' (creates) and the resource 'приложение в Timeweb Cloud' (application in Timeweb Cloud), making the primary action explicit. It also adds 'с автоматическим определением параметров проекта' (with automatic determination of project parameters), which hints at a useful capability. However, it does not explicitly distinguish this tool from other create_* siblings beyond the unique resource type, and 'приложение' could be ambiguous without additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an existing project or VCS provider) or scenarios where another tool like create_server or create_project would be more appropriate. The only contextual hint is embedded in the schema's framework parameter, which is not part of the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
This is an annotation contradiction: the description says 'returns' (a read operation), but annotations set readOnlyHint=false, suggesting the tool may not be read-only. The description also doesn't disclose side effects or safety characteristics, and the contradictory annotation undermines trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main verb ('Возвращает') and focuses on the return content. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one parameter, the description covers what it returns. However, it lacks context about cluster existence prerequisites, error behavior, or any distinction from sibling tools. The annotation contradiction also reduces overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the only parameter (cluster_id) is described as 'MANDATORY FIELD - Cluster ID,' which adds no semantic meaning beyond the name. The tool description doesn't elaborate on the cluster_id parameter, so it meets the baseline but doesn't exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns add-ons available for installation, listing specific attributes (type, version, dependencies, YAML template). It distinguishes from siblings like list_k8s_addons by specifying 'available for installation,' 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance or alternatives are provided. The phrase 'available for installation' implies use before installing an add-on, but it doesn't mention when not to use it or point to sibling tools like list_k8s_addons or install_k8s_addon.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal and does not disclose any behavioral traits beyond the basic list operation. The annotations include readOnlyHint: false, which is unusual for a list operation, and the description does not clarify whether there are side effects or specific behaviors like pagination or response shape. Thus, the description adds little transparency beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the core action and resource. It is appropriately concise for a simple list operation, though it is so brief that it borders on under-specification, missing opportunities to add useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no output schema, the description is adequate but not complete. It states the action and scope but does not mention what the response contains (e.g., bucket names, IDs) or any pagination or filtering behavior. Given the lack of an output schema, a more detailed description would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter 'project_id' with a mandatory flag and a brief description. The description rephrases this as 'in the specified project' but adds no new semantic detail. Since schema coverage is 100%, a baseline of 3 is appropriate, with no extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 'S3 storages' (buckets) scoped to a specified project, which provides a solid understanding of the action. However, it does not explicitly distinguish this from the similarly named sibling tool 'list_all_project_buckets', leaving some ambiguity about when to use one over the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool lists buckets for a specific project, but it provides no explicit guidance on when to choose this tool over alternatives like 'list_buckets' or 'list_all_project_buckets'. There are no exclusions or mention of alternative tools, leaving the usage context largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool 'deletes' an API token, which is clearly destructive, but the annotation destructiveHint is false. This is a direct contradiction. No additional behavioral context (e.g., irreversibility, permissions) is given, so the description fails to provide transparency and actually misleads.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and target. It has zero wasted words, appropriately sized for a simple deletion tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple one-parameter tool, the description's contradiction with destructiveHint and lack of any note about irreversibility or post-deletion effects leaves it incomplete. The annotations do not compensate, and the description fails to clarify the operation's impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers token_id with 100% coverage and a clear description ('ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID API-токена'). The description's phrase 'by its ID' adds no extra meaning beyond the schema. Baseline 3 applies because schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Удаляет API-токен по его ID' uses a specific verb ('Удаляет' = deletes) and resource ('API-токен' = API token) and adds scope ('by its ID'). This clearly distinguishes it from sibling tools like edit_api_key or list_api_keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, such as needing the token ID, or contrast with edit_api_key/refresh_api_key. The usage is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says the action is irreversible, implying destructive behavior. However, the annotation destructiveHint is false, directly contradicting the description. This is a serious inconsistency that misleads about the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise—two short sentences with no unnecessary words. It delivers the essential purpose and a key behavioral warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation, the description is too sparse. It lacks details about cluster impact, consequences for associated resources, or any prerequisites. The contradiction with destructiveHint further undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (node_id and cluster_id) are fully described in the schema with 100% coverage, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Deletes a specific node from the cluster.' It distinguishes itself from sibling tools like delete_k8s_cluster and delete_k8s_node_group by specifying 'node' and 'cluster'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor when not to use it. The description only states the action and irreversibility, leaving the agent to infer usage from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly says the operation is irreversible and all mail will be lost, which directly contradicts the destructiveHint=false annotation. This is a critical inconsistency that undermines the agent's understanding of the tool's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences in Russian with no unnecessary words. The key warning about irreversibility is front-loaded and clearly stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though the description warns about data loss, the contradiction with destructiveHint leaves the agent with conflicting signals. It also lacks details about return behavior, preconditions (e.g., empty mailbox), or domain-level side effects, making it incomplete for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters (domain and mailbox), so the description adds no additional parameter semantics. The baseline of 3 is appropriate since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool permanently deletes a mailbox, using a specific verb ('удаляет') and resource ('почтовый ящик'). It distinguishes itself from other delete-* tools by naming the exact resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like update_mailbox or batch_create_mailboxes. It only explains the consequence of the action, not the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Удаляет' (deletes), which is a destructive action, yet the annotation destructiveHint=false. This is a direct contradiction. The description adds no other behavioral context such as prerequisites or consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the action and key parameter. It is concise and front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and insufficient for a delete operation. It lacks any mention of return values, error conditions, or preconditions, and the contradiction with annotations leaves the agent confused about whether the operation is destructive. Given no output schema, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully covers the only parameter vpc_id with a required field description. The description merely restates 'by its ID,' adding no new semantic information beyond the schema, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Удаляет виртуальную приватную сеть (VPC) по её ID' (Deletes a VPC by its ID). This is a specific verb+resource, clearly distinguishing it from other VPC operations like create_vpc, update_vpc, get_vpc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It only states the action and parameter, leaving usage context implied from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint is false, but the description says 'list' which is a read-only operation. This is a direct contradiction, as the description implies the tool is safe and read-only while the annotation suggests it may not be. The description also adds no additional behavioral context beyond what the annotation already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and directly states the tool's purpose. It is front-loaded with the core action ('List') and resource ('dedicated servers'), making it easy to parse. There is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, but the lack of an output schema and the brief description leave uncertainty about the exact return fields (e.g., server IDs, names, project IDs). The description covers the essential purpose but is not fully complete given the absence of structured output details and the contradictory annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4. The description does not need to explain parameter meanings, and it does not add any parameter-related information, which is acceptable given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists all dedicated servers of the account with project binding, which is a specific action on a specific resource. It does not explicitly distinguish from sibling tools like list_dedicated_servers or list_project_dedicated, but 'all' and 'account' imply the account-wide scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only describes what it does, without stating the scenarios or exclusions. There is no mention of when to prefer this over list_dedicated_servers or list_project_dedicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only listing operation, but the annotations declare readOnlyHint=false, creating a direct contradiction. No additional behavioral traits (e.g., pagination, filtering, return format) are disclosed in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential purpose without unnecessary words. It is well-structured and immediately readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks context about expected response structure, pagination, or how this tool fits among similar tools. There is no output schema, and the annotations are contradictory, leaving the agent with insufficient information to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has a single parameter, project_id, which is fully described in the schema as 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID проекта'. The tool description mentions 'в указанном проекте' but adds no further detail beyond what the schema already provides. Since schema coverage is 100%, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Список балансировщиков в указанном проекте' clearly states the action (list), the resource (balancers), and the scope (in the specified project). It distinguishes itself from sibling tools like list_balancers and list_all_project_balancers by emphasizing the project context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Given the many sibling list tools (e.g., list_balancers, list_all_project_balancers), it would be helpful to specify that this is for the project-scoped list. The description merely states what it does without any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says the tool deletes subdomains, which directly contradicts the annotation destructiveHint=false. This is a significant annotation contradiction. No additional behavioral context is provided (e.g., irreversibility, partial failure behavior), and per the rubric this dimension must be scored 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first states the action, the second states the return value. Every word earns its place, and it is front-loaded with the core operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with well-documented schema parameters, the description is minimally viable: it states what is deleted and that per-subdomain status is returned. However, it lacks caveats about destructive effects, missing-subdomain behavior, or interactions with certificates, and the conflicting annotation undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with 100% description coverage, including an example for subdomains. The description adds only that deletion status is returned per subdomain, but this is not parameter-specific, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Удаляет один или несколько поддоменов из S3-хранилища' (Deletes one or more subdomains from S3 storage). This specifies a concrete verb and resource, and naturally distinguishes it from sibling tools like add_bucket_subdomains and list_bucket_subdomains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as delete_subdomain or add_bucket_subdomains. It also omits prerequisites or side effects, leaving the agent to infer usage solely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly contradicts the annotations: readOnlyHint is false, but the description describes a read-only listing operation ('Получает список'). This is a serious inconsistency, and the description does not disclose any potential side effects or reasons for the non-read-only flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the purpose without any fluff or extra details. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list operation, the description adequately explains what the tool returns (available database config presets). While there is no output schema, the description is sufficient for basic understanding, though the annotation contradiction slightly undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so according to the rubric the baseline is 4. The description does not need to add parameter information, and the schema already covers this entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Получает список доступных пресетов конфигураций для создания баз данных' (gets a list of available configuration presets for creating databases). It is specific about the resource (database presets) and distinguishes itself from similar preset tools for other resources like buckets or servers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_bucket_presets or get_allowed_presets. It simply states what the tool does without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it 'returns data,' implying a read-only operation, but annotations set readOnlyHint to false and idempotentHint to false. This is a direct contradiction. No additional behavioral context is provided to resolve the inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and resource, then adds valuable detail about the return format. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the response structure but lacks usage guidance and fails to resolve the annotation contradiction. Given the tool's simplicity and complete schema coverage, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (domain, mailbox) are fully described in the schema (100% coverage), so the description does not need to add much. It provides no extra semantics beyond the schema, achieving the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Возвращает' - returns) and identifies the exact resource ('данные одного почтового ящика') plus the API version (v1) and distinctive structured blocks (auto_reply/spam_filter/forwarding_*), distinguishing it from sibling tools like get_mailbox and list_mailboxes_v1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as get_mailbox or list_mailboxes_v1. The mention of 'API v1' implies a versioning context, but there is no clear instruction on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a pure read operation ('Возвращает все поддомены'), but the annotations set readOnlyHint to false, creating a direct contradiction. The description adds no clarifying behavioral details such as side effects, permissions, or rate limits, and the contradiction makes the tool's safety profile unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main action and enumerates the returned fields. Every word contributes to the understanding of the tool, making it concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one parameter, the description lists the returned fields, which is helpful, but it lacks details about pagination, error conditions, or the meaning of SSL statuses. More critically, the contradiction between the description and the readOnlyHint leaves the agent uncertain about potential side effects, reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter bucket_id is fully documented in the schema with a description, so schema coverage is 100%. The tool description does not add any additional semantic context beyond what the schema already provides, thus 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (возвращает / returns) and the specific resource (поддомены, привязанные к S3-хранилищу), along with the precise fields returned. It distinguishes itself from sibling tools like add_bucket_subdomains and delete_bucket_subdomains by being the list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any preconditions or exclusions. While the purpose is clear, there is no context about when to choose list_bucket_subdomains over related tools such as get_bucket or list_buckets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the basic action. Annotations already provide readOnlyHint and destructiveHint flags, but the description does not elaborate on anything like pagination, authentication, or side effects. Since 'list' implies a read operation but the annotation readOnlyHint is false, there is potential confusion, though the description itself does not explicitly contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous information. It is front-loaded, directly stating the function and scope. This is an appropriately minimal description for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, and the description covers the essential purpose. However, it lacks differentiation from sibling tools and does not clarify return format or any special behavior. Given the presence of many similar list tools, the description is adequate but leaves gaps for an agent to select unambiguously.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with a single required parameter 'project_id' described as 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID проекта'. The description does not add additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Список k8s-кластеров в указанном проекте' clearly states the action (list), the resource (k8s clusters), and the scope (specified project). It is specific and uses a distinct verb+resource pattern, though it does not explicitly differentiate from similar sibling tools like 'list_all_project_clusters' or 'list_k8s_clusters'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, preferred contexts, or relationships to other list tools among the many siblings. The description simply states what it does without any contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the action is irreversible and nodes cannot be restored, which is a critical behavioral trait. However, the annotations declare destructiveHint=false, directly contradicting the description's claim. This is a serious inconsistency, warranting a score of 1 per the rubric.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, information-dense sentences. It front-loads the primary function and then adds the critical irreversibility warning. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with three well-documented parameters and no output schema, the description covers the core action and a key consequence. However, the contradiction between the description's destructiveness and the annotations' destructiveHint=false undermines the overall completeness, confusing the agent about the tool's safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear Russian descriptions for all three required parameters: count (number of nodes to delete), group_id, and cluster_id. The description adds no additional parameter semantics beyond what the schema already 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Удаляет указанное количество воркер-нод из группы' (Deletes a specified number of worker nodes from the group). It specifies the verb, resource, and quantity, and the name 'reduce_k8s_node_group_nodes' matches the purpose. It is easily distinguishable from siblings like 'increase_k8s_node_group_nodes' and 'delete_k8s_node_group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any contextual guidance on when to use this tool versus alternatives. It does not mention scaling down, nor does it contrast with deleting individual nodes or increasing nodes. The usage context is only implied by the tool name and operation type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the action is irreversible, which directly contradicts the annotation destructiveHint=false. This is a serious inconsistency that could mislead an agent about the tool's safety profile, warranting the lowest score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, immediately states the purpose, and includes the critical side effect (irreversibility) without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and side effect for a simple 2-parameter tool, but the contradiction with annotations undermines completeness by leaving the agent uncertain about the destructive nature. No mention of prerequisites beyond 'previously installed' is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have clear descriptions in the schema. The tool description adds no additional parameter semantics, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'deletes' with the resource 'addon' and context 'cluster', clearly distinguishing it from sibling operations like install, update, or list. The phrase 'previously installed' adds scope and confirms the action is removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or how it differs from alternatives. The description only states what it does, leaving the agent to infer usage from the tool 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Операция необратима' (the operation is irreversible), which directly contradicts the annotation 'destructiveHint': false. This is a serious inconsistency that misleads the agent about the tool's side effects, warranting a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, but the second sentence ('отвязывает домен от аккаунта') largely repeats the action stated in the first sentence ('Удаляет домен с аккаунта'), adding minor redundancy. Still, it is compact and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description covers the action and irreversibility. However, the contradiction with the destructiveHint annotation leaves ambiguity about the actual destructive nature, and it does not mention any side effects or prerequisites. It is adequately rich but undermined by the inconsistency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'fqdn' parameter (schema coverage 100%), including a description that it is required and the full domain name for deletion. The description's mention of 'FQDN' reinforces this but adds no new semantic information beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Удаляет домен с аккаунта по FQDN' (Deletes a domain from the account by FQDN). It uses a specific verb and resource, distinctly differentiating it from sibling tools like add_domain, update_domain, and get_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied by the verb 'deletes' and the resource 'domain', but the description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions. It lacks direct recommendations or cautionary notes beyond the operation itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only GET operation, but the annotations set readOnlyHint=false and idempotentHint=false, which contradicts the behavioral nature of the tool. This is a flagrant contradiction, as GET requests are inherently read-only and idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that includes the endpoint URL. It is concise with no wasted words, earning a perfect score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the operation is simple, the description lacks important context: it does not explain what information is returned, does not mention authentication or prerequisite clusters, and the confusion with annotations reduces overall completeness. No output schema exists, so the description should have provided more detail on return values and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptive names and mandatory flags for both parameters (admin_id and db_cluster_id). The description does not add additional parameter semantics, but the schema already communicates the essential meaning, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns information about a database cluster user, and the endpoint path shows that it is a GET request for a specific admin_id within a db_cluster_id. This distinguishes it from sibling tools like list_database_admins, update_database_admin, and delete_database_admin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving a single database cluster admin by ID, but it does not explicitly state when to use this tool versus listing admins or other alternatives. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations state readOnlyHint=false and idempotentHint=false, but the description clearly indicates a read-only operation ('Возвращает детальную информацию'). This is a direct contradiction, as a GET-like operation should be read-only and idempotent. The description fails to disclose any side effects or mutations, and the annotations actively mislead about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main purpose and lists the returned fields without any fluff. Every word contributes meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the return value by enumerating the key fields, which is sufficient for a simple 1-parameter get operation. However, it does not mention error behavior, authentication requirements, or any edge cases, but given the low complexity and absence of an output schema, it is reasonably complete. The annotation contradiction slightly reduces trust but does not affect completeness directly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter image_id, and the description does not add additional semantics beyond what the schema states (e.g., format, constraints, or behavior). Baseline 3 is appropriate since the schema handles the load, and the description adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'возвращает' (returns) and specifies the resource 'информацию об образе' (information about an image) by ID. It also enumerates the returned fields (status, progress, sizes, OS, location, disk_id, custom flag), making the tool's purpose specific and distinguishable from siblings like list_images or get_image_download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or comparisons to sibling tools. It is simply a description of what the tool does, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description presents the tool as read-only ('Возвращает' – returns), but the annotation declares readOnlyHint=false. This is a direct contradiction. Additionally, it does not disclose any side effects, permissions, or state-changing behavior that might justify the readOnlyHint=false annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly conveys the tool's purpose and output. No unnecessary words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return values, which is helpful given no output schema. However, the contradiction with readOnlyHint and lack of any mention of potential side effects or non-read-only behavior makes it incomplete for a tool that may not be a pure read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage of the single 'domain' parameter with a clear description. The tool description adds no further meaning to the parameter itself, though it clarifies the return value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns mail domain information, specifically the catch-all address and used space. This distinguishes it from sibling tools like get_mailbox or update_mail_domain_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving mail domain info but does not explicitly state when to use it versus alternatives. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'gets list' which implies a read-only operation, but the annotations state readOnlyHint=false. This is a direct contradiction; the description does not clarify any potential side effects or why it is not read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. It is appropriately concise for a straightforward list operation, though it adds little beyond the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with no output schema, the description covers the core function but omits potential details like pagination, ordering, or return format. The lack of behavioral context combined with the annotation contradiction leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter provider_id has an adequate description. The tool description adds no extra semantic detail beyond what the schema already 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('gets') plus resource ('list of VCS provider repositories') and the key qualifier 'by ID', which distinguishes it from sibling tools like get_vcs_providers or get_vcs_provider_by_repository_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you have a provider ID and need its repositories) but provides no explicit guidance on when not to use it or alternatives. It lacks any exclusions or comparisons with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly shows `GET /api/v1/databases/{db_cluster_id}/admins`, indicating a read-only list operation, but annotations declare readOnlyHint=false. This is a direct contradiction. No other behavioral context (e.g., authentication, rate limits) is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that includes all essential information: the action, resource, and endpoint. There is zero waste or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description is nearly complete. It states the resource and endpoint, but doesn't mention the return format (e.g., array of user objects) or any potential pagination. The annotation contradiction slightly undermines completeness, but the description itself is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter db_cluster_id with a clear description. The tool description adds no further meaning beyond referencing the parameter in the endpoint, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Возвращает список' - returns a list), the resource (users/admins of a database cluster), and includes the exact endpoint with the parameter. It effectively distinguishes from siblings like get_database_admin (single admin) and list_database_clusters (list clusters).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_database_admin for a single admin). The description only states what it does, leaving the agent to infer usage context from the tool name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states a read-only operation ('Возвращает список' - returns a list), but annotations declare readOnlyHint=false. This is a clear contradiction: the tool seems to be a listing operation, yet the annotation suggests it may not be read-only. No additional behavioral context is provided beyond this inconsistent signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence clearly states the function and current scope. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the annotation contradiction makes the description misleading. No output schema is present, and the description does not clarify return format, pagination, or the significance of 'currently only servers'. The lack of usage guidance further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, group_id, is fully described in the input schema as a required firewall group ID. The description refers to it indirectly ('указанной группе правил firewall') but adds no extra semantics beyond the schema. With 100% schema description coverage, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns a list') and clearly identifies the resource (resources attached to a firewall rule group) with a scope note ('currently only servers'). This distinguishes it from sibling tools like list_firewall_groups and list_firewall_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it lists resources for a specified firewall group, but it does not explicitly contrast with related tools such as list_firewall_groups_by_resource or explain when to choose this tool over alternatives. The 'currently only servers' hint gives some context but no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description presents a read-only operation ('Возвращает' / returns), whereas the annotation declares readOnlyHint: false, creating a contradiction. This could mislead an agent about side effects. No further behavioral traits are disclosed beyond the contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and fully describes the result set without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but has no output schema, and the description does not detail the exact structure of the returned addresses. More importantly, the annotation contradiction (readOnlyHint false) undermines the description's clarity, making the tool's behavior ambiguous for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes server_id as a required field. The description adds no parameter-level semantics beyond the schema, which has 100% coverage, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns all IPv4 and IPv6 addresses assigned to the server, including PTR records and the main IP flag. The verb 'Возвращает' (returns) and the resource 'серверу' (server) specify a distinct action from sibling tools like list_balancer_ips or add_server_ip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing server IP addresses but does not explicitly state when to use this tool over alternatives like get_server or list_servers, nor does it mention any exclusions or alternative tools. It provides no comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already declare. It does not disclose side effects (e.g., whether the IP is detached from a previous service), error conditions, idempotency implications, or response behavior. Given idempotentHint=false and the write nature, the agent gets no insight into potential failures or state changes. The description merely restates the action without enriching the safety/behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the active verb 'Привязывает', and includes the key scope (resource types) without any fluff. Every word earns its place; it is optimally compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple binding operation, the description covers the core action and the three parameters, but it lacks important context: prereqs, success expectations, and any behavioral caveats. With no output schema, the agent cannot anticipate the response format. The description is minimal but adequate for a straightforward action; however, it does not explain what happens on success or failure, leaving the agent with the bare essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does repeat the resource_type enum values in parentheses, but these are already present in the schema. It adds no extra meaning for floating_ip_id or resource_id beyond what the schema says ('ID ресурса'). Thus it neither harms nor enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Привязывает плавающий IP к сервису' (binds floating IP to a service), and explicitly lists the supported resource types (server / balancer / database / network). This distinguishes it from sibling tools like unbind_floating_ip (opposite action) and add_server_ip (which likely adds a regular IP rather than binding a floating IP). The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or any prerequisites. It does not mention that the floating IP must be unbound, that the resource must exist, or that this tool is for floating IPs specifically (as opposed to regular IP assignment via add_server_ip or add_balancer_ips). No explicit context for selection is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read, non-destructive, non-idempotent operation. The description adds only the grouping purpose, which is core to the tool's function, but does not disclose any additional behavioral traits such as side effects, response format, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the core purpose without any wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple creation operation with three well-documented parameters and no output schema. The description provides the essential context of grouping resources but does not mention what the response contains or any post-creation behavior. For a simple tool this is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all three parameters, so the schema already fully documents each field. The description does not add parameter-level detail, which is acceptable given the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Создаёт' (creates) and identifies the resource as a project for grouping resources, making the tool's purpose clear. It distinguishes from siblings by focusing on the project entity, but does not explicitly contrast with other create_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool is for creating a project to group resources. However, there is no explicit guidance on when to use this tool versus alternatives like create_server or create_k8s_cluster, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the operation is irreversible and destructive, but the annotation destructiveHint=false contradicts this. This is a direct contradiction between description and structured metadata, reducing trust and transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a warning. It is front-loaded with the action and resource, contains no fluff, and effectively communicates the key caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description covers the essential behavior and irreversibility. However, the annotation contradiction introduces confusion, and there is no mention of side effects or error conditions, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully defines the sole parameter agent_id with a clear description, providing 100% coverage. The description does not add parameter-specific meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Удаляет AI-агента по ID' (Deletes AI agent by ID). It uses a specific verb and resource, distinguishing it from sibling tools like list_ai_agents, get_ai_agent, and update_ai_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The warning '⚠️ Операция необратима — подтверждай с пользователем' gives clear usage context: confirm with the user before use. However, it does not explicitly state when to use this tool versus alternatives or any prerequisites (e.g., existence of the agent).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint is false, yet the description explicitly states 'Действие необратимо' (action is irreversible). This is a direct contradiction: a delete operation that is irreversible is destructive. The description does add the irreversibility warning, but the contradiction with the annotation is a serious issue, so the score is 1 per rubric.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the action and the HTTP endpoint, the second warns about irreversibility. It is front-loaded with the key verb and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two parameters and no output schema, the description conveys the essential behavior and the important warning about irreversibility. However, it lacks details such as prerequisites, potential side effects on associated resources, or what happens if the admin does not exist. The annotation contradiction also undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both db_cluster_id and admin_id. The description does not add new parameter information beyond the schema, but the endpoint path in the description reinforces the roles of the two parameters. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the verb 'Удаляет' (deletes) and specifies the resource 'пользователя кластера базы данных' (database cluster user), clearly distinguishing it from tools like delete_database_cluster or update_database_admin. The inclusion of the exact HTTP endpoint further narrows the scope to a specific admin within a specific cluster.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the action obvious but provides no explicit guidance on when to use this tool versus alternatives such as update_database_admin or create_database_admin. The intended usage is implied by the name and endpoint rather than stated with clear context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states this tool deletes a floating IP, which is a destructive operation. However, annotations declare destructiveHint: false, directly contradicting the described behavior. This is a serious inconsistency, and no additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded with the action verb and contains no redundant or irrelevant information. It is concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one well-documented parameter, the description is minimally adequate. However, it lacks any mention of prerequisites (e.g., unbinding the IP) or effects (e.g., irreversibility), and the annotation contradiction further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter floating_ip_id with a full description, achieving 100% schema description coverage. The description's 'по его ID' simply mirrors the schema without adding new meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Удаляет' (deletes) and resource 'плавающий IP' (floating IP) with the method 'по его ID' (by its ID). It clearly distinguishes this tool from siblings like create_floating_ip, bind_floating_ip, unbind_floating_ip, and update_floating_ip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool or what alternatives exist. The usage is implied by the name and description, but there are no notes about prerequisites or scenarios such as unbinding before deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes a read operation ('returns information'), but the annotation readOnlyHint=false contradicts this, suggesting the tool may modify state. This is a serious inconsistency, so behavioral transparency is not disclosed accurately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence in Russian that conveys the action and endpoint without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with two required parameters and no output schema. Description provides the endpoint and resource but does not detail return shape, usage context, or contrasts with siblings. The contradiction with readOnlyHint also reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The tool description adds no additional semantic meaning beyond what the schema 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns information about a database instance in a cluster, with the verb 'возвращает' and the resource. It distinguishes from list_database_instances by targeting a specific instance, and includes the full API endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or exclusion of alternatives is provided. The context implies it is for fetching details of a single instance, but it does not contrast with list_database_instances or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint: false and openWorldHint: true, while the description states it merely 'Возвращает' (returns) information, implying a read-only operation. This directly contradicts the annotations. The description provides no explanation for the non-read-only or open-world behavior, leaving the agent with conflicting signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and lists the returned data fields without unnecessary words. It effectively communicates the tool's core functionality in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with only one parameter and no output schema, the description covers the purpose, parameter, and return fields. However, the contradictory annotations (readOnlyHint false, openWorldHint true) create a significant gap in behavioral context that the description fails to address, making the overall picture incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter cluster_id with a clear description ('ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID кластера'), and the description reinforces that the tool operates by cluster ID. However, the description adds no extra semantic detail about the parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Возвращает детальную информацию о Kubernetes-кластере по его ID' (returns detailed info about a Kubernetes cluster by its ID) and enumerates the specific fields returned (имя, статус, версия, драйвер, ресурсы, зона, ingress). This distinguishes it from sibling tools like get_k8s_cluster_resources or get_k8s_kubeconfig.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a cluster_id and need detailed cluster info, but it does not explicitly state when to use this tool versus alternatives like list_all_project_clusters or get_k8s_cluster_resources. No exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation contradiction: readOnlyHint is false while the description says 'Returns' (a read operation), and idempotentHint false also conflicts with typical GET semantics. The description adds no further behavioral context and misleads about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy, clearly stating the action and key return data. Efficiently sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists return fields and API version but lacks an explicit read-only note (contradicting annotations) and provides no information on errors or output structure. Given the absence of an output schema, the description only partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions for both domain and mailbox. The description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns detailed data for a single mailbox, lists specific fields (owner, spam filter, forwards, auto-reply, webmail), and specifies API v2, distinguishing it from siblings like get_mailbox_v1 and list_mailboxes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and the API v2 mention, but the description does not explicitly state when to use this tool over alternatives like list_mailboxes or get_mailbox_v1. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=false contradicts the description's clear statement that the tool returns information (a read operation). This is an annotation contradiction because the description implies read-only behavior while the annotation suggests the opposite, so the description does not add trustworthy behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the action and lists the returned fields. It is concise without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the what and the returned fields, and the schema covers the input, but the annotation contradiction creates uncertainty about the tool's effects. It does not mention any prerequisites or clarify that it is read-only given the conflicting annotation, so completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single required parameter network_drive_id with a clear description at 100% coverage. The description mentions 'by its ID' but adds no additional semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns detailed information about a specific network drive by ID, listing the fields returned. This distinguishes it from list_network_drives and other drive operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (you need a network drive ID) but does not explicitly mention when to use it versus alternatives like list_network_drives or other network drive operations. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotation readOnlyHint=false: a listing operation is read-only, but the annotation suggests the tool may not be read-only. No additional behavioral context such as pagination, sorting, or response format is disclosed, and the annotation contradiction undermines transparency entirely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Russian sentence that front-loads the key information: it is a list of all account S3 storages. There is no redundant or filler language, and every phrase contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description provides the essential scope—all account buckets with project association—but it does not mention pagination, ordering, or return field details, and there is no output schema to fill that gap. It is minimally adequate but leaves some ambiguity, especially given the contradictory readOnlyHint annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds useful meaning by noting that returned buckets are associated with project_id, which gives the agent a hint about the output structure without inventing input parameters that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Список' = list) and the resource ('S3-хранилищ аккаунта' = account S3 storages), and adds the specific scoping detail that buckets are tied to project_id. This distinguishes it from siblings like list_buckets and list_project_buckets, which are project-filtered or lack the account-wide project grouping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any explicit when-to-use guidance or comparison with similar listing tools. It never mentions list_buckets or list_project_buckets as alternatives, nor does it explain when the account-wide all-project variant should be chosen over a project-scoped one. Usage is only implied by the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('Получает список' - gets a list), but the annotations declare readOnlyHint=false, indicating the tool might not be read-only. This is a direct contradiction, confusing the agent about safety and side effects. No other behavioral details are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficient and front-loaded with the verb. It contains no redundant information and earns every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without output schema, the description covers the main purpose adequately. However, the contradiction with annotations and lack of response format details leave gaps that could confuse an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for balancer_id. The tool description itself does not add additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Получает' - gets) and the resource ('список backend IP-адресов, привязанных к балансировщику'). It also clarifies the purpose of these IPs in traffic distribution. This distinguishes it from sibling tools like list_balancers or get_balancer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving backend IPs of a balancer but provides no explicit when-to-use guidance, exclusions, or references to alternative tools. The context is clear, but the lack of differentiation from sibling tools prevents a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Returns a list', which is a read-only operation, but the annotations declare readOnlyHint: false. This is a direct contradiction: the annotation suggests the tool may modify state, while the description clearly indicates it only reads. No additional behavioral context is provided beyond this conflict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action ('Returns a list') and provides a necessary definition of what the rules are. No wasted words, perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema), the description adequately explains what the tool returns. However, the contradiction with the readOnlyHint annotation undermines overall completeness, and the description does not mention that a balancer_id is required (though the schema covers that). It is functional but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter balancer_id with a clear 'mandatory field' note. The tool description does not add any extra meaning about parameters, so it contributes nothing beyond the schema. Baseline 3 applies since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a list of balancer rules and explicitly defines what a rule is (mappings between balancer port and backend server port). This specific verb+resource makes the purpose unmistakable and distinguishes it from siblings like list_balancers or list_balancer_ips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to see balancer rules, use this tool. However, it does not explicitly state when to use it versus alternatives such as list_balancers or list_balancer_ips, and provides no exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states a GET endpoint and 'returns a list', strongly indicating a read-only operation. However, annotations declare readOnlyHint: false and idempotentHint: false, which contradict the read-only, idempotent nature of GET. This is a clear annotation contradiction, reducing transparency to 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loads the purpose, and includes the endpoint without any wasted words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with no output schema, the description adequately explains the resource and endpoint, but it does not describe the shape of the returned instances (e.g., fields, pagination) or address the annotation ambiguity. This leaves the agent with notable gaps in knowing what to expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single parameter db_cluster_id with a description and constraint. The description only echoes the parameter in the endpoint path and adds no additional semantic meaning, so with 100% schema coverage the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns a list') and resource ('instances (databases inside the cluster)'), clearly distinguishing this from listing clusters or getting a single instance. The included endpoint further clarifies the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to list instances for a given cluster (requires db_cluster_id), but it does not explicitly state when to choose this over alternatives like list_database_clusters or get_database_instance. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes a read operation ('Возвращает'), but annotations declare readOnlyHint=false, indicating it is not read-only. This is a direct contradiction; the description does not disclose any potential side effects or behaviors beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently communicates the tool's purpose and return fields without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return fields and operation types, but it fails to address the annotation contradiction and does not explain how this tool differs from related tools like get_domain_request or list_domains. Given the absence of an output schema, the description is the only source of return information, and while it lists fields, it lacks context on side effects or usage distinctions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the baseline is 4. The description does not need to add parameter semantics, and it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all user requests for domain operations (registration, renewal, transfer) and lists key fields. The verb 'Возвращает' (returns) and resource 'заявки' (requests) distinguish it from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_domain_request or list_domains. The description only states what the tool does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it 'Возвращает список нод' (returns a list of nodes), which is a read-only operation. However, the annotations declare readOnlyHint: false, indicating the tool may modify state. This is a direct contradiction, causing confusion about the tool's side effects. The description does not add clarity beyond the annotations or resolve the inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, front-loaded with the primary purpose and then a brief note on pagination. Every sentence adds useful information without redundancy or filler. It is appropriately sized for a straightforward list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and pagination, but for a list tool with no output schema, it does not specify the response structure or fields of the node objects. The annotation contradiction also undermines completeness. There is no mention of error conditions or authentication, but for a simple list, the description is adequate yet incomplete given the conflicting annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all parameters, including the meaning of limit and offset. The description mentions 'Поддерживает пагинацию через limit/offset' (supports pagination via limit/offset), which reinforces this but adds little new meaning beyond what the schema already states. The description does not clarify the relationship between cluster_id and group_id beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a list of nodes belonging to a specific cluster group, using the specific verb 'Возвращает' (returns) and resource 'список нод' (list of nodes). It differentiates from sibling tools like list_k8s_cluster_nodes (cluster-wide nodes) and list_k8s_node_groups (lists groups), 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: to list nodes of a specific group, as indicated by 'конкретной группе кластера'. However, it does not explicitly mention alternatives or when not to use it, such as using list_k8s_cluster_nodes for cluster-wide node lists. The usage context is clear but 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes a read-only list operation ('Возвращает список'), but the annotations specify readOnlyHint=false, which contradicts the read-only nature implied by the description. No additional behavioral context is provided, and the annotation conflict leaves the agent uncertain about potential side effects. This is an Annotation Contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the function and enumerates the returned service types. No filler or redundant phrasing is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter list operation, the description covers the basic purpose and parameter. However, the contradiction between the read-only description and readOnlyHint=false creates significant ambiguity about the tool's behavior, making it incomplete for an agent to confidently invoke it without risking unintended effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the only parameter (vpc_id) with 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID VPC' (REQUIRED FIELD - VPC ID), providing 100% coverage. The tool description adds no further meaning beyond restating that services are attached to the VPC. With full schema coverage, the baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Возвращает список' (returns a list) and explicitly names the resource type (services in VPC) with the service types enumerated (server / balancer / dbaas). This clearly distinguishes it from sibling tools like list_vpc_ports or list_vpcs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the description: use when you need to list services attached to a VPC. However, there is no explicit guidance about when not to use it, nor any mention of alternative tools for similar purposes (e.g., list_vpc_ports). The usage context is present but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-idempotent, non-destructive action. The description adds no additional behavioral context beyond what the name and schema already convey—it does not mention side effects, prerequisites, reversibility, or what happens to the resource after transfer. The resource type list is duplicated from the schema enum, adding no new transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action and supported resource types. It is compact, but the added note 'resource_type обязателен' is redundant with the schema and does not earn its place, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema and annotations are rich, the description is minimal for a state-changing transfer operation. It omits important context such as whether the resource is removed from the source project, any restrictions on transferring between project types, or potential service disruption during the move. This leaves the agent without sufficient operational expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description only reiterates that resource_type is required, which is already in the schema's required fields list, and lists resource types that match the enum. No additional parameter meaning is provided, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'переносит' (transfers) and clearly identifies the resource types (server, DB, balancer, storage, cluster, dedicated) being moved between projects. This clearly distinguishes the tool from related siblings like add_server_to_project or transfer_bucket, which handle different operations or resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a resource needs to be moved from one project to another, but provides no explicit guidance on when to choose this over alternatives such as add_*_to_project or transfer_bucket. The 'resource_type обязателен' note is a parameter constraint, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false, destructiveHint=false). The description adds the HTTP method and the list of modifiable fields but does not disclose additional behavioral traits such as whether omitted fields remain unchanged, whether privileges replace the entire list, or any permission requirements. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that includes the core action, the target resource, the affected fields, and the exact REST endpoint. Every word adds value, with no wasted space or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no nested objects. The description plus the schema is sufficient to understand how to invoke it, but it lacks information about the response format, side effects, or behavior when optional fields are omitted. Given the absence of an output schema, a brief note on the return value would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all six parameters, including required fields and constraints (e.g., minLength for password, enums for privileges, MySQL-only note for instance_id). The description only restates three of the fields (password, privileges, description) and adds no new meaning beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Изменяет параметры пользователя кластера') and clearly identifies the resource (cluster user). It also includes the HTTP PATCH endpoint, clarifying the operation type. It does not explicitly contrast with sibling tools like create_database_admin or update_database_cluster, but the resource is distinct enough to avoid confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_database_admin or delete_database_admin. It does not mention prerequisites, whether it partially updates fields, or any exclusions. The usage context is only implied by the tool name and 'PATCH' method.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so it is a create operation. The description confirms creation but fails to disclose that group_id is required, which is a critical prerequisite for the tool. No additional behavioral context such as idempotency or failure modes is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two short sentences with no fluff. It front-loads the main action and immediately covers key usage constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and no output schema, the description is minimal and covers some usage context but misses the required group_id param. It does not explain prerequisites like needing an existing firewall group, leaving gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds marginal value by mentioning port/cidr for tcp/udp, but it repeats schema information and omits group_id from its list of required fields, potentially misleading an agent relying solely on the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new rule in a firewall group, using a specific verb ('Создаёт') and resource ('правило в группе firewall'). It distinguishes from sibling create_firewall_group by specifying the rule context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance by listing required direction and protocol, and noting port/cidr for tcp/udp. However, it omits group_id as a required field and does not explicitly mention alternatives or when-not-to-use contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-idempotent, non-destructive operation. The description adds no behavioral context beyond restating the purpose; it doesn't disclose side effects, permission requirements, or state changes. With annotations present, more context would be needed to earn a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. Key information (creates a VPC) is front-loaded, and every word earns its place. This is an appropriately sized description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation, the description combined with the complete schema and annotations provides sufficient invocation details. However, there is no output schema and the description does not mention the response format or any post-creation behavior, which is a minor gap. Overall it is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full coverage (100%) of all three parameters with descriptions, including a regex pattern for subnet_v4 and an enum for availability_zone. The description adds no parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Создает' = Creates) with a clear resource ('новую виртуальную приватную сеть' = new VPC) and specifies the key scope (availability zone). This clearly distinguishes it from sibling tools like get_vpc, update_vpc, and delete_vpc, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or alternative guidance is provided. The description only states what the tool does, not when to choose it over related tools or any prerequisites. While the name and sibling list imply it is the creation counterpart, there is no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Действие необратимо' (the action is irreversible), which directly contradicts the annotation destructiveHint=false. Since destructiveHint indicates whether the operation destroys data irreversibly, this is a clear contradiction and the description actually provides conflicting information to 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two short sentences, front-loading the purpose and adding a critical note about irreversibility without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two parameters and no output schema, the description covers the core purpose and the important trait of irreversibility. It omits potential details like prerequisites (e.g., rule must exist) but such information is likely unnecessary for this simple tool. The low complexity justifies a high completeness score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both required parameters (rule_id and balancer_id) with 100% coverage. The description adds no additional parameter semantics beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Удаляет' - deletes) and the specific resource ('правило маршрутизации у балансировщика' - routing rule of a balancer). It differentiates from sibling tools like create_balancer_rule and update_balancer_rule by specifying deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the verb 'Удаляет' and the resource type, but there is no explicit guidance on when to use this tool vs. alternatives, nor any exclusions or prerequisites. A more explicit note about needing an existing rule or being preferable to update for removal would raise the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the warning 'Действие необратимо' (The action is irreversible), which is valuable behavioral context. However, this directly contradicts the annotation destructiveHint: false, which implies the operation is not destructive. This inconsistency creates an annotation contradiction and undermines the agent's ability to assess the operation's true risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one short sentence for the purpose and a second short clause for the irreversible nature. Every word earns its place, and the structure is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete operation, the description is sufficiently complete given the strong schema and annotations (aside from the contradiction). It clearly states what the tool does and adds an important caveat. However, the contradiction with destructiveHint prevents a perfect score, and there is no mention of what happens to dependent resources or whether the group must exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of both parameters (rule_id and group_id) with clear descriptions and required flags. The description does not add any additional meaning beyond the schema, so the baseline score of 3 applies. No extra context about parameter values, formats, or relationships is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Удаляет правило из группы firewall' (Deletes a rule from the firewall group). It uses a specific verb with a specific resource, and the title and name align. It is also distinct from sibling tools like delete_firewall_group, which delete the whole group, whereas this tool targets a single rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 alternatives like delete_firewall_group or update_firewall_rule. It does not mention prerequisites (like an existing rule_id) or conditions for safe use. The context implies it is for removing one rule from a group, but that is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Описание противоречит аннотации destructiveHint: false. В описании явно указано «НЕОБРАТИМО: Удаляет образ», что подразумевает деструктивность, тогда как аннотация утверждает обратное. Это серьёзное несоответствие, требующее минимальной оценки.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Описание состоит из двух предложений, начинается с важного предупреждения, а затем кратко объясняет последствия. Нет лишней информации, структура эффективна.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Для простого инструмента с одним параметром и без выходной схемы описание достаточно полно: объясняет необратимость, влияние на существующие серверы и ограничение только на создание новых. Не хватает информации об ошибках или разрешениях, но для данной операции это не критично.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Схема полностью покрывает параметр image_id (100% coverage) с описанием «ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID образа для удаления». Описание инструмента не добавляет дополнительной информации о параметрах, поэтому базовая оценка 3 оправдана.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Описание начинается с конкретного глагола «Удаляет» и указывает ресурс «образ по его ID». Это явно отличает инструмент от sibling-инструментов, таких как delete_image_download, и точно передаёт действие.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Описание не содержит явных указаний, когда использовать инструмент вместо альтернатив, и не называет их. Однако контекст понятен: инструмент предназначен для удаления образа. Предупреждение о последствиях для существующих серверов даёт полезный контекст, но не является руководством по выбору.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Все ноды группы будут удалены' (all nodes of the group will be deleted), which clearly indicates destructive behavior. However, the annotation destructiveHint is false, contradicting the description. This is a direct annotation contradiction, resulting in the lowest score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences that immediately state the action and its consequence. There is no unnecessary fluff, and the structure front-loads the primary purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with only two parameters, the description sufficiently covers the main effect (deleting the group and its nodes). It does not mention reversibility or permissions, but given the low complexity and lack of an output schema, the description is largely complete. The annotation contradiction slightly detracts from overall completeness, but the description itself provides the key context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has full coverage (100%) of the two parameters, both with descriptions, so the baseline is 3. The tool description does not add any parameter-specific meaning beyond the schema, so it neither improves nor detracts from the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Удаляет' (deletes) and identifies the resource as 'группу нод из кластера' (node group from cluster). This clearly distinguishes it from sibling tools like delete_k8s_cluster_node (deletes a single node) and delete_k8s_cluster (deletes the entire cluster).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used when you want to delete an entire node group, but it does not explicitly state when to use it versus alternatives such as delete_k8s_cluster_node. No exclusions or alternative guidance is provided, so usage is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a destructive deletion operation, but the annotation destructiveHint is false, directly contradicting the described behavior. This inconsistency misleads the agent about the tool's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the action, resource, and identifying context without unnecessary details. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two fully described parameters and no output schema, the description adequately covers the operation's scope and required inputs. The annotation contradiction is a flaw but doesn't diminish the description's inherent completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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's mention of 'by FQDN' and 'from main domain' adds no additional semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a subdomain by its FQDN from a specified main domain. It uses a specific verb (Удаляет) and resource (поддомен), distinguishing it from sibling tools like add_subdomain and delete_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting subdomains but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The context is clear but not differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims a read-only information retrieval operation, but the annotations set readOnlyHint=false and idempotentHint=false, which directly contradict the implied behavior. This is an annotation contradiction and leaves the agent uncertain about side effects, so transparency is severely compromised.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that leads with the action and resource, followed by a compact list of the returned data fields. Every part is useful and there is no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description compensates by listing the key information returned (status, protocol, port, etc.). It does not cover error cases or explicitly state read-only behavior, but for a simple get-by-ID tool, this is mostly sufficient. However, the annotation contradiction creates some incompleteness in the overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full coverage for the single parameter balancer_id, including a description that it is required and represents the balancer ID. The tool description merely repeats this by saying 'по ID' without adding additional semantic detail, so it neither enhances nor reduces the schema-provided information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Возвращает детальную информацию о балансировщике по ID' (returns detailed information about the balancer by ID), specifying a concrete verb, resource, and identifier. It also enumerates the returned fields (status, protocol, port, etc.), which distinguishes it from list-oriented sibling tools like list_balancers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via 'по ID' (by ID), indicating it is for retrieving a specific balancer rather than listing all balancers. However, it does not explicitly mention when to use it over sibling tools like list_balancers or update_balancer, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool 'returns' information, implying a read-only operation, but the annotations declare readOnlyHint=false. This contradicts the description, creating confusion about whether the tool has side effects. No additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the verb, resource, and the key identifier. No wasted words, and the API endpoint is included for reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID operation, the description covers the essential purpose. However, it does not specify what 'detailed information' includes, and the annotation contradiction undermines completeness. Given the simplicity, a score of 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single parameter db_cluster_id as the required ID. The description's mention of 'by its ID' adds no new semantic value 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns detailed information about a specific database cluster by its ID, using the exact REST endpoint. It is distinct from sibling tools like list_database_clusters by focusing on a single cluster.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single cluster by ID, but it does not explicitly mention alternatives or contrast with list/get other resources. Context is clear but no exclusions or comparisons to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states that the tool only returns information, implying a read-only operation, but the annotations have readOnlyHint: false, which contradicts this. This is an annotation contradiction and should be resolved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that starts with the action and resource, immediately communicates the purpose, and efficiently lists the key return fields. There is no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description adequately covers the input (FQDN) and lists the main return fields. However, the annotation contradiction regarding read-only behavior undermines overall completeness and trust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a complete description for the fqdn parameter (required, full domain name with example), and the tool description also mentions 'по его FQDN'. No additional semantic information is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Возвращает' (returns) with a clear resource 'домене' (domain) and lists the returned data fields (статус, дата окончания, автопродление, whois privacy, поддомены). This distinguishes it from list_domains and get_domain_name_servers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when detailed domain information by FQDN is needed, but it does not explicitly state when to use it instead of alternatives like list_domains or check_domain, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation ('returns details'), while the annotations declare readOnlyHint: false, which is a direct contradiction. This inconsistency confuses the agent about side effects. No additional behavioral context is provided beyond the contradictory annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the action, target, and returned fields. It uses a colon to enumerate the details, avoiding unnecessary words while remaining complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description is adequate—it lists the returned fields (name, description, policy, dates) and the input key (ID). It lacks mention of error conditions or related resources, but the tool is simple enough that this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter group_id, with a clear description in the schema. The tool description adds no new meaning beyond confirming the parameter is the group's ID, so it sits at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns details of a specific firewall rule group by ID, listing specific fields (name, description, policy, dates). This distinguishes it from sibling tools like get_firewall_rule (which targets a rule, not a group) and list_firewall_groups (which lists groups, not a single one).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you have a group ID and need its details), but it does not explicitly state when to use this versus listing tools or how to obtain the ID. It lacks explicit alternatives or exclusions, so the usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations exist but are ambiguous (readOnlyHint=false, openWorldHint=true). The description does not clarify whether this is a read-only lookup, what it returns, or any side effects. It adds no behavioral context beyond the one-line purpose, so the description carries minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant words. It is front-loaded and immediately states the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, yet the description does not explain what 'finds' returns (e.g., provider object, name, ID) or how it handles URLs that do not match a provider. This missing behavioral info makes the tool incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter (repository_url) with 'URL репозитория для поиска VCS провайдера'. The description adds no further parameter semantics. Baseline 3 is appropriate since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'finds VCS provider by repository URL' with a specific verb and resource. This clearly differentiates it from sibling tools like get_vcs_providers (which lists providers) and get_vcs_provider_repositories (which lists repositories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention get_vcs_providers or get_vcs_provider_repositories as related tools, nor does it explain the prerequisite of having a repository URL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark readOnlyHint=false and destructiveHint=false. The description adds that the tool returns specific fields, which is useful, but it does not disclose any other behaviors such as rate limits, side effects, or the contradiction between the implied read-only nature of a list operation and the readOnlyHint=false annotation. No explicit contradiction with annotations, but limited extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two sentences that state the return content and a usage hint. However, the unnecessary and incorrect 'plan_id' term slightly detracts from the overall clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description provides return fields and a context for use. However, the plan_id/preset_id mismatch and lack of details about ordering, pagination, or how additional services integrate with create_dedicated_server leave minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has full description coverage for the only parameter, but the tool description introduces 'plan_id' as if it were the parameter name, directly conflicting with the schema's 'preset_id'. This inconsistency undermines the parameter semantics and could cause an agent to misidentify the input field, despite the schema being clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of additional services for a specific dedicated server tariff, with fields (ID, name, price, period, description). The verb 'Возвращает' is specific and the resource is identifiable. However, it refers to the parameter as 'plan_id' while the schema uses 'preset_id', introducing potential confusion about the exact parameter name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use this tool to obtain plan_id for passing to create_dedicated_server. The schema parameter description further advises getting the ID via list_dedicated_server_presets. It does not mention exclusions or alternatives, but for a simple listing tool this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation ('Возвращает список' / 'Returns a list'), but the annotations declare readOnlyHint=false, creating a direct contradiction. No additional behavioral context (e.g., side effects, permissions, pagination) is provided, so the description fails to clarify the actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant information. It precisely conveys the function and return fields without filler, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description adequately specifies the output fields and scope (all nodes). However, the annotation contradiction and lack of usage guidance reduce completeness slightly, though the core functionality is clear enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter (cluster_id, required, integer, with description 'ID кластера'). The tool description adds no additional parameter detail, but since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of all cluster nodes (master and worker) with specific attributes (ID, type, group, status, characteristics). This uses a specific verb ('returns') and resource ('nodes'), and the 'master and worker' distinction helps differentiate it from node-group-specific tools like list_k8s_node_group_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('all nodes in cluster') but does not explicitly mention when to use this tool versus alternatives such as list_k8s_node_group_nodes. No exclusions or alternative guidance is provided, so it's minimally adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
This is an annotation contradiction. The description describes a list (read) operation, yet annotations set readOnlyHint=false, implying possible state changes. This directly contradicts the semantics of listing and provides misleading behavioral guidance. No other behavioral context (e.g., permission requirements, side effects) is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-front-loaded sentence that does exactly what is needed—states the resource and scope. No filler or redundant explanation. It is appropriately concise for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the simple nature of the tool reduces complexity, the description omits critical details: no mention of response format or whether any pagination/filtering exists. More importantly, the annotation contradiction (readOnlyHint=false) is not clarified, leaving users confused about side effects. The lack of an output schema makes this a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter, project_id, is fully described with type and required status. The description adds no extra meaning about the parameter, so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List VPS servers in the specified project' clearly identifies the action (list), resource (VPS servers), and scope (within a given project). It also distinguishes itself from sibling tools like list_all_project_servers by explicitly narrowing to a specified project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies strong usage context: call this tool when you need VPS servers belonging to a specific project (project_id). It does not explicitly exclude or compare to alternatives such as list_all_project_servers, but the scoping phrase 'in the specified project' makes the intended 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool 'Возвращает' (returns) a list, implying a read-only operation. However, the annotation readOnlyHint is set to false, indicating the tool may not be read-only. This directly contradicts the description's implied behavior, constituting a serious inconsistency. Thus, the description fails to disclose behavioral traits consistent 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose and sample return data without unnecessary words or redundancy. It is perfectly sized for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides useful context about the return payload (MAC addresses, IPv4, services) which is valuable given the lack of an output schema. It does not address error cases or pagination, but for a simple list operation with one parameter, it offers sufficient context to understand what the tool does and returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter vpc_id is fully documented in the schema with description 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID VPC' (Required field - VPC ID), providing 100% coverage. The tool description adds no additional parameter semantics beyond what the schema already specifies, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Возвращает список портов VPC с MAC-адресами, IPv4 и сервисами' (Returns a list of VPC ports with MAC addresses, IPv4 and services), providing a specific verb (list) and resource (VPC ports) with additional detail on returned data. It distinguishes itself from sibling tools like list_vpc_services and get_vpc by focusing on ports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to retrieve port information for a given VPC, but it does not provide explicit guidance on when to use it versus alternatives or mention exclusions. No alternative tools are named, and no context for selection is given beyond the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond what annotations already provide. Annotations indicate readOnlyHint=false and destructiveHint=false, and the verb 'attaches' aligns with those, but the description does not disclose edge cases such as whether the operation is idempotent, what happens if the cluster is already attached, or any prerequisites. Since annotations exist but the description contributes little extra context, a score of 2 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and object. It is front-loaded and contains no unnecessary words, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple linking operation with 2 parameters and no output schema, the description is adequate. However, it omits potential contextual details such as idempotency, error conditions, or side effects that could matter during invocation. Given the simplicity, a mid-range score is reasonable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both project_id and resource_id having clear descriptions. The description itself adds no parameter-specific meaning beyond what the schema already provides. Baseline for high coverage is 3, and there is no additional enrichment, so the score stays at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Привязывает существующий Kubernetes-кластер к проекту' (attaches an existing Kubernetes cluster to a project). This uses a specific verb and resource, and the phrase 'existing' distinguishes it from creation tools like create_k8s_cluster. It also aligns with sibling tools like add_balancer_to_project, making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario: when you need to associate an already-created Kubernetes cluster with a project. However, it does not explicitly state when not to use it, nor does it reference alternative tools such as create_k8s_cluster or list_all_project_clusters. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states that deletion is irreversible and all images will be lost, which is destructive behavior. However, the annotation destructiveHint is false, directly contradicting this. This is a serious inconsistency that would mislead an agent about the tool's safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key action, and includes a concise warning. Every sentence contributes meaningful information without redundancy or unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential destructive behavior and user warning, which is sufficient for a simple single-parameter delete operation. However, the contradiction with destructiveHint creates confusion and undermines the overall contextual completeness, as the agent cannot rely on the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the single parameter (registry_id) completely with a required-field note and explanation. The tool description does not add any additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a container registry irreversibly. The verb 'Удаляет' (deletes) and resource 'реестр контейнеров' (container registry) are specific, and it distinguishes itself from sibling tools like create/update/get/list container registries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (to permanently delete a registry) and includes a warning to ensure the registry is not in use before deletion. It does not explicitly list alternatives or when-not-to-use scenarios, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'deletes' which directly contradicts the destructiveHint=false annotation. This is a serious inconsistency that could mislead an agent about the tool's side effects. No additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The mention of 'API v2' is a minor extra but does not detract from conciseness. It is appropriately front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete tool, the description adequately states the purpose. However, the annotation contradiction undermines the overall completeness, and the description does not address failure scenarios or prerequisites, leaving gaps that could matter in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (100% coverage). The description adds no additional meaning to the parameters, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes a DNS record by ID for a specified domain. The verb 'deletes' and resource 'DNS record' are specific, and the scope ('by ID for the specified domain') distinguishes it from domain or subdomain deletion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context for use is clear: this tool is for deleting a specific DNS record. It does not explicitly mention alternatives or when not to use it, but the narrow scope makes the usage obvious. It lacks explicit exclusions but is not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Действие необратимо' (action is irreversible) and describes a deletion operation, while the annotation destructiveHint=false indicates the tool is non-destructive. This is a direct contradiction. The description also does not disclose additional behavioral traits beyond the 2FA steps, and the contradiction undermines the tool's transparency entirely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, front-loaded with the core purpose ('Удаляет Kubernetes-кластер'), followed by the critical irreversibility note and the 2FA flow. No redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential deletion action and two-step 2FA process, but it does not explain the final response after successful deletion or what happens for accounts without 2FA. Combined with the annotation contradiction, the overall context is incomplete, though the core function is adequately addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes all parameters (100% coverage), but the description adds meaningful workflow context by explaining that for 2FA accounts, the first call returns a hash and the second call requires both hash and code. This clarifies the parameter interplay beyond the individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Удаляет' (deletes) with resource 'Kubernetes-кластер' (Kubernetes cluster), clearly distinguishing it from sibling tools like delete_k8s_cluster_node or delete_k8s_node_group. The purpose is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for whole-cluster deletion and provides the 2FA conditional flow, but it does not explicitly compare against alternatives or state when not to use this tool. No exclusions or alternative tool references are given, making the guidance partly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply restates that it returns a list, adding no behavioral detail beyond annotations. More seriously, annotations mark readOnlyHint:false, while a 'get list' operation implies read-only semantics, creating an annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, front-loaded sentence with no filler or redundant clauses. It is appropriately sized for a zero-parameter list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In isolation, the description names the resource and result, but it lacks any mention of return format, completeness caveats (openWorldHint is only in annotations), or relation to create_timeweb_app. Because it is a very simple no-param tool, the gaps are moderate; however, the contradictory annotation and absence of output schema reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is trivially fully covered. The description adds no parameter semantics, but none are needed; baseline 4 for zero-param tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Получает список' – gets a list) and identifies the exact resource ('доступных пресетов для создания приложения' – available presets for creating an application). This clearly distinguishes it from sibling preset-list tools such as get_bucket_presets or list_server_presets by adding the 'for application creation' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to choose this tool over alternatives, nor does it mention exclusions or prerequisites. The only implied use case is retrieving presets before creating an application (sibling create_timeweb_app), but this is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description presents the operation as a read-only status query, but annotations declare readOnlyHint=false, contradicting the implied read-only nature. This is a significant inconsistency that confuses the agent about whether the tool may have side effects. Flagged as annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the main action and includes a useful list of returned attributes plus usage advice. It could be slightly more structured (e.g., separating usage from return values) but is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 param, no output schema), the description covers the purpose, return content, and usage context. It could add details about polling behavior or error conditions, but the provided information is largely sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents bucket_id with 100% coverage, including a required-field note. The description adds no additional parameter-specific meaning beyond establishing that this is the bucket being transferred, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Возвращает статус переноса хранилища' (Returns transfer status) and specifies the resource (S3 bucket from third-party provider to Timeweb Cloud). Lists specific statuses and metrics, clearly distinguishing it from sibling tools like transfer_bucket (initiates transfer) and get_bucket (general bucket info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Используй после transfer_bucket' provides explicit temporal guidance for when to call this tool. However, it does not mention when not to use it or suggest alternative tools for other scenarios, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'returns details' and adds no context about side effects, permissions, rate limits, or error behavior. The annotations are contradictory (readOnlyHint=false for a GET operation), and the description does not clarify or compensate for this, leaving ambiguity about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It is appropriately sized and front-loaded, efficiently conveying the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, the description covers the essential purpose, but since there is no output schema, it does not specify the actual fields or structure of the returned 'details'. It also doesn't address error scenarios or the conflicting annotations, leaving notable gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents request_id as the mandatory field with 100% coverage, so the baseline is 3. The description reinforces 'by its ID' but adds no additional semantic detail such as format, examples, or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Возвращает' - returns), the resource ('заявки на регистрацию/продление/трансфер' - requests for registration/renewal/transfer), and the lookup method ('по её ID' - by its ID). This clearly distinguishes it from sibling tools like list_domain_requests, which would list requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single request by ID, but it does not explicitly state when to use this tool versus alternatives like list_domain_requests or update_domain_request. No exclusions or alternative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the operation 'Возвращает' (returns) information, implying a read-only action, but the annotation declares readOnlyHint=false, contradicting the described behavior. This is a serious inconsistency that misleads the agent about potential side effects. Flagging as an annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's purpose without irrelevant details or redundancy. It effectively communicates the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two required parameters and a straightforward return of detailed info. No output schema exists, so the description's failure to detail the response structure is acceptable for a get operation. However, the annotation contradiction (readOnlyHint=false) creates uncertainty about the operation's actual side effects, making the overall context incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both required parameters (cluster_id and group_id) with clear Russian labels and required flags. The description adds only the generic phrase 'по её ID', which adds no meaningful semantic value beyond the schema. Baseline 3 applies because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Возвращает' (returns) with a clear resource 'информацию о группе нод кластера' and identifier 'по её ID', making it distinct from siblings like list_k8s_node_groups or get_k8s_cluster.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool provides detailed information for a specific node group given a cluster and group ID. It does not explicitly name alternatives or exclusions, but the context is clear. A minor gap is the lack of mention of when to prefer this over list_k8s_node_groups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes a read-only operation ('gets list'), but annotations have readOnlyHint=false, suggesting the tool may not be read-only. This is a contradiction and no additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core function with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is simple and adequate for a zero-parameter listing tool, but it omits the return format and does not clarify the read-only contradiction stemming from annotations. Since annotations are contradictory, completeness suffers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and empty schema, so baseline is 4. The description adds nothing about parameters, but none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Получает список всех виртуальных частных сетей (VPC) пользователя' (gets list of all user's VPCs). It distinguishes from sibling tools like get_vpc (singular) and list_vpc_services by explicitly indicating all VPCs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name and description: it lists all VPCs. However, there is no explicit guidance on when to use it vs alternatives (e.g., get_vpc for a single VPC) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes a read-only operation ('Returns a list'), but the annotation readOnlyHint=false contradicts this. This is a direct contradiction, making the behavioral semantics confusing. The annotation should be true for a listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose, and includes the API path as a useful reference. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with optional pagination, the description provides purpose and usage. However, the contradiction with annotations creates uncertainty about the tool's behavior. It also doesn't mention return structure, but that's not required given no output schema. Overall, adequate but with a notable inconsistency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters fully with descriptions (100% coverage). The description adds no additional parameter semantics, but the schema already provides sufficient detail. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Returns a list of database clusters of the account' with a specific verb and resource, and includes the API endpoint. It distinguishes from sibling tools like list_all_project_clusters or list_database_instances by specifying database clusters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear usage context: 'Use before operations on a cluster to get its ID.' This tells the agent when to invoke the tool. It does not mention alternative tools or exclusions, but the guidance is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=false and openWorldHint=true, which are surprising for a list operation. The description explicitly states it returns a list, adding transparency about the operation's primary behavior. However, it does not elaborate on side effects, pagination, or safety, and the annotation conflict (readOnlyHint=false) is not clarified. The description adds some value but leaves ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently states the operation and output fields. No unnecessary words. Slightly brief but appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description enumerates the key returned fields, which is valuable. The tool is low complexity with one parameter, and the description covers the essential scope. It does not discuss edge cases, empty results, or error conditions, but for a straightforward list operation it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter cluster_id with a mandatory description, achieving 100% coverage. The description mentions 'в кластере' but adds no supplementary meaning beyond the schema. Since schema does the heavy lifting, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Возвращает' (returns), the resource 'список всех групп нод в кластере' (list of all node groups in the cluster), and lists the output fields (ID, name, preset_id, node count). This distinguishes it from sibling tools like get_k8s_node_group (single group) or list_k8s_node_group_nodes (nodes within a group).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or compare with sibling listing tools. The clear name and output fields imply its use, but no contextual direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotations. It says 'Возвращает список' (returns a list), implying a read-only operation, but the readOnlyHint is false. This is a serious inconsistency. Additionally, the description does not provide other behavioral context such as pagination, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that clearly state the action and when to use it. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the core purpose and usage. However, the annotation contradiction undermines completeness, and details like output shape or potential edge cases are absent. The API v1 mention adds useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100%, with the domain parameter already fully described in the schema (including the example). The tool description adds no additional meaning beyond noting the domain scope, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Возвращает список') and resource ('почтовых ящиков указанного домена'), clearly stating the tool's scope. It distinguishes itself from sibling tools like list_mailboxes by specifying the domain filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Используй, когда нужны только ящики конкретного домена' (use when you need only mailboxes of a specific domain). It provides a clear usage condition, though it does not explicitly mention alternatives or exclusions, which would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate openWorldHint=true (likely paginated or returns list) and destructiveHint=false. The description adds no behavioral details beyond the annotation. It doesn't mention if it returns cluster-level or instance-level DBs, or whether the list is paginated, but with annotations covering safety and open-world nature, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded: verb 'List', object 'managed DBs', scope 'in the specified project'. Zero waste; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 required param) and the schema fully describes the parameter. With no output schema and minimal annotations, a one-line description is arguably sufficient for a list operation. However, it would benefit from clarifying the exact response type (database clusters vs. instances) given the sibling list_database_clusters and list_database_instances. Still, given the low complexity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (project_id has clear description 'REQUIRED FIELD - project ID'). The description adds the term 'managed databases' and 'in the specified project' but doesn't add deeper parameter semantics beyond the schema. Baseline 3 is correct because the schema carries the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List managed databases in the specified project' clearly states the action (list) and resource (managed databases) with a project scope. It differentiates from siblings like list_all_project_databases (which lists across projects) and list_database_clusters/instances, though it doesn't 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when you need the managed DBs of a specific project. There is no explicit when-not-to-use or alternative mention, but the 'specified project' scoping and sibling tool 'list_all_project_databases' (all projects) provide context. However, no explicit guidance on prerequisites or distinction from list_database_clusters/instances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation contradiction: the description says 'returns a summary', implying a read-only operation, but readOnlyHint=false indicates the tool is NOT read-only. No other behavioral context is provided (e.g., side effects, permissions, pagination). This is a serious inconsistency that could mislead 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the operation and resource scope without excess. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not explain the structure of the summary or what 'all resources' includes (e.g., does it include SSH keys, IPs, network drives?). While the resource list is helpful, the incomplete enumeration and lack of return format leave gaps for a tool claiming to cover 'all resources'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers project_id 100% with 'REQUIRED FIELD - Project ID'. The tool description does not add additional parameter semantics, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a summary of all project resources, enumerating resource types (servers, balancers, storages, clusters, DBs, dedicated servers). This distinguishes it from sibling list_all_project_* tools that target specific resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this tool to get an aggregated overview of all project resources. It does not explicitly mention alternatives or when-not-to-use, but the resource enumeration makes it clear this is the aggregate version of more specific list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly indicates a read-only list operation, but the annotation readOnlyHint=false contradicts this by implying potential side effects. No other behavioral traits (e.g., pagination, performance) are disclosed, and the contradiction is a serious flaw.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. The first states the primary action and scope; the second adds useful domain context about disk-level snapshots and the prerequisite. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool, the description covers purpose and prerequisite adequately. However, no return format or pagination details are given, and the annotation contradiction undermines the overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions provide complete coverage (100%) for both parameters, including how to obtain disk_id. The description essentially repeats the schema's guidance without adding parameter-level semantics beyond what is already documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Возвращает список') and identifies the exact resource (backups of a specific VPS server disk). It distinguishes the scope by noting backups are disk-level snapshots, not server-level, which differentiates from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that disk_id must first be obtained via the list server disks API, giving a prerequisite. It implicitly indicates this tool is for listing disk backups, but does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating but non-destructive operation. The description adds no further behavioral context, such as overwriting existing catch-all settings, response format, or validation checks. Thus it provides minimal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that is front-loaded and contains no filler. It clearly states the action and target without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with complete schema descriptions and annotations, the description is sufficient to understand the basic operation. However, it omits any mention of return values or side effects, though openWorldHint=true might warrant additional caveats. Overall, adequately complete for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for both required parameters (domain and email). The tool description restates what 'email' does but adds no new semantic context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Меняет' (changes) and identifies the exact resource: the catch-all address for emails to non-existent mailboxes in a domain. This clearly distinguishes it from siblings like update_mailbox or get_mail_domain_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to configure the domain's catch-all address, but it doesn't explicitly state when to use this over related tools (e.g., update_mailbox) or mention prerequisites like domain ownership. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-idempotent, non-destructive operation. The description adds the context of allocating a new address and optional PTR record, but doesn't disclose side effects like billing or constraints. It doesn't 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, with two sentences that convey the core action and the optional PTR feature. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and safety annotations, the description adequately covers the tool's purpose and the optional PTR behavior. It lacks return-value details, but no output schema exists and the schema already explains parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptive schema entries (100% coverage), so the description adds little beyond the schema. The description mentions IPv4/IPv6 and PTR, which aligns with the 'type' and 'ptr' parameters, but doesn't add new semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool allocates a new IPv4 or IPv6 address for a server, with optional PTR record. This specific verb+resource distinguishes it from sibling tools like delete_server_ip and update_server_ip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance, exclusions, or alternative recommendations. It only states the action, leaving the agent to infer usage from the tool's name and action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false), and the description's 'adds' is consistent. However, it does not disclose additional behavioral traits such as whether a connectivity check is performed, side effects, or reversibility. The error-handling instructions are in the schema parameter descriptions, not the tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the purpose. No filler, redundant details, or unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema descriptions and annotations, the short description is largely sufficient. The main gap is the lack of an output schema or explicit mention of return values, but the purpose and required inputs are clear, and the schema covers authentication and error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with detailed descriptions for all four parameters, including format, example, enum, requirements for private repositories, and error recovery steps. The tool description itself does not add any parameter information, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'adds' with a clear resource 'VCS provider' and states the purpose 'for connecting Git repositories to Timeweb Cloud'. This clearly distinguishes it from sibling tools like get_vcs_providers that list providers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or comparisons to sibling tools; the only usage context is implied by the verb 'adds'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, confirming a write operation. The description adds no behavioral context beyond the obvious act of creation—no mention of side effects, required permissions, return values, or impact on existing resources. It fails to disclose any traits not already captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and contains no filler. It efficiently combines the primary action, required fields, and prerequisite lookups in a compact structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 13 parameters and no output schema, the description provides essential invocation context: required fields and how to obtain prerequisite IDs. It does not mention what the tool returns or optional parameter behavior, but the schema covers parameter details. Given the complexity, the description is adequate for a knowledgeable agent, though not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter individually described, including hints to list_ai_models and list_ai_agent_token_packages. The description reiterates the required fields but adds no new semantic meaning beyond what the schema already provides. The prerequisite guidance is already embedded in the schema descriptions, so the description adds no incremental value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Создаёт нового AI-агента' (Creates a new AI agent), using a specific verb and resource. It distinguishes from siblings like update_ai_agent, delete_ai_agent, list_ai_agents, and get_ai_agent by clarifying it creates a new entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides procedural guidance: 'Перед вызовом получи model_id через list_ai_models и token_package_id через list_ai_agent_token_packages' (Before calling, get model_id via list_ai_models and token_package_id via list_ai_agent_token_packages). However, it does not explicitly state when to use this tool versus alternatives (e.g., update_ai_agent), making usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the creation effect is implied. The description adds the availability zone constraint but does not disclose other potential behaviors like network requirements, cost, or that the created IP is unbound until a separate bind operation. This is acceptable but lacks extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that conveys the essential purpose without any filler. It is appropriately sized for the simplicity of the tool and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no nested objects) and the presence of annotations, the description covers the core functionality well. It does not describe the return value, which could be useful since no output schema exists, but for a basic create operation this is a minor gap. Overall, it is contextually complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (is_ddos_guard and availability_zone) with 100% coverage. The tool description mentions only the availability zone and adds no extra semantic information beyond the schema, so it meets the baseline without adding additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Creates a new floating IP address in the specified availability zone' clearly states the action (create) and resource (floating IP), distinguishing it from siblings like update_floating_ip, delete_floating_ip, or bind_floating_ip. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., needing an existing server or network) or conditions under which creating a floating IP is appropriate. The sibling tool bind_floating_ip is not referenced, so the agent receives no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false (mutation), openWorldHint=true (external side effects), and idempotentHint=false, so the safety profile is established. The description adds only the fact that the tool 'creates' a cluster, which is consistent but does not disclose additional behavioral traits like long-running execution, cost implications, or required permissions. Given the annotation coverage, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the core purpose. It efficiently lists required and optional parameters. However, the inclusion of the erroneous 'OIDC' reference is a minor clarity issue, and the structure could be slightly improved by separating prerequisites from optional flags, so it loses one point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 13 parameters, nested objects, and no output schema. The description is a bare summary that omits key contextual details: it does not mention that cluster creation is likely asynchronous, that certain parameters like project_id or network_id may be required in practice, or what the response returns (e.g., cluster ID). The misleading OIDC reference further detracts from completeness, leaving significant gaps for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description introduces an undocumented parameter by mentioning 'OIDC' as optional. The input schema has no OIDC property, which is misleading and could cause an agent to attempt passing a non-existent parameter. The rest of the parameter hints (required fields, preset_id/configuration exclusivity) merely repeat what the schema already states, adding no net positive value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear verb and resource: 'Создаёт новый Kubernetes-кластер' (Creates a new Kubernetes cluster). It specifies the resource (Kubernetes cluster) and the action (create), which clearly distinguishes it from sibling tools like create_k8s_node_group, edit_k8s_cluster, or delete_k8s_cluster. 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly identifies the context for use (creating a new cluster) and provides actionable parameter guidance, such as required fields and the mutual exclusivity of preset_id vs configuration. However, it does not explicitly exclude alternative tools or state when not to use it (e.g., for existing clusters or node groups), which prevents a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Действие необратимо' (irreversible), which directly contradicts the annotation destructiveHint=false. This is a serious inconsistency that misleads the agent about the tool's side effects. Therefore, it scores 1 and is flagged as an annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences, front-loaded with the main action and then providing the crucial 2FA detail. It is efficient and free of unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the primary behavior and the significant 2FA edge case, which is a non-trivial part of the tool's usage. It does not mention error handling or response format, but given the lack of an output schema, this is acceptable. The annotation contradiction slightly reduces completeness confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all three parameters (100% coverage). The description adds valuable context about the 2FA two-step flow, explaining that the first call returns a hash and the second call requires hash and code to complete deletion. This goes beyond the schema's static parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Удаляет балансировщик') and the resource, making it easy to understand that this tool deletes a balancer. It distinguishes from sibling tools like delete_balancer_rule by specifically targeting the balancer itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit alternatives are mentioned, but the purpose is clear from the name and description. The 2FA flow is explained, implying the usage scenario. However, there is no explicit guidance on when not to use this tool or comparison with other delete tools, so the score is moderate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses irreversibility and total data loss, which is essential behavioral context. However, the annotation destructiveHint is false, directly contradicting the description's statements that the action is irreversible and all data will be lost. Per rubric, any contradiction forces a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary action. Each sentence adds important information: the action, irreversibility, and the 2FA process. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential operational details: irreversible deletion, data loss, and the 2FA workflow. Since there is no output schema, the description carries the burden of explaining behavior, which it does adequately. However, it omits potential prerequisites like permissions or bucket state, and the annotation contradiction undermines trust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description's 2FA flow is already reflected in the schema's descriptions for hash and code, so it adds minimal additional semantic value beyond what the schema provides. No new parameter details are introduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: deleting an S3 bucket ('Удаляет S3-хранилище'). It uses a specific verb and resource, distinguishing it from sibling delete operations like delete_vpc or delete_balancer. The resource type is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the two-step flow for accounts with 2FA, giving explicit sequencing guidance. However, it does not mention alternatives or conditions for when to avoid using this tool. The context is clear for a delete operation, but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Действие необратимо' (irreversible), but the annotation destructiveHint is false. This directly contradicts the annotation, as deleting a firewall group is clearly a destructive action. Per the rubric, any contradiction with annotations yields a score of 1 and triggers the annotation_contradiction flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and includes only essential warnings and guidance. No redundant or verbose content. This is an appropriately-sized, well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with one parameter and no output schema, the description covers the irreversible nature and the recommended pre-deletion step. It lacks only minor details like error handling or behavior with linked resources, but the core context is complete. The annotation contradiction slightly detracts from overall completeness, but the description itself is fairly thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter, including a clear description of group_id as the required ID. The tool description adds no additional semantic information about the parameter beyond what the schema already states, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Удаляет группу правил firewall' explicitly states the action (delete) and the target (firewall rules group), clearly distinguishing it from related tools like delete_firewall_rule. The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete preparatory step: 'Перед удалением рекомендуется отлинковать все связанные ресурсы через unlink_firewall_resource'. This gives clear context for when to use this tool and a recommended prerequisite. However, it does not explicitly mention when not to use it or contrast it with alternative deletion tools, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Действие необратимо' (the action is irreversible), which is important behavioral context. However, the annotation `destructiveHint: false` contradicts this claim, as deleting a backup is inherently destructive. This is a direct contradiction, so the score is 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the main purpose and then add a crucial warning. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with no output schema, the description covers the action, irreversibility, and a safeguard to verify before deletion. It lacks mention of permissions or response format, but that is not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the schema fully documents the required parameters (server_id, disk_id, backup_id). The description adds no additional parameter-specific meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Удаляет бэкап диска сервера' (deletes a server disk backup). It uses a specific verb and resource, distinguishing it from siblings like create_server_disk_backup or list_server_disk_backups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises checking via list_server_disk_backups before deleting to ensure it is not the last actual backup, providing practical usage context. However, it does not explicitly exclude when to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool deletes an IP address, which is a destructive action, but the annotation destructiveHint=false claims the tool is not destructive. This is a direct contradiction that would confuse an agent about the operation's effects. No additional behavioral details are provided beyond the main-IP constraint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action, and includes a critical limitation without redundancy. Every word is useful and contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two parameters and no output schema, the description is mostly complete. It covers the operation and the key limitation. However, it does not mention error behavior or whether deletion is reversible, and the annotation contradiction reduces overall clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the schema already explains what ip and server_id are. The description adds a constraint about the main IP not being deletable, which slightly aids parameter selection, but does not meaningfully go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (deletes a specific IP address), the resource (server), and includes a scope constraint (main IP cannot be deleted). It also distinguishes itself from sibling tools like add_server_ip and list_server_ips by specifying the exact deletion of an IP.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool, and explicitly notes a when-not: the main IP cannot be deleted. However, it does not name alternative tools or provide explicit guidance on when to prefer this over other IP management tools, which prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Действие необратимо' (the action is irreversible), but the annotations declare destructiveHint=false. This is a direct contradiction: a delete operation with irreversible effect is inherently destructive. The description's disclosure conflicts with the structured safety hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and includes a necessary safety warning. Two sentences carry all essential information without fluff, making it well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter delete tool, the description covers the key contextual points: irreversibility and a pre-check action. It lacks details about consequences if the key is in use or return values, but given the simplicity and no output schema, it is sufficiently complete. However, the contradiction with annotations prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter ssh_key_id is fully described in the schema as 'REQUIRED FIELD - ID SSH-ключа для удаления', achieving 100% coverage. The description adds no additional parameter-level information 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('deletes') and resource ('SSH key from account by ID'), clearly distinguishing it from sibling tools like remove_ssh_key_from_server and update_ssh_key. The Russian text 'Удаляет SSH-ключ из аккаунта по ID' unambiguously states the action and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit pre-usage guidance: check list_ssh_keys to ensure the key is not used on critical servers (field used_by) before deletion. This gives clear operational context, though it does not explicitly contrast with alternatives like remove_ssh_key_from_server, so a perfect score is not warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says it 'returns detailed information' (a read operation), but the annotation readOnlyHint=false suggests the operation may have side effects or is not read-only. This is a direct contradiction. The description does not disclose any potential non-read behavior or side effects, and with annotations missing clarity, the description fails to provide transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource, then lists the return fields. There is no fluff or redundancy; every element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter GET tool with no output schema, the description adequately covers what is returned (name, status, access, model, token package, system prompt, remaining tokens). It doesn't mention error cases or prerequisites, but given the simplicity, it is reasonably complete. The annotation contradiction slightly detracts from overall context but is not directly relevant to completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter agent_id with a clear description ('REQUIRED FIELD - AI agent ID'). The tool description only reinforces that it operates by ID without adding additional syntax, format, or nuance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: returns detailed information about an AI agent by ID, listing the specific fields returned. This distinguishes it from siblings like list_ai_agents (which lists agents) and get_ai_agent_statistic (which returns statistics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool when you need detailed information about a specific AI agent by its ID. No explicit exclusions or alternatives are mentioned, but the usage is straightforward and unambiguous for a single-parameter GET-style tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool 'returns detailed information' (a read-only operation), but annotations set readOnlyHint=false, which suggests the tool is not read-only. This is a direct contradiction between the description and the annotation metadata, so the description fails to provide the needed behavioral transparency and instead conflicts with structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that lists the returned fields (name, description, tariff, disk usage, creation and update dates) without any redundant or vague phrasing. It is effectively concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is fairly complete: it specifies the resource, the lookup key, and the expected response fields. The only notable gap is the failure to address the readOnlyHint contradiction, but this is a transparency issue rather than a completeness issue for the description itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the sole parameter with a clear description and required marking, so schema coverage is 100%. The tool description does not add parameter-related meaning beyond what the schema already provides, which matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('возвращает' - returns) and identifies the resource ('реестр контейнеров' - container registry) with a clear scope ('по ID' - by ID). It clearly distinguishes from siblings like list_container_registries which would list all registries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single registry by ID, and the schema parameter description adds 'получить через list_container_registries' (get via list_container_registries), which guides the agent on obtaining the ID. However, it does not explicitly state when to prefer this tool over alternatives like list_container_registries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation contradiction: readOnlyHint=false conflicts with the description's 'Возвращает детальную информацию' which clearly indicates a read-only operation. No additional behavioral disclosure beyond this mismatch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, no filler. The first sentence specifies what is returned, the second gives usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the main fields returned (status, CPU/RAM/HDD, IP, IPMI, VNC, tariff, price, comment), compensating for the lack of an output schema. Minor omission: no error or edge-case handling, but adequate for a simple GET.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema fully documents the single parameter (dedicated_id) with a clear description. The tool description adds nothing beyond the schema, but does not need to given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns detailed information about a specific dedicated server, enumerating the data fields. It distinguishes from list operations by emphasizing 'по конкретному' (specific) server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'use when you need details on a single server' with an example (IPMI account for connection). Does not explicitly name alternatives, but the context makes it clear this is for single-server lookups rather than listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the operation returns information, implying a read-only action, but the annotations declare readOnlyHint=false. This is a direct contradiction, meaning the description contradicts the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. No irrelevant content is included, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 one parameter, the description adequately states the purpose. Although the return format is not detailed, the lack of an output schema and the tool's simplicity make this sufficient. The annotation contradiction is already penalized elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a full description of the only parameter (floating_ip_id as required UUID). The description adds no extra semantic detail beyond what the schema covers, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Возвращает детальную информацию') and resource ('плавающего IP') with a scope ('по его ID'). This distinguishes it from sibling tools like list_floating_ips (listing) and bind_floating_ip (binding).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for fetching details of a single floating IP by ID, which is clear context. However, it does not explicitly mention alternatives or exclusions (e.g., 'use list_floating_ips for all IPs'), so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'returns detailed information' without addressing potential side effects or clarifying the readOnlyHint=false and openWorldHint=true annotations. It doesn't disclose any additional behavioral context such as permissions or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, focused sentence in Russian that front-loads the action and object. No filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool without output schema, the description gives adequate purpose but leaves the return structure vague. It could specify what 'detailed information' includes, but the tool's complexity is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter project_id with a clear description, and the tool description adds no further parameter semantics. The phrase 'by its ID' echoes the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns detailed project information by ID, using a specific verb and resource. The 'by ID' scope distinguishes it from list_projects and other project-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single project but doesn't provide explicit guidance on when to use it vs alternatives like list_projects. No exclusions or alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes a read-only retrieval operation ('Возвращает детальную информацию'), but the annotations set readOnlyHint=false. This is a direct contradiction: the tool is presented as purely returning data while the annotation suggests it is not read-only. No further behavioral context is provided to resolve this inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and details, and includes a concise usage note. No redundant or filler content; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 parameter and no output schema, the description covers the return fields and usage context well. It could mention error scenarios or response format, but the current information is mostly sufficient. The contradiction with annotations slightly harms completeness, but the dimension focuses on contextual coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter (server_id) with 100% schema description coverage, already explaining it is required and how to obtain it via list_servers. The description adds no additional parameter semantics beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Возвращает детальную информацию по конкретному VPS-серверу' (returns detailed info about a specific VPS server) and enumerates specific data returned (status, CPU/RAM, OS, IPs, preset/configurator ID). It distinguishes from list tools by emphasizing 'конкретному серверу' (specific server) and gives use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Использовать когда нужны подробности по одному серверу' (use when details about one server are needed) with examples like core count for load calculation and status before an operation. It does not explicitly name alternatives or exclusions, but the guidance is sufficient for a specific fetch operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Аннотации содержат readOnlyHint: false, тогда как описание заявляет только возврат информации ('Возвращает детальную информацию'), что является прямым противоречием. Дополнительных поведенческих деталей (аутентификация, ошибки, ограничения, возможные побочные эффекты) нет.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Одно предложение, ключевая информация вынесена вперёд, перечислены возвращаемые поля без лишней воды. Всё необходимое для понимания работы инструмента представлено компактно.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Для простого GET-запроса с одним параметром описание достаточно полно: перечислены все значимые возвращаемые данные (имя, тело, дата, is_default, серверы). Однако отсутствует выходная схема, детали об ошибках и формате ответа, а также есть противоречие с аннотацией readOnlyHint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Входная схема покрывает 100% параметров (ssh_key_id) и уже содержит описание 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID SSH-ключа'. Описание добавляет лишь контекст 'по его ID', не углубляясь в формат или валидацию, поэтому базовая оценка 3 за счёт высокой покрытости схемы.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Описание начинается с глагола 'Возвращает' и конкретного объекта 'детальную информацию об SSH-ключе по его ID', чётко отличаясь от list_ssh_keys (список всех ключей) и create/update/delete. Указание возвращаемых полей (имя, тело, дата создания, is_default, серверы) делает назначение однозначным.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Описание явно указывает на сценарий 'по его ID', подразумевая использование для получения конкретного ключа, а не списка. Нет явных исключений или упоминания альтернатив, но контекст достаточно ясен для правильного выбора среди sibling-инструментов.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims a read-only operation ('gets list') while the annotation readOnlyHint=false indicates the tool may not be read-only. This is a direct contradiction between the description and the annotation, so the description fails to provide consistent behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that directly states the function. Every word is necessary, and it is appropriately concise for a zero-parameter list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 parameters and no output schema, the description provides the essential purpose. It includes 'all added' which clarifies scope. However, it lacks any detail about return format or behavior beyond listing, but the simplicity of the tool makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameter semantics as there are none, and the empty input schema is fully covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'получает' (gets) and resource 'список всех добавленных VCS провайдеров' (list of all added VCS providers), clearly distinguishing from sibling tools like add_vcs_provider and get_vcs_provider_repositories. It is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it retrieves a list, but it does not explicitly state when to choose this over similar tools, nor does it mention any alternatives or exclusions. No when-to-use context beyond the obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly describes a read-only list operation, but annotations set readOnlyHint=false, which contradicts the description. No additional behavioral context (e.g., pagination, return format) is provided beyond the contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key information. It contains no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description adequately conveys its purpose. However, it does not explicitly describe the return format or differentiate from similar sibling tools, and there is no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. According to the rubric, a baseline score of 4 is appropriate for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Список всех Kubernetes-кластеров аккаунта с привязкой к проекту' (List of all account Kubernetes clusters with project binding), specifying the verb (list), resource (Kubernetes clusters), and scope (account, with project binding). This distinguishes it from project-specific siblings like list_project_clusters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies account-wide usage by saying 'всех' (all), but does not explicitly say when to use this tool instead of alternatives like list_project_clusters or list_k8s_clusters. There is no when-not guidance or mention of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation readOnlyHint is false while description clearly describes a pure read/list operation ('Возвращает все балансировщики'). This is a direct contradiction, so score is 1 per the annotation contradiction rule.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core function and return fields, followed by usage guidance. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with optional pagination params and no output schema, the description covers the purpose, return fields, and usage context. However, it omits mention of pagination behavior and doesn't clarify the read-only nature in conflict with annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for both limit and offset, so baseline is 3. The tool description adds no parameter-specific semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Возвращает' (returns) and resource 'все балансировщики нагрузки аккаунта' (all account load balancers), listing key returned fields. It distinguishes from project-scoped sibling tools like list_project_balancers by stating account-wide scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use before any balancer operations to obtain the balancer ID, providing clear context. However, it does not name alternative tools for project-specific lists or exclude edge cases, so it falls short of full when-not/alternatives coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Описание подразумевает read-only операцию ('Возвращает список'), но аннотация readOnlyHint: false указывает на возможное изменение состояния. Это противоречие, поэтому оценка 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Описание состоит из двух предложений, первое сразу объясняет действие и результат, второе — вариант использования. Нет лишней информации.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Для инструмента с одним параметром и без выходной схемы описание достаточно полно: указаны назначение, возвращаемые поля и контекст использования. Однако отсутствуют сведения о пагинации и прочих ограничениях, а противоречие с аннотацией снижает общую полноту.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Схема параметра полностью документирует registry_id (100% покрытие) и включает описание, откуда брать ID. Описание добавляет только контекст возвращаемых полей, но не уточняет параметр. Базовый уровень 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Описание четко указывает, что инструмент возвращает список репозиториев внутри конкретного реестра, перечисляет возвращаемые поля (имя, тег, digest, размер) и отличает его от list_container_registries, который возвращает сами реестры.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Описание содержит явную инструкцию применения: 'Используй чтобы посмотреть, какие образы уже загружены в реестр'. В схеме параметра также указано, как получить registry_id через list_container_registries, что является подсказкой к использованию. Однако нет явного 'когда не использовать' или альтернативных инструментов.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotations: it says 'Возвращает' (returns), implying a read-only operation, while readOnlyHint is false. This is a serious inconsistency. No additional behavioral details are provided, so the annotation contradiction makes transparency poor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the action and return fields. Every word contributes value, with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing operation with one parameter, the description adequately states the resource and the returned data. It lacks details like pagination or error conditions, but these are not critical for such a tool. The annotation contradiction, however, undermines overall context slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter fqdn with a complete description, giving 100% schema coverage. The tool description does not add further parameter-specific meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all user DNS records for a domain, listing specific fields (ID, type, value, TTL, subdomain, priority). It is distinct from sibling tools like list_default_dns_records because it specifies 'пользовательские' (user) records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use (listing custom DNS records of a domain) but does not explicitly mention alternatives or exclusions. Sibling tools hint at classification (e.g., list_default_dns_records), but the description does not reference them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation (returns a list), but the annotations set readOnlyHint to false, directly contradicting the description. This is a serious inconsistency, as the agent may be misled about the tool's effects. Flagged as annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and includes a usage hint. Every sentence earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no output schema, the description sufficiently states what is returned and when to use it. However, the annotation contradiction slightly undermines completeness, as the agent cannot fully rely on the stated safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (resource_type, resource_id) already adequately described in the input schema. The tool description adds no additional parameter semantics beyond what the schema 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of firewall rule groups attached to a specific resource, using the verb 'Возвращает список' (returns a list) and specifies the resource scope. This distinguishes it from sibling tools like list_firewall_groups (all groups) and list_firewall_group_resources (resources per group).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Используй, чтобы узнать какие группы защищают сервер' (Use to find out which groups protect the server). It does not mention explicit exclusions or alternatives, but the resource-specific focus is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'returns a list' (read-only), but the annotations declare readOnlyHint: false, implying the tool may modify state. This directly contradicts the described behavior. No other behavioral context (e.g., pagination, side effects) is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource, listing the key return fields without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters and no output schema, the description adequately covers the return fields. However, the annotation contradiction and lack of any mention of pagination or limits slightly reduce completeness, though not severely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, making parameter semantics irrelevant. The description adds value by naming the fields in the return payload, which helps the agent understand the output. Baseline 4 for 0 params is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of all floating IPs with specific fields (ID, addresses, zones, and service bindings). This unambiguous verb-resource pairing distinguishes it from sibling tools like get_floating_ip (singular) and bind/unbind_floating_ip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need all floating IPs of a user, but does not explicitly mention when not to use it or point to alternatives. No exclusions or comparisons to siblings are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: The description says 'Возвращает список' (returns a list), implying a read-only operation. However, the annotation readOnlyHint=false indicates the tool is not read-only, which contradicts the stated behavior. No additional behavioral traits (e.g., side effects, link expiration) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences, with the primary purpose stated first and the use case in the second sentence. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the essential context (purpose and use case) and the schema covers parameter details. However, it does not describe the response format, and with no output schema, some information about the returned links (e.g., structure, temporary nature) would be helpful. The contradiction with readOnlyHint also reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add any additional parameter semantics beyond what is already in the schema. It only refers to 'конкретного образа' (specific image), but the schema already documents image_id, limit, and offset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of all download links for a specific image ('Возвращает список всех ссылок на скачивание конкретного образа'). It uses a specific verb and resource, and it distinguishes from sibling tools like get_image_download and create_image_download by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is used when migrating an image to external storage (Timeweb, Google Drive, Yandex.Disk). This gives the agent specific guidance on when to invoke the tool, though it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Возвращает список' (returns a list), clearly a read-only operation, but annotations set readOnlyHint=false, implying the tool may not be read-only. This is a direct contradiction, mandating a score of 1 despite the description adding useful context about what images are.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first states the tool's purpose and output fields, the second defines images for context. No unnecessary words, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing the returned fields (id, name, status, OS, location, size) and explaining the concept of images. It omits exact array structure but that is implied by 'list'. Adequate for a simple read-only list tool with optional pagination params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both limit and offset, including their optional nature and defaults. The description does not add any parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of all images for the account, specifying the exact fields (id, name, status, OS, location, size). It also defines what images are (disk snapshots or uploaded qcow2/iso), which helps distinguish it from sibling tools like get_image or list_image_downloads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to list all images of the account, with no mention of alternatives or exclusions. It implies the use case (listing images) but does not explicitly compare against get_image or other image-related tools, so it stays one step below a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the patch semantics (only provided fields are updated), which is not in annotations. However, it does not disclose error behavior, prerequisites, or return value. Annotations already mark it as not read-only and not destructive, so the description adds moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler. The first states the action, the second gives the key optionality rule. Ideal structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 24 parameters and no output schema, this description is too brief. It omits return format, error conditions (e.g., non-existent balancer_id), and implications of idempotentHint=false. The rich schema covers parameter meaning but not operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description's note about optionality partially repeats the schema's required field list but adds the 'pass only changed fields' advice, which is helpful yet not per-parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Обновляет параметры существующего балансировщика' (Updates parameters of an existing balancer), specifying the verb, resource, and scope. It differentiates from create/delete by emphasizing 'existing', though it does not explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: 'Все поля кроме balancer_id — опциональные; передавай только то, что меняется' (all fields except balancer_id are optional; pass only what changes). This tells the agent when to use it and how to construct calls, though it doesn't explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait: it replaces the entire list, which indicates a mutating operation and is more specific than the annotation readOnlyHint=false. However, it does not mention potential side effects like propagation delays, whether the operation is reversible, or if partial failures can occur. The annotations provide idempotentHint=false and destructiveHint=false, but the description adds minimal context beyond the replacement semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary action and key input format. It contains no fluff, but it is very brief and could arguably include a note about the replacement effect. Still, it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with full schema coverage and no output schema, the description is minimally sufficient: it states the action and input shape. However, it lacks context about prerequisites (e.g., domain must exist) or how to verify the result (e.g., use the corresponding get tool). Given the low complexity, this is acceptable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with clear descriptions for both parameters. The description's mention of 'массив объектов {host, ips?}' merely summarizes the schema without adding extra meaning. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Заменяет' (replaces) with a clear resource: the list of name servers of a domain. This unambiguously distinguishes it from sibling tools like get_domain_name_servers or update_dns_record, and the scope is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context via 'replaces' (you use this when you want to set the entire name server list), but it does not explicitly state when not to use it or mention alternatives such as get_domain_name_servers for reading current settings. No exclusions are provided, but the intent is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide a basic safety profile (not read-only, not destructive, not idempotent), and the description adds the prerequisite that the bucket must already exist. However, it does not disclose failure behavior, duplicate handling, or external side effects hinted by openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, terse sentence that conveys the core purpose without unnecessary words. It is front-loaded and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation with no output schema, the description covers the core action but omits what a successful result looks like or idempotency behavior. Given the openWorldHint, it would be stronger to state external side effects or return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema with required-field labels and IDs, so the description adds no additional parameter semantics. The schema already covers the meaning of project_id and resource_id adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: attaching an existing S3 bucket to a project. This clearly distinguishes it from sibling tools like create_bucket or transfer_bucket, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for associating an already-existing bucket with a project, but it does not explicitly name alternatives or state when not to use it. Siblings like transfer_bucket could overlap in context, and the description does not clarify the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false). The description adds the API endpoint but no additional context about permissions, side effects, or response details. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no filler, front-loaded action and resource. The inclusion of the API endpoint is useful and concise, making every word count.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite full schema coverage, the description is minimal and does not mention return values or prerequisites. For a create operation with 7 parameters, more context could be helpful, but annotations and schema cover safety and parameter details adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions, including required/optional flags and an enum list for privileges. The description text itself adds no parameter information, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'Создаёт' (creates) and clearly names the resource 'пользователя в кластере базы данных' (user in database cluster), making the action unambiguous. Including the API endpoint further distinguishes it from sibling tools like create_database or create_database_instance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The purpose is implied by the resource name, but there is no mention of prerequisites (e.g., cluster must exist) or exclusions. Usage context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly contradicts the annotation destructiveHint: false, as it says 'Удаляет' (deletes) and uses the DELETE HTTP method. This is a serious inconsistency that could mislead the agent about the tool's destructive nature. The 2FA explanation is helpful, but the contradiction forces a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core action and followed by the 2FA caveat. Every word adds value, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary action and the critical 2FA behavior, but with no output schema, it does not describe success/failure response details or the full impact of the deletion. The contradictory destructiveHint annotation also undermines completeness for an agent assessing risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema covers all parameters (100%), the description adds inter-parameter semantics by explaining the two-step 2FA flow: the first response provides 'hash', which must then be sent along with 'code' on a repeat request. This clarifies how code and hash relate beyond their individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Удаляет кластер баз данных' (Deletes a database cluster) and specifies the exact HTTP endpoint. This distinguishes it from sibling tools like get_database_cluster or update_database_cluster.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context and includes explicit 2FA handling instructions: for 2FA accounts, the first request returns a hash, and the agent must repeat the request with that hash and the authenticator code. It does not explicitly mention alternatives, but the action is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states that all data on the server will be lost irreversibly, which is destructive behavior. However, the annotations include destructiveHint=false, directly contradicting the description. This is a serious annotation contradiction, so the score is 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences front-load the action, then provide a critical warning and a user-confirmation instruction. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description covers all essential aspects: the action, the irreversible data loss consequence, and the required confirmation step. It is complete and self-contained, despite the annotation contradiction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter (dedicated_id) with a complete description, achieving 100% schema_description_coverage. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Удаляет' (deletes) and clearly identifies the resource as 'выделенный (dedicated) сервер' (dedicated server). This unambiguously distinguishes it from sibling tools like delete_server (regular server) and other delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to confirm the operation with the user before calling, which is a meaningful usage guideline. However, it does not explicitly state when to use this tool versus alternatives (e.g., delete_server for regular servers), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes a read operation ('returns status'), but annotations mark readOnlyHint=false and idempotentHint=false, suggesting possible side effects. This is a direct contradiction. No additional behavioral context is provided beyond the conflicting read-only implication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, immediately states the core function and provides a practical use case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and use case, but the contradiction with annotations creates a significant gap regarding actual behavior. It also doesn't describe the return format, though the tool is simple. The completeness is undermined by the behavioral conflict.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (empty). The description adds no parameter-specific info, but none is needed. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns account blocking status and notification settings, using a specific verb ('возвращает') and identifying the resource. It distinguishes itself from sibling tools by focusing on account status and blocking diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case: diagnosing why the API is not responding, with a note about possible blocking due to insufficient funds. It doesn't name alternatives or exclusions, but the context is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool 'gets' a list, implying a read-only operation, but the annotations declare readOnlyHint=false, which contradicts this. No other behavioral traits are disclosed, making this a severe transparency failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets straight to the point. It contains no filler or redundant information, and the structure is appropriate for the simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter listing tool, the description provides the core purpose but lacks any detail about the return format (no output schema). Additionally, the contradiction between the described read behavior and readOnlyHint=false leaves a meaningful completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so the rubric establishes a baseline score of 4. The description does not need to add parameter details because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Получает' (gets) and identifies a clear resource: 'список настроек деплоя по умолчанию для различных фреймворков' (list of default deployment settings for various frameworks). This clearly distinguishes it from all sibling tools, which focus on other resources like servers, databases, or networks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is unique among siblings, as no other tool deals with deployment settings, so the intended use case is obvious. Although it does not explicitly mention alternatives or exclusions, the context makes it clear when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context about the return value (delegation status, NS update tasks) but does not disclose any potential side effects, permissions, or rate limits. Given readOnlyHint=false, the ambiguity about possible state changes is not resolved. This is a gap, though not a direct contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise, front-loaded sentence with no unnecessary words. It efficiently communicates the tool's operation and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, the description adequately covers the return values (NS list, delegation status, NS update tasks). This is sufficient for an agent to understand what to expect from the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a clear description for the fqdn parameter. The tool description does not add additional parameter semantics, which is acceptable since the schema already explains the parameter fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses a specific verb 'Возвращает' (returns) and identifies the resource (name-серверы домена) and scope (host + IP-адреса, статус делегирования and задачи обновления NS). This distinguishes it from sibling tools like get_domain or update_domain_name_servers, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like list_dns_records or get_domain. Usage is implied by the tool's purpose, but there is no guidance on exclusions or alternative selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool 'returns' buckets, implying a read-only operation, but the annotation readOnlyHint is false. This is a direct contradiction, making the behavioral disclosure unreliable. No additional behavioral context (e.g., authentication, rate limits) is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and includes a practical usage tip. Every sentence contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), and the description lists the returned fields and usage context, which is relatively complete. However, the contradiction between the read-only description and readOnlyHint=false undermines completeness, leaving ambiguity about whether side effects exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (an empty properties object). The description does not need to explain parameters, and the baseline for 0 params is 4. The description actually adds value by listing the returned fields, but that is not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to return all S3 buckets of the account with specific fields. It uses a specific verb ('returns'), resource ('S3 buckets'), and scope ('account'), which distinguishes it from sibling tools like list_project_buckets or list_all_project_buckets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool before any storage operation to get the bucket ID, providing clear context for when to use it. However, it does not mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation readOnlyHint=false contradicts the description's clear read-only intent ('Возвращает список' - returns a list). This is a serious inconsistency. Additionally, no behavioral details beyond the contradiction are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence that front-loads the action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description omits any details about the return value structure (since no output schema), and the annotation contradiction undermines trust. It also lacks explicit comparison to list_dns_records, which is directly relevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the sole parameter fqdn. The description adds that the tool works for domains OR subdomains, which is extra context beyond the schema's 'полное имя домена'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Возвращает список' (returns a list) and identifies the resource as default DNS records for a domain or subdomain, clearly distinguishing from the sibling tool 'list_dns_records'. It is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions that these are Timeweb system records, implying use for default/system records rather than user-defined ones. However, it doesn't explicitly contrast with list_dns_records or state when not to use this tool, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description claims read-only behavior ('Возвращает список' - returns a list), but annotations set readOnlyHint=false and idempotentHint=false, contradicting the described behavior. No additional behavioral details like pagination or rate limits are provided. This is an annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, first describes function, second gives usage guidance. No redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description covers return fields and usage context. However, the annotation contradiction and lack of pagination/sorting details leave gaps; no output schema means the agent relies on the incomplete list of 'key parameters'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters; schema coverage is 100% (trivially). Description adds no parameter info needed, so baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns a list of all account domains with specific fields (ID, FQDN, status, expiry, auto-renewal), using the specific verb 'Возвращает' (returns). This distinguishes it from siblings like get_domain, add_domain, or check_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Используй перед любой операцией над доменом' (Use before any domain operation), indicating when to call. However, it doesn't mention exclusions or alternative tools, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims a pure read operation ('Returns all...'), but the annotation readOnlyHint is false, indicating potential side effects. This contradiction is serious; the description does not clarify any side effects or permissions. Consequently, transparency fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the result fields and a usage tip. It is well-structured and front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description covers the return content and provides a practical usage tip. However, the annotation contradiction regarding read-only behavior creates ambiguity about the tool's safety, so completeness is reduced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined in the input schema, and the description correctly implies no required inputs. With 0 parameters, the description doesn't need to explain parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all firewall rule groups with specific fields (ID, name, description, policy, dates), distinguishing it from related tools like list_firewall_rules by focusing on groups. The verb 'returns' plus resource 'firewall rule groups' makes 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool before any group operation to obtain the group ID, providing clear when-to-use context. It does not mention alternatives or when-not-to-use, but the usage context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation ('Возвращает конфигураторы'), while annotations set readOnlyHint=false, implying the operation may have side effects. This is a direct contradiction with the annotation, misleading the agent about the tool's behavioral safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise, front-loaded sentences. The first states the core function and returned data, the second gives usage guidance. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description provides useful context about what is returned and when to use it. However, the contradiction with readOnlyHint creates ambiguity about side effects, and the lack of an output schema leaves the response structure partially unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by definition. The description adds no parameter-specific semantics, but none are needed; per the rubric, 0 params earns a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Возвращает' (returns) and identifies the resource 'конфигураторы серверов' with details about CPU/RAM/Disk/Bandwidth/GPU ranges and change steps. The phrase '(не тарифом)' clearly distinguishes it from preset/tariff tools like list_server_presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Используй, если нужно создать VPS с произвольной конфигурацией (не тарифом).' This provides a clear usage context and a when-not case (tariff), but it does not name a specific alternative tool, relying on the implicit sibling list_server_presets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that the new password is sent to the account owner's email, providing useful behavioral context. However, it does not disclose other traits like potential delays or effects on existing sessions, so it only partially adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main action and followed by the outcome. No unnecessary words, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core action and the method of receiving the new password. However, it does not explain the response format, potential side effects, or any prerequisites, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents server_id as mandatory and its purpose. The description does not add any further information about the parameter, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: initiating a reset of the server's root password. It uses a specific verb ('reset') and resource ('root password'), and the title reinforces this. It is distinct from all sibling tools, as no other password reset tool exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to reset a server's root password) but does not explicitly state when to use it versus alternatives, nor does it mention prerequisites or exclusions. It provides clear context of the action but lacks direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds minimal behavioral context by specifying 'from current service', but it does not describe side effects, prerequisites, or what happens to the IP after unbinding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, concise and front-loaded. No wasted words, and it conveys the essential purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. Annotations cover safety. However, the description is very brief and does not explain the outcome or side effects of unbinding, such as whether the IP remains in the account or what happens to the service. This is sufficient for a basic action but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add extra meaning beyond the schema. The parameter is fully documented in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (unbind), resource (floating IP), and scope (from current service). It distinguishes itself from sibling tools like bind_floating_ip and delete_floating_ip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to unbind an IP), but it does not provide explicit alternatives or state when not to use it. No comparison with bind_floating_ip is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that the tool is not read-only, not destructive, and not idempotent. The description adds minimal behavioral context beyond stating that it changes configuration and version, which is already implied by the name and title. No additional side effects or prerequisites are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the purpose. However, the second sentence, 'Нужны type, config_type, yaml_config, version', is redundant with the schema and incomplete, as it omits two required parameters. This slightly misleads and reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core action and mentions previously installed addons, but it lacks information about return values (no output schema) and provides an incomplete parameter list. Given the tool's complexity (6 required parameters), the description is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all six parameters having detailed descriptions. The description lists only four of the six required parameters (type, config_type, yaml_config, version), omitting cluster_id and addon_id. It adds no extra semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Изменяет конфигурацию или версию ранее установленного дополнения' (changes configuration or version of a previously installed addon). This is a specific verb+resource pair and distinguishes it from install/uninstall by noting the addon must be previously installed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'ранее установленного дополнения' implies usage for existing addons, providing clear context for when this tool should be used. However, it does not explicitly mention alternatives or exclusions, such as 'use install_k8s_addon for new addons'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds context about traffic distribution, but it does not disclose behavior such as whether adding IPs is additive or replaces existing ones, duplicate handling, or ordering. With annotations covering the basic safety profile, the description adds some 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, with the action stated first and the effect in the second. There is no redundant information or filler. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple add operation with two required parameters and no output schema, the description effectively communicates the core function and expected consequence. It lacks any mention of error conditions or edge cases, but given the low complexity, it is nearly complete. A small addition about idempotency or limits could push it to 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'ips' and 'balancer_id' have detailed descriptions in the schema. The tool description does not add any parameter-specific meaning beyond what the schema already provides, so it stays at the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Добавляет backend IP-адреса к балансировщику' (adds backend IP addresses to the balancer). It names the resource (balancer) and the operation (add IPs), and the second sentence clarifies the effect (traffic distribution). This distinguishes it from siblings like add_server_ip, add_balancer_to_project, and especially remove_balancer_ips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to attach backend IPs to a balancer, but it does not explicitly state when not to use it or mention alternatives such as remove_balancer_ips for removal. No exclusions or conditions are provided, so it meets the 'implied usage' level but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, indicating a mutating but non-destructive operation. The description adds that the database must be 'existing', clarifying this is an association rather than creation. It does not disclose potential side effects or reversibility, but given annotation coverage, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action. Every word adds value, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with only two well-documented parameters and comprehensive annotations. The description sufficiently communicates the purpose and adds the nuance that the database must already exist. While it doesn't mention return values or error cases, no output schema is present, and the operation is straightforward, making the description complete enough for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (project_id and resource_id), so the schema fully documents them. The description adds no parameter-level details, and per the rubric, baseline 3 applies when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Привязывает существующую managed-БД к проекту' clearly states the specific action (links/binds) and resource (existing managed database) to a project. It distinguishes from sibling tools like add_server_to_project or add_cluster_to_project by specifying 'existing managed-БД', 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool vs alternatives. However, the tool name and description imply it is for linking existing databases, which is implied rather than stated. There are no exclusions or mentions of alternative tools, so the usage context is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply states the creation action, which aligns with the non-read-only annotation. It does not add additional behavioral context beyond what annotations already provide, such as potential DNS propagation or idempotency effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, stating the action and required inputs in two sentences with no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter creation tool with annotations covering the safety profile, the description is largely sufficient. However, it omits explicit prerequisites (e.g., main domain must exist) which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents both parameters with descriptions. The description restates that FQDN of main domain and subdomain are required, adding no new semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a subdomain for a specified main domain, using a specific verb and resource. It distinguishes from sibling tools like add_domain by targeting subdomains specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when adding a subdomain to an existing domain, but does not explicitly state when to use it over alternatives or provide exclusions. No guidance is given for scenarios like domain verification or existing subdomains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide openWorldHint (results depend on external state). The description adds the return type (boolean) and clarifies that it checks registration availability, which is useful. However, it does not disclose side effects or address the readOnlyHint: false inconsistency, as the operation appears read-only. The added context is minimal but non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the primary action and includes the return type. No redundant information; it's appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description adequately covers the purpose and return value. The phrase 'свободен ли домен' makes it clear that true corresponds to availability. Annotations cover external-world dependence, and the schema covers the parameter definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the fqdn parameter ('ОБЯЗАТЕЛЬНОЕ ПОЛЕ - полное имя домена для проверки доступности'), covering 100% of parameters. The description adds no parameter-specific semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether a domain is free and can be registered ('Проверяет, свободен ли домен и можно ли его зарегистрировать') with a specific verb and resource. This distinguishes it from domain management/creation tools like add_domain, create_domain_request, and get_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies use for pre-registration availability checks, but there is no explicit guidance on when to use this tool versus alternatives such as add_domain or create_domain_request. No exclusions or alternative tools are mentioned; the usage context is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, and the description's 'creates' is consistent with a mutation operation. The description adds the endpoint but does not disclose additional behavioral traits such as prerequisites, cost implications, or expected response. This meets the lower bar set by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, front-loaded sentence that directly states the action, resource, and endpoint. There is no unnecessary information, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 fully documented parameters, clear annotations, and no output schema, the description provides sufficient purpose and context ('inside the cluster'). Minor gaps include not explicitly stating that the cluster must exist or describing the expected response, but these are not critical for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter clearly described in the schema (e.g., 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ - название инстанса базы данных'). The description itself adds no parameter-level details beyond the schema, aligning with the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Создаёт новый инстанс (БД) внутри кластера' and provides the exact API endpoint (`POST /api/v1/databases/{db_cluster_id}/instances`). This distinguishes it from sibling tools like create_database and create_database_admin by specifying the resource and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The endpoint and the phrase 'внутри кластера' imply that an existing cluster is required, but the description does not explicitly state when to use this tool over alternatives like create_database or list_database_instances. There is no when-not-to-use guidance or mention of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a write operation (readOnlyHint=false) and non-idempotent, so the description does not need to repeat that. It adds the specific SRV parameter exception and supported record types, but does not disclose other behavioral details like validation or effect on existing records.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, each serving a purpose: one defines the action and scope, the other highlights a critical parameter exception. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential use case and the SRV special case, while the schema details all 11 parameters. Given the lack of an output schema and the straightforward nature of a create operation, the description is sufficient, though it could mention requirements like domain existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so parameter semantics are fully documented. The description adds a concise reminder that SRV uses host/port/service/protocol instead of value, which complements the schema but does not significantly exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates DNS records, enumerates supported types (A, AAAA, TXT, CNAME, MX, SRV), and scopes it to domains or subdomains. This distinguishes it from sibling tools like update_dns_record or delete_dns_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating DNS records but does not explicitly compare with alternatives or state when not to use it. The API v2 note is more implementation detail than usage guidance. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose that this is a non-read-only, non-idempotent, non-destructive operation. The description adds useful context by explaining the is_default flag's effect on server creation and stating that the key is created in the account. However, it does not disclose potential side effects, required permissions, or what the response contains, so it only marginally extends beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that directly state the action and the required parameters. It is front-loaded with the primary purpose and wastes no words. The explanation of is_default is valuable and included without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with three fully documented parameters and no nested objects or output schema, the description is adequate. It explains the key purpose and the meaning of the is_default flag. However, it does not mention what the tool returns (e.g., the created key object) or any prerequisites, which would improve completeness slightly. The overall context is sufficient for a straightforward creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all three parameters with detailed descriptions. The tool description repeats the schema's parameter explanations without adding any new meaning or context beyond what is already structured. Since schema coverage is high, the description does not need to compensate, but it also does not add value beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Создаёт' (creates) and the resource 'SSH-ключ в аккаунте' (SSH key in the account), making the tool's purpose specific and unambiguous. It naturally distinguishes from sibling operations like update_ssh_key, delete_ssh_key, or add_ssh_keys_to_server by defining a new key creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to create a new SSH key) but does not explicitly mention alternative tools or exclusions. It provides no guidance about when to use this versus updating or adding existing keys, which would be helpful. The usage context is only implied by the tool's name and action verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses irreversible data loss, which is valuable. However, the annotations declare destructiveHint: false, which directly contradicts the description's claim that data will be lost. This is a serious inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it states the action, warns of irreversibility, and gives a prerequisite in three short sentences. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete-by-ID operation, the description covers the essential context: irreversibility and the need to unmount first. It lacks information about error handling if the drive is still mounted, but this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with a detailed description of network_drive_id as a required UUID. The description adds nothing 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('delete'), the resource ('network drive'), and the method (by ID). This distinguishes it from sibling tools like mount/unmount or update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states a prerequisite: the drive must be unmounted from all services before deletion, pointing to the unmount_network_drive tool. This gives clear guidance on when to use this tool versus first using another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool returns data, implying a read-only operation, but the annotation readOnlyHint=false contradicts this by suggesting the tool may have side effects. This is a clear annotation contradiction, requiring a score of 1 per rubric.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of just two sentences. The first sentence front-loads the return data, and the second provides concrete usage examples. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description lists the main data points (balance, subscription fee, etc.) and includes a specific field (hours_left) for a key use case. It is sufficient for a zero-parameter read operation, though it could clarify units or formatting. The readOnly contradiction slightly undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so schema coverage is 100% trivially. Baseline for 0 parameters is 4; the description adds no parameter details because there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Возвращает' (returns) and specifies the resource 'финансы аккаунта' (account finances), listing concrete data fields (balance, subscription fee, service cost, discount, autopayment). It also provides example user questions, making the tool's purpose unmistakable and distinguishing it from sibling tools like get_account_status and get_account_services_cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases with example questions ('сколько денег осталось', 'сколько тратим в месяц', 'когда кончатся деньги'), which clearly indicates when to use it. However, it does not mention exclusions or alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide safety hints (not destructive, idempotent false) and the description does not contradict them. The description adds the time interval aggregation behavior but does not disclose potential response details or any side effects. Since annotations lower the burden, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and followed by key parameter details. It is concise, well-structured, and every word earns its place without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with four parameters (all documented in schema) and no output schema. The description explains the core behavior and parameter formats, which is sufficient for basic usage. However, it does not specify the structure of the returned statistics (e.g., total tokens, input/output split), which would have been helpful for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description. The description reinforces start_time/end_time as ISO 8601 and interval default of 60 minutes, but these are already in the schema. It adds minimal extra meaning beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns token usage statistics for an agent over time intervals, using a specific verb ('returns') and resource ('token usage statistics'). It distinguishes itself from sibling tools like list_ai_agents and get_ai_agent by focusing on usage statistics rather than listing or retrieving agent details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when needing token usage statistics) but does not explicitly mention alternatives or exclusions. There is no guidance on when not to use it or which sibling tool to choose instead, so the context is clear but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists the returned attributes, adding some behavioral context beyond the annotations. However, it does not disclose other traits such as error handling, permission requirements, or that it requires both IDs to be valid. Annotations provide readOnlyHint=false (odd for a getter) but the description neither contradicts nor enriches that significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core purpose ('Возвращает детали конкретного правила firewall') and then lists the expected fields. No wasted words; it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 full schema coverage and no output schema, the description is reasonably complete: it states the purpose and enumerates the return contents. It does not explain return structure or errors, but the low complexity makes that acceptable. A small gap is the lack of any guidance on how to obtain the required IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the two required parameters (rule_id and group_id) with clear descriptions, giving 100% coverage. The description adds no extra parameter details beyond referring to a 'specific rule', so it does not meaningfully elevate beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns details of a specific firewall rule and enumerates the fields (direction, protocol, port, CIDR, description, group ID). This distinguishes it from sibling tools like list_firewall_rules, which lists rules, and get_firewall_group, which gets group-level info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining details of a single rule, but it does not explicitly mention when to use it over alternatives or any exclusions. It lacks guidance like 'use list_firewall_rules to enumerate rules first' or 'requires an existing rule ID.' The context is clear but no explicit alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are partially present (readOnlyHint=false), but the description adds useful context by listing the specific fields returned. It does not contradict annotations, but it also does not explain the non-read-only hint—there is no mention of side effects, permissions, or error behavior. Given annotations provide a baseline, the extra field details earn a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action, followed by a list of return details. Every word contributes value, though the list could be slightly more structured. It is concise and efficient, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 one parameter and no output schema, the description is complete: it clearly states the resource, the required identifier, and the specific information returned. No additional context is needed for an agent to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter tld_id with a Russian description 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID доменной зоны' (REQUIRED FIELD - ID of domain zone). The tool description merely repeats 'по её ID' (by its ID), adding no new semantic meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Возвращает' (returns) and the resource 'доменной зоне (TLD) по её ID' (domain zone by ID), specifying the exact data returned: prices, registrar, grace periods, whois privacy. This unambiguously distinguishes it from the sibling list_tlds, which lists all TLDs rather than getting one by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to get detailed info about a specific TLD, you need its ID. However, it does not explicitly mention alternatives (e.g., list_tlds) or when not to use it. No exclusions or comparative guidance are provided, so it stops at implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical behavioral trait: data in RAM and unfinished writes will be lost. However, the annotations declare destructiveHint: false, which directly contradicts this warning. This is an annotation contradiction because the tool is described as destructive in terms of data loss while the annotation claims it is not destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence states the core action and method, the second adds usage caution and risk. No wasted words, fully front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers purpose, when to use, and risk. However, the contradiction with destructiveHint reduces overall reliability, so it is not a 5. The description is otherwise complete for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has full coverage (100%) for the single required parameter server_id, which is described as 'ID сервера для принудительного выключения'. The description does not add additional semantics beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Принудительно выключает сервер (reset power)' (forcibly turns off the server), which is a specific verb and resource. It distinguishes itself from sibling tools like shutdown_server and hard_reboot_server by emphasizing the 'reset power' nature and emergency use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Использовать только если мягкий shutdown_server завис или не реагирует' (use only if soft shutdown_server is hung or unresponsive). It also names the alternative (shutdown_server) and warns about data loss, providing clear guidance on usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering the mutation and safety profile. The description adds that it adds worker nodes and optionally labels, but does not disclose side effects like potential cost increase or long-running provisioning, so it does not go beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action, and contains no extraneous information. It is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 fully documented parameters, annotations indicating a non-read-only mutation, and no output schema, the description is adequate for a straightforward operation. It could mention preconditions or asynchronous behavior, but the schema and sibling tools provide enough context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, including count and labels. The description merely restates that a specified number of nodes are added and labels can be assigned, which is already captured in the schema, so it adds no new semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Добавляет указанное количество воркер-нод в группу' (Adds the specified number of worker nodes to the group), providing a specific verb and resource. It distinguishes from the sibling tool reduce_k8s_node_group_nodes by indicating an increase rather than a decrease.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives, such as reduce_k8s_node_group_nodes, nor does it mention any exclusions or preconditions. Usage is implied by the clear purpose and the presence of a sibling operation that scales in the opposite direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation declares readOnlyHint=false, meaning the tool is not read-only, yet the description describes a pure list/read operation ("Возвращает список"). This is a direct contradiction. No side effects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core outcome (returns list), and includes only essential fields and usage guidance. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description adequately covers the return fields and positioning for use. However, the annotation contradiction prevents a perfect completeness score as the description is not fully aligned with the tool's declared behavioral hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameters. Per the rubric, a zero-parameter tool gets a baseline score of 4, and the description appropriately adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of all AI agents in the account, specifying exact fields (ID, name, status, access type, model ID, token usage). This distinguishes it from related tools like get_ai_agent (single agent) and create/update/delete agent operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool before operations on an agent to obtain the ID, providing clear when-to-use context. It does not mention alternatives but the use case is specific and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool returns a list, implying read-only behavior, but the annotations declare readOnlyHint=false. This directly contradicts the description. The description does add return-field details, but the contradiction with the annotation is a severe flaw, leading to a score of 1 per the rubric.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys the purpose and return fields. It contains no unnecessary words or repetition, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description adequately explains what is returned and the scope (all account API tokens). However, the contradiction with readOnlyHint=false creates ambiguity about whether the tool is truly read-only, which prevents a perfect score. Without that issue, it would be a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by specifying the returned fields (ID, names, lifetime), but since there are no parameters to explain, it cannot exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Возвращает список' (returns a list) and identifies the resource as 'API-токенов аккаунта' (account API tokens), also mentioning the returned fields (ID, names, lifetime). This clearly distinguishes it from sibling mutation tools like create_api_key, delete_api_key, edit_api_key, and refresh_api_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to list all API tokens of an account. While it doesn't explicitly state when to use it over alternatives, the context is clear from the name and the fact that siblings are mutations. No exclusions or alternative guidance is provided, so it misses a 5 but is above a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states a read operation ('Возвращает' - returns) while annotations declare readOnlyHint=false, which indicates the tool may not be read-only. This is a direct contradiction. Although the description adds a valuable caveat about secret_key, the contradiction overrides any positive contribution, resulting in a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the purpose and return fields, the second adds a relevant security note about secret_key. Every sentence earns its place, and there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no output schema), the description sufficiently explains what is returned and offers a practical caution about secret_key. It does not describe the full response format or pagination, but for a simple list operation this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (vacuously). According to the rubric, a zero-parameter tool receives a baseline of 4. The description adds no parameter information because there is nothing to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Возвращает' (returns) and clearly identifies the resource: all administrator users of S3 storages of the account. It also lists the returned fields (id, access_key), making its purpose unambiguous. It is easily distinguishable from the sibling update_bucket_user and other listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool to use when you need the list of S3 storage admin users. It also provides guidance on not relying on secret_key from the response and instead using update_bucket_user for updates. However, it does not explicitly mention when not to use this tool or alternative listing tools, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation contradiction: the description implies a read-only operation ('Возвращает список'), but annotations set readOnlyHint=false. The description also does not disclose response format or authorization needs, but the contradiction alone drops this to 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and object, and enumerates all known driver values. It contains no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list tool, the description provides the purpose and all expected values (kuberouter, calico, flannel, cilium). It does not describe the response shape, but it is sufficient to invoke correctly given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the baseline for zero params is 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Возвращает список' and names the resource 'сетевых драйверов для создания кластера', listing concrete values. This clearly distinguishes it from sibling list tools like list_k8s_versions and list_k8s_presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the intended use context: 'для создания кластера' (for cluster creation). It does not explicitly mention when not to use it or name alternatives, but the context is clear for a simple enumeration tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('returns a list'), but the annotation readOnlyHint=false indicates that the tool may modify state. This is a direct contradiction between the description and the annotation, meriting a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the main purpose and a clear usage pointer. There is no wasted information, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 parameters and no output schema, the description adequately explains the return concept (list of services/servers with resource_id) and the typical usage flow. It could mention response structure but is sufficient for the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters; the schema is empty and the description adds no parameter information. Per the rubric, a 0-param tool gets a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of services (servers) that can be used for connecting a network drive, using a specific verb ('returns') and resource. It also distinguishes itself from sibling tools by explicitly tying it to the mount_network_drive workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool before mount_network_drive to discover valid resource_id values, providing a clear 'when to use' context. However, it does not mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: The description says the tool returns a list (read-only behavior), but annotations set readOnlyHint to false, implying the tool is not read-only and may have side effects. This is a serious inconsistency that could mislead an agent. The description provides no additional behavioral context beyond the contradictory annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, with the main action and output details front-loaded. The second sentence provides actionable usage guidance. No redundant information or filler words; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless list tool with no output schema, the description covers the essential points: what it returns, the fields included, and when to use it (to obtain project_id). It doesn't explain pagination or advanced filtering, but given the simplicity of the tool, this is not a significant gap. However, the contradiction with annotations reduces the overall completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no schema to compensate for. The description adds value by specifying the return fields (id, имя, описание, флаг по умолчанию), which is useful for an agent expecting to extract project_id. Since there are no parameters, the baseline is 4 and the description fulfills the informational need without missing details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Возвращает' - returns) and resource ('список всех проектов аккаунта' - list of all account projects), and specifies the returned fields (id, имя, описание, флаг по умолчанию). This clearly distinguishes it from sibling tools that list specific project resources (e.g., list_project_servers, list_project_balancers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Используй перед работой с ресурсами проекта, чтобы получить project_id.' This gives a clear use case and prerequisite for obtaining a project_id. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation by saying 'Возвращает список' (returns a list), but the annotations set readOnlyHint=false. This directly contradicts the structured hint, undermining confidence in the tool's safety profile. No additional behavioral details like pagination or side effects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences: the first states the core purpose and return fields, the second gives usage context. There is no fluff and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing the returned fields (ID, size, load, status). For a simple one-parameter list tool, this is fairly complete, though it lacks details like pagination or response format examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with server_id described as 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID сервера' (REQUIRED FIELD - server ID). The description adds no additional parameter semantics beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Возвращает список дисков сервера' (Returns a list of server disks) with specific fields (ID, size, load, status), making the verb and resource clear. It distinguishes from sibling tools by mentioning its use before backup operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Используй перед операциями с бэкапами' (Use before backup operations) and names the specific sibling tools requiring disk_id (list_server_disk_backups and create_server_disk_backup), providing clear when-to-use guidance and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes a read-only list operation ('Возвращает список'), but annotations declare readOnlyHint=false, which suggests potential side effects. This contradicts the description's clear read-only nature. Beyond the contradiction, the description provides no additional behavioral details such as authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the main action first and usage guidance second. Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description adequately covers what the tool returns and when to use it. It could mention response format or whether the list is exhaustive, but the complexity is low, so it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter burden to carry. The description adds value by listing the returned fields (ID, family, name, etc.), which helps the agent know what to expect, though not needed for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of operating systems available for VPS installation, listing specific fields (ID, family, name, version, codename, minimum requirements). The verb 'Возвращает' plus resource 'список операционных систем' is specific and distinguishes it from sibling list tools like list_server_presets or list_server_software.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool before creating a VPS to choose os_id, providing clear usage context. However, it does not mention when not to use it or compare with alternative list tools, so it's slightly below top mark.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=false, implying the tool may modify state, but the description states it only returns a list. This is a direct contradiction with the annotations, requiring a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the purpose and output fields, the second gives usage guidance. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list operation, the description covers the returned fields and usage context. It lacks pagination or sorting details, but the operation is simple and there is no output schema, so this is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%. The description correctly omits parameter details, and the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of all SSH keys with specific fields (ID, name, creation date, is_default flag, and server list). This distinguishes it from get_ssh_key (single key) and mutating key operations like create_ssh_key or delete_ssh_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it before SSH key operations to get IDs, which gives clear usage context. It does not name alternatives or exclusions, but the context strongly implies when this list tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral trait not captured by annotations: applying changes will require downtime for the server. This adds meaningful context beyond the readOnlyHint, idempotentHint, and destructiveHint annotations, which are all false but don't describe operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: it states the core function, the key side effect (downtime), and a helpful prerequisite reference. No fluff or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation with no output schema, the description covers the main action, the two configuration modes, a significant side effect, and a cross-reference for presets. It could mention the mutual exclusivity explicitly, but the schema already does, so the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover each parameter with mode-specific explanations and mutual exclusion constraints (e.g., preset_id cannot be used with configurator_id). The description reiterates the two modes but adds no significant new details beyond what the schema provides, so it doesn't push beyond the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes a server's tariff or custom configuration and applies to an existing server. It specifies the two modes (preset_id vs configurator_id with cpu/ram/disk/gpu). However, it doesn't explicitly distinguish this from the sibling update_server tool, which may also modify server settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context (applies to existing server, requires downtime) and points to get_allowed_presets for obtaining preset list. However, it does not provide explicit when-not-to-use guidance or contrast with update_server, leaving some ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the behavioral outcome of each mode ('полный доступ', 'только исходящий', 'изоляция в локальной сети'), which adds value beyond the schema. Annotations already indicate it's a non-read-only, non-idempotent, non-destructive mutation. However, it stops short of warning about potential side effects like connection disruption when switching modes, which could be important.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the purpose and the three modes. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with full schema coverage and no output schema, the description is nearly complete. It explains the effect of each mode and the overall action. It lacks explicit usage guidance and side-effect warnings, but those are minor gaps given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both server_id and nat_mode already described in the schema. The tool description recaps the enum meanings but does not add substantial new information beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Меняет' (changes) with a clear resource ('правила маршрутизации трафика') and lists the three possible modes with their meanings. This distinguishes it from sibling server tools like set_server_boot_mode or update_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: an agent would use this when needing to alter a server's NAT mode. However, there is no explicit guidance on when to use this tool versus alternatives (e.g., other server configuration tools), nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'Идемпотентен' (idempotent) while the annotations set idempotentHint=false, contradicting the structured data. The described behavior (error on already running server) is not idempotent, making the claim misleading and inconsistent with the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and each word provides necessary information: the action, the idempotence claim (though flawed), the error condition, and a precondition check. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description provides the core behavior, the error case, and a recommended prerequisite (get_server), making it mostly complete. The misleading idempotence claim creates some confusion, but it does not omit essential operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single required parameter server_id with a clear description (ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID сервера для запуска). The tool description adds no extra parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Запускает выключенный VPS' (Starts a powered-off VPS), clearly stating the action, target, and scope. This distinguishes it from sibling tools like hard_reboot_server or shutdown_server by focusing on starting an off server and noting the error on an already-running one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to check the server status via get_server before calling, establishing a clear precondition. It also states that calling on a running server returns an error, providing both when-to-use and when-not-to-use guidance without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds the behavioral consequence that rules no longer apply after detachment, which is useful context beyond annotations. It does not disclose side effects or reversibility, but the basic effect is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and contains no wasted words. It efficiently states the operation and its effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple unlink operation, the description is largely complete: it names the operation and its consequence. It could mention reversibility (linking again) or error cases, but given the low complexity and schema richness, it is sufficient. No output schema exists, so return values are not explained, but that is not critical for this mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters, so the schema does the heavy lifting. The description does not add parameter-specific details beyond what is already in the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Отвязывает ресурс от группы правил firewall' (detaches a resource from a firewall rules group). It uses a specific verb and resource, and the effect is described, distinguishing it from the sibling 'link_firewall_resource'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (when you want to stop applying firewall rules) but does not explicitly state when to use this tool versus alternatives like 'link_firewall_resource' or list functions. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows it is a mutating but non-destructive operation. The description adds the PATCH method and the set of modifiable parameters, which is useful, but it does not disclose side effects, auth needs, or behavior for omitted fields. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently states the purpose and includes the API endpoint. There is no waste, and it is front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters (1 required), no output schema, and no nested objects, the description plus schema and annotations provide sufficient context for a typical PATCH update operation. It lacks details about return values or potential side effects, but the openWorldHint annotation hints at broader impacts, and the description is adequate for an update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters already have descriptions. The description summarizes a subset of parameters (name, tariff, description, public network) but does not add new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it changes database cluster parameters, listing specific fields (name, tariff, description, public network) and includes the API endpoint. This distinguishes it from other update_* tools like update_database_instance or update_database_admin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the action and resource, but does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The context is clear but guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only (readOnlyHint=false), non-destructive (destructiveHint=false), and non-idempotent (idempotentHint=false). The description adds the HTTP PATCH method and the fact it changes parameters, which is consistent. However, it does not disclose any side effects, required permissions, or behavior beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that includes the HTTP method and path. It is front-loaded with the purpose and contains no filler, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple update tool with full schema coverage and annotations, the description is adequate. It conveys the operation and endpoint, while schema handles parameter details. It could be slightly more explicit about which fields are updatable, but the schema already specifies optional name/description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters described (required IDs and optional name/description). The description adds little beyond the endpoint path, which merely reiterates the required parameters. No additional semantic meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'changes database instance parameters in a cluster' and includes the endpoint PATCH /api/v1/databases/{db_cluster_id}/instances/{instance_id}. It clearly identifies the action and the specific resource (database instance in a cluster), distinguishing it from siblings like update_database_cluster and update_database_admin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the necessary context (updating instance parameters) but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It is implied by the name and endpoint, but there is no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, covering the safety profile. The description adds minimal extra context: it mentions 'Использует API v2' (uses API v2) and the need to provide type and new fields. It does not disclose side effects, permission requirements, or reversibility, which are not covered by annotations. This is a partial enhancement over structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and contains no fluff. Every sentence provides useful information: what it does, API version, and required inputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 12 parameters and supports 6 DNS record types, with conditional requirements (e.g., SRV needs host, port, service, protocol). The description is too brief to guide an agent on which fields are relevant for each type. It does not mention response behavior or any type-specific logic. Given the tool's complexity, the description is inadequate for full autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already described in the schema. The description only restates that type and new fields must be passed, adding little beyond the schema. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Обновляет существующую DNS-запись по ID' (Updates an existing DNS record by ID). This distinguishes it from sibling tools like create_dns_record and delete_dns_record by specifying the update operation and the requirement of a record ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: updating an existing DNS record with a known ID. It implies when this tool is appropriate (update scenario) and notes the need to pass the record type and new fields. However, it does not explicitly name alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the write operation is known. The description adds that the update sets a payment source, which is mildly informative, but it does not disclose side effects, idempotency, or authorization requirements beyond what the annotations already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core function and enumerates the payment source options. Every part earns its place with no redundancy or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters with conditional requirements, but the input schema covers these thoroughly (100% coverage). The description provides enough context to understand the operation's purpose, and the schema handles parameter semantics. However, it does not mention return values or post-update effects, and the operation's side effects are not fully elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents all 7 parameters, including conditional requirements. The description only repeats the enum values already present in the schema (use, invoice, free, bonus) and their meanings, adding no new semantic information beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Обновляет заявку') on a specific resource ('на регистрацию/продление/трансфер') and conveys the purpose of setting a payment source. This distinguishes it from sibling tools like create_domain_request or get_domain_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: updating a domain request's payment method for registration, renewal, or transfer. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., create_domain_request), nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating, non-idempotent operation (readOnlyHint: false, idempotentHint: false). The description adds that the group is initially empty and can be populated later, which is useful behavioral context. However, it does not disclose potential errors, default policy behavior when omitted, or the operation's return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences. The first sentence states the action and required/optional fields; the second sentence provides workflow context. No words are wasted, and the structure is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain what the operation returns (e.g., group ID or object) or error conditions (e.g., duplicate name). The references to subsequent tools (create_firewall_rule, link_firewall_resource) and optional field clarifications provide moderate context, but the lack of return/error information leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – all parameters (name, policy, description) are documented in the input schema. The description only restates that name is required and description/policy are optional, adding no semantic value beyond the schema. The mention of policy as a query-parameter is already in the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with 'Создаёт новую группу правил firewall' – a specific verb+resource combination. It clearly distinguishes from create_firewall_rule (which creates rules within a group) and link_firewall_resource (which attaches a group to a server), 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the typical workflow: after creating the group, rules can be added via create_firewall_rule and the group can be linked to a server via link_firewall_resource. This gives clear contextual usage guidance, but it does not explicitly state when not to use this tool or mention alternatives beyond these sequential steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the write nature of the operation, consistent with annotations (readOnlyHint=false). It adds the practical context of checking presets first, but doesn't elaborate on side effects, costs, or post-creation state of the drive. Given that annotations already cover the basic safety profile, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and gets straight to the point, stating the action first and then the prerequisite. No wasted words, easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool creates a resource but the description doesn't mention what the response contains, which is relevant since there is no output schema. It also doesn't note that the operation may incur costs or whether the drive requires mounting after creation. However, the core action and prerequisite are covered, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all four parameters with 100% coverage, so the baseline is 3. The description echoes preset_id and size but adds no new parameter-specific details beyond what the schema states. It doesn't compensate with extra information about constraints or units beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new network drive with a specified size and selected preset (preset_id), using a specific verb and resource. This distinguishes it from sibling tools like update_network_drive, delete_network_drive, or list_network_drives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by instructing the user to first retrieve available tariffs via list_network_drive_presets. This is a clear prerequisite, though it doesn't discuss exclusions or alternative creation paths since create is unique among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: The description states 'Удаляет проект' (deletes a project), which is a destructive operation, but the annotations declare destructiveHint: false. This is a direct contradiction. The description also mentions resources remain, but the core destructive nature conflicts with the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the primary action, followed by important caveats. Every sentence adds value: the deletion action, the default project restriction, and the resource transfer instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 1-parameter delete tool with no output schema, the description covers the essential context: what it deletes, a key restriction, and a prerequisite action. It adequately prepares an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description for the only parameter (project_id), achieving 100% schema coverage. The description adds no extra parameter context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Удаляет проект' (Deletes a project), identifying the specific verb and resource. It also distinguishes the tool from siblings by noting the default project restriction and mentioning transfer_project_resource as an alternative for resource handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (delete a project), when not to (default project cannot be deleted), and what to do instead (transfer resources via transfer_project_resource). This provides clear usage guidance and distinguishes from related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation contradiction: the description claims a read-only operation ('Returns a list'), but readOnlyHint=false indicates it may modify state. This is a serious inconsistency that undermines trust. No other behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then usage guidance. Every word is useful; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool with no output schema, the description fully covers the return fields and a concrete use case. It is sufficiently complete for the agent to understand what the tool does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so baseline 4 applies. The description does not need to explain parameters and does not add any conflicting information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns a list of available tariffs for S3 storage, naming specific fields (id, disk size, price, class, location). It clearly differentiates from sibling bucket management tools like get_bucket or list_buckets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use before create_bucket to get preset_id.' This tells the agent when to call it, but doesn't mention alternatives (e.g., get_allowed_presets) or when not to use, so it misses the full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation returns information, which is a read behavior, but it provides no extra context such as error handling, authentication requirements, or what 'detailed information' includes. Annotations do not add useful safety context (readOnlyHint is false, which is ambiguous for a get operation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and directly states the action. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool, the description is adequate but vague about the exact details returned. With no output schema, the agent cannot know what fields to expect, and the description does not enumerate them or mention potential error cases, leaving some uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with vpc_id clearly documented as required. The description adds minimal meaning by using 'по её ID' (by its ID), but does not elaborate on format, examples, or additional constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns detailed information about a VPC by its ID, using the specific verb 'Возвращает' and naming the resource. It distinguishes itself from the sibling get_vpcs (list all) by specifying a single VPC lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a VPC ID and need its details, which is clear context. However, it does not explicitly mention alternatives like get_vpcs for listing all VPCs or state when not to use this tool, though the purpose makes it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse and readOnlyHint is false, which could be misleading for a list operation. The description adds the clarifying behavior that the tool merely 'list(s)' DBs, implying a non-mutating read, and adds the detail that results include project_id binding. It does not disclose pagination, ordering, or response structure, but the core non-destructive nature is clear from the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the essential information ('Список всех managed-БД аккаунта'), then adds the relevant scoping detail about project binding. There is no redundant or filler content, and the structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (0 params, simple list) and no output schema, the description is somewhat complete but leaves ambiguity about whether 'managed-БД' includes both clusters and instances, and what fields are returned beyond project_id. It does not explicitly describe the output structure, which an agent would need to know for downstream processing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the description's mention of project_id (as a result binding, not an input) adds meaning beyond the empty schema. It correctly implies no input is needed, earning the baseline score of 4 for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 clear resource 'все managed-БД аккаунта' (all managed DBs of the account) with an explicit scoping detail 'с привязкой к проекту (project_id)'. This distinguishes it from the sibling tool list_project_databases, which presumably lists databases for a single project, making the account-wide scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies through 'все ... аккаунта' that this is the account-wide listing tool, contrasting with project-scoped siblings like list_project_databases. However, it does not explicitly state when to prefer this tool or mention alternatives, exclusions, or project-specific filtering options, leaving the usage context only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=false and idempotentHint=false, but the description describes a read-only operation ('returns a list'), which is a direct contradiction. This inconsistency undermines the agent's ability to infer the tool's side effects. The description itself does disclose the return behavior, but the annotation conflict is a serious flaw.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, focused sentences with no redundant information. It front-loads the primary purpose and then gives a concrete usage hint, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter list operation, the description fully covers the purpose, the return type, and the intended usage pattern. Given the lack of parameters and output schema, there is no critical missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so the description is not required to explain parameters. The description adds value by mentioning preset_id as an output concept, implying what the agent will receive, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of available presets for balancers, using the verb 'returns' and specifying the resource type. It distinguishes from sibling tools like list_balancers or list_dedicated_server_presets by naming the exact domain (balancer presets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool before create_balancer to select a preset_id, providing clear usage context. It does not mention when not to use it or alternatives, but for this resource-specific list tool, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes a read-only list operation, but annotations declare readOnlyHint=false, creating a direct contradiction. According to rules, this must be scored 1 and flagged as an annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each serving a clear purpose: the first defines the result set, the second gives a usage directive. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides all essential information: what it returns (with field list) and when to use it. It is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter information. The baseline for 0 params is 4, and the description additionally clarifies the output fields, so it adds value without needing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Возвращает список всех реестров контейнеров' (returns a list of all container registries) and enumerates the returned fields, making it clear this is a list operation. It distinguishes itself from sibling tools like list_container_registry_repositories and list_container_registry_presets by focusing on the top-level registry objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence instructs to use it before registry operations to obtain the registry ID, giving clear when-to-use guidance. However, it doesn't explicitly mention alternatives or exclusions, so not a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint is false, but the description clearly indicates a read-only operation ('Возвращает список'). This is a direct contradiction between the annotation and description, so the transparency score is 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that immediately state the action and the useful return fields. No word is wasted, and it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool, the description provides sufficient detail about the return value (code, ISO, availability zones) and the use case. No output schema exists, so the description carries the burden, and it does so effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so there is nothing for the description to explain. According to the rubric, a 0-param tool gets a baseline of 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Возвращает список') and the resource ('доступных локаций и зон доступности'), and lists the specific fields returned. It also mentions its purpose in VPS creation, distinguishing it from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Нужен для выбора location/availability_zone при создании VPS.' It provides clear context but does not mention when not to use it or alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool 'returns a list' (read operation), but the annotation readOnlyHint=false implies the operation may not be read-only. This is a direct contradiction. No other behavioral details like permissions or side effects are disclosed, but the contradiction mandates a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the essential purpose and followed by actionable guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately conveys the return fields (ID, name, os_ids, requirements) and the use case (selecting software_id during VPS creation). This is sufficient for an agent to understand the tool's role and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no need for parameter explanation. The description adds context about what the output contains, effectively compensating for the lack of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning a list of marketplace software available for VPS installation, with specific fields (ID, name, os_ids, requirements). It distinguishes itself from sibling list tools like list_server_os and list_server_presets by scoping to marketplace software.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit usage directive: 'Используй, чтобы выбрать software_id' (Use to select software_id). This indicates when to use the tool, though it does not mention alternatives or exclusions. The context is clearly for VPS creation setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Возвращает список' (returns a list), clearly indicating a read-only operation. However, annotations set readOnlyHint to false, which suggests the tool may modify state. This is a direct contradiction between the description and annotations, so the score is 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the exact purpose (list TLDs with prices), and the second provides a clear usage directive. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list operation with no output schema, the description covers the essential context: what is returned, what information is included, and when to use it. It is fully adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and the schema is empty, so schema coverage is trivially 100%. With no parameters to document, the description does not need to add parameter information, and the baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Возвращает список' (returns a list) and identifies the resource as 'всех доступных доменных зон' (all available domain zones), including registration and renewal prices. This clearly distinguishes it from sibling get_tld, which returns a single TLD.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Используй перед созданием заявки на регистрацию' (Use before creating a registration request). It does not mention alternatives or exclusions, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose mutation (readOnlyHint=false) and non-destructive nature (destructiveHint=false). The description adds the key behavioral trait of partial update ('only fields you need change'), but it does not disclose potential side effects (e.g., implications of changing status, whether other fields are reset) or return value. With annotations covering safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It front-loads the action ('Обновляет параметры AI-агента'), lists the key fields concisely, and ends with a practical instruction. Every part earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with 14 parameters, the description covers the essential purpose and the partial-update pattern, but it does not mention the return value, validation rules, or potential consequences of updates (e.g., whether setting status to 'suspended' has side effects). Given annotations, the missing response format leaves moderate gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 14 parameters with individual descriptions (100% coverage), so the baseline is 3. The description repeats some parameter names and adds 'Pass only fields that need change', which reinforces that all parameters except agent_id are optional, but it does not provide deeper semantic detail beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Обновляет параметры AI-агента' (Updates AI agent parameters), specifying the resource and action. It further enumerates the exact fields that can be updated (имя, описание, статус, access_type, пакет токенов, system prompt и настройки модели), distinguishing it from sibling tools like create_ai_agent, delete_ai_agent, and get_ai_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Передавай только поля, которые нужно изменить' (Pass only fields that need to be changed) provides clear guidance on how to use the tool for partial updates. However, it does not explicitly mention when to use this over alternatives or any exclusions, though the sibling tool names make the distinction obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the description adds the key behavioral detail that fields overwrite current values ('эти поля перезаписывают текущие значения правила'). However, it does not disclose permissions, error conditions, or effects on unspecified fields, leaving some ambiguity about the update semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main purpose and explicitly lists the relevant fields. No redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description explains the update behavior but does not mention the required identifiers (group_id, rule_id) or what the response returns. This is a moderate gap, especially since the tool requires four mandatory parameters, two of which are missing from the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are documented. The description reiterates the required optionality of direction, protocol, port, cidr, and description, but adds minimal semantic value beyond the overwrite behavior. It omits the required identification parameters group_id and rule_id, which are present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Полностью обновляет правило firewall' (Fully updates the firewall rule). It specifies that the provided fields overwrite current values, distinguishing this update operation from create/delete/list siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this is for updating an existing rule, but it does not explicitly mention alternatives like create_firewall_rule or delete_firewall_rule. The context implies usage for modifications, which is sufficient for an agent to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the binding operation is understood as a mutation but not destructive. The description adds the context that the server is "existing," implying no creation. It does not disclose additional behavior like whether it replaces an existing project association or what happens if the server is already in a project, but given the annotations, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, focused sentence that immediately states the action and object. There is no unnecessary information, and it is front-loaded with the core verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple binding operation with two well-documented parameters and no output schema, the description is sufficient. It does not explain the full implications of binding (e.g., resource listing changes), but the core behavior is clear. The sibling tool list provides additional context for disambiguation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both required parameters (project_id and resource_id). The description does not add any extra semantic detail beyond what the schema 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb "Привязывает" (binds) with a clear resource (existing dedicated server) and target (project), clearly distinguishing it from sibling tools like add_server_to_project or add_database_to_project. The title also says "Добавление выделенного сервера в проект" (Adding dedicated server to project), reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for attaching an existing dedicated server to a project, which provides clear context. However, it does not explicitly state exclusions or mention alternative tools for other resource types, leaving some ambiguity if the agent is unsure about dedicated vs. regular servers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context that the keys are existing and that multiple keys can be added in one call, which is useful beyond the annotations. Annotations already indicate it is not read-only (readOnlyHint: false) and not destructive, so the description doesn't need to restate those. However, it does not disclose potential side effects or prerequisites like server state, but this is a simple tool and annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action, and includes valuable lookup hints without any redundancy or filler. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with no output schema, the description provides enough context: it explains what the tool does, how to get the required IDs, and that it operates on existing keys. It could optionally mention what happens if a key is already attached, but the tool is simple enough that the current description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for both parameters, including that ssh_key_ids is an array of IDs and both are required. The description adds little beyond reinforcing the 'array of IDs' concept and the 'existing' aspect, which is a minor semantic addition. Since schema coverage is 100%, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool adds one or more existing SSH keys to a server by their IDs. It names the specific resource (server, SSH keys) and the action, and the reference to list_ssh_keys and list_servers distinguishes how to obtain prerequisites, making it distinct from related tools like create_ssh_key or remove_ssh_key_from_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent how to obtain the required IDs (via list_ssh_keys and list_servers), which is essential for correct usage. It implies the keys must already exist, but it does not explicitly exclude cases like when to use create_ssh_key instead, so it lacks an explicit when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=false and readOnlyHint=false. The description adds that it returns a list of created mailboxes and an array of errors, which hints at partial-failure behavior. However, it does not disclose rate limits, maximum batch size, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action ('Создаёт сразу несколько...') followed by return-value behavior. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool without an output schema, the description gives essential return information (created list and errors) and API version. It lacks edge-case details like partial-failure semantics or size limits, but given the rich schema and sibling differentiation, it is almost complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with detailed descriptions, including required 'domain' and 'mailboxes' array with nested properties. The description adds no extra parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates multiple mailboxes at once on a single domain. It specifies 'API v2', distinguishing it from sibling tools like batch_create_mailboxes_v1 and create_mailbox. The verb 'Создаёт' and resource are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch creation on one domain, but it does not explicitly mention alternatives or when not to use it. It lacks a direct comparison with create_mailbox or batch_create_mailboxes_v1.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical behavioral trait: the token value is returned only once and must be saved. This goes beyond the annotations (readOnlyHint=false, destructiveHint=false) and adds necessary security-related context. However, it does not elaborate on side effects or authorization requirements, so it stops short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and followed by the key warning. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with four well-documented parameters and no output schema, the description provides the essential warning about the one-time token return. It does not describe the full response structure, but given the lack of an output schema and the simplicity of the tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters individually described. The tool description adds no additional parameter-level detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Создает новый API-токен' (Creates a new API token). It uses a specific verb and resource, and the sibling tools (delete_api_key, list_api_keys, edit_api_key, refresh_api_key) make the creation purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating tokens but provides no explicit guidance on when to choose this over alternatives like edit_api_key or refresh_api_key. It does offer a caveat about saving the token value, which is useful context, but lacks direct usage versus alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds the list of mandatory parameters and conditional settings (private network, SSL), but does not disclose additional behavioral traits such as async behavior, potential errors, or what the response contains. It does not contradict the annotations, but relies on them for safety profile while contributing moderate extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. It lists required parameters compactly in a single sentence, followed by two short conditional clauses. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (28 parameters, no output schema), the description covers the essential context: purpose, required fields, and key conditional parameters. It points to list_balancer_presets for preset_id and mentions private network and SSL handling. It does not explain all optional parameters, but the schema fully covers them. The description is sufficiently complete for an agent to select and invoke the tool correctly, though it could mention that custom SSL certificates require additional data fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters already have descriptions. The description explicitly lists required fields and adds two conditional hints (network_id for private network, certificate_type for SSL), but these are also partly present in the schema (e.g., preset_id schema already mentions list_balancer_presets). The description adds minimal semantic value beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Создаёт новый балансировщик нагрузки' (Creates a new load balancer), providing a specific verb and resource. This distinguishes it from sibling tools like update_balancer, delete_balancer, and get_balancer. The title 'Создание балансировщика' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: it lists required fields and gives conditional guidance ('Для приватной сети задай network_id', 'Для SSL — certificate_type'). It also directs the user to list_balancer_presets for obtaining preset_id, which is a useful cross-tool reference. However, it does not explicitly mention when not to use this tool or alternatives like update_balancer, hence not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false). The description confirms creation and points out required/optional fields but does not add significant behavioral details such as billing implications, creation duration, or return value. The prerequisite for preset_id is useful but also present in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: one sentence for purpose, one for required fields, and one for optional fields and prerequisite. Every sentence conveys necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 11 parameters and no output schema, the description covers core usage: purpose, required fields, major optional fields, and the critical prerequisite. Minor omissions (e.g., comment, bandwidth_id) are covered by the schema, but the description is sufficiently complete for practical invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description provides a high-level summary of optional fields (OS, panel, additional services) but largely restates schema info. It adds value by grouping fields into required and optional, but does not compensate beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'Создаёт новый выделенный (dedicated) физический сервер' (creates a new dedicated physical server). It distinguishes from regular server creation by specifying 'dedicated physical' and is clearly differentiated from sibling tools like create_server and create_timeweb_app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite: 'Перед вызовом получи preset_id через list_dedicated_server_presets' (obtain preset_id beforehand). Clearly lists required fields and indicates optional categories. Does not explicitly state when not to use, but context makes it clear this tool is for dedicated servers only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it creates a 'request' (заявку), indicating indirect operation rather than immediate action, which is useful beyond the annotations. It does not elaborate on side effects, asynchronous behavior, or return formats, but the annotations already signal it is a non-read-only mutation. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and immediately followed by key conditional requirements. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and 3 action types, the description gives a sufficient overview and highlights the most important conditional fields. It does not explain the response structure (no output schema), but the schema covers parameter details, making the description adequately complete for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description adds a concise mapping of when person_id and auth_code are required, reinforcing but not significantly exceeding schema semantics. This matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a request for domain operations (register, prolong, transfer), using a specific verb and resource. It distinguishes itself from related tools like add_domain or create_dns_record by focusing on domain operation requests and enumerating the action types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for usage by specifying that registration requires person_id and transfer requires auth_code, which guides parameter selection. However, it does not explicitly mention alternatives or when not to use this tool, though the action-specific requirements effectively imply usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) with no destructive behavior. The description adds the API version and optional features, but does not disclose potential side effects, idempotency issues, or auth requirements beyond what the annotations imply. It is consistent with annotations but adds limited extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, each providing distinct valuable information: the core action and key optional features. No filler or repetition, with the most important detail (creates mailbox) front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters and rich schema, the description is adequate for a straightforward creation tool. It does not describe response/return values, but no output schema exists, and the description conveys the essential purpose and capabilities. Slightly more detail on potential errors or uniqueness constraints could improve completeness, but it's not critically lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of parameters, including detailed explanations for mailbox and password. The description only mentions owner full name and spam filter settings, which echoes the schema but does not add new semantic meaning. It meets the baseline for complete schema coverage without further clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Создаёт новый почтовый ящик') and specifies the resource ('на указанном домене'), with a direct mention of API v2 to distinguish from v1 siblings. It also highlights key configurable aspects (owner full name, spam filter), 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is for creating a single mailbox on a specified domain. It does not explicitly mention alternatives like batch_create_mailboxes or create_mailbox_v1, but the API v2 reference implies it is the current single-creation tool. There are no exclusions or when-not-to-use guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive behavior. The description adds the XOR constraints, but these are already present in the schema's parameter descriptions. No additional behavioral details such as rate limits, idempotency, or side effects are disclosed beyond what annotations and schema provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action ('Creates a new cloud server'), followed by a compact enumeration of modes and supported parameters. Every phrase provides information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 19-parameter tool with 100% schema coverage and no output schema, the description gives a concise overview and emphasizes the key constraints (mode choices, OS choice). It omits some optional parameters (comment, software_id), but those are documented in the schema. The lack of return-value information is acceptable given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents each parameter. The description summarizes groups (e.g., cpu/ram/disk for configurator mode) and repeats the XOR constraints already in the schema. It adds no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Creates a new cloud server', a specific verb+resource. It distinguishes from sibling tools like create_dedicated_server and create_k8s_cluster by explicitly mentioning 'cloud' and detailing creation modes (preset/configurator) and OS selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance for parameter selection: 'preset_id XOR configurator_id' and 'os_id XOR image_id', clarifying when to use which parameters. It does not explicitly name alternative tools for exclusion, but the context of creating a new cloud server is clear from the description and name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description adds extra context about canceling a copy process. However, it does not disclose side effects or failure behavior beyond that. The description is consistent with annotations, adding moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main action and usage context, with no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete/cancel tool, the description adequately explains the purpose and usage. It doesn't mention preconditions or error handling, but given the tool's simplicity and the completeness of the schema, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters have clear descriptions in the schema. The tool description adds no additional parameter information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Удаляет' (deletes) and a resource 'ссылку на скачивание образа' (image download link), clearly distinguishing it from related tools like delete_image or create_image_download. It also adds context about canceling the image copy process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit usage instruction: 'Используй для отмены процесса копирования образа во внешнее хранилище.' This tells the agent when to use the tool. It does not mention exclusions or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, making it clear this is a write operation. The description adds that it changes the name and/or flag, but it doesn't disclose additional behavioral aspects such as whether changes require special permissions, whether the token value is invalidated, or what the response looks like. With annotations handling the basic safety profile, the description adds minimal extra context, warranting a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 key details. It contains no fluff and conveys the essential information efficiently. It is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, well-documented schema, annotations present), the description is adequate. It does not explain return values, but for an edit operation, this is not critical. The description, combined with schema and annotations, provides enough context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already well-documented. The description's mention of 'имя и/или флаг' aligns with the name and is_able_to_delete parameters, and 'по его ID' clarifies the token_id role, but it doesn't add meaning beyond what the schema provides. Baseline for full coverage is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Изменяет имя и/или флаг is_able_to_delete API-токена по его ID' (changes the name and/or is_able_to_delete flag of an API token by its ID). This specifies the verb (change), resource (API token), the fields affected, and the identifier, distinguishing it from sibling tools like create_api_key, delete_api_key, or refresh_api_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool when you need to update the name or deletion permission flag of an existing API token. No explicit exclusions or alternatives are mentioned, but the description implicitly indicates that for creating or regenerating tokens, other sibling tools would be appropriate. Since there is no ambiguity about the primary use case, it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds the list of returned fields, which is useful, but it does not address the readOnlyHint=false annotation by explaining any potential side effects or clarifying why it might not be read-only. There is no explicit contradiction, but the description could be more transparent about behavior beyond retrieving data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and then lists the returned properties. There is no redundant or extraneous content; every element adds informational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get operation with no output schema, the description provides a sufficiently complete picture by listing the detailed return fields (name, type, status, class, location, hostname, access keys, disk usage, website settings). It does not cover error cases or authentication, but these are less critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (bucket_id) with 100% description coverage, clearly marked as required and defined as 'ID S3-хранилища' (S3 bucket ID). The main description also mentions 'по его ID' (by its ID), reinforcing the parameter's role. No additional meaning is added beyond the schema, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Возвращает детальную информацию об одном S3-хранилище по его ID' (Returns detailed information about one S3 bucket by its ID). It enumerates specific returned fields (name, type, status, class, location, hostname, access keys, disk usage, website settings), distinguishing it from listing or mutation tools like list_buckets or update_bucket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need detailed information about a single S3 bucket identified by its ID. It does not explicitly mention alternatives or when-not-to-use, but the singular focus and the 'by its ID' phrasing make the usage scenario evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful details about return fields and the conditional inclusion of the URL based on status. However, annotations do not mark it as read-only (readOnlyHint: false), and the description does not explicitly state whether the operation has side effects or requires special permissions. It provides some transparency beyond the annotations but not full disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('Возвращает детальную информацию') and lists specific fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description adequately covers what the tool returns. It does not mention error conditions or prerequisites, but the complexity is low and the parameter schema fills in the required IDs. The description is complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with descriptions ('ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID образа' and 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID ссылки на скачивание'), providing 100% coverage. The tool description does not add further semantics about the relationship between the IDs or how to obtain them, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns detailed information about a specific image download link, listing key fields (type, status, progress, URL). This distinguishes it from sibling tools like create_image_download, delete_image_download, and list_image_downloads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for retrieving details about a single download link. It does not explicitly mention alternatives or exclusions, but the purpose is specific enough that an agent would use it when needing per-link details rather than listing all downloads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false, annotations do not clearly signal safety, but the description explicitly says 'returns' and enumerates the metrics, providing useful behavioral context beyond the schema. It does not describe response format or units, but the list of returned metrics is helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and resource, followed by the list of returned metrics. No wasted words and easily parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description adequately covers the main return payload by listing the metric categories. It lacks specifics like units or response fields, but for a resources-getter, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with only one parameter (cluster_id) described as required and labeled 'ID кластера'. The description adds no additional semantics about the parameter beyond what the schema already says, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns aggregated Kubernetes cluster resource metrics, listing specific categories (nodes, CPU, memory, pods with requested/allocatable/capacity/used). This distinguishes it from sibling get_k8s_cluster (likely cluster metadata) and get_k8s_node_group (per-node resources).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need cluster resource summary, but it does not explicitly say when to prefer this over alternatives like get_k8s_cluster or list_k8s_cluster_nodes. It lacks exclusions or comparisons, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The warning that the content contains secrets and should not be published adds valuable sensitivity context beyond the annotations. However, it does not disclose other behaviors like required permissions or potential errors, which would improve transparency further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the action ('Возвращает содержимое') and resource, with no wasted words. The security note is placed appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description covers the core purpose, the return value, and adds a security warning. It is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully covers the only parameter cluster_id with a clear description ('ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID кластера'), and the tool description does not need to add more. Baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the contents of the kubeconfig file for connecting kubectl to a cluster. This specific verb+resource combination distinguishes it from sibling tools like get_k8s_cluster or list_k8s_clusters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for kubectl connection setup but does not mention when not to use it or provide alternatives. It gives context but no explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a write operation. The description adds the requirement for YAML config and config_type, but does not disclose potential behaviors like failure if the addon already exists, if installation is synchronous, or permissions needed. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first states the action, the second lists requirements and points to the catalog. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, required inputs, and a way to find valid values. There is no output schema, but the action is straightforward. Missing details like response format or idempotency notes are minor given annotations and tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The description restates required parameters and mentions the config_type enum, adding a reference to the catalog for valid type/version values, which is useful. It does not clarify whether yaml_config is always required or just for custom, but the schema marks it required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Installs an addon into a cluster', with a specific verb (installs) and resource (addon). It distinguishes from siblings like update_k8s_addon, uninstall_k8s_addon, and list_k8s_addons by conveying the install operation specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by listing required inputs (type, version, config_type, YAML) and explicitly points to list_k8s_addon_configs as a catalog for available addons. It does not mention when not to use it or name alternatives, but the sibling list and action verb imply distinctions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations by describing the consequence of linking ('правила группы начинают действовать на ресурс') and the current resource-type restriction. It does not contradict the readOnlyHint, idempotentHint, or destructiveHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief, information-dense sentences. Every word earns its place, with no filler or repetition. The structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, full schema coverage, annotations provided), the description covers the core purpose and effect. It does not elaborate on edge cases like repeated linking, but the idempotentHint=false annotation hints at that, making this nearly complete for a simple mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all three parameters are already documented. The description's mention of 'сейчас только сервер' is redundant with the resource_type enum, and no additional parameter-specific meaning is added beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Привязывает ресурс') and the target ('к группе правил firewall'), and it includes a scope constraint ('сейчас только сервер'). It distinguishes itself from sibling tools like unlink_firewall_resource by describing the linking direction and the effect of rules applying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to attach a resource to a firewall group) and notes the server-only limitation, but it does not explicitly mention alternatives or give 'when not to use' guidance. It lacks reference to the sibling unlink tool or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by disclosing the exact return fields (ID, direction, protocol, port, CIDR, description), which is especially useful given no output schema is provided. It does not contradict the annotations, and the readOnlyHint=false is not a direct contradiction since the description doesn't claim side effects. It stops short of mentioning pagination, auth, or error behavior, but the field list is substantive for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose and enumerates the returned fields with no wasted words. It is optimally concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 required parameter and no output schema, the description covers the essential return format and parameter context. It omits potential pagination or error details, but the low complexity and strong sibling context make it sufficiently complete. A 4 reflects that it goes beyond a minimal description but isn't exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the property description already clearly explains 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID группы правил firewall'. The description repeats the notion of 'указанной группе' but adds no new syntax or format details. Baseline 3 is appropriate since the schema carries the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Возвращает список правил firewall') and the resource ('в указанной группе'), distinguishing it from sibling tools like list_firewall_groups (which lists groups) or get_firewall_rule (which retrieves a single rule). The verb is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by requiring a group_id, but it does not explicitly contrast with alternatives or state when-not-to-use. For instance, it doesn't mention that list_firewall_groups_by_resource might be relevant for other contexts. This is intermediate between clear context and only implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the returned data structure (ID, type, version, status), which is useful since no output schema exists. However, annotations include readOnlyHint=false and idempotentHint=false, which might imply side effects; the description does not explicitly state whether the operation is read-only or has any side effects. No direct contradiction, but the safety profile is not fully clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately starts with the action verb and states the resource and return fields. Every word earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description is adequately complete: it states the purpose, scope, and return fields. Since no output schema exists, the mention of returned fields helps fill the gap. It does not discuss pagination or error cases, but those are less critical for this simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter cluster_id with the description 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID кластера'. The tool description adds only the phrase 'в кластере', which does not meaningfully enhance the schema-provided meaning. Baseline of 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Возвращает список') with a clear resource ('установленных в кластере дополнений') and lists the returned fields (ID, type, version, status). This fully distinguishes the tool from siblings like list_k8s_addon_configs, install_k8s_addon, and update_k8s_addon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use: to retrieve the list of installed cluster add-ons. It does not explicitly mention alternatives or when not to use it, but the context is unambiguous and needs no exclusions for a simple list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=false and readOnlyHint=false. The description adds useful return-field information but does not explicitly state whether the operation has any side effects. Given that readOnlyHint is false, the description could have clarified that this is a safe list operation, but it does not directly contradict the annotations. The lack of explicit side-effect disclosure is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences. The first sentence immediately states the action and lists the return fields in a compact, informative manner. The second sentence provides practical usage advice. No unnecessary words or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with two optional, well-documented parameters and no output schema, the description does a good job by enumerating the return fields and providing a usage tip. It could have mentioned pagination behavior (beyond the parameter descriptions) or error scenarios, but the essentials for an agent to invoke it are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (limit, offset) have descriptions in the schema, providing 100% coverage. The description does not add any parameter-specific guidance beyond the schema. This is the baseline case where the schema already documents semantics, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'returns a list of all Kubernetes clusters of the account' with a specific set of fields (ID, name, status, k8s version, network driver, availability zone, CPU/RAM/Disk). It distinguishes itself from project-scoped cluster lists by specifying 'account', and from more specific cluster tools like 'get_k8s_cluster' by its plural list scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool 'before operations on a cluster to get its ID', which tells the agent when it is appropriate to call. It does not explicitly mention alternatives or exclusions (e.g., 'for a single cluster use get_k8s_cluster'), but the context provided is sufficient for a list operation with clear scope (account-wide).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context about the return content (address, spam filter statuses, webmail, forwarding, comment) and the API version, but does not explicitly clarify whether the operation is read-only. Annotations provide readOnlyHint=false, which is ambiguous; the description's 'returns' wording implies a safe read, but it could be more explicit about side effects or permissions. This is a moderate transparency contribution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first front-loads the action and scope, and the second lists the returned fields. There is no redundant filler or vague wording. Every word contributes meaning, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple account-wide list operation with no output schema, the description sufficiently covers the return values and scope. It clearly states what is returned and includes a summary of the fields. It lacks details about pagination or response structure, but given the tool's simplicity and the absence of parameters, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms no inputs. The description reinforces this by stating it returns all mailboxes without any filtering, which is exactly what an agent needs to know about parameter semantics. This meets the baseline for no-parameter tools, and the description adds no confusing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Возвращает' (returns) and clearly identifies the resource as 'все почтовые ящики аккаунта' (all mailboxes of the account). It also includes 'API v2', which distinguishes it from list_mailboxes_v1, and the account-wide scope differentiates it from list_mailboxes_by_domain. This makes the tool's purpose highly specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool—when all account mailboxes are needed—but it does not explicitly mention alternatives such as list_mailboxes_by_domain for domain-filtered queries, nor does it provide any exclusions or when-not-to-use guidance. The usage context is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Возвращает' (returns), implying a read-only operation, but the annotation readOnlyHint is false. This is a direct contradiction. The description also fails to disclose any other behavioral traits such as pagination or rate limits, but the contradiction alone mandates a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the purpose, and the second gives usage guidance. It is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is largely complete: it identifies what is returned, the format, and the alternative. It even names the specific fields included, compensating for the lack of an output schema. However, the contradiction with readOnlyHint creates uncertainty about side effects, slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema already provides complete coverage (100%). The description adds value by mentioning the response fields (auto_reply/spam_filter/forwarding), which helps the agent understand what the v1 format includes. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all account mailboxes in API v1 format with full detail on auto_reply/spam_filter/forwarding. It also distinguishes from the sibling list_mailboxes by explicitly naming the v2 alternative, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to prefer list_mailboxes (v2) and notes that this v1 version is only needed when v1 fields are required. This provides clear when-to-use guidance and names the alternative, going beyond a vague hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('returns all available tariffs'), but the annotation readOnlyHint=false indicates the tool may not be read-only. This is an annotation contradiction. No other behavioral context is provided, so the score is 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with clear structure: what it returns, when to use, and explicit exclusion of application presets. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description is fairly complete: it names the returned fields, provides usage context, and disambiguates from a related tool. It lacks note about pagination or authorization, but those are not apparent from the schema; the annotation contradiction slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by enumerating the output fields (ID, price, location, CPU, RAM, disk, disk type, bandwidth) which is helpful despite the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'returns all available tariffs (presets) for VPS servers' and lists specific attributes (ID, price, location, CPU, RAM, disk, disk type, bandwidth). It also explicitly distinguishes itself from application presets by naming the alternative tool get_allowed_presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use before creating a VPS to select preset_id' and clarifies 'NOT presets for applications — for those there is get_allowed_presets', providing both when-to-use and when-not-to-use guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a critical behavioral detail not in annotations: the new token value is returned only once. It does not disclose whether the old token becomes invalid, but the provided one-time visibility is valuable and consistent 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and the key return behavior. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters, the description adequately covers purpose and the one-time return constraint. However, it omits whether the old token is invalidated and any usage restrictions, leaving minor gaps for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the baseline is 3. The description does not add extra meaning for parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (reissue) on a specific resource (API token) and notes the one-time return of the new value. This distinguishes it from siblings like create_api_key, edit_api_key, and delete_api_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for refreshing an existing token, but it gives no explicit when-to-use guidance or comparison with alternatives such as edit_api_key. There is no mention of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false. The description adds behavioral context by clarifying that IPs are 'снимает их из распределения трафика' (removed from traffic distribution), which goes beyond a simple 'remove' and suggests a non-destructive, reversible action. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly conveys purpose and behavior without unnecessary filler. It is well-structured and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only 2 required parameters and no output schema, the description sufficiently explains the tool's purpose and effect. It could optionally mention expected response or error conditions, but those are not required given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (ips and balancer_id) with 100% coverage. The description does not add any additional parameter-level meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Удаляет' (removes) and the resource 'backend IP-адреса у балансировщика' (backend IP addresses from the balancer), distinguishing it from sibling add_balancer_ips. The parenthetical 'снимает их из распределения трафика' further clarifies the exact purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (removing backend IPs from traffic distribution) but does not explicitly state when to use this tool versus alternatives like add_balancer_ips or list_balancer_ips. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds the important behavioral detail that the API expects a complete rule description, implying a full overwrite semantic. This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the clear purpose and immediately followed by the most important usage constraint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple update semantics, the description covers the core behavior. However, the ambiguous 'except id' statement creates a completeness gap, and there is no information about error cases or prerequisites. The full-overwrite note is present, but the id confusion lowers the overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. However, the description states 'all fields except id are required', which is ambiguous and contradicts the schema where all 6 parameters including rule_id and balancer_id are required. This misleading guidance could cause the agent to omit a required field, making the description worse than no parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'updates' and the resource 'balancer routing rule', which distinguishes it from siblings like create_balancer_rule and delete_balancer_rule. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides key usage guidance: all fields except id are required and the API expects a full rule description. This tells the agent to send a complete replacement, not a partial update. It does not explicitly name alternatives but the update verb makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the tool as non-read-only and non-destructive, and the description consistently indicates a mutation operation. It adds the specific fields being changed (comment/PTR) but does not reveal additional behavioral traits such as DNS propagation delays for PTR updates, prerequisite checks, or error behavior. The description is consistent with annotations, so 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, concise sentence that is front-loaded with the verb 'Изменяет' (changes) and directly states the action and object. There is no redundant or irrelevant information; every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with no output schema, the description provides sufficient context: it specifies the resource, the fields to update, and the requirement of an ID. Combined with the fully-described input schema and annotations, an agent can invoke it correctly. It lacks a mention of return values, but that is not critical for a straightforward update.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions already cover all three parameters (floating_ip_id, ptr, comment) with 100% coverage. The tool description mentions 'comment and/or PTR' but adds no new semantic detail beyond what the schema already provides, such as formats or validation rules. The baseline of 3 is appropriate given the full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Изменяет' - changes), the target resource ('плавающего IP' - floating IP), and the fields affected ('комментарий и/или PTR-запись'). This distinguishes it from sibling tools like create_floating_ip, delete_floating_ip, bind_floating_ip, and unbind_floating_ip, and it is not a mere restatement of the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear that this tool should be used when updating the comment or PTR record of a floating IP, identified by its ID. While it does not explicitly mention when not to use it or name alternatives, the specificity of the action and fields provides clear context for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so 'changes' is consistent. The description adds specificity that it targets a server IP's PTR, but does not disclose side effects such as overwriting existing records, DNS propagation delays, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the action and target, with no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple, single-purpose mutator with full schema coverage and no output schema. The description adequately covers its purpose and context, though it could briefly mention expected effects or response, but this is not critical given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have full descriptions in the schema (100% coverage), so the description does not need to add parameter details. It provides no additional semantics beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Меняет' (changes) with a clear resource 'PTR-запись (обратное DNS)' for a specific server IP, distinguishing it from general DNS record tools and IP add/delete tools. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: changing a PTR record for a server IP. It does not explicitly mention when not to use it or alternatives, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not a read-only or destructive operation. The description adds that only name and description are affected, but does not disclose any further behavioral consequences. Given the annotation coverage, the description provides adequate but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately conveys the action and target. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update operation with complete parameter schema and annotations, the description is sufficient. It states the purpose and the modifiable fields, and the schema handles parameter details. There is no output schema, so return value documentation is not expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, so the schema already documents each field. The description mentions name and description but adds no syntax or format details beyond what the schema provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates the name and/or description of a VPC by its ID. This is a specific action on a defined resource, distinguishing it from creation, deletion, or query operations. The Russian text explicitly mentions the resource (VPC) and the action (change).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's purpose but does not explicitly state when to use it relative to alternatives. It names the exact fields that can be modified, which provides context, but lacks guidance on when not to use it (e.g., for deleting or creating VPCs). Since the function name and description are self-explanatory, a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnly=false) and non-idempotent behavior. The description adds valuable context: 'Процесс асинхронный' (asynchronous process) and the auth requirement for cloud types. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the primary purpose and packs in essential details about type behavior and async execution without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core action and parameter semantics are well covered, but there is no output schema and the description does not mention what the response contains or how to track the async process (e.g., using get_image_download). This leaves a notable gap for a 7-parameter, conditionally auth-dependent tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description enriches the 'type' parameter by explaining what each enum value does (direct link vs cloud copy) and clarifies the conditional requirement for access_token. This adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a download link for an image ('Создаёт ссылку на скачивание образа'). It further distinguishes between direct link (timeweb) and cloud copy (google_drive/yandex), setting it apart from create_image or get_image_download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers usage context for the type parameter (direct link vs cloud copy) and notes the access_token requirement for cloud types. However, it does not explicitly mention when to use this tool over sibling tools like get_image_download for status polling, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: The description describes a listing/read operation, which should be read-only and idempotent, yet the annotations declare 'readOnlyHint: false' and 'idempotentHint: false'. This directly contradicts the described behavior. No additional behavioral context is provided to resolve this inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, consisting of two tightly packed clauses with no filler. It front-loads the core action and immediately provides the differentiating detail, earning the highest score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a zero-parameter, simple listing tool with no output schema, the description is complete for the agent's needs. It states what the tool returns, when to use it, and how it differs from a sibling. No additional context is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (vacuously). No parameter details are needed, and the description adds no parameter meaning. Per the rubric's zero-parameter baseline, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource combination: it lists all VPS of the account with project association. It explicitly distinguishes itself from the sibling 'list_servers' by noting it includes the 'project_id' field, making the purpose unambiguous and uniquely identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the alternative tool 'list_servers' and states the key differentiator: this tool returns 'project_id' for each server. This directly tells the agent when to use this tool over the sibling, which is exactly what usage guidelines should do.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that this is an asynchronous operation requiring progress monitoring, which is not present in the annotations. It also clarifies that it initiates a transfer (non-read-only) and involves external credentials, adding behavioral context. There is no contradiction with the provided annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and parameters. It is concise, with no redundant or filler content. The instruction to monitor via get_bucket_transfer_status is efficiently integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and monitoring, but it omits details about the tool's response (e.g., a transfer ID) which would be necessary to use the suggested monitoring tool effectively. Since there is no output schema, the description should have hinted at the return value. However, given the moderate complexity, it is still reasonably usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all 7 parameters with clear 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ' (required field) annotations and specific roles. The tool description only lists a few parameter names without adding new meaning beyond what the schema already provides. As the schema coverage is 100%, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific action: launching a transfer of an S3 storage from a third-party provider to Timeweb Cloud. It explicitly names the required input parameters and the destination bucket name, making it distinct from sibling tools like create_bucket. The mention of a dedicated monitoring tool further clarifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit follow-up guidance: monitor progress via get_bucket_transfer_status, which tells the agent what to do after invocation. It indirectly implies this is for third-party migrations but does not explicitly state when to avoid using it or name alternative tools beyond the monitoring one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that each subdomain gets a status (success, empty_cname, duplicate, failed), which is beyond what annotations provide. It also implies the tool performs a write operation (adding subdomains) and does not contradict annotations. It doesn't mention side effects like idempotency or potential partial failures, but the status list gives useful behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first states the core action, the second lists return statuses and gives a clear next step. No redundant information, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers the return statuses and follow-up action. It could be slightly more complete by specifying the exact response structure or mentioning possible error conditions, but the information provided is sufficient for an agent to understand the tool's behavior in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters (bucket_id and subdomains) with detailed examples, achieving 100% coverage. The description adds no additional parameter semantics beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Добавляет' - adds) and resource (subdomains to S3 bucket), distinguishing it from siblings like add_bucket_subdomain_certificate or delete_bucket_subdomains. It also lists expected return statuses, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context (adding subdomains to S3) and explicitly mentions the follow-up action of issuing SSL via add_bucket_subdomain_certificate, which guides the agent on next steps. However, it doesn't explicitly state when not to use this tool or contrast with alternatives like delete_bucket_subdomains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnly=false and destructive=false. The description adds the behavioral nuance that the tool does not register a new domain, only adds existing ones. However, it does not describe side effects like whether existing DNS records are imported, whether adding an already-managed domain fails, or any authorization requirements. Some additional behavioral context is provided but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the action and purpose, the second provides an exclusion and points to the alternative. It is front-loaded, concise, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description covers the core purpose, the prerequisite (domain already registered elsewhere), and the key distinction from create_domain_request. It lacks explicit mention of response behavior or post-conditions, but these are not critical for this simple mutation tool given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, and the parameter 'fqdn' is well described as a full domain name already registered elsewhere. The tool description reinforces this by mentioning 'already registered in another place,' but does not add additional parameter-level detail 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'adds an already registered elsewhere domain to the Timeweb Cloud account for DNS and name-server management.' It clearly distinguishes from registration by explicitly saying 'Does not perform registration,' which differentiates it from the sibling create_domain_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when not to use the tool: 'Does not perform registration — for registration use create_domain_request.' This names the alternative and provides a clear conditional. It also implies use when the domain is already registered elsewhere, which is helpful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds little beyond mentioning 'existing VPS server', which implies the operation is non-destructive. It does not disclose any additional behavioral traits such as error conditions or side effects. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and immediately communicates the core purpose and the key alternative. There is no redundant information or filler. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description is adequate. It explains the action and provides a pointer to the related transfer tool. However, it does not mention potential prerequisites or behavior if the server is already attached to another project, which could be relevant. With good annotations, this is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both required parameters ('project_id' and 'resource_id'), covering 100% of the parameters. The description does not add further meaning beyond the schema; it only repeats the concept of attaching a server to a project. Thus, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Привязывает существующий VPS-сервер к проекту' (Attaches an existing VPS server to a project). It uses a specific verb ('привязывает') and resource ('VPS-сервер'), and distinguishes itself from the sibling 'transfer_project_resource' by explicitly noting that the latter is for transferring between projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance by stating that for transferring a server between projects, one should use 'transfer_project_resource' instead. This clearly indicates when to use this tool (attaching an existing server to a project) and when to use an alternative (transfer).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is not read-only and not destructive, so the bar for additional behavioral disclosure is lowered. The description adds that this is the v1 API variant and recommends v2, which is useful context but does not disclose potential partial failures, error handling, or other behavioral nuances. With annotations present, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the core action front-loaded. It avoids redundancy and gets straight to the point, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has full schema coverage, annotations indicating a non-read-only, non-destructive write operation, and no output schema. The description is sufficient for a straightforward batch create action, but it could have included notes about partial failure behavior or response format. Nonetheless, given the context, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning every parameter (domain, mailboxes, login, password, comment, owner_full_name) already has a descriptive label in the schema. The description does not add any parameter-level meaning beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Создаёт несколько ящиков на домене' (creates multiple mailboxes on a domain) via API v1. It also differentiates itself from the v2 sibling by explicitly naming the preferred alternative. This meets the criterion of specific verb+resource with sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs users to 'Предпочитай batch_create_mailboxes (v2)' (prefer batch_create_mailboxes v2), providing a clear alternative and implying this tool is a fallback/legacy version. This gives direct guidance on when to use an alternative, satisfying the when/when-not/alternatives criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds valuable context that the operation creates a 'полную копию' (full copy) in a 'отдельный VPS' (separate VPS), implying the source server is unaffected. It does not detail async behavior or runtime, but annotations cover the mutation profile adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first defines exactly what the tool does, the second gives use cases. No redundant or filler content; every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, minimal schema, and annotations provided, the description covers the essential aspects: what it does, when to use it, and that it creates a separate copy. It lacks detail about return values or async behavior, but given the simplicity and annotations, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for server_id with its own description ('ID исходного сервера для клонирования'). The tool description adds no additional parameter information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Создаёт полную копию сервера в отдельный VPS' (creates a full copy of the server in a separate VPS), specifying the exact action (creates a full copy), the resource (server), and the target (separate VPS). This distinguishes it from siblings like create_server or update_server, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence provides explicit use cases: 'миграций, blue-green deploy или тестирования рискованных операций' (migrations, blue-green deploy, or testing risky operations). This clearly indicates when the tool should be used, though it does not explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds meaningful context by detailing exactly what the rule represents—a mapping between the balancer's (protocol, port) and the backend server's (protocol, port)—which goes beyond the annotations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the tool's purpose and core semantics without any wasted words. It is concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with fully documented parameters and no output schema, the description adequately explains the tool's function and the relationship between parameters. It could mention prerequisites or return value, but these are not critical given the straightforward semantics and annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all five parameters with descriptions, so baseline is 3. The description adds relational meaning by clarifying that balancer_proto/balancer_port and server_proto/server_port form paired endpoints of the mapping, which is not explicit from individual schema descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'создаёт' (creates) and clearly identifies the resource as a routing rule for a balancer, explaining the mapping between balancer and backend protocol/port pairs. This distinguishes it from sibling tools like create_balancer, update_balancer_rule, and delete_balancer_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating routing rules, and sibling names hint at related operations, but it does not explicitly state when to use this over alternatives or list prerequisites such as an existing balancer. No exclusions or explicit usage context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations showing readOnlyHint=false and destructiveHint=false, the description adds meaningful behavioral details by explaining the mutually exclusive modes and the naming constraints. This goes beyond the annotations, though it does not discuss side effects, permissions, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise paragraph of two sentences, front-loaded with the core action. It includes essential constraints without any fluff or redundant phrasing, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, 1 required, and a fully documented schema, the description covers the essential usage (creation, modes, naming). It does not mention response format or synchronous behavior, but the schema and annotations provide sufficient context for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the schema already documents all parameters. The description reiterates the key constraints (preset_id vs configurator_id + disk) that are already present in the schema, adding little new semantic value. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool creates a new container registry, using the specific verb 'Создаёт' and resource 'реестр контейнеров'. This clearly distinguishes it from sibling tools like list_container_registries or delete_container_registry, and the two configuration modes are also mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by indicating when to use the tool (to create a registry) and how to choose between the two configuration modes (preset_id or configurator_id + disk). However, it does not explicitly mention exclusions or alternative tools for related operations like updates or deletes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds useful behavioral context by disclosing that the process is asynchronous ('Процесс асинхронный') and instructs the agent to track status via get_image, which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence using (а), (б), (в) to structure three scenarios. Every clause adds value—modes, HTTP upload instruction, and async tracking—without any filler or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three creation modes, 6 parameters, no output schema), the description covers the essential behavioral aspects: how to invoke each mode, async tracking, and follow-up via get_image. It does not explain return values, but the pointer to get_image compensates for 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All six parameters have detailed descriptions in the schema, including relationship constraints (e.g., upload_url should not be used with disk_id). The description recaps these modes but does not add significant new syntax or format details beyond what the schema provides, so a baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Создаёт образ' (Creates an image) and enumerates three distinct creation modes: snapshot from disk_id, import from upload_url, or empty slot for HTTP upload. This specific verb+resource+scope distinguishes it from siblings like delete_image, get_image, and create_image_download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use each mode by specifying parameter combinations: disk_id for snapshots, upload_url for qcow2/iso imports, and neither for an empty slot. It also advises tracking via get_image for async completion, but does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the mutual exclusivity constraint, which is not visible from annotations. Annotations already indicate this is a mutating operation (readOnlyHint false), so the description does not need to restate that. It lacks details on side effects or return values, but annotations provide the basic behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action and required parameters. Every word earns its place, with no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and a nested configuration object, the description covers the critical decision points (required fields, tariff selection). The schema descriptions cover the remaining parameters, so the description is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters already have descriptions. The description adds value by clarifying the mutually exclusive relationship between preset_id and configuration, which is not stated in the schema. It also reiterates required fields, reinforcing what is already present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new worker node group in a cluster, using a specific verb and resource. It distinguishes itself from sibling tools like delete_k8s_node_group or increase_k8s_node_group_nodes by focusing on the creation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context by specifying required fields (name, node_count) and the mutually exclusive choice between preset_id and configuration. It does not explicitly mention alternatives or when-not-to-use, but the creation context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the description does not need to repeat that. It adds the contextual detail that this is an API v1 endpoint intended for compatibility, which is useful but not a deep behavioral disclosure. No contradictions with annotations, but there is no mention of side effects, permissions, or return behavior beyond the write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary purpose and immediately followed by the critical usage guidance. There is zero waste; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a compatibility shim and the schema covers all parameters, the description provides enough context: it states the action, the API version, and the preference for the v2 alternative. It does not detail return values, but no output schema is provided and the tool is simple enough that this is acceptable. The explicit warning to prefer v2 makes the tool's role fully clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (domain, mailbox, password, comment) is already well-documented. The description does not add any parameter-level semantics beyond what the schema 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('Создаёт почтовый ящик') with a specific verb and resource. It immediately distinguishes itself from the sibling tool create_mailbox by mentioning 'API v1' and explicitly stating it is only for compatibility, making it one of the clearest purpose statements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-to-use guidance: 'Предпочитай create_mailbox (v2) — этот нужен только для совместимости' (Prefer create_mailbox (v2) — this one is needed only for compatibility). This directly names the alternative and states the condition for using this tool, which is excellent usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description discloses the non-obvious 2FA flow (first call returns hash, second call requires hash and code) and the possibility of quarantine. This adds meaningful behavioral context that the annotations alone do not provide, though it omits details about resource side-effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action. Every sentence adds value: the first states what the tool does, the second reveals the multi-step 2FA behavior and quarantine outcome. No filler or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple scope of the tool, the schema thoroughly documents parameters, and annotations signal the non-read-only, non-idempotent nature, the description adequately covers the key additional context (2FA flow, quarantine). It could be enhanced by mentioning what happens to associated resources, but this is not critical for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—all three parameters are described in the schema (server_id required, hash from first DELETE request, code transmitted with hash). The description adds minimal new meaning beyond reinforcing the 2FA sequence, so the baseline 3 for high schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Удаляет сервер' (Deletes a server), which clearly states the action and resource. This directly differentiates it from sibling tools like delete_server_disk_backup or delete_server_ip, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two-step process for 2FA accounts, which is a usage guideline for this specific tool. It does not explicitly contrast with alternatives like shutdown_server, but the deletion purpose is self-evident, and the 2FA note provides clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows it is a non-destructive write. The description adds that only name, description, or OIDC provider are edited, and that version/nodes are excluded, but it does not disclose details like whether the OIDC provider is replaced wholesale or if permissions are required. With annotations present, the description adds adequate but not extensive context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main purpose and includes an important exclusion. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a straightforward update tool with good annotations and complete schema. The description effectively clarifies scope and separation from other tools, but does not mention behavior when optional fields are omitted (e.g., are they left unchanged) or require cluster existence. Given the low complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 each parameter. The description merely lists which fields are editable (name, description, oidc_provider) without adding semantics beyond the schema. This is the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool edits the cluster's name, description, or OIDC provider, and explicitly distinguishes from other tools by noting that version and nodes are changed separately. This makes the purpose specific and well-differentiated from sibling tools like update_k8s_cluster_version and node group operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-not-to-use guidance by stating that other parameters (version, nodes) are modified by separate tools. This helps an agent decide when to select this tool versus alternatives, though it does not name exact sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations do not mark the tool as read-only, so the description clarifies that it returns log data. It also discloses the behavioral boundary that only hypervisor-level lifecycle events are included, not application logs or syslog. It omits details like pagination or output format, but the core behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the primary purpose and examples; the second adds diagnostic use and explicit exclusions. It is front-loaded and every phrase contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-like tool with only two parameters and no output schema, the description covers what is returned, why it is useful, and what is excluded. The only minor gap is that it does not describe the shape or fields of the returned log entries, but given the low complexity this is not a major omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage: server_id is described as required, and order has an enum with a default and Russian description. The tool description adds domain context about event types but no additional parameter-level semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb+resource pairing ('Возвращает лог жизненного цикла сервера') and lists concrete event types (install, reboot, shutdown, reinstall). It further distinguishes itself from application logs and syslog, making its scope unambiguous relative to any logging-related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case ('Полезно для диагностики — почему сервер сейчас в off, когда последний reinstall') and explicitly states what it is not for ('НЕ application logs и НЕ syslog'). It does not name a specific alternative tool, but the when/when-not guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds the context that results include project_id, which is useful. However, it does not disclose additional behavioral traits such as pagination, auth requirements, or whether all balancers or only project-assigned ones are returned. The description 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and a practical usage hint. There is no fluff or repetition of structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 parameters and no output schema, the description is mostly complete. It states the scope (all account balancers) and the key output attribute (project_id). However, there is slight ambiguity about whether it returns only balancers with a project assignment or all balancers with the project binding as an attribute. Also, no mention of pagination or result size is made, but given the low complexity, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description adds value by mentioning that the response includes project_id, which is a key field for the returned data, even though it is not a parameter. This goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'balancers' with account-wide scope ('все балансировщики на аккаунте'). It explicitly mentions the project binding (project_id), which distinguishes it from sibling tools like list_balancers (which likely lacks project info) and list_project_balancers (which is scoped to a single project).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is convenient for searching which project a balancer belongs to, implying use when you need an account-wide overview with project associations. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses what is returned (ID, description, disk size, price, location) and implies a read operation. However, the annotations set readOnlyHint=false, which is unusual for a list operation, and the description does not explain this or add caveats like pagination or freshness. The added fields are useful, but more context could be provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant words. It states the purpose, lists output fields, and gives usage guidance efficiently. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is largely complete: it names the returned fields and explicitly ties usage to create_container_registry. It could mention response format or that results should be fetched fresh, but these are minor given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description is not required to explain parameter details. It still adds value by listing the return fields, which is the semantic core of the tool. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Возвращает список' (returns a list) and clearly identifies the resource: available tariffs for Container Registry, including ID, description, disk size, price, and location. This distinguishes it from related tools like list_container_registries and other preset-listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Используй перед create_container_registry, чтобы выбрать preset_id' (use before create_container_registry to choose preset_id). This clearly tells the agent when to call it, though it does not mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the annotations by listing the returned fields and the optional location filter. Although readOnlyHint is false, the description clearly indicates a read-style operation (returns a list) and does not contradict the annotation. It lacks details like pagination, but for a simple list tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and then the filter and usage instruction. Every sentence earns its place, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description compensates by listing the key fields of the response (ID, description, CPU, IPMI, pre-installed). It provides enough context for an agent to understand what the tool returns and how to use it with the optional filter. Minor omissions like pagination are acceptable for this simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage of the single 'location' parameter, including an enum and description. The description only reiterates the filter without adding new semantic value, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of dedicated server presets, specifying the resource and the included fields (ID, description, CPU, IPMI support, pre-installed). It distinguishes itself from sibling preset-listing tools by focusing on dedicated servers and mentioning the target use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool before create_dedicated_server to select a preset_id, providing clear contextual guidance. It does not name alternatives or when not to use, but the context is strong enough for an agent to know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context by listing the returned fields (ID, name, status, type, size, zone, etc.) and implying a read-only list operation. However, it does not disclose any edge behaviors like pagination, sorting, or errors. Additionally, the annotation readOnlyHint=false contrasts with the intuitive read-only nature of a list operation, but the description does not explicitly contradict this annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and immediately states the action and scope. The second sentence gives a clear use case. There is no fluff or repetition, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no params, no output schema), the description covers the essential context: what it returns and when to use it. It could mention pagination or sorting behavior, but it is reasonably complete for a list operation with this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage). With no parameters to describe, the baseline for parameter semantics is 4. The description does not need to add parameter details, and it correctly focuses on the return values instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Возвращает список всех сетевых дисков аккаунта') and clearly identifies the resource (network drives) and scope (all drives of the account). It also enumerates the key parameters returned, which distinguishes it from other list tools like list_network_drive_presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: 'Используй перед любой операцией над диском, чтобы получить его ID' (use before any operation on a drive to get its ID). It does not mention alternatives or when not to use it, but the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-idempotent, non-destructive operation. The description adds beyond annotations by disclosing the zone constraint and pointing to the prerequisite list call. This context helps the agent avoid failed operations, which is valuable behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: the first states the action, the second adds a constraint and a useful reference to a prerequisite tool. No filler words, perfectly front-loaded, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 fully described parameters, the description covers the essential context: what the operation does, the zone constraint, and how to discover valid resources. It doesn't discuss error cases or response formats, but no output schema exists and annotations cover the safety profile, so the overall package (description + schema + annotations) is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with each parameter described in detail: resource_id includes example and pointer to list_network_drive_available_resources, resource_type explains only 'server' is supported, and network_drive_id shows UUID. The tool description adds no additional parameter-specific meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: "Подключает сетевой диск к сервису (серверу)" — connects a network drive to a service/server. This specific verb+resource phrasing distinguishes it from the sibling tool unmount_network_drive, which does the reverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key usage condition: "Сервис и диск должны быть в одной зоне доступности" (service and disk must be in the same availability zone), and directs users to list_network_drive_available_resources to find eligible resources. While it doesn't explicitly contrast with unmount_network_drive, the prerequisite guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating, non-destructive operation. The description adds valuable behavioral context by explaining the ACPI reboot mechanism and that the OS gracefully terminates processes before restart. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three short, meaningful sentences, each earning its place. The action is front-loaded, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter design and existing annotations, the description adequately covers the tool's purpose, mechanism, and use cases. It does not explicitly address edge cases like ACPI unavailability, but for a reboot tool, the coverage is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (server_id) has complete schema description coverage (100%), so the baseline score is 3. The description adds no additional parameter details beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('перезагружает' - reboots) and resource ('сервер' - server), with 'мягко' (softly) qualifying the reboot method. This clearly distinguishes it from sibling tools like hard_reboot_server and shutdown_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Используй для применения обновлений ядра или сброса подвисшего состояния' (use for applying kernel updates or resetting a hung state). It provides clear context but does not mention exclusions or directly reference alternatives like hard_reboot_server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (destructiveHint=false), and the description adds useful behavioral context: the drive must be disconnected before deletion, implying a prerequisite step. It does not disclose error conditions or reversibility, but overall it adds value beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the main purpose and followed by a key usage note. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is sufficiently complete. It states the action, the target, and a critical prerequisite (before deletion). It doesn't cover edge cases like 'what if already unmounted', but the low complexity justifies a high score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter (network_drive_id) is already described as required UUID in the schema. The description does not add any further parameter-level detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: disconnects a network drive from the service/server it was connected to. This is a specific verb+resource pairing, and it implicitly distinguishes from delete_network_drive by noting the drive must be disconnected before deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is used for disconnecting a drive before deletion. While it does not explicitly name alternative tools, the 'before deleting' note clarifies when this action is needed versus deletion. It lacks explicit exclusions but is sufficient for the simple use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key side effect: 'перезагружает сервер в штатном режиме' (reboots the server in normal mode), which goes beyond the annotations. It does not mention prerequisites like the ISO being mounted or potential service interruption, but the added reboot behavior provides meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the primary action, and contains no redundant information. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with one well-documented parameter and no output schema, the description provides sufficient context to understand what the tool does and the important consequence. It lacks only minor details like error conditions or prerequisites, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter server_id is fully documented in the schema with 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID сервера', providing 100% coverage. The description adds nothing beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Отмонтирует примонтированный ISO-образ' (unmounts the mounted ISO image) and adds the consequential behavior of rebooting the server. This distinguishes it from sibling tools like unmount_network_drive (network drive) and reboot_server (just reboot).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when an ISO image is mounted and the server should be returned to normal operation. It mentions the reboot, but does not explicitly state when not to use or alternatives. Still, the context is clear enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose non-read-only and non-destructive behavior. The description adds a constraint about mutually exclusive parameters, but it does not explain operational details such as permissions, rate limits, or side effects. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action verb, and contains no redundant information. It efficiently conveys the purpose and the critical constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update tool with no output schema, the description covers purpose, key parameters, and the main constraint. It does not mention prerequisites like bucket existence, but the given information is sufficient for typical use. Minor gaps remain but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by grouping configurator parameters (disk, configurator_id) and explicitly stating the exclusivity rule, which clarifies the intended parameter usage beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates S3 storage parameters, listing the specific mutable fields. This distinguishes it from sibling tools like create_bucket, delete_bucket, and update_bucket_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it does not explicitly name alternatives, the verb 'изменяет' and sibling context make the intended use evident. It provides a key usage constraint: preset_id and configurator cannot be passed together, which is practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a writing operation (readOnlyHint=false) but are silent on downstream effects. The description discloses a significant behavioral consequence: 'После смены пароля нужно обновить конфигурацию всех клиентов' (after changing the password, you need to update the configuration of all clients). This adds value beyond annotations and helps the agent anticipate side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action. It consists of two sentences, the first stating the core function and the second providing a crucial operational note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with annotations and complete schema coverage, the description covers the main action and an important side-effect (client config update). It does not explain return values or error cases, but given the lack of an output schema and the straightforward nature of the update, it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters, but the description adds nuance by specifying the user is an administrator (пользователя-администратора), which clarifies the intended user_id. This is extra meaning beyond the generic schema description 'ID пользователя S3-хранилища'. The secret_key parameter is also mentioned in context, so the description complements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'Меняет secret_key пользователя-администратора S3-хранилища' (Changes the secret_key of the S3 storage administrator user). It uses a specific verb and resource, and distinguishes this from sibling update tools by specifying it targets the S3 storage administrator user's secret key/password.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when rotating the admin user's secret_key, but does not explicitly state when to use it vs alternatives or provide exclusions. It does add a post-condition about updating client configurations, which is useful context, but lacks direct guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a write operation (readOnlyHint: false) and non-destructive (destructiveHint: false). The description adds behavioral detail by specifying exactly what changes can be made (auto-renewal toggle, IP assignment). It does not contradict annotations and provides enough context about the mutation's scope, though it does not elaborate on side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that directly states the tool's function. It is appropriately sized, front-loads the key actions, and contains no irrelevant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool with only 3 parameters and full schema coverage, the description is complete enough. It covers the main operations and the required field. There is no output schema, which is acceptable, and the annotations provide safety context. It could optionally mention limitations (e.g., only for owned domains), but this is not critical given the existing clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is well-documented. The description provides a high-level summary but does not add meaning beyond the schema; it simply restates the actions. The 'и/или' (and/or) hints that both parameters can be updated together, which is a small addition, but overall the parameter semantics are already fully detailed in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific actions: enabling/disabling domain auto-renewal and/or changing the linked IP address. This distinguishes it from sibling tools like update_domain_name_servers, which handle a different aspect of domain configuration. The resource (domain) and verb (update) are immediately apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you need to modify auto-renewal or the linked IP of a domain. It does not explicitly exclude alternatives, but the specificity of the stated actions makes it evident that this tool is not for other domain-related updates (e.g., name servers). The requirement that FQDN is mandatory is also mentioned, giving a key prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the explicit constraint that the group policy is not changed through this endpoint, which is meaningful behavioral context beyond the annotations (readOnlyHint=false, destructiveHint=false). It does not mention side effects, permissions, or error cases, but the annotations already cover the basic safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence, front-loaded with the action and resource. It states the purpose and a critical limitation in minimal words, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update operation with fully described parameters, the description adequately scopes the action and clarifies what is not affected. It does not describe return values or behavior on non-existent groups, but these are not required for a basic update tool and no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description's statement that name and/or description can be updated aligns with the schema but does not add additional semantic detail about the parameters themselves, such as format, constraints, or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Обновляет' (updates) with a clear resource 'группы правил firewall' and states the exact fields affected (name and/or description). It clearly distinguishes from sibling tools like update_firewall_rule and create_firewall_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool: to update the name or description of a firewall group. It also explicitly states what is not changed ('Политика группы через этот эндпоинт не меняется'), which helps the agent avoid using it for policy changes. However, it does not name alternative tools like update_firewall_rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-destructive operation. The description adds valuable behavioral context by specifying that only name and description are updatable, while OS, location, and disk_id are immutable. This goes beyond the annotation flags and clarifies the tool's actual side effects and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and resource, then adds a crucial constraint in a second clause. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with only three parameters fully described in the schema and safety profile covered by annotations, the description is adequate. It specifies the extent of changes and what cannot be changed. The lack of an output schema is not a significant gap given the straightforward nature of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter (name, image_id, description) already having a description. The tool description mentions 'name and/or description' but does not add new information beyond the schema. The baseline of 3 is appropriate since the schema carries the full parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates the name and/or description of an image, using the specific verb 'Обновляет' and identifying the resource ('образа'). It also explicitly lists non-modifiable attributes (ОС, локация, disk_id), which distinguishes it from update tools for other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what this tool does and explicitly states which attributes cannot be changed, helping the agent avoid misuse. It does not name alternative tools, but the uniqueness of 'update_image' among siblings makes usage obvious. The exclusion of specific attributes serves as practical guidance for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the safety profile is known. The description adds that the tool uses structured blocks for four settings, but does not disclose additional behavioral traits like authorization requirements, rate limits, or whether existing settings are replaced. No contradiction, but minimal added transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the core action, the second gives usage preference and a brief structural note. Every sentence adds value, front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a legacy v1 update tool with a complete schema and safety annotations, the description covers the essential context: what it does, that v2 is preferred, and the key structural distinction. It does not mention return values or side effects, but the absence of an output schema and the presence of annotations make this acceptable. Slightly more detail on when v1 is necessary would elevate it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 8 parameters are already described in the schema. The description only lists four of the parameter names (auto_reply, spam_filter, forwarding_incoming, forwarding_outgoing) as 'structured blocks', which does not add meaning beyond the schema's existing 'объект' descriptions. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Обновляет почтовый ящик через API v1' (updates mailbox via API v1), using a specific verb+resource. It distinguishes itself from the sibling v2 tool by explicitly naming update_mailbox (v2) as the preferred alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Предпочитай update_mailbox (v2)' (prefer v2), providing an alternative and indicating when to use this tool. It also notes the use of structured blocks, offering context for why v1 might be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey mutability (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds that the project must exist and that at least one optional field is needed, but it does not elaborate on error cases or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, low-redundancy sentence that states the action, fields, and constraint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with good annotations and full schema coverage, the description covers the essential behavior and constraint. It does not mention return values, but no output schema exists and the tool's simplicity makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full parameter descriptions (100% coverage), so the baseline is 3. The description adds the 'at least one field' requirement, which is not explicit in the schema and clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing project's name, description, or avatar. This specific verb+resource+fields distinguishes it from other update_* tools that target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use for updating existing projects, with at least one field required. It does not explicitly name alternatives or exclusions, but the task is well-scoped among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the write nature is clear. The description adds the specific list of updatable fields and the resize alternative, but does not disclose behavioral nuances like partial update semantics or effect of cloud_init changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and then providing an explicit alternative. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple metadata update tool with 5 parameters and full schema coverage, the description covers the purpose and key alternative. It does not mention return values or prerequisites, but these are less critical given the simplicity and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a Russian description. The tool description only lists the field names in prose, adding no additional semantic detail beyond what the JSON Schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates server metadata (name, comment, avatar_id, cloud_init), using the specific verb 'обновляет' and resource 'сервера'. It also distinguishes itself from resize_server, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to use resize_server for resizing (preset/configurator), providing a clear alternative. It implies this tool is for metadata updates only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=false, destructiveHint=false, and openWorldHint=true, but the description does not address the non-read-only hint. It adds useful return content details (price, size range, IOPS) but does not disclose side effects or permissions. The description is compatible with annotations, so 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the operation and output details, followed by a direct usage instruction. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (no params, no output schema), the description adequately covers return content and intended usage. It includes price per GB, size range, and IOPS, and tells the agent to use it before create_network_drive, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already provides full coverage. No parameter-level detail is needed, and the description adds nothing extra. Baseline is 4 for no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Возвращает' (returns) and specifies the resource 'список доступных тарифов для сетевых дисков' (list of available presets for network drives), including details on price, size range, and IOPS. This clearly distinguishes it from sibling tools like list_network_drives and list_network_drive_available_resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool before create_network_drive to select a preset_id, providing clear when-to-use guidance. It does not mention alternatives or when not to use it, but the context is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds the behavioral constraint that the registry name is immutable, which is not present in annotations or schema. It also clarifies the 'custom configuration' mode but does not disclose side effects such as billing changes or service impact, keeping it slightly below a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: the first states the action and modifiable parameters, the second states a key limitation. Every word earns its place, with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the core action and fields, it omits that at least one of the updatable parameters should be provided (the schema only requires registry_id), which could lead an agent to make an empty update call. It also doesn't mention the effect of changes on the registry, leaving some gaps for a complete operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage for all 5 parameters, including mutual exclusivity rules. The description adds value by summarizing the three modifiable categories (description, preset, custom config) and noting the name restriction, which is not in the schema. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Изменяет' (changes) and specifies the resource 'реестр контейнеров' (container registry), enumerating the exact parameters that can be updated: description, preset_id, configurator_id+disk. It clearly distinguishes this from sibling create/delete/get/list tools and further clarifies scope by stating that the registry name cannot be changed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating existing registry settings and explicitly states that the name cannot be changed, which serves as a clear when-not for renaming. However, it does not name alternative tools (e.g., create_container_registry) for other operations, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-idempotent, non-destructive operation, so the description does not need to restate that. It adds the useful behavioral detail that omitting the version selects the next available one. It does not mention potential risks like downtime, but given the annotations, the provided extra context is sufficient for a baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two short sentences. It leads with the purpose and immediately follows with a relevant behavioral nuance. No words are wasted, and the structure is clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (two parameters, no nested objects) and the presence of annotations covering safety characteristics, the description is complete enough for an agent to understand what it does and how to use it. It explains the core action and the optional version behavior. No output schema is present, but the description does not need to explain return values since the focus is on the operation itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds meaningful semantics for k8s_version by explaining that it is optional and that omission triggers selection of the next available version. This goes beyond the schema's basic description, though it offers no additional insight for cluster_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool updates the Kubernetes version in a cluster, using a specific verb and resource. It distinguishes itself from siblings like edit_k8s_cluster by focusing explicitly on the version aspect, and it further clarifies an optional behavior (auto-selecting the next available version).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is used to update the Kubernetes version, and it explains that the version can be omitted to trigger an automatic next-available selection. However, it does not explicitly compare with alternatives like edit_k8s_cluster, though the name and sibling list imply the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that the operation is not read-only and not idempotent. The description adds useful behavioral context by referencing Let's Encrypt and stating that the subdomain must be pre-added with a correct CNAME record. No contradictions with annotations were found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, focused sentences. It front-loads the core action and adds one prerequisite sentence, with no redundant or filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool without an output schema, the description provides the essential purpose, prerequisites, and a key requirement (CNAME). It is sufficiently complete, though it could optionally mention error handling or issuance time, which are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single 'subdomain' parameter is 100%, so the baseline is 3. The description adds extra meaning by specifying that the subdomain must be tied to an S3 bucket and must meet CNAME requirements, which goes beyond the raw schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: issuing an SSL certificate (Let's Encrypt) for an S3 bucket subdomain. It uses a specific verb ('выпускает') and names the resource, distinguishing it from sibling tools like add_bucket_subdomains and list_bucket_subdomains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the prerequisite tool (add_bucket_subdomains) and mentions the required CNAME record, telling the agent when this tool can be used. It does not explicitly list alternatives for when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark non-readOnly/openWorld, and the description adds that it returns access_key and secret_key — useful behavior not present in the annotations or output schema. It doesn't discuss billing or side effects, but openWorldHint partially covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the operation, the second covers required fields, alternatives, and return value. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 7 params and no output schema, this description covers the essential purpose, input alternatives, and output credentials. The optional project_id/description are left to the schema, which is acceptable since schema descriptions are complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the crucial XOR rule ('ЛИБО preset_id, ЛИБО configurator_id + configurator_disk_mb') and clarifies that configurator_disk_mb is needed when using configurator_id, which the schema marks as merely 'опц.'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Создаёт новое S3-хранилище' — a clear verb+resource statement. It unambiguously creates a bucket and differentiates this from the many other create_* sibling tools by specifying S3 storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states required inputs and the exclusive-or requirement between preset_id and configurator_id+configurator_disk_mb. It doesn't explicitly mention alternatives or when-not-to-use, but the context is sufficient for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses asynchronous behavior and the status lifecycle (create → done) that is not present in annotations. This is valuable beyond what annotations offer, helping the agent understand immediate return and delayed completion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the purpose, second adds behavioral and usage guidance. No wasted words, each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool, it covers purpose, async behavior, and usage context. It does not describe the return value, but given no output schema and clear status flow, it is sufficiently complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage), so the description adds no additional parameter semantics. It correctly relies on the schema for parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Создаёт'), the object ('ручной бэкап диска VPS'), and includes the async status transition, making it specific and distinct from sibling backup tools like delete_server_disk_backup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Используй перед рискованными операциями (миграция, обновление ОС)'. It provides clear context, though it doesn't mention when-not or alternatives, which are less relevant given no competing create backup tool exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds meaningful context: the ACPI mechanism, analogy to pressing the power button, and that the OS gracefully terminates processes. It goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and includes the alternative without any fluff. Every clause earns its place; it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers the action, mechanism, and alternative. It could mention prerequisites like the server being running, but the graceful-shutdown context is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: server_id is described as 'ОБЯЗАТЕЛЬНОЕ ПОЛЕ - ID сервера для выключения'. The description adds no additional parameter information, but the schema already fully documents the only parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Мягко выключает сервер через ACPI shutdown' (softly shuts down the server via ACPI shutdown). It specifies the method and differentiates from hard shutdown by referencing the ACPI power-button analogy, distinguishing it from siblings like hard_shutdown_server and reboot_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Для принудительного выключения используй hard-shutdown через /action API (не покрыто этим tool-ом)' — clearly tells when NOT to use this tool and directs to an alternative. The description also implies use for graceful shutdown when OS process termination is desired.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already indicating readOnlyHint=false and destructiveHint=false, the description adds the scoping constraint of 'name and/or comment' and the requirement that at least one field be passed. This clarifies partial update semantics, though it does not discuss errors or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states what the tool does and the key usage rule. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with three well-documented parameters and no output schema, the description covers the essential behavior. It could mention return values or error conditions, but given the low complexity 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema describes each parameter. The description adds the important relational constraint that at least one of name or comment must be provided, which is not enforced by the schema itself. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Изменяет' (changes) with a clear resource 'выделенного сервера' (dedicated server) and specifies the exact parameters affected: name and/or comment. This distinguishes it from sibling tools like delete_dedicated_server or get_dedicated_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that both fields are optional but at least one must be provided, which is a clear usage constraint. It does not explicitly name alternatives or exclusions, but the context of what the tool does is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) already indicate safety, and the description adds valuable behavioral context: partial update semantics (only changed fields) and how complex blocks must be structured. It also references the OpenAPI schema for spam details. It does not contradict annotations and provides useful nuance beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and key attributes, followed by a concise usage tip. Every word contributes; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update tool with no output schema, the description adequately covers the input structure and usage. It mentions the API version, partial updates, and complex object requirements. It could mention return values or prerequisites, but these are less critical for an update action and are partially implied by required fields. Overall, it is sufficiently complete given the schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description adds value with the 'only changed fields' instruction and clarifies that complex fields (forward/autoreply/spam) expect objects with is_enabled, which aligns with schema descriptions. This goes beyond simply repeating schema info, though it doesn't fully explain all nested fields itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a mailbox (API v2) and lists specific updatable attributes (пароль, комментарий, ФИО, спам-фильтр, автоответчик, пересылки). The explicit mention of 'API v2' distinguishes it from the sibling update_mailbox_v1, and the verb 'Обновляет' conveys a precise action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives operational guidance: 'Передавай только изменяемые поля' (pass only changed fields) and explains the structure of complex blocks (objects with is_enabled and additional fields). It does not explicitly state when to use this tool over update_mailbox_v1, but the API version mention provides a functional differentiator. This is clear enough but lacks explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, covering the safety profile. The description adds beyond that by disclosing partial-update behavior: only provided fields are updated, which is valuable behavioral context not present in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence states the core function and identification method; the second provides actionable guidance. Information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with four parameters, full schema coverage, and no output schema, the description adequately explains the operation and usage. It could mention response format, but that is unnecessary given the tool's simplicity and the absence of an output schema requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description adds meaning by explicitly listing the updatable fields (name, body, is_default) and emphasizing the partial-update semantics, guiding the agent on which fields to include per request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Изменяет' = 'changes') with a clear resource ('SSH-ключа' = 'SSH key') and specifies the identification method ('по ID' = 'by ID'). It clearly differentiates this update operation from sibling tools like create_ssh_key, delete_ssh_key, get_ssh_key, and list_ssh_keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Передавай только те поля, которые нужно изменить' ('Pass only the fields that need to be changed') provides clear usage guidance for partial updates. While it doesn't explicitly exclude alternatives, the context of updating an existing key by ID is unambiguous and sufficient for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating operation (readOnlyHint=false), and the description aligns by saying 'attaches'. It adds the qualifier 'existing' and distinguishes from transfer, giving some behavioral context. However, it does not disclose potential side effects or failure conditions, but no contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the main action. The second sentence earns its place by directing users to the correct alternative tool. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter attach operation with no output schema, the description covers purpose, usage, and distinction from transfer. It is complete for an agent to decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides detailed descriptions for both required parameters (project_id and resource_id). The description reinforces that the balancer must be existing, adding minimal value beyond the schema. Coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Привязывает' (attaches) and identifies the resource (existing balancer) and target (project), clearly distinguishing it from sibling tools like add_database_to_project. It also explicitly notes the tool works with an existing balancer, not a new one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the use case: attaching an existing balancer to a project. It provides a direct alternative for a different scenario: 'Для переноса между проектами используй transfer_project_resource' (use transfer_project_resource for transfers between projects). This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are present (readOnlyHint=false, destructiveHint=false), but the description does not add significant behavioral context beyond what annotations state. It does not explicitly mention that the tool is a read-only operation or any side-effect risks or guarantees, though the wording implies a simple retrieval. The description adds value in explaining the response content but not in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the action, and every clause serves a purpose: what it returns, why it is useful, and which alternative to choose. There is no wasted verbiage or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides sufficient contextual completeness: it names the output granularity (per service type), states common use cases, and points to the related tool for balance. An agent can confidently invoke this tool without additional guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no requirement to document them. The description focuses on the return value, which is appropriate. Baseline for 0-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Возвращает детализацию расходов' (returns cost breakdown) and identifies the resource as 'по всем сервисам' (across all services). It lists example service types (VPS, DB, S3, DNS) and clearly distinguishes the tool's purpose from the sibling get_account_finances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('куда уходят деньги', find most expensive resources) and provides a direct alternative for a different scenario: 'Для общего баланса используй get_account_finances.' This is clear guidance on selection among related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the exact fields returned, including status values (installing/installed/on/off), location, specs, IPs, and price. Annotations do not declare read-only, but the description's 'returns list' implies a read operation. It adds useful scope context (account-level) beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: first states the primary action and output, second gives usage guidance. Every word is informative, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 parameters and no output schema, the description fully covers what the tool does and what it returns. It also includes usage context. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% vacuously. The description does not need to explain parameters. According to the baseline, 0 params warrants a score of 4; no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Возвращает список всех выделенных серверов аккаунта' (Returns list of all dedicated servers of the account), and enumerates the returned fields. This clearly distinguishes it from sibling tools like list_project_dedicated or get_dedicated_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool before operations on a dedicated server to obtain its ID. This provides clear context for when to use it, though it does not mention alternatives or when-not-to-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses what data is returned and suggests usage context, which is sufficient for a simple list operation. Although annotations set readOnlyHint=false, the description itself does not contradict this; it simply describes a read-like operation without mentioning side effects, which are not expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one to state the return values and one to state usage context. It is front-loaded, contains no redundant information, and every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list tool, the description fully covers the return fields and usage scenario. No output schema is provided, but the description compensates by explicitly enumerating the returned attributes (ID, type, CPU, RAM, Disk, Network, price).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is trivially 100%. The description does not need to explain parameters, and the baseline of 4 for zero parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Возвращает' (returns) and clearly identifies the resource as tariffs for master and worker Kubernetes nodes, listing the exact fields (ID, type, CPU, RAM, Disk, Network, price). This distinguishes it from sibling tools like list_server_presets or list_balancer_presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use before creating a cluster or node group.' It provides clear context but does not mention exclusions or alternative tools, so it misses a full when-not-to-use guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the context that versions are for creation/update, which is useful, but it does not disclose other behavioral aspects such as output format, sorting, or whether special permissions are needed. The annotations (readOnlyHint: false) are at odds with the read-only nature of a list operation, but the description does not contradict them; it simply lacks richer detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first states the primary purpose, the second gives usage guidance. Every word provides value, and there is no wasteful repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple list operation with no parameters and no output schema, the description fully covers what an agent needs: what the tool returns and when to use it. The sibling tools are numerous, but the description clearly situates this one in the create/update workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. With 0 params, the baseline is 4; the description need not explain parameters and does not try to, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns all Kubernetes versions available for creation or update, distinguishing it from siblings like list_k8s_presets or list_k8s_clusters. The verb 'returns' and specific resource 'versions Kubernetes' make 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use the tool before create_k8s_cluster or update_k8s_cluster_version, providing clear when-to-use guidance. This also implicitly differentiates it from other list tools by narrowing its use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds concrete return-field context beyond annotations (ID, name, status, etc.) and clarifies account-wide scope. Annotations already cover mutation/destructive hints, so description complements without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences; first sentence is front-loaded with the action and return values, second gives practical guidance. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-param list operation, the description covers what it returns and when to use it, sufficient for an agent to select and invoke correctly. Output schema absent, but the listed fields provide the needed expectation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema coverage is complete; description is not required to explain parameters. Baseline for zero-param tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies a concrete action ('Возвращает список') and resource ('всех VPS-серверов аккаунта'), listing key return fields. It differentiates from sibling project-scoped list tools by emphasizing account-level scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use before any server operation to obtain the server ID, providing a clear use case. Lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly warns that the server reboots ('Сервер перезагружается'), which is a critical behavioral side effect not mentioned in the annotations. It also adds context about what each mode does, going beyond the schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—two sentences that front-load the action and include the critical reboot warning. No redundant information; every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with 2 parameters, no output schema, and annotations present, the description covers the purpose, the parameter options with their nuances, and the important side effect (reboot). It 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters, but the description adds meaningful enrichment by explaining the purpose of the 'single' mode (root recovery) and 'recovery_disk' semantics, making the enum values more actionable. This exceeds the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb 'Меняет' (changes) and clearly identifies the resource 'boot_mode сервера' (server boot mode). It enumerates the three possible modes, which distinguishes it from sibling tools like set_server_nat_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the meaning and purpose of each boot mode (e.g., single is for root recovery, recovery_disk for booting from recovery disk), which implies usage scenarios. However, it does not explicitly state when to prefer this tool over alternatives or provide exclusions, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation set already indicates readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the mutation/non-destructive nature is known. The description adds valuable context beyond annotations: 'Размер можно только увеличивать' (size can only be increased), which is a critical behavioral constraint. This goes beyond the schema's basic type/description and helps the agent avoid invalid calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action and followed by critical constraints. Every word adds value; there is no fluff or repetition of schema content. This is an example of efficient, high-density writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update operation with full schema coverage and clear annotations, the description is complete enough. It covers the purpose, the modifiable fields, the size restriction, and the minimum-input requirement. No output schema exists, but the tool's behavior is well-framed for an agent to select and invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing descriptions for all four parameters, so the baseline is 3. The description adds extra semantics by explaining the size field can only be increased, and that at least one of name/comment/size must be provided. This supplements the schema, which only marks network_drive_id as required and would otherwise allow an update with no changes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Изменяет параметры сетевого диска' – changes network drive parameters) and specifies the affected fields (name, comment, size). This is a specific verb+resource combination that distinguishes it from related tools like create_network_drive, delete_network_drive, and other update_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by indicating this tool updates an existing network drive and lists the modifiable fields. It also states a key requirement: 'Нужно указать хотя бы одно из полей' (must specify at least one of the fields). However, it does not explicitly mention alternatives or exclusions (e.g., 'use create_network_drive to create a new drive'), so it stops short of the highest tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical behavioral consequence: 'Данные в RAM потеряются' – data in RAM will be lost. It also explicitly calls out the hardware-level nature ('reset power'), which goes beyond the annotations' simple readOnlyHint false. This adds valuable context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Each sentence serves a purpose: what the tool does, when to use it, and the consequence. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and no output schema, so the description covers all essential aspects: action, trigger condition, and RAM data loss. It is self-sufficient and leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter (server_id) with a detailed description ('ID сервера для принудительной перезагрузки'), achieving 100% coverage. The tool description itself does not further elaborate on parameters, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Принудительно перезагружает сервер (reset power)' – force reboots the server via power reset. It also distinguishes itself from the sibling tool reboot_server by positioning this as a harder alternative when the soft reboot fails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a when-to-use instruction: 'Использовать когда мягкий reboot_server не помогает (зависшая ОС)' – use when soft reboot fails (hung OS). This names the alternative tool and gives a clear prerequisite scenario, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining what is affected and what is not: the key remains in the account, only the binding to the server is deleted. This adds critical context to destructiveHint=false and clearly discloses the operation's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and contains zero filler. Every sentence adds value, making it highly efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 required parameters and no output schema, the description fully covers the operation, the distinction from related tools, and the precise effect. No additional context is needed for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters (server_id, ssh_key_id) already described. The tool description does not add further parameter-specific details, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Удаляет конкретный SSH-ключ с сервера' (deletes a specific SSH key from the server). It distinguishes itself from the sibling delete_ssh_key by clarifying that the key remains in the account, only the server binding is removed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Для полного удаления ключа используй delete_ssh_key' (for full deletion use delete_ssh_key). This tells the agent when not to use this tool and points to the correct alternative, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![timeweb-mcp MCP server](https://glama.ai/mcp/servers/ichinya/timeweb-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ichinya/timeweb-mcp)

Score Badge

Copy to your README.md:

[![timeweb-mcp MCP server](https://glama.ai/mcp/servers/ichinya/timeweb-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ichinya/timeweb-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ichinya/timeweb-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server