OPS MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, with clear separation between monitoring (e.g., get_system_load, monitor_processes), Docker operations (e.g., list_docker_containers, check_docker_health), and security tasks (e.g., security_vulnerability_scan, check_ssh_risk_logins). However, some overlap exists between analyze_logs and get_container_logs, as both involve log analysis, which could cause minor confusion.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern in snake_case for most tools (e.g., check_service_status, get_memory_info), making them predictable and readable. The only deviation is _list_available_tools, which uses an underscore prefix and is less descriptive, but this is a minor inconsistency in an otherwise uniform set.
Tool Count4/5
With 19 tools, the count is slightly high but reasonable for an operations server covering monitoring, Docker, and security. It avoids being overwhelming (e.g., not 25+ tools) and provides comprehensive coverage without excessive redundancy, though it could be streamlined by merging some overlapping functions.
Completeness4/5
The tool set offers good coverage for server operations, including monitoring (e.g., get_system_load), Docker management (e.g., list_docker_containers), and security (e.g., security_vulnerability_scan). Minor gaps exist, such as lack of tools for updating configurations or handling backups beyond critical files, but agents can work around these with existing tools.
Average 2.4/5 across 19 of 19 tools scored. Lowest: 1/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?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool does ('获取操作系统详细信息') without mentioning that it requires remote authentication (hostname, username, password), operates over SSH (port 22 default), has timeout behavior, or what kind of OS details are returned. For a tool with 5 parameters including authentication credentials, this is inadequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at a single phrase ('获取操作系统详细信息'). While this represents under-specification rather than ideal conciseness, it contains no redundant or unnecessary information. Every word contributes to stating the basic purpose, earning its place in the minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (including authentication credentials), no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It doesn't explain what OS details are returned, how authentication works, what the timeout means, or any behavioral characteristics. The description fails to provide the minimal context needed for an agent to understand this tool's operation.
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?
With 0% schema description coverage for 5 parameters, the description provides no information about any parameters. The schema shows this tool requires hostname and username authentication with optional password, port, and timeout settings, but the description doesn't mention these requirements or their purposes. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取操作系统详细信息' (Get operating system details) states the basic purpose but is vague about scope and specificity. It doesn't distinguish this tool from siblings like 'get_system_load' or 'get_memory_info' that also retrieve system information. The description restates the tool name concept without clarifying what specific OS details are obtained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 siblings like 'get_system_load', 'get_memory_info', and 'remote_server_inspection' that also retrieve system information, there's no indication of what makes this tool distinct or when it should be preferred over other options. No context about prerequisites or typical use cases is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but provides none. It doesn't mention whether this is a read-only operation, what permissions are required, whether it connects to remote Docker daemons, what format the output takes, or any error conditions. The description is completely inadequate for behavioral understanding.
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 maximally concise - a single phrase that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. While this conciseness comes at the cost of completeness, the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It doesn't explain what the tool returns, how to interpret results, what authentication is needed, or any operational context. This leaves the agent with insufficient information to use the tool effectively.
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?
The description provides zero information about parameters. With 5 parameters (hostname, username, password, port, timeout) and 0% schema description coverage, the description doesn't explain what any parameters mean, why they're needed, or how they affect the operation. This leaves all parameters completely undocumented.
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 '列出Docker镜像' (List Docker images) clearly states the verb and resource, but it's vague about scope and doesn't distinguish from sibling tools like 'list_docker_containers' or 'list_docker_volumes'. It specifies what it does but lacks detail about what kind of listing this provides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 for Docker operations (list_docker_containers, list_docker_volumes, check_docker_health) but no indication of when this specific image listing tool is appropriate versus those other options.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. '列出Docker卷' only states the action without any information about authentication requirements (though parameters suggest SSH connection), rate limits, error conditions, or what the output looks like. For a tool with 5 parameters including credentials, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase '列出Docker卷' - which is appropriately sized for what it communicates. There's no wasted language, though this conciseness comes at the cost of completeness. The structure is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters including authentication, no annotations, no output schema, 0% schema coverage), the description is completely inadequate. It doesn't explain the SSH connection requirement, authentication needs, what information is returned about volumes, or how this differs from other Docker listing tools. For a tool that appears to connect remotely to list Docker resources, this minimal description leaves critical 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 5 parameters have descriptions in the schema. The tool description provides absolutely no information about parameters - it doesn't mention that this requires SSH connection parameters (hostname, username, password, port, timeout) or explain their purpose. The description fails to compensate for the complete lack of schema documentation.
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 '列出Docker卷' (List Docker volumes) states a clear verb ('list') and resource ('Docker volumes'), which is better than a tautology. However, it doesn't distinguish this tool from its sibling 'list_docker_containers' or 'list_docker_images' - all three appear to list different Docker resources without clear differentiation in the description itself.
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 listing tools in the sibling set (list_docker_containers, list_docker_images, list_docker_volumes), but the description doesn't help an agent choose between them or indicate any specific context for volume listing versus other Docker operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but fails to disclose behavioral traits. It doesn't mention that this likely requires SSH authentication (hostname, username, password), involves remote execution, has a timeout, or what the output format looks like. This leaves critical operational context unspecified.
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, which is appropriately concise. However, it's too brief given the tool's complexity—it doesn't front-load critical information about authentication or output.
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 (8 parameters, no annotations, no output schema), the description is incomplete. It lacks details on authentication, remote execution, output format, and error handling, making it inadequate for safe and effective use by an AI agent.
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 but adds no parameter information. It doesn't explain what 'container', 'tail', 'since', or other parameters mean, their formats (e.g., 'since' as timestamp), or how they affect the log retrieval. This leaves 8 parameters largely undocumented.
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 '获取指定容器的日志' (Get logs for a specified container) clearly states the verb (get) and resource (container logs), but it's vague about scope and format. It doesn't distinguish from sibling tools like 'analyze_logs' or 'monitor_container_stats' which might also involve container logs.
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 (e.g., troubleshooting vs. monitoring), or how it differs from sibling tools like 'analyze_logs' or 'monitor_container_stats'.
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. '备份' (backup) implies a read-only copy operation, but the description doesn't specify whether this requires special permissions, what happens if files don't exist, whether the operation is idempotent, or what the expected output format is. It mentions '重要系统配置文件' (important system configuration files) but doesn't define importance criteria or default 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 extremely concise - a single Chinese phrase. While this is efficient, it's arguably under-specified rather than appropriately concise. There's no wasted language, but also no structural elements like separation of purpose from usage guidelines. The front-loading is perfect since there's only one element to front-load.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations and no output schema, the description is severely incomplete. It doesn't explain the remote SSH nature of the operation (implied by parameters), doesn't describe what constitutes a successful backup, doesn't mention error conditions, and provides no information about return values or side effects. The description leaves critical gaps for understanding how to properly invoke and interpret results from this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 7 parameters, the description provides no information about any parameters. It doesn't explain what 'hostname', 'username', 'password', 'port', 'files', 'backup_dir', or 'timeout' mean in context, nor does it clarify the relationship between these parameters (e.g., that this appears to be a remote SSH backup operation). The description fails to compensate for the complete lack of schema documentation.
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 '备份重要系统配置文件' (Backup important system configuration files) clearly states the action (backup) and target (system configuration files), but it's vague about scope and doesn't differentiate from sibling tools. It doesn't specify what makes files 'important' or whether this is for local or remote systems, though the input schema suggests remote SSH access via hostname/username parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or exclusions. With sibling tools like 'remote_server_inspection' and 'security_vulnerability_scan' available, there's no indication of how this backup tool fits into the overall workflow or when it should be preferred over other inspection tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('检查Docker服务的健康状态和基本信息') without revealing any behavioral traits. It doesn't mention that this likely performs a remote check via SSH (implied by parameters like hostname, username, password, port), whether it's read-only or has side effects, what specific health metrics are returned, or any error handling. 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: '检查Docker服务的健康状态和基本信息'. It's front-loaded with the core action and resource, with no wasted words. Every part of the sentence directly contributes to understanding the tool's purpose, making it appropriately concise for a simple health check tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., remote SSH execution, read-only nature), parameter meanings, expected outputs, or error conditions. For a tool that likely performs remote system checks with multiple inputs, this minimal description fails to provide sufficient context for safe and effective use.
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 5 parameters have descriptions in the schema. The tool description adds no information about parameters beyond what's implied by the tool's purpose. It doesn't explain what 'hostname', 'username', 'password', 'port', or 'timeout' mean in this context, their expected formats, or how they affect the Docker health check. With 0% coverage and no compensation in the description, this is inadequate.
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 '检查Docker服务的健康状态和基本信息' clearly states the tool's purpose as checking Docker service health and basic information. It specifies the verb '检查' (check) and resource 'Docker服务' (Docker service), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'check_service_status' or 'monitor_container_stats', which could also relate to Docker monitoring.
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, such as requiring SSH access via the hostname and username parameters, or differentiate it from siblings like 'check_service_status' (which might check general services) or 'list_docker_containers' (which lists containers without health info). Without this context, users 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?
No annotations are provided, so the description carries full burden. It mentions checking status but doesn't disclose behavioral traits like authentication needs (implied by username/password parameters), network dependencies, timeouts, or what the output might look like. This is a significant gap for a tool with multiple parameters and no output schema.
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 directly states the purpose. It's front-loaded with no wasted words, though it could benefit from more detail given the tool's complexity. The brevity is appropriate but under-specified for the number of parameters.
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 has 6 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain the input semantics, behavioral aspects, or expected results. For a tool that likely involves remote connections and service checks, more context is needed to guide 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 description must compensate. It only vaguely references 'specified services', which relates to the 'services' parameter, but doesn't explain the meaning of other parameters like hostname, username, password, port, or timeout. This leaves most parameters undocumented and unclear in context.
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 '检查指定服务的运行状态' (Check the running status of specified services) clearly states the verb ('check') and resource ('services'), but it's vague about scope and method. It doesn't distinguish from siblings like 'check_docker_health' or 'monitor_processes', which might overlap in functionality. The purpose is understandable but lacks specificity.
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. For example, it doesn't clarify if this is for local or remote services, or how it differs from 'check_docker_health' or 'monitor_processes'. The description implies usage for checking service status but offers no context on 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 but reveals minimal behavioral traits. It mentions listing containers 'and their information' but doesn't specify what information, format, or behavior (e.g., pagination, error handling, authentication requirements). The description doesn't contradict annotations since none exist, but it fails to adequately describe the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short phrase) and front-loaded with the core action. However, this brevity comes at the cost of completeness - it's under-specified rather than efficiently informative. Every word earns its place, but more words are needed.
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 6 parameters with 0% schema coverage, no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain what information is returned, how parameters interact, or how this differs from related container tools. For a tool with remote authentication parameters and container listing functionality, 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 6 parameters, the description provides no parameter information beyond what's implied by the tool name. It doesn't explain what 'hostname', 'username', 'show_all', or other parameters mean in context, leaving significant gaps in understanding how to use the tool effectively.
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 '列出Docker容器及其信息' (List Docker containers and their information) states the basic verb and resource, but it's vague about scope and doesn't differentiate from siblings like 'list_docker_images' or 'list_docker_volumes'. It doesn't specify whether this lists all containers, running containers, or provides detailed vs summary 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 about when to use this tool versus alternatives. There's no mention of prerequisites, context, or comparison with sibling tools like 'monitor_container_stats' or 'get_container_logs'. The description offers no usage context beyond the basic action.
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 the tool checks configuration and ports, but doesn't disclose behavioral traits such as whether it performs read-only operations (likely, but not confirmed), authentication requirements (implied by username/password parameters but not explained), potential side effects, or output format. This leaves significant gaps for an agent to understand how to invoke it safely.
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 purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste, 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 complexity (a tool with 5 parameters for checking firewall configurations, likely involving remote access), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't provide enough context for an agent to understand the tool's behavior, inputs, or outputs, 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%, meaning parameters like hostname, username, password, port, and timeout are undocumented in the schema. The description adds no parameter semantics—it doesn't explain what these inputs mean (e.g., hostname for target server, password for authentication) or how they affect the check. This fails to compensate for the low coverage, leaving parameters ambiguous.
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 '检查防火墙配置和开放端口' (Check firewall configuration and open ports) clearly states the tool's purpose with a specific verb ('check') and resource ('firewall configuration and open ports'), but it doesn't distinguish this from sibling tools like 'inspect_network' or 'security_vulnerability_scan', which might have overlapping functionality. The purpose is understandable but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., SSH access implied by parameters), exclusions, or compare it to siblings like 'inspect_network' or 'security_vulnerability_scan'. Usage is implied through the action 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the purpose without revealing that this likely involves remote SSH access (implied by hostname, username, password parameters), potential authentication requirements, timeout behavior, or what the output format might be. This is inadequate for a tool with multiple parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase, '获取系统负载信息', which is front-loaded and wastes no words. While it may be too brief for completeness, it earns full marks for conciseness as every word contributes directly to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the remote access nature, parameter roles, expected output, or error conditions. For a tool that likely performs system monitoring via SSH, this leaves significant gaps in understanding how to use it effectively.
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 by explaining parameters, but it adds no semantic information beyond the tool's name. Parameters like hostname, username, password, port, and timeout are undocumented in both schema and description, leaving their purposes and formats unclear. This fails to address the coverage gap.
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 '获取系统负载信息' (Get system load information) states what the tool does but is vague about scope and method. It doesn't specify what 'system load' includes (CPU, memory, processes) or how it's obtained (local vs remote). While it distinguishes from some siblings like 'get_memory_info' by focusing on load, it lacks the specificity needed for a higher 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. It doesn't mention prerequisites like SSH access, compare to similar tools (e.g., 'get_memory_info' for memory-specific data), or indicate scenarios where it's appropriate. This leaves the agent with little 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('inspect') but doesn't describe what the inspection entails (e.g., returns interface details, connection metrics), whether it requires authentication (implied by parameters but not stated), or any side effects (e.g., read-only vs. disruptive). For a tool with 5 parameters and no annotation coverage, this is inadequate.
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 unnecessary words. It's appropriately sized and front-loaded, with zero waste, making it easy 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 complexity (5 parameters, no annotations, no output schema) and the server's context with many sibling tools, the description is incomplete. It doesn't cover parameter meanings, usage scenarios, behavioral details, or output expectations, leaving significant gaps for the agent to operate effectively.
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%, meaning none of the 5 parameters are documented in the schema. The description adds no information about parameters, failing to compensate for the coverage gap. It doesn't explain what 'hostname', 'username', etc., are used for (e.g., SSH connection details), leaving their semantics unclear beyond the schema's basic titles.
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 '检查网络接口和连接状态' (Inspect network interfaces and connection status) states a clear purpose with a specific verb ('inspect') and resource ('network interfaces and connection status'), but it doesn't distinguish this tool from siblings like 'remote_server_inspection' or 'check_firewall_config' that might also involve network-related operations. It avoids tautology but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., troubleshooting vs. monitoring), or exclusions, leaving the agent to infer usage from the tool name and parameters alone. This is a significant gap given the server has multiple inspection-related 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?
With no annotations provided, the description carries full burden for behavioral disclosure. '执行远程服务器巡检' implies a read-only inspection operation, but it doesn't disclose whether this requires SSH access, what permissions are needed, whether it's destructive, what the output format is, or any rate limits. The description provides minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one phrase ('执行远程服务器巡检'). While this may be too brief for adequate documentation, it's perfectly front-loaded with zero wasted words and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description is severely incomplete. It doesn't explain what the tool actually inspects, what the output looks like, or provide any context about the inspection process. The single phrase is inadequate for the tool's complexity.
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 and 7 parameters, the description provides no information about any parameters. It doesn't explain what 'inspection_modules' are, what values they accept, what 'use_connection_cache' means, or any parameter semantics. The description fails to compensate for the complete lack of schema documentation.
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 '执行远程服务器巡检' (Perform remote server inspection) states a clear verb ('执行' - perform) and resource ('远程服务器巡检' - remote server inspection), but it's vague about what 'inspection' entails compared to siblings like 'get_system_load' or 'check_service_status'. It doesn't specifically differentiate from other monitoring tools in the sibling list.
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_system_load', 'check_service_status', and 'get_os_details' that perform specific checks, the description doesn't indicate whether this is a comprehensive inspection tool or how it relates to these more focused 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?
With no annotations provided, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't mention permissions needed, whether it's destructive, rate limits, output format, or error handling, leaving critical operational details unclear for a security scanning tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('执行基础安全漏洞扫描') that is front-loaded and wastes no words. It's appropriately sized for conveying the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't address the tool's complexity, missing details on what the scan entails, expected results, or how parameters interact, 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%, so the description must compensate but adds no parameter information. It doesn't explain what 'hostname', 'username', 'scan_type', or other parameters mean in context, failing to provide meaning beyond the bare schema with titles only.
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 '执行基础安全漏洞扫描' (perform basic security vulnerability scan) states a general purpose with a verb and resource, but it's vague about scope and methodology. It doesn't distinguish from potential sibling tools like 'check_firewall_config' or 'inspect_network', leaving ambiguity about what 'basic' entails.
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 'check_ssh_risk_logins' and 'remote_server_inspection', the description lacks context for choosing this scan over other security-related tools, offering no explicit or implied usage scenarios.
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 'analyze' implies a read-only operation, the description doesn't specify whether this requires authentication, what permissions are needed, how results are returned, or any rate limits. It mentions analyzing 'errors and warnings' but doesn't explain the analysis methodology or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. There's no wasted language or unnecessary elaboration. It's appropriately sized for a tool with this level of 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?
For a tool with 8 parameters, no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain what the analysis produces, how results are structured, what authentication is required, or provide any parameter context. The agent would struggle to use this tool effectively without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about any of the 8 parameters, and schema description coverage is 0%. The agent must rely entirely on parameter titles and types in the schema, with no contextual explanation of what 'hostname', 'username', 'pattern', or other parameters mean in this specific analysis context.
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: '分析服务器日志文件中的错误和警告' (analyze errors and warnings in server log files). It specifies both the verb ('analyze') and resource ('server log files'), making it easy to understand what the tool does. However, it doesn't differentiate from sibling tools like 'get_container_logs' or 'check_ssh_risk_logins', 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. There's no mention of prerequisites, when this tool is appropriate versus other logging tools like 'get_container_logs', or any exclusions. The agent must infer usage from the tool name and parameters 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. It mentions checking '失败尝试和可疑IP' (failed attempts and suspicious IPs), which hints at analysis behavior, but doesn't describe what the tool actually does (e.g., reads logs, analyzes patterns, returns risk scores), potential side effects (e.g., network connections, log parsing), authentication needs (implied by SSH parameters but not stated), or output format. For a tool with 7 parameters and no annotations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese: '检查SSH登录风险，包括失败尝试和可疑IP'. It's front-loaded with the core purpose and includes key elements (SSH, risks, failed attempts, suspicious IPs) without waste. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's behavior, parameter usage, or output, leaving gaps in understanding how to invoke it correctly. For a security analysis tool with multiple inputs, more detail is needed to be complete, especially without annotations or output schema to fill in the gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds no meaning beyond the schema—it doesn't explain what 'hostname', 'username', 'password', etc., are used for (e.g., SSH connection details vs. log analysis), how 'threshold' relates to risk detection, or what 'log_file' defaults to. With 7 parameters and no schema descriptions, the description fails to provide necessary context, scoring below the baseline of 3.
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: '检查SSH登录风险，包括失败尝试和可疑IP' (Check SSH login risks, including failed attempts and suspicious IPs). It specifies the verb ('检查' - check) and resource ('SSH登录风险' - SSH login risks), and distinguishes it from siblings like 'analyze_logs' or 'security_vulnerability_scan' by focusing specifically on SSH. However, it doesn't explicitly differentiate from all siblings (e.g., 'check_firewall_config' might overlap in security context), so it's not a perfect 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 prerequisites (e.g., SSH access, log file availability), exclusions (e.g., not for non-SSH logs), or compare it to siblings like 'analyze_logs' (general log analysis) or 'security_vulnerability_scan' (broader security checks). Usage is implied by the name and description 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only monitoring operation but doesn't specify critical details: whether it's real-time or historical, output format (e.g., metrics, alerts), authentication requirements (implied by SSH params but not stated), or potential side effects (e.g., performance impact). This leaves significant gaps for a tool with 6 parameters.
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 is front-loaded with the core action and resource, with no redundant or verbose elements, making it highly concise.
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 (6 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., how monitoring works, output format), parameter usage, and differentiation from siblings. For a monitoring tool with SSH-related inputs, this minimal description is insufficient for effective agent 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 description must compensate for undocumented parameters. It mentions 'containers' indirectly but adds no meaning beyond the schema—no explanation of what 'monitor' entails for each parameter (e.g., hostname for SSH, containers array for filtering, timeout for operation limits). This fails to address the coverage gap adequately.
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 '监控容器的资源使用情况' (Monitor container resource usage) clearly states the verb (monitor) and resource (container resource usage). It distinguishes from siblings like 'list_docker_containers' (lists containers) or 'get_container_logs' (gets logs), but doesn't specify what resource metrics (e.g., CPU, memory) are monitored, keeping it from 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. It doesn't mention prerequisites (e.g., SSH access to a host), compare to siblings like 'check_docker_health' or 'get_memory_info', or specify use cases (e.g., real-time monitoring vs. one-time checks).
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 monitoring and returning data, implying a read-only operation, but doesn't specify authentication requirements (e.g., SSH credentials), potential side effects (e.g., network connections, process queries), rate limits, or error handling. For a tool with 7 parameters and remote server interaction, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: a single sentence that directly states the tool's core function. There is no wasted language or redundancy, making it efficient and easy to parse. Every word contributes to understanding the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, remote server interaction, no annotations, no output schema), the description is incomplete. It lacks details on authentication, network behavior, output format, error conditions, and how it differs from sibling tools. For a monitoring tool with multiple inputs and no structured output, more context is needed to ensure 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 description must compensate by explaining parameters. It only implicitly references 'hostname' (via '远程服务器' - remote server) and 'top_n'/'sort_by' (via '占用资源最多的进程' - most resource-consuming processes), but doesn't clarify the purpose of 'username', 'password', 'port', 'timeout', or the meaning of 'sort_by' values. With 7 parameters, this minimal coverage is inadequate.
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: '监控远程服务器进程，返回占用资源最多的进程' (monitor remote server processes, return the processes consuming the most resources). It specifies the verb (monitor), resource (remote server processes), and outcome (return top resource-consuming processes). However, it doesn't explicitly differentiate from sibling tools like 'get_system_load' or 'monitor_container_stats', 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. It doesn't mention prerequisites (e.g., SSH access), compare to siblings like 'get_system_load' (which might provide overall system metrics) or 'monitor_container_stats' (which focuses on containers), or specify scenarios where this tool is preferred. Usage is implied 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?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a read-only operation, if it requires specific permissions, what format the output is in, or any rate limits. For a system tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the purpose without any fluff. It's appropriately sized for a simple tool and front-loaded with the essential information.
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 simplicity (0 parameters) but lack of annotations and output schema, the description is incomplete. It doesn't explain what memory information is returned (e.g., usage, capacity, stats), which is critical for an agent to understand the tool's utility. For a system monitoring tool, this gap reduces effectiveness.
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 absence of inputs. The description doesn't need to add parameter semantics, and it doesn't incorrectly imply any parameters. Baseline 4 is appropriate for a zero-parameter tool with complete 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 '获取本地服务器内存信息' (Get local server memory information) clearly states the verb ('获取' - get) and resource ('本地服务器内存信息' - local server memory information). It's specific about what information is retrieved, though it doesn't explicitly distinguish from siblings like 'get_system_load' or 'get_os_details' which might overlap in system monitoring.
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 context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone. This is a basic gap for a tool in a set with multiple system monitoring siblings.
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:

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

Score Badge

Copy to your README.md:

[![ops-mcp-server MCP server](https://glama.ai/mcp/servers/Heht571/ops-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Heht571/ops-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/Heht571/ops-mcp-server'

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