This server provides a comprehensive toolkit for retrieving detailed system and operating environment information across multiple platforms:
System Information: Platform details (OS, architecture, hostname, version), memory statistics, CPU information and usage
Network Information: Interfaces, IPv4/IPv6 addresses, proxy settings, Wi-Fi, VPN details
Hardware Information: Manufacturer specifications, model, serial numbers, USB devices, graphics cards/displays, printers
User Information: Username, UID/GID, home directory, shell, SSH public keys
Device Information: Battery status, audio devices, Bluetooth connections, terminal types
Storage Information: Disk usage statistics
Software Information: Installed applications, Docker details (version, images, containers), Node.js version
Process Information: Running processes statistics
Environmental Information: Timezone data, available networks
Allows deployment and integration as an NPM package, making the system information retrieval functionality available for other applications via package installation
Provides TypeScript interfaces for integrating with the system information retrieval functionality, enabling type-safe access to system data
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Current operating environment what's my current system memory usage?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
一个用于获取当前环境系统信息的 MCP 工具包。
获取详细的系统信息
支持跨平台使用
易于集成到支持 MCP 的应用程序中
提供 TypeScript 类型支持
Related MCP server: Hostname MCP Server
npm install @zhijianren/env-mcp -g在应用的 MCP 配置中添加以下内容：
{
"mcpServers": {
"env-mcp": {
"name": "env-mcp",
"type": "command",
"command": "node",
"args": [
"/usr/local/lib/node_modules/@zhijianren/env-mcp/dist/index.js"
],
"enabled": true
}
}
}// 获取平台信息
const platformInfo = await mcp.env.getPlatformInfo();
// 获取内存信息
const memoryInfo = await mcp.env.getMemoryInfo();
// 获取 CPU 信息
const cpuInfo = await mcp.env.getCpuInfo();
// 获取网络信息
const networkInfo = await mcp.env.getNetworkInfo();
// 获取用户信息
const userInfo = await mcp.env.getUserInfo();
// 获取 CPU 使用率
const cpuUsage = await mcp.env.getCpuUsage();
// 获取硬盘使用率
const diskUsage = await mcp.env.getDiskUsage();
// 获取终端类型
const terminalTypes = await mcp.env.getTerminalTypes();
// 获取 IPv4 信息
const ipv4Info = await mcp.env.getIpv4Info();
// 获取 IPv6 信息
const ipv6Info = await mcp.env.getIpv6Info();
// 获取代理信息
const proxyInfo = await mcp.env.getProxyInfo();
// 获取 Docker 信息
const dockerInfo = await mcp.env.getDockerInfo();
// 获取 Node.js 版本信息
const nodeInfo = await mcp.env.getNodeInfo();工具名称 | 描述 | 返回数据结构示例 |
| 获取当前设备的电池信息 |
|
| 获取当前设备的显卡信息 |
|
| 获取当前设备的进程信息 |
|
| 获取当前设备的蓝牙信息 |
|
| 获取当前设备的音频设备信息 |
|
| 获取当前设备可用的网络信息 |
|
| 获取当前设备的时区信息 |
|
| 获取当前设备所有注册唤醒的 App Schema 信息 |
|
| 获取当前设备的 Wi-Fi 信息 |
|
| 获取当前设备已安装的应用信息 |
|
| 获取当前设备的 VPN 信息 |
|
| 获取当前设备的硬件信息，包括生产日期等 |
|
| 获取当前系统的平台信息 |
|
| 获取当前系统的内存信息 |
|
| 获取当前系统的 CPU 信息 |
|
| 获取当前系统的网络信息 |
|
| 获取当前系统的用户信息 |
|
| 获取当前平台的 CPU 占用率 |
|
| 获取当前平台的硬盘使用率 |
|
| 获取系统上支持的所有终端类型 |
|
| 获取当前设备的 IPv4 信息 |
|
| 获取当前设备的 IPv6 信息 |
|
| 获取当前网络的所有代理信息 |
|
| 获取当前设备的 USB 设备信息 |
|
| 获取当前设备的打印机信息 |
|
| 获取当前用户的 SSH 公钥 |
|
| 获取当前设备的 Docker 信息 |
|
| 获取当前设备安装的 Node.js 版本信息 |
|
# 安装依赖
npm install
# 开发模式（监听文件变化）
npm run dev
# 构建项目
npm run build
# 运行项目
npm start通过 .env 文件配置环境变量：
PORT：服务器端口号（默认：3000）
NODE_ENV：运行环境（development/production）
本项目采用 ISC 许可证
获取当前设备所有注册唤醒的 App Schema 信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 action ('获取') but doesn't disclose behavioral traits like whether it's read-only (implied by 'get'), requires permissions, has rate limits, returns structured data, or handles errors. 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.
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 function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It specifies the resource (App Schema info for wake-up apps) but lacks details on return format, error handling, or system dependencies. For a read operation in a system info context, it meets basic needs but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the tool's purpose. Baseline is 4 for zero-parameter tools when the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get/retrieve) and the resource 'App Schema 信息' (App Schema information), specifying it's for '当前设备所有注册唤醒的' (all registered wake-up apps on the current device). This distinguishes it from siblings like getInstalledApps by focusing on schema/wake-up registration rather than general installation. However, it doesn't explicitly contrast with siblings beyond the resource specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., system diagnostics vs. app management), or exclusions (e.g., not for unregistered apps). With many sibling tools for system info, this lack of differentiation leaves usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备的音频设备信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 'gets' information, implying a read-only operation, but doesn't disclose behavioral traits such as whether it requires permissions, if it's real-time or cached, potential errors (e.g., no audio devices), or output format. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese: '获取当前设备的音频设备信息'. It is front-loaded with the core action and resource, with no wasted words. Every part earns its place by specifying the verb, scope, and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, no annotations, and no output schema, the description is minimally complete. It states what the tool does but lacks details on output (e.g., what audio info is returned), error handling, or dependencies. For a simple info-fetching tool, this is adequate but leaves gaps that could hinder an agent's understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. No additional value is required beyond stating the purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取当前设备的音频设备信息' (Get current device's audio device information) clearly states the verb ('获取' - get) and resource ('音频设备信息' - audio device information), with scope ('当前设备' - current device). It distinguishes from siblings like getBatteryInfo or getMemoryInfo by specifying audio devices. It loses a point for not being more specific about what 'audio device information' includes (e.g., devices, volume, status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires audio hardware), exclusions (e.g., not for network audio), or related tools (e.g., use getHardwareInfo for general hardware details). The context is implied (when audio info is needed), but no explicit usage rules are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备可用的网络信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 it gets network information but doesn't specify what type of information (e.g., Wi-Fi networks, Ethernet connections, signal strength), whether it requires permissions, or if it's a read-only operation. 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.
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 for a simple tool, though it could be slightly more specific to improve clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of network-related tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'available network information' entails or how it differs from sibling tools, leaving gaps in understanding the tool's behavior and output for 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it doesn't introduce any confusion, warranting a baseline score of 4 for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('获取' meaning 'get') and resource ('当前设备可用的网络信息' meaning 'available network information for the current device'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'getNetworkInfo' or 'getWifiInfo', which likely provide different scopes or details of network information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'getNetworkInfo', 'getWifiInfo', 'getIpv4Info', and 'getIpv6Info' available, there's no indication of how this tool differs in scope or context, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备的电池信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read-only operation ('获取' means get) but doesn't disclose if it requires permissions, has side effects, rate limits, or error conditions. For a tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's function without any fluff. It's front-loaded with the core purpose and wastes no words, making it ideal for quick comprehension by an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what data is retrieved but lacks details on return format, error handling, or system dependencies. For a basic read operation, it's passable but could be more informative about the output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no inputs are required by not mentioning any. This meets the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取当前设备的电池信息' (Get current device battery information) clearly states the verb '获取' (get) and resource '电池信息' (battery information), making the purpose unambiguous. It distinguishes from siblings like getCpuInfo or getMemoryInfo by specifying battery data. However, it doesn't explicitly mention what specific battery information is retrieved (e.g., level, status, health), 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.
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, timing considerations, or compare it to other battery-related tools (none exist in siblings). The agent must infer usage from the name alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备的蓝牙信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 it retrieves Bluetooth information but doesn't specify whether this requires permissions, what format the information is returned in, whether it's real-time or cached data, or if there are any rate limits or side effects. For a system information tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally complete. It tells the agent what information will be retrieved but doesn't provide details about the return format, data structure, or potential limitations. For a system information tool among many similar siblings, more context about what specific Bluetooth data is included would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist. This meets the baseline expectation for a parameterless tool, though it doesn't add any extra context about why no parameters are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取当前设备的蓝牙信息' (Get current device's Bluetooth information) clearly states the verb '获取' (get) and resource '蓝牙信息' (Bluetooth information), making the purpose immediately understandable. It distinguishes from siblings by specifying Bluetooth rather than other system information types like battery, CPU, or network. However, it doesn't specify what specific Bluetooth information is retrieved, 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.
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. While the name implies it's for Bluetooth information specifically, there's no explicit comparison to other tools like getNetworkInfo or getWifiInfo that might provide related connectivity data. No prerequisites, limitations, or recommended contexts are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前系统的 CPU 信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 CPU information but doesn't specify what type of information (e.g., model, cores, speed), whether it requires permissions, if it's read-only or has side effects, or any rate limits. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese: '获取当前系统的 CPU 信息' (get current system CPU information). It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple tool. Every part of the sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with no parameters) and the absence of annotations and output schema, the description is incomplete. It doesn't explain what CPU information is returned (e.g., details vs. summary), potential errors, or behavioral traits. For a tool with no structured output documentation, the description should provide more context about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate as there are no parameters to document, and the description doesn't introduce any confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取当前系统的 CPU 信息' (get current system CPU information), which is a specific verb+resource combination. However, it doesn't explicitly distinguish itself from sibling tools like 'getCpuUsage' or 'getHardwareInfo', which might provide overlapping or related information. The purpose is clear 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.
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 'getCpuUsage' (which might focus on usage metrics) and 'getHardwareInfo' (which could include broader hardware details), there's no indication of context, exclusions, or when this specific CPU info tool is preferred. It relies solely on the tool name for implicit usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前平台的 CPU 占用率
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 'gets' CPU usage, implying a read-only operation, but doesn't specify whether this requires permissions, how frequently it can be called, what format the output is in, or if it's real-time vs. averaged data. 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.
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 function without any fluff or redundancy. It's front-loaded with the core purpose and appropriately sized for a simple, parameter-less tool, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal but adequate for basic understanding. However, it lacks details on output format, error handling, or system-specific behaviors, which could be important for an AI agent to use it correctly in varied contexts. With no annotations or output schema, the description should provide more contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100% (since there are no parameters to describe). In such cases, the baseline score is 4, as the description doesn't need to compensate for any parameter documentation gaps. The description appropriately focuses on the tool's purpose without unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('获取' meaning 'get') and resource ('CPU 占用率' meaning 'CPU usage'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from its sibling 'getCpuInfo', which might provide related but different CPU information, leaving some ambiguity in sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'getCpuInfo' or other system monitoring tools in the sibling list. It lacks context on use cases, prerequisites, or exclusions, offering only a basic functional statement without operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前平台的硬盘使用率
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 it gets disk usage but doesn't specify what data is returned (e.g., percentage, free space, total space), whether it's real-time or cached, any permissions required, or potential errors. For a 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.
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 unnecessary words. It is front-loaded and appropriately sized for a simple, parameter-less 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for effective use. It doesn't explain the return format (e.g., numeric value, structured data), units, or any behavioral nuances. For a tool that likely returns system metrics, more context is needed to understand what the agent will receive and how to interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate as it avoids redundancy while clearly indicating no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' meaning 'get') and resource ('硬盘使用率' meaning 'hard disk usage'), making the purpose immediately understandable. It distinguishes itself from siblings by focusing specifically on disk usage rather than other system metrics like CPU, memory, or network. However, it doesn't specify the platform scope beyond '当前平台' (current platform), which is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools like getHardwareInfo or getPlatformInfo that might overlap. The agent must infer usage based solely on the tool name and description without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备的 Docker 信息，若未安装则返回空
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 key behavioral trait: returning empty when Docker isn't installed. However, it doesn't describe what 'Docker information' includes (e.g., version, containers, images), whether it requires permissions, or the return format. For a zero-parameter tool, this is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that efficiently conveys the core functionality and one important behavioral detail. Every word earns its place, with no redundant information. It's front-loaded with the main purpose followed by the conditional behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no annotations, no output schema), the description is reasonably complete for basic understanding. It explains what the tool does and one behavioral condition. However, for a system information tool, it could benefit from specifying what 'Docker information' includes or the return format, especially without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there's no need to explain parameter semantics. The description appropriately focuses on the tool's behavior rather than inputs. With 100% schema coverage (empty schema), a baseline of 4 is justified as the description doesn't need to compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取当前设备的 Docker 信息' (get Docker information for the current device). It specifies the resource (Docker information) and includes a conditional behavior ('若未安装则返回空' - returns empty if not installed). While it distinguishes from siblings by focusing on Docker, it doesn't explicitly contrast with other system info tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, use cases, or comparisons with sibling tools like getHardwareInfo or getPlatformInfo. The conditional behavior about returning empty when Docker isn't installed is useful but doesn't constitute usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备的显卡信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 it retrieves information ('获取'), implying a read-only operation, but doesn't specify details like whether it requires admin permissions, what format the output is in (e.g., JSON, text), potential rate limits, or if it works across all platforms. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Chinese: '获取当前设备的显卡信息'. It is front-loaded with the core action and resource, with zero wasted words. Every part of the sentence directly contributes to understanding the tool's purpose, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally complete. It states what the tool does but lacks context on usage, behavioral details, or output format. For a basic read operation, this might be adequate, but it doesn't fully compensate for the absence of annotations or output schema, leaving the agent to infer behavior from the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, as there are none to explain. A baseline score of 4 is appropriate for a parameterless tool, as the description adequately conveys the action without unnecessary complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取当前设备的显卡信息' (Get current device's graphics card information) clearly states the verb ('获取' - get) and resource ('显卡信息' - graphics card information), making the purpose immediately understandable. It distinguishes from siblings by specifying graphics hardware rather than CPU, memory, network, etc. However, it doesn't explicitly contrast with other hardware-related tools like getHardwareInfo, which might cover broader hardware details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires graphics hardware), exclusions (e.g., not for virtual machines without GPUs), or comparisons to siblings like getHardwareInfo (which might include graphics info). Usage is implied only by the tool name and description, with no explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备的硬件信息，包括生产日期等
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 it 'gets' information, implying a read-only operation, but doesn't clarify if this requires permissions, what format the output is in, or any rate limits. For a tool with zero annotation coverage, this is a significant gap, as it lacks details on safety, performance, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: '获取当前设备的硬件信息，包括生产日期等'. It's front-loaded with the core purpose and adds a brief scope. There's no wasted text, but it could be slightly more structured by explicitly mentioning output or context, though not required for full marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'hardware information' entails beyond 'production date', how it differs from siblings, or what the return format is. For a tool in a crowded namespace with no structured support, 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for tools with no parameters. It efficiently avoids unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取当前设备的硬件信息，包括生产日期等' (Get current device hardware information, including production date, etc.). It specifies the verb '获取' (get) and resource '硬件信息' (hardware information), with additional scope '包括生产日期等' (including production date, etc.). However, it doesn't explicitly distinguish this tool from its many siblings (e.g., getCpuInfo, getMemoryInfo), which are also hardware-related, making it less specific than 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.
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 like getCpuInfo, getMemoryInfo, and getGraphicsInfo, it's unclear if this tool aggregates multiple hardware aspects or overlaps with them. There's no mention of prerequisites, context, or exclusions, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备已安装的应用信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 ('获取') but doesn't add context like whether this is a read-only operation, if it requires permissions, what format the information is returned in, or any rate limits. This is a significant gap 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.
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 unnecessary words or fluff. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with no parameters) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what '应用信息' includes (e.g., names, versions, paths) or the return format, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any, earning a baseline high score for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get/retrieve) and the resource '当前设备已安装的应用信息' (currently installed application information on the device), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'getAppSchemas' or 'getProcesses', which might also relate to applications, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, such as whether it's for system-wide apps only or includes user-installed ones, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备的 IPv4 信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states it gets IPv4 information but doesn't specify what information is returned (e.g., address, subnet, gateway), whether it requires network permissions, or if it's read-only (implied but not explicit). The description is too vague about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Chinese that directly states the tool's function without any fluff or redundant information. It's perfectly front-loaded and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is minimally adequate but incomplete. It identifies the resource (IPv4 information) but doesn't specify what information is returned or any behavioral constraints, leaving gaps for the agent to understand the tool fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose without unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' meaning 'get') and resource ('IPv4 信息' meaning 'IPv4 information'), making the purpose immediately understandable. It distinguishes from siblings like getIpv6Info by specifying IPv4, but doesn't fully differentiate from broader tools like getNetworkInfo that might include IPv4 data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like getNetworkInfo or getIpv6Info. It simply states what it does without indicating specific use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备的 IPv6 信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 IPv6 information but doesn't specify what that includes (e.g., addresses, configuration, status), whether it requires permissions, if it's read-only or has side effects, or how it handles errors. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese: '获取当前设备的 IPv6 信息'. It's front-loaded with the core action and resource, with zero wasted words. Every part of the sentence contributes directly to understanding the tool's function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what IPv6 information is returned (e.g., addresses, subnet, gateway), the format of the output, or any behavioral aspects like error handling. For a tool that likely returns structured data, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it meets the baseline for this scenario. It appropriately focuses on the tool's purpose without unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取当前设备的 IPv6 信息' (Get the current device's IPv6 information). It specifies the verb (获取/get) and resource (IPv6 信息/IPv6 information) with the scope of '当前设备' (current device). However, it doesn't explicitly differentiate from its sibling 'getIpv4Info' or other network-related tools like 'getNetworkInfo' or 'getProxyInfo', 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.
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 'getIpv4Info' for IPv4 data, 'getNetworkInfo' for broader network details, or 'getProxyInfo' for proxy settings. There's no context on prerequisites, exclusions, or specific use cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前系统的内存信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 '获取' (get) implies a read-only operation, the description doesn't specify what memory information is returned (total, used, free, etc.), format of the output, whether this requires special permissions, or any rate limits. For a system information 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized for a simple, parameterless tool and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple read-only system information tool with no parameters and no output schema, the description is adequate but minimal. It states what information is retrieved but doesn't provide enough context about the output format or how this fits with the broader system monitoring toolset. The lack of annotations means the description should do more to explain behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and it correctly focuses on what the tool does rather than trying to explain non-existent inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取当前系统的内存信息' (Get current system memory information), which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like getCpuInfo or getDiskUsage, which follow the same pattern for different system resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that retrieve different types of system information (CPU, disk, network, etc.), there's no indication of when memory information specifically is needed or how this tool relates to other system monitoring tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前系统的网络信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 what the tool does ('获取当前系统的网络信息') but doesn't disclose behavioral traits like what specific network information is returned (e.g., interfaces, IP addresses, connectivity status), whether it requires permissions, or if it's read-only/safe. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese: '获取当前系统的网络信息'. It's front-loaded with the core action and resource, with zero wasted words. Every part of the sentence directly contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (retrieving system network information), lack of annotations, and no output schema, the description is incomplete. It doesn't specify what '网络信息' includes (e.g., interfaces, IPs, DNS), making it hard for an agent to understand the return value. For a tool with no structured output documentation, the description should provide more context about the expected data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though empty). With no parameters to document, the description doesn't need to compensate for schema gaps. A baseline of 4 is appropriate since there are no parameters to explain beyond what the schema already indicates (none).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取当前系统的网络信息' (Get current system network information) clearly states the verb ('获取' - get) and resource ('网络信息' - network information). It distinguishes from siblings like getIpv4Info, getIpv6Info, getWifiInfo, and getAvailableNetworks by specifying it retrieves general network information rather than specific aspects. However, it doesn't explicitly contrast with these alternatives, 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.
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 getIpv4Info, getIpv6Info, getWifiInfo, and getAvailableNetworks that retrieve specific network details, there's no indication whether this tool aggregates these or provides different information. It lacks explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备安装的 Node.js 版本信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 it 'gets' information, implying a read-only operation, but doesn't specify whether it requires permissions, returns structured data, has any side effects, or handles errors. For a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Chinese that directly states the tool's purpose without any extraneous information. It is front-loaded and efficiently communicates the core functionality, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is minimal but adequate for a simple read operation. It specifies what information is retrieved (Node.js version on the current device), which covers the basic purpose. However, it lacks details on output format, error handling, or usage context, which could be important for integration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied since no parameters exist, and the description doesn't introduce unnecessary complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' meaning 'get') and the resource ('Node.js 版本信息' meaning 'Node.js version information'), making the purpose unambiguous. It specifies '当前设备安装的' (installed on the current device), which adds context, but it doesn't explicitly differentiate from potential siblings like getPlatformInfo or getHardwareInfo that might also provide system-level details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like getPlatformInfo or getHardwareInfo that might overlap in providing system information, there's no indication of when this specific tool is appropriate or what distinguishes it from others in the list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前系统的平台信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 the tool retrieves information (implying read-only), but doesn't disclose behavioral traits like whether it requires permissions, returns structured data, has rate limits, or what 'platform' specifically includes (OS, architecture, etc.). This is inadequate for a 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.
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 with no wasted words. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'platform information' includes (e.g., OS name, version, architecture), the return format, or how it differs from other system info tools. For a tool in a crowded sibling set, more context is needed to guide proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. No additional parameter context is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取当前系统的平台信息' (get current system platform information), which specifies the verb (get) and resource (platform information). It distinguishes from siblings by focusing on 'platform' rather than specific hardware/software components, though it doesn't explicitly differentiate from tools like getHardwareInfo or getNodeInfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools retrieving system information (e.g., getHardwareInfo, getCpuInfo, getNodeInfo), there's no indication of what 'platform information' encompasses or when it's preferred over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备的打印机信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 'gets' information, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires permissions, what format the output is in, or if it might fail if no printer is available. This leaves significant gaps 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.
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 unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a hardware query tool with no annotations and no output schema, the description is incomplete. It doesn't explain what information is returned (e.g., printer name, status, capabilities) or potential errors, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add or detract from parameter semantics, but with no parameters, a baseline score of 4 is appropriate as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get) and resource '打印机信息' (printer information) with scope '当前设备的' (current device's), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'getGraphicsInfo' or 'getHardwareInfo' that might also provide hardware-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as whether the device must have a printer connected, or exclusions like when other tools might be more appropriate for related hardware queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备的进程信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While '获取' implies a read operation, it doesn't disclose whether this requires special permissions, what format the process information returns, whether it includes all processes or filtered ones, or any rate limits. For a system information tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple, parameterless tool and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description provides the minimum viable information about what the tool does. However, for a system information tool among many similar siblings, it should ideally provide more context about what 'process information' includes and how it differs from other system monitoring tools. The description is complete enough to understand the basic purpose but lacks depth for optimal agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to explain parameters since none exist, and it correctly doesn't mention any. The description focuses appropriately on what the tool does rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取当前设备的进程信息' clearly states the verb ('获取' - get/retrieve) and resource ('当前设备的进程信息' - current device's process information). It distinguishes from siblings by focusing specifically on processes rather than other system information like CPU, memory, or network. However, it doesn't explicitly differentiate from potential similar tools (none exist in siblings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools retrieving different types of system information (CPU, memory, network, etc.), there's no indication that this is specifically for process information rather than other system metrics. No exclusions, prerequisites, or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前网络的所有代理信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 what the tool does but lacks details on traits like whether it's read-only, requires permissions, has rate limits, or what format the output takes. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. 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.
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, no output schema, no annotations), the description is minimally complete. It covers the basic purpose but lacks context on usage, behavioral traits, or output, which could be helpful for an agent to make informed decisions, especially with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
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 this is acceptable given the lack of parameters, aligning with the baseline for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' meaning 'get') and resource ('当前网络的所有代理信息' meaning 'all proxy information for the current network'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'getNetworkInfo' or 'getVpnInfo', which might also relate to network configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for system information (e.g., 'getNetworkInfo', 'getVpnInfo'), there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on 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.
获取当前用户的 SSH 公钥
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 ('get'), without mentioning whether it's read-only, requires authentication, has rate limits, returns specific formats, or handles errors. This is inadequate for a 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.
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 or redundancy. It's appropriately sized and front-loaded, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the SSH public key output looks like (e.g., format, key type), potential errors, or behavioral traits. For a tool that retrieves security-sensitive information, this leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, but that's appropriate here. A baseline of 4 is given as it meets expectations for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' meaning 'get') and resource ('当前用户的 SSH 公钥' meaning 'current user's SSH public key'), providing a specific purpose. However, it doesn't explicitly differentiate from sibling tools like 'getUserInfo' which might also provide user-related information, preventing 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.
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 (e.g., 'getUserInfo', 'getPlatformInfo'), there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on 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.
获取系统上支持的所有终端类型
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 whether it's read-only, if it requires permissions, what format the output is in, or any potential side effects. This is a significant gap 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Chinese that directly states the tool's purpose without any unnecessary words or fluff. It is front-loaded and efficiently communicates the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally complete. It tells the agent what the tool does, but lacks details on output format, behavioral traits, or usage context. For a basic retrieval tool, this is adequate but leaves gaps in understanding how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, making it adequate for this case. A baseline of 4 is appropriate as it doesn't introduce confusion about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' meaning 'get' or 'retrieve') and the resource ('所有终端类型' meaning 'all terminal types'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from its siblings (e.g., getGraphicsInfo, getHardwareInfo), which are also retrieval tools for different system information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, specific contexts, or comparisons with sibling tools, leaving the agent to infer usage based solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备的时区信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 what the tool does ('获取当前设备的时区信息') but doesn't describe traits like whether it's read-only (implied by 'get'), if it requires permissions, how it handles errors, or the format of returned data. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('获取当前设备的时区信息'), which directly states the purpose without any waste. It's front-loaded with the core action and resource, 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.
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, no output schema, no annotations), the description is minimally complete—it tells what the tool does. However, it lacks details on behavioral aspects (e.g., data format, error handling) and usage context, which are gaps even for a simple tool. It meets the basic requirement but doesn't provide rich contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics beyond the schema, but this is appropriate given the lack of parameters. A baseline of 4 is assigned as it adequately handles the parameter-free case without unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('获取' meaning 'get') and resource ('时区信息' meaning 'timezone information'), specifying it retrieves timezone data for the current device. It distinguishes from siblings by focusing on timezone rather than other system metrics like battery, network, or hardware info. However, it doesn't explicitly contrast with a hypothetical alternative like 'setTimezone', which slightly limits differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., device access), exclusions (e.g., not for historical timezone data), or compare to sibling tools like getPlatformInfo (which might include timezone). Usage is implied only by the tool name and description, lacking explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备的 USB 设备信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 it retrieves information (implying read-only), but doesn't disclose behavioral traits like whether it requires permissions, returns real-time vs cached data, format of returned info, or potential errors. For a system info tool with zero 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.
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 function without unnecessary words. It's appropriately sized for a simple, parameterless tool and front-loads the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally complete. It tells what the tool does but lacks context about return format, data scope, or system dependencies. For a system information tool, more detail about what 'USB device information' includes would be helpful, but the basic purpose is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to explain parameters, and appropriately doesn't mention any. It focuses solely on what the tool does, which is sufficient given the parameterless design.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取当前设备的 USB 设备信息' (Get current device's USB device information). It specifies the verb ('获取' - get) and resource ('USB 设备信息' - USB device information), but doesn't differentiate from sibling tools like getHardwareInfo or getGraphicsInfo that also retrieve hardware information. The purpose is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like getHardwareInfo (which might include USB info) and getBluetoothInfo (similar peripheral info), there's no indication of scope boundaries, prerequisites, or comparison. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前系统的用户信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. '获取' (get/retrieve) implies a read-only operation, but there's no information about what specific user information is returned, whether authentication is required, potential rate limits, or the format/structure of the response. The description is too minimal 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.
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. There's zero wasted language or unnecessary elaboration. It's appropriately sized for a simple retrieval tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and the description's minimal nature, this is incomplete for a system information retrieval tool. While simple (0 parameters), the description doesn't explain what 'user information' encompasses (username, UID, home directory, etc.) or provide any context about the response format, making it inadequate for an agent to understand what will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already fully documents this. No additional parameter information is needed or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取当前系统的用户信息' clearly states the verb ('获取' - get/retrieve) and resource ('当前系统的用户信息' - current system's user information), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like getPlatformInfo or getHardwareInfo, but the specificity of 'user information' provides reasonable distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools retrieving different types of system information (CPU, memory, network, etc.), there's no indication of what 'user information' specifically includes or when this tool is appropriate versus other system info tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备的 VPN 信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. While '获取' implies a read-only operation, the description doesn't explicitly state whether this requires permissions, what format the VPN information returns, whether it's real-time or cached data, or any error conditions. For a system information tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without any unnecessary words. It's appropriately sized for a simple information retrieval tool and front-loads the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple read-only information retrieval tool with no parameters and no output schema, the description is minimally adequate. However, without annotations or output schema, it should ideally provide more context about what specific VPN information is returned (connection status, server details, protocols, etc.) to help the agent understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist. It focuses on what information will be retrieved rather than how to request it, which is correct for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' meaning 'get') and resource ('当前设备的 VPN 信息' meaning 'current device's VPN information'), providing a specific verb+resource combination. It distinguishes itself from siblings like getNetworkInfo or getProxyInfo by focusing specifically on VPN information. However, it doesn't explicitly contrast with these alternatives in the description text itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like getNetworkInfo or getProxyInfo. There's no mention of prerequisites, context, or specific use cases. The agent must infer usage from the tool name and description alone without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前设备的 Wi-Fi 信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 what the tool does but doesn't describe how it behaves: whether it returns connection status, SSID, signal strength, security type, or other Wi-Fi details. There's no mention of permissions needed, error conditions, or what format the information comes in.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without any unnecessary words. It's perfectly front-loaded with the core functionality and wastes no space on redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a system information retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what specific Wi-Fi information will be returned (connection status, SSID, signal strength, etc.), which is critical context for an agent to understand what this tool provides versus similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already fully documents the empty parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取当前设备的 Wi-Fi 信息' (Get current device's Wi-Fi information), which is a specific verb+resource combination. It distinguishes itself from siblings like getNetworkInfo or getAvailableNetworks by focusing specifically on Wi-Fi information rather than general network data or available networks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it's clear this tool retrieves Wi-Fi information, there's no mention of when to choose it over similar tools like getNetworkInfo or getAvailableNetworks, nor any prerequisites or context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0getAppSchemasgetAudioInfogetAvailableNetworksgetBatteryInfogetBluetoothInfogetCpuInfogetCpuUsagegetDiskUsagegetDockerInfogetGraphicsInfogetHardwareInfogetInstalledAppsgetIpv4InfogetIpv6InfogetMemoryInfogetNetworkInfogetNodeInfogetPlatformInfogetPrinterInfogetProcessesgetProxyInfogetSshPublicKeygetTerminalTypesgetTimezonegetUsbInfogetUserInfogetVpnInfogetWifiInfogetAppSchemasgetAudioInfogetAvailableNetworksgetBatteryInfogetBluetoothInfogetCpuInfogetCpuUsagegetDiskUsagegetDockerInfogetGraphicsInfogetHardwareInfogetInstalledAppsgetIpv4InfogetIpv6InfogetMemoryInfogetNetworkInfogetNodeInfogetPlatformInfogetPrinterInfogetProcessesgetProxyInfogetSshPublicKeygetTerminalTypesgetTimezonegetUsbInfogetUserInfogetVpnInfogetWifiInfogetAppSchemasgetAudioInfogetAvailableNetworksgetBatteryInfogetBluetoothInfogetCpuInfogetCpuUsagegetDiskUsagegetDockerInfogetGraphicsInfogetHardwareInfogetInstalledAppsgetIpv4InfogetIpv6InfogetMemoryInfogetNetworkInfogetNodeInfogetPlatformInfogetPrinterInfogetProcessesgetProxyInfogetSshPublicKeygetTerminalTypesgetTimezonegetUsbInfogetUserInfogetVpnInfogetWifiInfoEach tool has a clearly distinct purpose targeting specific hardware, software, or network components of the operating environment. There is no overlap in functionality; for example, getCpuInfo and getCpuUsage serve different but related purposes without ambiguity.
All tool names follow a consistent verb_noun pattern using 'get' as the verb and descriptive nouns in camelCase. This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming style.
With 28 tools, the count is high for a server focused on environment information retrieval. While comprehensive, it may feel heavy and could potentially be streamlined by grouping related data into fewer, more general tools without sacrificing functionality.
The tool set provides extensive coverage of the operating environment domain, including hardware, software, network, and system details. There are no obvious gaps; it supports a wide range of queries an agent might need for environment analysis.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only discovery of Framekeep capabilities, security boundaries, and public resources.
Real-time planetary signal engine and Model Context Protocol (MCP) server for autonomous AI agents.
Agents report which MCP servers, APIs and CLIs actually worked. Look up before use, report after.
Physical-world evidence and operability checks with provenance and explicit data gaps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JackXuyi/env-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server