Cloud Manage MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
There is significant overlap and unclear boundaries between tools. For example, get_instance_by_provider, get_instance_info, and individual provider-specific get_*_instance_info tools all retrieve instance information, making it ambiguous which to use. Similarly, power management tools are duplicated across providers (e.g., power_on_alibaba_instance, power_on_digitalocean_droplet) while a generic manage_instance_power also exists, causing confusion. The descriptions do not clearly differentiate when to use generic vs. provider-specific tools.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern with minor deviations. Most tools use snake_case and start with verbs like get, list, manage, power_off, etc., followed by provider and resource names (e.g., get_aws_instance_info, list_digitalocean_droplets). However, there are inconsistencies like check_provider_availability (which doesn't fit the provider-specific pattern) and some tools omit provider names in verbs (e.g., get_system_status, get_supported_providers), but overall the naming is mostly predictable.
Tool Count2/5
With 30 tools, the count is too high for the apparent scope of cloud instance management across four providers. The server includes many redundant tools (e.g., separate power management tools for each provider instead of consolidating) and could be streamlined. This large number increases complexity and potential for confusion, making it feel heavy and over-engineered for the domain.
Completeness3/5
The tool surface covers core operations like listing instances, getting info, monitoring, and power management across providers, but there are notable gaps. For example, there are no tools for creating, updating, or deleting instances, which are essential CRUD operations in cloud management. Additionally, while monitoring and bandwidth tools exist for some providers, coverage is inconsistent (e.g., missing for Alibaba in descriptions). The surface allows basic read and power control but lacks full lifecycle management.
Average 3/5 across 30 of 30 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does without mentioning any behavioral traits such as read-only vs. destructive nature, authentication requirements, rate limits, error handling, or response format. This leaves critical operational details unspecified.
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 sentence in Chinese that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 has an output schema (which handles return values) and a simple input schema with one parameter, the description is minimally adequate. However, with no annotations and low parameter semantics, it lacks completeness for operational context like error cases or usage prerequisites, leaving gaps in understanding the tool's full behavior.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'Vultr实例' (Vultr instance) which implies the 'instance_id' parameter, but adds no meaning beyond the schema's basic type and title. No details on format, constraints, or examples are provided, failing to adequately clarify the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取Vultr实例带宽使用情况' (Get Vultr instance bandwidth usage) clearly states the verb (get) and resource (Vultr instance bandwidth usage), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_vultr_instance_info' or monitoring tools, leaving ambiguity about what specific bandwidth data is retrieved versus other instance information.
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. With siblings like 'get_vultr_instance_info' and monitoring tools for other providers, the description lacks context on whether this is for real-time monitoring, historical data, or specific bandwidth metrics, offering no help in tool 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states what the tool does ('获取...操作历史'), without any information on permissions, rate limits, response format, or side effects. This is a significant gap for a tool that likely involves read operations on a cloud resource.
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 sentence in Chinese ('获取DigitalOcean Droplet操作历史'), which directly states the purpose without unnecessary words. It is appropriately sized and front-loaded, 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?
Given the tool's complexity (interacting with a cloud provider), lack of annotations, and 0% schema description coverage, the description is incomplete. While an output schema exists, the description doesn't compensate for missing behavioral and parameter details, making it inadequate for safe and effective use.
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 description coverage is 0%, with one parameter 'droplet_id' documented only by title and type in the schema. The description adds no meaning beyond the schema, failing to explain what 'droplet_id' represents or how to obtain it, which is critical for correct invocation.
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 ('获取' meaning 'get') and resource ('DigitalOcean Droplet操作历史' meaning 'DigitalOcean Droplet operation history'), making the purpose specific and understandable. It distinguishes from siblings like 'get_digitalocean_droplet_info' by focusing on actions/history rather than general information, 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 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 doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the purpose alone, which is insufficient for effective tool 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?
No annotations are provided, so the description carries full burden. It implies a read-only operation ('获取' - get), but doesn't disclose any behavioral traits such as authentication requirements, rate limits, error conditions, or what the monitoring data includes (e.g., CPU, memory, network metrics). For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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 sentence in Chinese that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 has an output schema (which should document return values), the description's minimalism is somewhat acceptable. However, with no annotations, 0% schema description coverage, and a single parameter, the description doesn't provide enough context about usage, behavior, or parameter details to be fully complete. It meets a bare minimum but leaves the agent with significant uncertainty.
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 description coverage is 0%, so the description must compensate. It mentions '阿里云ECS实例' (Alibaba Cloud ECS instance), which hints at the 'instance_id' parameter, but doesn't add meaningful semantics beyond what's obvious from the parameter name. No details are provided about the format, constraints, or examples for the instance ID, leaving the parameter poorly documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取阿里云ECS实例监控信息' (Get Alibaba Cloud ECS instance monitoring information) states a clear verb ('获取' - get) and resource ('阿里云ECS实例监控信息' - Alibaba Cloud ECS instance monitoring information), but it's somewhat vague about what specific monitoring information is retrieved. It distinguishes from some siblings like 'get_alibaba_instance_info' by focusing on monitoring, but doesn't clearly differentiate from 'get_aws_instance_monitoring' or 'get_digitalocean_droplet_monitoring' beyond the provider.
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 doesn't mention when this tool is appropriate compared to other monitoring tools (like AWS or DigitalOcean variants), nor does it specify prerequisites or constraints. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves monitoring information, implying a read-only operation, but doesn't specify authentication needs, rate limits, error conditions, or the format of returned data. This leaves significant gaps for an agent to understand how to interact with it effectively.
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 sentence in Chinese that directly states the tool's purpose. It's front-loaded with no unnecessary words, making it highly concise and well-structured for quick understanding.
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 has 1 parameter with 0% schema coverage, no annotations, and an output schema exists, the description is minimally complete. It identifies the resource and action but lacks details on parameter meaning, behavioral traits, and usage context. The output schema may cover return values, but the description doesn't provide enough guidance 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'DigitalOcean Droplet监控信息', which implies a droplet_id parameter, but doesn't explain what droplet_id is, its format, or where to obtain it. The description adds minimal semantic value beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取DigitalOcean Droplet监控信息' clearly states the action (获取/get) and resource (DigitalOcean Droplet监控信息/monitoring information), but it's vague about what specific monitoring data is retrieved. It distinguishes from siblings like 'get_digitalocean_droplet_info' by specifying monitoring, but doesn't detail the scope or type of metrics.
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 doesn't mention prerequisites, such as needing a valid droplet ID, or differentiate from other monitoring tools like 'get_aws_instance_monitoring'. The description alone offers no usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('list all Vultr instances') without any behavioral details. It doesn't mention whether this is a read-only operation, what data is returned (e.g., instance IDs, statuses, metadata), pagination, rate limits, or error handling. For a tool with zero annotation coverage, this is a significant gap in 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, efficient sentence ('列出所有Vultr实例') that directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized for a simple listing tool, 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?
Given that annotations are absent and the tool has an output schema (which handles return values), the description is incomplete. It lacks behavioral context (e.g., read-only nature, data format) and usage guidelines, which are crucial for an AI agent to invoke it correctly. While the output schema may cover return values, the description doesn't provide enough overall context for effective tool selection and use.
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 0 parameters with 100% description coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, but since there are no parameters, this is acceptable. A baseline score of 4 is appropriate as the description doesn't need to compensate for missing parameter documentation, and it aligns with the schema's lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出所有Vultr实例' (List all Vultr instances) clearly states the verb ('list') and resource ('Vultr instances'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'list_aws_instances', 'list_alibaba_instances', or 'list_digitalocean_droplets' beyond specifying the provider, which is already implied by the tool name. The description is adequate but lacks differentiation from similar 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'get_vultr_instance_info' for detailed info on a single instance, or 'get_instance_by_provider' for cross-provider queries. There's no context about prerequisites, such as authentication or provider setup, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates this is a forceful shutdown operation requiring three confirmations, which suggests it's destructive and irreversible. However, it doesn't disclose critical behavioral details like whether this action is immediate, what happens to data, if there are rate limits, or what permissions are required. The description adds some context but leaves significant gaps for a destructive 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 extremely concise—just one sentence in Chinese that directly states the tool's purpose and a key behavioral requirement. It's front-loaded with the core action and wastes no words, making it efficient for quick understanding.
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?
Given the complexity (a destructive power-off operation), no annotations, 0% schema coverage, and the presence of an output schema (which might help with return values), the description is incomplete. It mentions the need for three confirmations but doesn't cover parameter meanings, error conditions, or other critical context needed for safe and correct usage. The output schema existence doesn't fully compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters (droplet_id, ip_confirmation, name_confirmation, operation_confirmation) are documented in the schema. The description doesn't mention any parameters or explain their purposes, such as what the three confirmations entail or how droplet_id should be obtained. This fails to compensate for the lack of schema documentation.
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 ('强制关闭' means 'force shut down') and the target resource ('DigitalOcean Droplet'), which is specific and unambiguous. It distinguishes this from sibling tools like 'shutdown_digitalocean_droplet' by implying a more forceful action, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions '需要三次确认' (requires three confirmations), which provides some usage context about safety measures. However, it doesn't explicitly state when to use this tool versus alternatives like 'shutdown_digitalocean_droplet' or 'manage_instance_power', nor does it mention prerequisites or exclusions.
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?
With no annotations provided, the description carries full burden. It discloses the confirmation requirement ('需要三次确认'), which is a behavioral trait. However, it doesn't mention critical details like whether this operation is destructive, irreversible, requires specific permissions, has rate limits, or what the output looks like. For a power-off tool with zero annotation coverage, this is insufficient.
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 sentence in Chinese that directly states the tool's purpose and key requirement. It's front-loaded with no wasted words, making it highly concise and well-structured for its content.
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?
Given the tool's complexity (forceful power-off with confirmations), no annotations, 0% schema coverage, and 4 parameters, the description is incomplete. While an output schema exists, the description lacks crucial context like behavioral risks, parameter explanations, and differentiation from siblings. It doesn't provide enough information for safe and correct usage.
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 description coverage is 0%, so the description must compensate. It implies confirmations are needed but doesn't explain what the three confirmation parameters (ip_confirmation, name_confirmation, operation_confirmation) represent or how to use them. The description adds minimal value beyond the schema, failing to clarify parameter meanings or usage.
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 ('强制停止' = force stop) and the resource ('阿里云ECS实例' = Alibaba Cloud ECS instance). It distinguishes from siblings like 'power_on_alibaba_instance' and 'reboot_alibaba_instance' by specifying forceful stopping. However, it doesn't explicitly differentiate from 'manage_instance_power' which might handle similar operations.
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 mentions '需要三次确认' (requires three confirmations), which provides some context about when to use it (when confirmations are needed). However, it doesn't explain when to choose this tool over alternatives like 'power_off_digitalocean_droplet' or 'shutdown_digitalocean_droplet', nor does it specify prerequisites or exclusions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a forceful shutdown operation requiring three confirmations, which suggests it's destructive and has safety mechanisms. However, it lacks details on permissions needed, rate limits, whether the action is reversible, what happens to data, or the expected response format. For a destructive operation, this is insufficient.
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—a single sentence in Chinese that states the action and a key requirement. It's front-loaded with the core purpose and wastes no words, making it efficient for quick understanding.
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?
Given the tool's complexity (a destructive operation with 4 parameters, 0% schema coverage, no annotations, but with an output schema), the description is incomplete. It doesn't cover parameter details, behavioral traits like safety or permissions, or how it differs from siblings. The output schema might help with return values, but the description lacks essential context for proper use.
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 description coverage is 0%, so the schema provides no parameter descriptions. The description mentions '需要三次确认' (requires three confirmations), which hints at the purpose of the three confirmation parameters (ip_confirmation, name_confirmation, operation_confirmation) but doesn't explain what each confirmation entails or how to provide them. It adds minimal value beyond the parameter names, leaving most semantics unclear.
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 ('强制关闭' meaning 'force shut down') and target resource ('Vultr实例' meaning 'Vultr instance'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'manage_instance_power' or 'shutdown_digitalocean_droplet', which might offer similar functionality for different providers or with different behaviors.
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 mentions '需要三次确认' (requires three confirmations), which provides some context about prerequisites but doesn't specify when to use this tool versus alternatives like 'power_off_alibaba_instance' or 'reboot_vultr_instance'. No explicit guidance on scenarios, exclusions, or comparisons with sibling tools is provided.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the need for three confirmations, which adds some context about safety measures, but fails to describe other critical behaviors such as required permissions, potential impacts (e.g., billing, service interruption), rate limits, or what happens if the instance is already powered on. This is inadequate for a mutation tool with zero annotation coverage.
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 with a single sentence in Chinese, front-loaded with the core action and resource. There is zero waste, and every word earns its place by conveying essential information efficiently.
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?
Given the complexity of a power-on operation with 4 parameters, no annotations, and 0% schema coverage, the description is incomplete. It lacks details on parameters, behavioral traits beyond confirmations, and usage context. While an output schema exists (which might cover return values), the description doesn't provide enough guidance for safe and correct tool invocation in a multi-provider environment with sibling tools.
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 description coverage is 0%, so the schema provides no parameter details. The description does not explain any of the 4 parameters (instance_id, ip_confirmation, name_confirmation, operation_confirmation), leaving their purposes and formats completely undocumented. This fails to compensate for the low schema coverage, making parameter understanding difficult.
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 ('启动' meaning 'start up' or 'power on') and the resource ('阿里云ECS实例' meaning 'Alibaba Cloud ECS instance'), which is specific and unambiguous. It distinguishes from siblings like 'power_off_alibaba_instance' by indicating the opposite power state. However, it doesn't explicitly differentiate from 'reboot_alibaba_instance' or 'manage_instance_power', which slightly limits clarity.
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 mentions '需要三次确认' (requires three confirmations), which implies a specific usage context for safety, but doesn't provide explicit guidance on when to use this tool versus alternatives like 'reboot_alibaba_instance' or 'manage_instance_power'. No exclusions or prerequisites are stated, leaving gaps in usage instructions.
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?
No annotations are provided, so the description carries the full burden. It mentions '需要三次确认' (requires three confirmations), which adds some behavioral context about a safety mechanism. However, it doesn't disclose other critical traits like whether this is a destructive operation, what permissions are required, rate limits, or what happens during the reboot process. For a mutation tool with zero annotation coverage, this is insufficient.
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 sentence in Chinese that is front-loaded with the core action and resource. There is no wasted text, and it's appropriately sized for the tool's complexity.
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?
Given the tool's complexity (a destructive reboot operation with 4 parameters), no annotations, and 0% schema description coverage, the description is incomplete. It lacks details on prerequisites, error conditions, output format (though an output schema exists, the description doesn't reference it), and how to handle the confirmations. For a mutation tool, this is inadequate.
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 description coverage is 0%, so the description must compensate. It implies confirmations are needed but doesn't explain the four parameters (instance_id, ip_confirmation, name_confirmation, operation_confirmation) or their purposes. The description adds minimal value beyond the schema, failing to clarify parameter meanings or usage.
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 ('重启' meaning 'reboot') and the resource ('阿里云ECS实例' meaning 'Alibaba Cloud ECS instance'), which is specific and unambiguous. It distinguishes from siblings like 'power_off_alibaba_instance' by focusing on reboot rather than power off/on. However, it doesn't explicitly differentiate from 'manage_instance_power' which might also handle reboots.
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 mentions '需要三次确认' (requires three confirmations), which implies a specific usage context where confirmations are needed, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'power_off_alibaba_instance' or 'manage_instance_power'. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the three-confirmation requirement, which is useful context about safety measures, but doesn't describe what the reboot entails (e.g., temporary downtime, data persistence, permissions needed, rate limits, or response format). For a destructive operation with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one short sentence in Chinese, front-loading the core action and a key constraint. There's zero wasted text, making it efficient for quick understanding, though this brevity contributes to gaps in other dimensions.
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?
Given the tool's complexity (a destructive reboot operation with 4 parameters), no annotations, 0% schema description coverage, and an output schema (which helps but isn't described), the description is incomplete. It lacks parameter explanations, detailed behavioral context, and usage guidelines, making it insufficient for safe and effective tool invocation.
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 description coverage is 0%, so the schema provides no parameter documentation. The description doesn't mention any parameters at all, failing to explain the four parameters (droplet_id and three confirmation fields) or their purposes. This leaves all parameters completely undocumented, which is inadequate given the low 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 verb ('重启' meaning 'reboot') and resource ('DigitalOcean Droplet'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'reboot_alibaba_instance' or 'reboot_vultr_instance' beyond mentioning the specific provider, which is somewhat implied but not explicit.
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 mentions '需要三次确认' (requires three confirmations), which provides some context about prerequisites, but offers no guidance on when to use this tool versus alternatives like 'manage_instance_power', 'shutdown_digitalocean_droplet', or other reboot tools for different providers. There's no explicit when/when-not or alternative tool recommendations.
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?
With no annotations provided, the description carries full burden. It discloses a behavioral trait ('需要三次确认' - requires three confirmations), indicating a safety or confirmation mechanism, which adds some value. However, it lacks details on permissions, side effects (e.g., downtime, data loss), rate limits, or response behavior, leaving significant gaps for a destructive operation like rebooting.
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 with a single sentence in Chinese: '重启Vultr实例（需要三次确认）'. It's front-loaded with the core action and includes a brief constraint, with zero wasted words, making it highly efficient for an agent 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?
Given the tool's complexity (a destructive reboot operation with 4 parameters), no annotations, 0% schema coverage, and an output schema (which helps but isn't described), the description is incomplete. It mentions a confirmation requirement but lacks critical details like permissions, consequences, or how to use the parameters, leaving the agent under-informed for safe and effective use.
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 description coverage is 0%, so the schema provides no parameter descriptions. The description mentions '需要三次确认' (requires three confirmations), which loosely relates to the three confirmation parameters (ip_confirmation, name_confirmation, operation_confirmation), but doesn't explain their purpose, format, or how they differ. It adds minimal meaning beyond the schema, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('重启' meaning 'reboot') and resource ('Vultr实例' meaning 'Vultr instance'), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like 'reboot_alibaba_instance' or 'reboot_digitalocean_droplet', but the provider specificity is inherent in the tool name, so it's clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions '需要三次确认' (requires three confirmations), which hints at a usage constraint but doesn't explain when to use this tool versus alternatives like 'manage_instance_power' or 'power_off_vultr_instance'. No explicit guidance on prerequisites, scenarios, or exclusions is provided, leaving the agent with minimal context for 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the tool checks availability and returns a dictionary, it doesn't describe what 'availability' means (API endpoints, service status, region availability), what authentication might be required, whether there are rate limits, or what specific information the dictionary contains beyond the generic '可用性信息' (availability information).
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 appropriately concise with a clear purpose statement followed by Args and Returns sections. The structure is front-loaded with the main purpose, though the Chinese-only content might limit accessibility for some agents. Every sentence serves a purpose with minimal 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?
Given the tool has an output schema (which handles return value documentation) and only one parameter, the description is reasonably complete for its complexity level. However, the lack of behavioral context (what 'availability' means operationally) and usage guidance relative to sibling tools leaves clear gaps that could hinder effective tool selection.
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 description adds some value beyond the input schema by listing the valid provider names ('aws', 'digitalocean', 'vultr', 'alibaba'), which isn't captured in the schema (0% description coverage). However, it doesn't explain what these providers represent or provide additional context about the parameter beyond the enum values.
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 purpose as '检查特定云服务提供商的可用性' (check specific cloud service provider availability), which is a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'get_system_status' or 'get_supported_providers' that might also provide availability or provider information.
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. There are multiple sibling tools that deal with provider information (get_supported_providers, get_system_status) and instance-level tools, but the description offers no context about when this specific availability check is appropriate versus other options.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't clarify if it requires specific permissions, has rate limits, returns partial or complete data, or handles errors. For a cloud API tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded, with the core purpose stated first in a single sentence. The Args and Returns sections are structured but could be more integrated. There's no wasted text, though it lacks elaboration on usage or behavior that might be necessary for 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?
Given the tool's moderate complexity (cloud instance info retrieval), no annotations, and an output schema present (which handles return values), the description is minimally adequate. It covers the basic purpose and parameter intent but misses usage guidelines, behavioral details, and deeper parameter context, making it incomplete for optimal agent operation without additional inference.
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 description adds minimal semantics beyond the input schema. It explains that 'ip_address_or_id' accepts a public IP address or instance ID, which clarifies the parameter's purpose, but with 0% schema description coverage, this doesn't fully compensate. It doesn't detail format constraints (e.g., IP address validation, ID patterns) or provide examples, leaving the agent to infer from the schema alone.
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 purpose: '获取阿里云ECS实例信息' (Get Alibaba Cloud ECS instance information). It specifies the resource (Alibaba Cloud ECS instances) and the action (get information), which distinguishes it from power management or listing tools among siblings. However, it doesn't explicitly differentiate from similar tools like 'get_instance_info' or 'get_instance_by_provider' that might serve overlapping functions.
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 doesn't mention when to choose this over 'list_alibaba_instances' for bulk retrieval, 'get_alibaba_instance_monitoring' for metrics, or 'get_instance_info' which might be provider-agnostic. There's also no indication of prerequisites, such as authentication or instance state requirements.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves monitoring data, implying a read-only operation, but doesn't specify details like authentication requirements, rate limits, data format, or whether it's a real-time or historical query. For a tool with no annotations, this is a significant gap in 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 concise and well-structured: a clear purpose statement followed by Args and Returns sections. It uses minimal sentences that directly address key elements. However, it could be more front-loaded with critical details (e.g., distinguishing from siblings), and the Returns section is vague ('Dict: 监控数据'), slightly reducing efficiency.
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 moderate complexity (2 parameters, no annotations, but has an output schema), the description is partially complete. It covers the basic purpose and parameters but misses behavioral context (e.g., auth, limits) and usage guidelines. The output schema exists, so the description doesn't need to detail return values, but overall, it leaves gaps for effective agent 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 description adds minimal semantics beyond the input schema: it names the parameters (instance_id, hours) and their types (str, int), but the schema already provides titles and types with 0% description coverage. It doesn't explain what 'hours' means (e.g., past hours from now) or provide examples. With schema coverage low, the description partially compensates but lacks depth, aligning with the baseline.
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 purpose: '获取AWS EC2实例的监控数据' (Get AWS EC2 instance monitoring data). It specifies the verb (获取/get) and resource (AWS EC2 instance monitoring data), which is clear. However, it doesn't explicitly distinguish this tool from its sibling 'get_aws_instance_info' or other monitoring tools like 'get_alibaba_instance_monitoring', which would be needed for a score of 5.
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 doesn't mention sibling tools like 'get_aws_instance_info' (for general info) or 'get_aws_instance_storage_info' (for storage-specific data), nor does it specify prerequisites or exclusions (e.g., only for AWS EC2 instances). This lack of context makes it harder for an agent to choose correctly among similar tools.
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?
No annotations are provided, so the description carries full burden. It mentions the tool '获取' (gets) information, implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what specific information is returned. This is inadequate for a tool with no annotation coverage.
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 structured with clear sections for Args and Returns. It's front-loaded with the purpose, and each sentence adds value, though the Returns section is minimal given the output schema exists.
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 has an output schema, the description doesn't need to detail return values. However, with no annotations and minimal behavioral context, it's incomplete for guiding usage. It covers the parameter semantics adequately but lacks broader context like when to use it or error cases.
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 description adds meaningful semantics: it explains that 'ip_address_or_id' accepts either a public IP address or an instance ID. With 0% schema description coverage and only 1 parameter, this clarification compensates well, though it could detail format constraints (e.g., IP format).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取Vultr实例信息' (Get Vultr instance information), which clearly indicates the verb (get) and resource (Vultr instance). However, it doesn't distinguish from sibling tools like 'get_instance_info' or 'get_vultr_instance_bandwidth', making the purpose somewhat vague in 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?
No guidance is provided on when to use this tool versus alternatives such as 'get_instance_info' (general) or 'list_vultr_instances' (list all). The description only states what it does, not when it's appropriate, leaving the agent without context for 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?
With no annotations provided, the description carries the full burden. It discloses the three-confirmation requirement, which is a crucial behavioral trait for safety. However, it doesn't mention other important aspects like whether this is a graceful shutdown versus hard power-off, what permissions are needed, whether it's reversible, or what the output contains. The description adds some value but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that conveys the core action and a key constraint. It's front-loaded with the main purpose. However, the inclusion of '优雅' (graceful/elegant) adds a slight stylistic flourish that doesn't contribute essential information, keeping it from 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?
This is a destructive operation (shutdown) with no annotations, 4 parameters (3 of which are confirmation-related with unclear semantics), and an output schema exists (which reduces the need to describe returns). The description mentions the three-confirmation safety measure but fails to address critical aspects like what '优雅关闭' (graceful shutdown) entails operationally, error conditions, or how it differs from sibling tools. For a potentially risky tool, this is inadequate.
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 description coverage is 0%, so the schema provides no parameter documentation. The description mentions '需要三次确认' (requires three confirmations), which hints at the purpose of the three confirmation parameters (ip_confirmation, name_confirmation, operation_confirmation) but doesn't explain what they are, their format, or why they're needed. It doesn't address the droplet_id parameter at all. The description adds minimal semantic value beyond the 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 '优雅关闭DigitalOcean Droplet（需要三次确认）' clearly states the action (shutdown) and resource (DigitalOcean Droplet) with a specific behavioral constraint (requires three confirmations). It distinguishes from siblings like 'power_off_digitalocean_droplet' by implying a more controlled shutdown process, though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions '需要三次确认' (requires three confirmations), which provides some usage context about safety measures. However, it doesn't specify when to use this tool versus alternatives like 'power_off_digitalocean_droplet' or 'manage_instance_power', nor does it mention prerequisites or exclusions. The guidance is minimal and implicit.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states the tool returns a dictionary of provider information, it doesn't describe what that information includes (e.g., provider names, capabilities, status), whether the data is cached or real-time, or any authentication/rate limit considerations. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 brief with two sentences, but the structure could be improved. The first sentence states the purpose clearly, but the second ('Returns: Dict: 支持的云服务提供商信息') is redundant with what an output schema would provide (output schema exists). This repetition slightly reduces efficiency, though overall it's not verbose.
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 (0 parameters, output schema exists), the description is somewhat complete but has gaps. The output schema handles return values, so the description doesn't need to explain those. However, for a tool with no annotations, it should provide more behavioral context (e.g., what 'supported' means, data freshness). It's adequate but could be more informative for agent usage.
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 schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to explain any parameters, which is appropriate. It gets a baseline 4 since there are no parameters to document, and it correctly avoids unnecessary parameter explanations.
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 purpose: '获取支持的云服务提供商列表' (Get supported cloud service provider list). It uses a specific verb ('获取' - get) and resource ('云服务提供商列表' - cloud service provider list), making the function immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'check_provider_availability' or 'get_instance_by_provider', which prevents a perfect score.
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. With multiple sibling tools that interact with specific providers (e.g., 'get_aws_instance_info', 'list_alibaba_instances'), there's no indication that this tool should be used to discover available providers before using provider-specific tools. The description lacks any 'when-to-use' context or prerequisites.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions returning a dictionary of system status information, it doesn't specify what 'entire system' means (e.g., all cloud providers, local infrastructure, or something else), whether there are authentication requirements, rate limits, or what specific data is included in the status overview.
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 brief with two sentences, but the second sentence 'Returns: Dict: 系统状态信息' is redundant given that an output schema exists. The first sentence is front-loaded but could be more informative about what 'system status' entails.
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 that the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description doesn't need to explain parameters or return values. However, for a tool with no annotations and many sibling tools, it should provide more context about what 'system status' includes and how it differs from other status-related tools to be 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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and it correctly doesn't mention any parameters, maintaining a baseline score of 4 for this scenario.
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 purpose as '获取整个系统的状态概览' (get an overview of the entire system's status), which is a specific verb+resource combination. However, it doesn't distinguish itself from sibling tools like 'check_provider_availability' or various monitoring tools, which might provide overlapping or related status information.
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. With many sibling tools focused on specific providers or instances, there's no indication of whether this tool provides a higher-level summary, aggregates data from other tools, or serves a different purpose entirely.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists instances but doesn't describe any behavioral traits such as whether it's read-only, safe to use, requires authentication, has rate limits, or what the output format entails. For a tool with zero annotation coverage, this is a significant gap in 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, clear sentence in Chinese ('列出所有阿里云ECS实例') that directly states the tool's purpose without any unnecessary words. It is front-loaded and efficiently conveys the core action, making it highly concise and well-structured for its 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 (0 parameters, output schema exists), the description is minimally adequate. It states what the tool does but lacks details on behavioral aspects, usage context, or output interpretation. With an output schema present, the description doesn't need to explain return values, but it should provide more guidance on when and how to use the tool effectively, especially compared to siblings.
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 0 parameters with 100% coverage, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional information is required or provided, which is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出所有阿里云ECS实例' clearly states the action (list) and resource (Alibaba Cloud ECS instances) in Chinese, making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'list_aws_instances' or 'list_digitalocean_droplets' beyond specifying the provider, which is a basic differentiation but not fully explicit about unique scope or functionality compared to similar 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 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 doesn't mention any prerequisites, context for usage, or comparisons to sibling tools like 'get_alibaba_instance_info' for detailed information or 'get_instance_by_provider' for cross-provider queries. This lack of usage context leaves the agent without explicit direction.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions returning a dictionary of AWS instances but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or error handling. This is a significant gap for a tool that likely interacts with cloud resources.
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 brief with two sentences, but it's not optimally structured. The first sentence states the purpose, and the second redundantly notes the return type (which is already covered by the output schema). It could be more front-loaded with key behavioral insights.
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 (0 parameters, output schema exists) and lack of annotations, the description is minimally adequate. However, it misses opportunities to explain scope (e.g., all regions vs. current region), filtering options, or how it differs from sibling tools, leaving gaps in contextual 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could have mentioned any implicit assumptions (e.g., region or credential context). Baseline is 4 for zero parameters.
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 ('列出' meaning 'list') and resource ('AWS EC2实例'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_alibaba_instances' or 'list_digitalocean_droplets' beyond specifying AWS EC2, which is somewhat helpful but not explicit about scope distinctions.
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 like 'get_aws_instance_info' or 'get_instance_by_provider'. The description lacks context about use cases, prerequisites, or exclusions, leaving the agent without direction on 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?
With no annotations provided, the description carries full burden. It discloses one important behavioral trait: '需要三次确认' (requires three confirmations), which explains why there are three confirmation parameters in the schema. However, it doesn't mention other critical behaviors like whether this is a destructive operation, what permissions are required, rate limits, or what happens if the instance is already powered on. The description adds some value but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one sentence containing 7 Chinese characters. It's front-loaded with the core action and includes the critical behavioral constraint. Every word earns its place with no wasted text.
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?
Given this is a power management tool with 4 parameters, 0% schema coverage, no annotations, but with an output schema, the description is incomplete. While the output schema might handle return values, the description doesn't address the mutation nature of the operation, safety considerations, or parameter requirements. For a tool that changes instance state and requires multiple confirmations, more context is needed.
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?
With 0% schema description coverage for 4 parameters, the description must compensate but fails to do so. It mentions '需要三次确认' (requires three confirmations) which hints at the purpose of three parameters, but doesn't explain what 'instance_id' is, what format confirmations should take, or why three separate confirmations are needed versus one. The description adds minimal semantic value beyond what's obvious from parameter names.
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 ('开启' meaning 'power on') and the resource ('Vultr实例' meaning 'Vultr instance'), providing a specific verb+resource combination. It distinguishes from sibling tools like 'power_off_vultr_instance' by specifying the opposite power action. However, it doesn't explicitly differentiate from 'manage_instance_power' which might handle multiple power states.
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 doesn't mention prerequisites (e.g., instance must be powered off), when not to use it, or how it differs from similar tools like 'reboot_vultr_instance' or 'manage_instance_power'. The '需要三次确认' (requires three confirmations) is a behavioral constraint rather than usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves storage details but doesn't mention whether it's a read-only operation, requires specific AWS permissions, has rate limits, or what happens on errors. For a cloud API tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by structured Args and Returns sections. Every sentence earns its place, though the Returns section could be more detailed given the output schema exists.
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 has an output schema (which covers return values), the description is moderately complete. It defines the purpose and parameter semantics adequately. However, for a cloud API tool with no annotations, it lacks behavioral context like authentication needs, error handling, or rate limits, which are important for an agent to use it 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 description adds meaningful context for the single parameter: 'instance_id (str): EC2实例ID' clarifies it's an EC2 instance ID. With 0% schema description coverage (schema only has 'Instance Id' as title), this compensates well. However, it doesn't specify format constraints (e.g., AWS instance ID pattern like 'i-1234567890abcdef0').
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 purpose: '获取AWS EC2实例的存储详细信息' (Get AWS EC2 instance storage details). It specifies the verb ('获取' - get) and resource ('AWS EC2实例的存储详细信息' - AWS EC2 instance storage details), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_aws_instance_info', which might provide broader instance information.
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 doesn't mention sibling tools like 'get_aws_instance_info' or 'get_aws_instance_monitoring', nor does it specify use cases, prerequisites, or exclusions. The agent must infer usage from the name and description alone.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states the tool '获取DigitalOcean Droplet信息' (gets Droplet information), it doesn't describe what specific information is returned, whether this is a read-only operation, what happens if the droplet doesn't exist, authentication requirements, rate limits, or any error conditions. For a tool with zero annotation coverage, this represents significant gaps in behavioral 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 appropriately concise with three clear sections: purpose statement, parameter explanation, and return value indication. Each sentence earns its place, though the structure could be slightly improved by front-loading more behavioral context. The bilingual nature (Chinese purpose, English parameter names) is efficient but might cause minor parsing issues for some agents.
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 that there's an output schema (which should document the return structure), the description doesn't need to detail return values. However, for a tool with no annotations and multiple sibling tools, the description should provide more context about when to use this specific tool, what authentication is required, and what happens in error cases. The parameter explanation is good, but overall completeness is only adequate.
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 description adds meaningful context for the single parameter by explaining that 'ip_address_or_id' accepts either a public IP address or a Droplet ID. This is valuable semantic information since the schema only shows it's a string with 0% description coverage. The description compensates well for the schema's lack of parameter documentation, though it doesn't specify format requirements (e.g., IP address format, ID format).
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 purpose as '获取DigitalOcean Droplet信息' (Get DigitalOcean Droplet information), which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'list_digitalocean_droplets' (which lists multiple droplets) and 'get_digitalocean_droplet_monitoring' (which focuses on monitoring data). However, it doesn't explicitly differentiate from 'get_instance_info' or 'get_instance_by_provider' which might serve similar functions across 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 doesn't mention when this tool is appropriate compared to 'list_digitalocean_droplets' (for listing all droplets) or 'get_digitalocean_droplet_monitoring' (for performance metrics). There's also no mention of prerequisites like authentication requirements or rate limits that might affect usage decisions.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool supports multiple cloud platforms and lists parameters, but doesn't describe critical behavioral aspects: whether this is a destructive operation (power off/reboot/shutdown clearly are), what permissions are required, whether operations are reversible, error handling, rate limits, or what the return dictionary contains. For a power management tool with potentially destructive actions, this is a significant gap.
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 efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence serves a purpose: establishing scope, documenting parameters, and indicating return type. The parameter documentation is comprehensive yet concise. Minor improvement could be adding a brief usage note about the confirmation parameters.
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 this is a potentially destructive power management tool with 6 parameters, no annotations, and an output schema (though unspecified), the description is moderately complete. It covers parameters well and states the return type, but lacks critical behavioral context about destructive operations, permissions, and error handling. The presence of an output schema means the description doesn't need to detail return values, but other gaps remain significant for safe tool 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?
With 0% schema description coverage, the description provides substantial parameter information beyond the bare schema. It documents all 6 parameters with their purposes: provider (with specific platform options), instance_id, action (with specific operation types), and three confirmation parameters. This compensates well for the schema's lack of descriptions, though it doesn't explain the confirmation parameters' exact validation logic or format requirements.
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 purpose as '通用的实例电源管理函数（支持所有云平台）' which translates to 'general instance power management function (supports all cloud platforms)'. This specifies the verb (manage power) and resource (instances), and mentions multi-platform support. However, it doesn't explicitly distinguish this unified tool from the many provider-specific power management siblings like 'power_on_alibaba_instance' or 'reboot_digitalocean_droplet'.
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 the many provider-specific alternatives listed among siblings. There's no mention of prerequisites, trade-offs between using this unified tool versus individual provider tools, or any context about when this multi-platform approach is preferable. The agent must infer usage from the description's mention of supporting all platforms.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states '只读' (read-only), which is helpful for safety, but lacks other critical details: authentication requirements, rate limits, error handling, or what specific information is returned. The description adds minimal value beyond the basic read-only hint, leaving significant gaps in 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first line. The Args and Returns sections are structured but could be more integrated. It avoids redundancy, though the translation to English in the response might slightly affect conciseness. Overall, it's efficient with minimal 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?
Given the tool's moderate complexity (single parameter, read-only operation) and the presence of an output schema (which handles return values), the description is partially complete. It covers the basic purpose and parameter semantics but lacks usage guidelines, detailed behavioral context, and integration with sibling tools. With no annotations and low schema coverage, it should do more to compensate, making it adequate but with 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?
Schema description coverage is 0%, so the description must compensate. It adds semantics by explaining that 'ip_address_or_id' accepts either a public IP address or instance ID, which clarifies the parameter's purpose beyond the schema's generic string type. However, it doesn't provide format examples, validation rules, or handling of ambiguous inputs, leaving some gaps in parameter understanding.
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 purpose: '获取AWS EC2实例信息（只读）' translates to 'Get AWS EC2 instance information (read-only)'. This specifies the verb ('get'), resource ('AWS EC2 instance information'), and scope ('read-only'). However, it doesn't explicitly differentiate from siblings like 'get_aws_instance_monitoring' or 'list_aws_instances', which reduces the score from 5 to 4.
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 doesn't mention sibling tools like 'get_instance_info' (generic) or 'list_aws_instances' (list all), nor does it specify use cases or exclusions. The only implied usage is retrieving info for a specific instance, but no explicit alternatives are provided.
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?
No annotations are provided, so the description carries the full burden. It states it lists droplets but doesn't disclose behavioral traits such as whether it requires authentication, rate limits, pagination, or what the output format includes. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 sentence in Chinese ('列出所有DigitalOcean Droplets'), which is appropriately sized and front-loaded with the core action. There's no wasted text, making it highly concise and well-structured for its 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?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, with no annotations and a read operation, it should ideally mention output characteristics or usage context. It's complete enough for a simple list tool but lacks depth for full agent 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 tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description doesn't add parameter semantics, but with no parameters, a baseline of 4 is appropriate as it doesn't need to compensate for any gaps.
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 '列出所有DigitalOcean Droplets' clearly states the verb ('列出' meaning 'list') and resource ('DigitalOcean Droplets'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_digitalocean_droplet_info' or 'list_aws_instances', which would require mentioning it returns all droplets without filtering or that it's specific to DigitalOcean (though implied by name).
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 doesn't mention when to choose it over 'get_digitalocean_droplet_info' (for single droplet details) or 'list_aws_instances' (for other providers), nor does it specify any prerequisites or exclusions. Usage is implied by the name but not explicitly stated.
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?
No annotations are provided, so the description carries full burden. It states this is a query operation ('查询'), implying read-only behavior, but doesn't disclose authentication requirements, rate limits, error conditions, or what happens if the instance doesn't exist. For a tool with no annotation coverage, this leaves significant behavioral gaps.
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 efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence earns its place: the first sentence states the purpose, and the parameter/return explanations are necessary given the 0% schema coverage. 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 2 parameters with 0% schema coverage and no annotations, the description does well by fully explaining parameter semantics. The presence of an output schema (Returns: Dict) means the description doesn't need to detail return values. However, for a read operation with no annotations, it could better address authentication, errors, or rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides clear parameter semantics: 'provider' is explained as cloud service provider with enumerated values ('aws', 'digitalocean', 'vultr', 'alibaba'), and 'identifier' is explained as instance identifier (IP address or instance ID). This adds essential meaning beyond the bare 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 the tool's purpose as '查询实例信息' (query instance information) with a specific resource (instances) and verb (query). It distinguishes itself from siblings by specifying '通过明确指定的云服务提供商' (through explicitly specified cloud service provider), which differentiates it from generic instance query tools like 'get_instance_info'. However, it doesn't fully distinguish from provider-specific tools like 'get_aws_instance_info' beyond being multi-provider.
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 through the parameter descriptions (provider and identifier), suggesting this tool is for querying instances when you know both the provider and identifier. However, it doesn't explicitly state when to use this versus the many sibling tools (like provider-specific instance info tools or list tools), nor does it mention prerequisites 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?
With no annotations provided, the description carries full burden. It effectively discloses the critical behavioral trait of requiring three confirmations (IP, name, and operation type), which is essential for understanding this tool's safety mechanism. It also mentions the return type ('Dict: 操作结果或确认要求' - operation result or confirmation request), adding useful context about possible outcomes.
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 well-structured with clear sections (Args, Returns) and uses minimal but effective language. Every sentence earns its place by providing essential information. The only minor improvement could be making the purpose statement more prominent rather than embedding it in the first line.
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 this is a mutation tool with no annotations but with an output schema, the description provides good coverage. It explains the confirmation requirements, documents all parameters thoroughly, and mentions the return type. The main gap is lack of information about authentication requirements or error conditions, but the output schema likely covers return values adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. It explains all four parameters: droplet_id, ip_confirmation, name_confirmation, and operation_confirmation with their purposes and even specifies acceptable values for operation_confirmation ('输入"开机"或"power_on"' - enter '开机' or 'power_on'). This adds significant value beyond the bare 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 the action ('开启' meaning 'power on') and the resource ('DigitalOcean Droplet'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'power_on_alibaba_instance' or 'power_on_vultr_instance' beyond mentioning DigitalOcean 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 usage through the phrase '需要三次确认' (requires three confirmations), suggesting this tool should be used when extra caution is needed. However, it doesn't provide explicit guidance on when to choose this over alternatives like 'manage_instance_power' or other power-on tools for different providers.
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?
With no annotations provided, the description carries full burden. It describes the core behavior (automatic detection + instance retrieval) and mentions the return format (Dict with provider info and instance details). However, it doesn't disclose important behavioral aspects like error handling, rate limits, authentication requirements, or whether this is a read-only 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 perfectly structured and concise. It begins with a clear purpose statement, then provides well-organized Args and Returns sections. Every sentence earns its place, with no redundant information. The bilingual format (Chinese purpose, English parameter names) is 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 an output schema (Returns: Dict), the description doesn't need to detail return values. It adequately covers the tool's purpose and parameters. However, for a tool with no annotations and moderate complexity (automatic detection logic), additional behavioral context about error cases or limitations would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the schema. With 0% schema description coverage, the description fully documents both parameters: ip_address is explained as a public IP address, and provider is clearly described as optional with specific allowed values ('aws', 'digitalocean', 'vultr', 'alibaba'). This completely compensates for the schema's lack of 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 purpose: '根据IP地址自动检测云服务提供商并获取实例信息' (Automatically detect cloud service provider based on IP address and get instance information). It specifies both the detection and retrieval functions, distinguishing it from sibling tools like get_aws_instance_info which require explicit provider specification.
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 usage: it automatically detects the provider when only an IP is given, but allows optional explicit provider specification. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools.
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:

[![cloud_manage_mcp_server MCP server](https://glama.ai/mcp/servers/rainhan99/cloud_manage_mcp_server/badges/card.svg)](https://glama.ai/mcp/servers/rainhan99/cloud_manage_mcp_server)

Score Badge

Copy to your README.md:

[![cloud_manage_mcp_server MCP server](https://glama.ai/mcp/servers/rainhan99/cloud_manage_mcp_server/badges/score.svg)](https://glama.ai/mcp/servers/rainhan99/cloud_manage_mcp_server)

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/rainhan99/cloud_manage_mcp_server'

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