Server Ops MCP enables AI tools to perform server operations and project code management via natural language, supporting both local and remote (SSH) modes with robust security controls.
System Monitoring: View CPU, memory, disk, load, and process info; analyze memory/disk usage to identify high-consumption processes and large files; check status of services like Nginx, PHP-FPM, MySQL, and Redis.
Log Management: Search system logs via journalctl; list, read (with pagination), and search project logs by channel, level, or keyword.
File & Code Operations: List, read, and search files within a sandboxed project root; write, patch, and delete files (all require confirmation).
Nginx & Certificate Management: Test config syntax, read configs, reload Nginx, and install/renew Let's Encrypt certificates via certbot (destructive/reload actions require confirmation).
Command Execution: Run whitelisted shell commands; dangerous commands are blocked outright.
Project Insights & Auditing: Get a project overview (tech stack, Git status, branches, recent commits) and audit config files for leaked secrets with automatic redaction.
Security Features: Two-step confirmation for all write, delete, and reload operations; command whitelisting; path-traversal protection; automatic redaction of sensitive data in outputs and logs.
Provides tools for managing Nginx configurations, including testing, reading, and reloading.
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., "@server-ops-mcp Show me the server's CPU, memory, and disk 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.
English | 简体中文
A general-purpose server-ops MCP Server. Let AI tools like Claude Code / Cursor / Codex manage multiple projects or servers through .mcp.json — log troubleshooting, system resource inspection, code read/write, and Nginx / certificate management.
Supports local and remote (SSH) modes, with built-in two-step confirmation, command whitelisting, path-traversal protection, and automatic secret redaction.
🔍 Log troubleshooting: list / read / search project logs, multi-channel logs & system logs
📊 Resource monitoring: CPU / memory / disk / load / processes / service status at a glance
📁 Code operations: read, write, patch, delete, and search files — all sandboxed to the project root
🌐 Nginx & certificates: config test & read, safe reload, certificate install & renewal
🔒 Secure by design: two-step confirmation for writes, command whitelist, path-traversal protection, auto redaction
Related MCP server: remote-admin-mcp
Requires Node.js 18+. No clone or build needed — npx fetches and runs the published npm package on first use (see the config below).
To build from source instead (e.g. for development):
git clone https://github.com/GT-dinuo/server-ops-mcp.git
cd server-ops-mcp
npm install
npm run buildBuild output goes to dist/; the entry point is dist/index.js.
In each project where you want to use this tool, create (or append to) .mcp.json and declare an MCP Server per environment. Local mode only needs OPS_PROJECT_ROOT; remote mode adds the SSH variables.
{
"mcpServers": {
"myproject-server": {
"command": "npx",
"args": ["-y", "server-ops-mcp"],
"env": {
"OPS_PROJECT_ROOT": "/www/wwwroot/your-project",
"OPS_SSH_HOST": "<server-ip-or-domain>",
"OPS_SSH_PORT": "22",
"OPS_SSH_USER": "ubuntu",
"OPS_SSH_KEY": "~/.ssh/id_rsa"
}
}
}
}If you built from source, point the command at the local build instead: "command": "node", "args": ["/absolute/path/to/server-ops-mcp/dist/index.js"].
Variable | Required | Description |
| Yes | Project root path; all file operations are sandboxed here |
| No | Remote server IP / domain; leave empty to run locally |
| No | SSH port, default |
| No | SSH username |
| No | Path to SSH private key (choose either key or password) |
| No | SSH password (choose either key or password) |
| No | Private key passphrase |
| No | Path to an extra config file — see "Custom Configuration" |
Once configured, just give ops instructions in natural language in your AI tool. The AI picks and calls the right tool automatically.
Check the server's CPU, memory, and disk usage
Search for error-level logs from the last hour
List the project's log files
Read the Nginx config and check for problems
Find every place in the code that calls sendSmsFor writes, deletes, command execution, Nginx reload, certificate install, and similar, the tool first returns a confirmationId. The AI shows you exactly what will run, and it only executes after you confirm:
You: Reload nginx
AI: (calls nginx_reload, returns the pending action + confirmationId)
About to run: nginx -s reload. Confirm?
You: Confirm
AI: (calls confirm_execute to run it)file_write, file_patch, file_delete, command_exec, and similar all follow the same confirmation flow.
Production troubleshooting: "Why is the server memory full?" → memory_analysis + log_search working together
Routine inspection: "Is the disk almost full? Which directory uses the most?" → disk_analysis
Security audit: "Audit the project config for leaked secrets" → config_audit (output is auto-redacted)
Tool | Description |
| CPU / memory / disk / load / processes |
| Memory usage analysis |
| Disk usage analysis |
| Service status |
| Search system logs |
| Test Nginx config |
| Read Nginx config |
| Reload Nginx (requires confirmation) |
| Install certificate (requires confirmation) |
| Renew certificate (requires confirmation) |
Tool | Description |
| List project logs |
| Read a log |
| Search logs |
| Read a file |
| List a directory |
| Search code |
| Write a file (requires confirmation) |
| Patch a file (requires confirmation) |
| Delete a file (requires confirmation) |
| Run whitelisted commands |
| Project overview |
| Audit config (auto-redacted) |
| Confirm and run a pending action |
Read-only tools run directly.
Writes, command execution, Nginx reload, certificate install require two-step confirmation (confirm_execute).
Command execution uses a whitelist — dangerous operations like rm -rf, sudo, and piping into a shell are rejected.
File operations are sandboxed to OPS_PROJECT_ROOT; path traversal is blocked.
Passwords, tokens, and other secrets in .env files and logs are automatically redacted.
Download config.example.json as config.json, then point OPS_CONFIG_PATH at it to customize log channels, the command whitelist, read limits, and more.
curl -o config.json https://raw.githubusercontent.com/GT-dinuo/server-ops-mcp/main/config.example.json
# (if you cloned the repo: cp config.example.json config.json)
# After editing config.json, set in the .mcp.json env:
# "OPS_CONFIG_PATH": "/absolute/path/to/config.json"Main fields of config.example.json:
logChannels: channel name → log directory path (relative to project root)
maxReadLines / maxReadBytes: per-read line / byte limits
commandWhitelist.direct: commands that run directly
commandWhitelist.confirm: commands that require confirmation
npm run dev # watch mode, recompiles on change
npm run build # build to dist/
npm run clean # remove dist/
npm start # run the built ServerRemote operations rely on SSH — use a read-only account or a tightly-scoped command whitelist for the AI.
Private key files should have permission 600 (chmod 600 ~/.ssh/id_rsa).
Never commit .mcp.json or config.json containing passwords to a repository.
MIT © 2026 server-ops-mcp
为指定域名申请并安装 Let's Encrypt 证书
| Name | Required | Description | Default |
|---|---|---|---|
| plugin | No | certbot 插件 | nginx |
| domains | Yes | 域名列表 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as effects on nginx configuration, need for root privileges, rate limits, or reversibility. The bare statement of installation 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?
Description is a single concise sentence with no redundancy. However, given the tool's potential impact, more behavioral context could be added without significant verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters, no output schema, and no annotations. The description omits critical context such as return values, side effects, prerequisites (e.g., domain pointing to server, nginx installed), and error scenarios, making it incomplete for safe 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?
Schema coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond the schema; it only repeats that domains are specified. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool applies for and installs Let's Encrypt certificates for specified domains, using the verb '申请并安装' and specifying resource 'Let's Encrypt 证书'. However, it does not differentiate from the sibling tool certbot_renew.
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?
Description implies usage for initial certificate installation on given domains, but provides no explicit guidance on when to use versus alternatives like certbot_renew, nor any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
手动触发 certbot 证书续期
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | 是否模拟运行 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注释信息，描述未披露行为特征（如是否修改系统、需要权限、影响服务等）。仅通过参数名为 dryRun 暗示行为，但未明确说明。
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?
描述非常简洁，一句话涵盖核心功能。虽然可以更详细，但当前结构高效无冗余。
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?
对于可能修改系统的操作，描述缺少重要上下文（如是否需要确认、对服务的影响）。兄弟工具 confirm_execute 暗示可能需要确认步骤，但描述未提及。
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?
输入模式中已完整描述 dryRun 参数（是否模拟运行），描述未添加额外含义。在高覆盖率下，基线为 3。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明了触发 certbot 证书续期的目的（手动触发 certbot 证书续期），但未与兄弟工具（如 certbot_install）区分。
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?
没有提供何时使用或何时不使用的指导，也没有提及替代工具。描述仅说明手动触发，但缺乏上下文。
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 |
|---|---|---|---|
| cwd | No | 执行目录（相对项目根目录） | |
| command | Yes | 要执行的命令 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the two categories of commands (read-only vs. non-read-only) but fails to explain what happens if a command is not on the whitelist, how the confirmation process works (e.g., involving 'confirm_execute'), or any side effects. Key behavioral traits are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that conveys the core purpose and key behavioral distinction (direct vs. confirmed execution). No extraneous information, perfectly front-loaded and efficient.
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 command execution tool and the lack of an output schema, the description is too brief. It does not explain return values, error handling, or how to interact with the sibling tool 'confirm_execute'. The description leaves critical gaps for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both 'cwd' and 'command' described. The description does not add any additional meaning or constraints beyond what the schema already provides, so it meets the baseline for parameter semantics.
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 it executes safe commands from a whitelist, distinguishing between read-only and non-read-only commands. This provides a specific verb and resource, but does not explicitly contrast with sibling tools like file_read or file_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that read-only commands can be executed directly and non-read-only commands require confirmation, which gives some usage context. However, it does not specify when to use this tool versus other specific file or system tools, nor does it mention alternatives or prerequisites such as the need for a whitelist to be defined.
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 |
|---|---|---|---|
| file | No | 配置文件相对项目根目录的路径 | server/.env |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions auto-desensitization as a behavioral trait, but beyond that it does not disclose what the audit does (e.g., read-only vs. write, output format, auth needs). With no annotations, the description carries a heavy burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It is concise and front-loaded, but could include more details without being verbose.
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?
With no output schema and only one parameter, the description should clarify what the agent receives after execution. It mentions desensitization but not the return value or side effects, making it incomplete for proper tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the parameter. The description adds no new meaning to the parameter, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly conveys the tool audits a project configuration file with automatic desensitization. It uses a specific verb and resource, but does not explicitly distinguish from sibling tools like file_read.
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 does not mention prerequisites, exclusions, or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
确认并执行需要二次确认的操作（如 file_write、file_delete、nginx_reload 等）
| Name | Required | Description | Default |
|---|---|---|---|
| confirmationId | Yes | 需要确认的操作 ID，由之前的工具调用返回 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool confirms and executes, implying a mutation, but lacks details on side effects, irreversibility, or what happens on failure. The description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and provides examples. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple confirmation tool with one parameter, the description covers the essential purpose and usage context. It does not explain return values, but that is acceptable given no output schema and the straightforward nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter. The tool description does not add new meaning beyond the schema's description. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool confirms and executes operations requiring secondary confirmation, with explicit examples like file_write, file_delete, and nginx_reload. This distinguishes it from siblings which are the operations themselves.
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 indicates when to use the tool (for operations needing secondary confirmation) and implicitly when not to use it (for operations that don't require confirmation). It could provide more explicit guidance on alternatives or prerequisites.
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 |
|---|---|---|---|
| path | No | / | |
| depth | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the analysis purpose without indicating whether the tool is read-only, performance implications, or error conditions. This is insufficient for a disk analysis operation.
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 short sentence, concise and front-loaded. However, it lacks structure such as separate sections for purpose and usage. The brevity saves space but omits needed details.
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 no output schema, no annotations, and no parameter descriptions, the description is severely incomplete. It does not address return format, potential data volume, or how results are presented, leaving the agent with minimal context.
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% description coverage, and the description does not explain any parameters. The meaning of 'path' and 'depth' is absent, forcing the agent to infer from defaults. This is a critical gap.
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 analyzes disk usage and identifies large files and directories. This verb+resource combination effectively conveys its primary function, distinguishing it from sibling tools like file_list or file_search that list or search files by name.
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 does not mention scenarios, prerequisites, or contrast with similar tools such as command_exec for disk space.
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 |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose if deletion is permanent, reversible, requires confirmation, or behavior on non-existent paths. Carries full burden but fails.
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?
Extremely concise but under-specified. The description is too minimal to convey necessary 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 one parameter, no output schema, and no annotations, the description provides no context on return values, side effects, or error handling.
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?
Single 'path' parameter with no schema description and no elaboration in description. Agent cannot infer path format, allowed values, or restrictions.
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 'delete project files' clearly indicates the action (delete) and resource (project files). While vague, it distinguishes from sibling file tools like read, write, list.
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 on when to use this tool vs alternatives, no prerequisites (e.g., file existence, permissions) or conditions for safe usage.
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 |
|---|---|---|---|
| path | No | 目录路径（相对项目根目录） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details (e.g., recursive listing, hidden files). The description does not compensate for the missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that is front-loaded with the core purpose. Could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is minimally adequate but could mention output format or recursion behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description of 'path' as '目录路径（相对项目根目录）' adds meaningful context about relative paths.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出项目目录内容' clearly states the action (list) and resource (project directory contents). It distinguishes from sibling tools like file_read and file_search.
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 explicit guidance on when to use this tool versus alternatives. Usage is implied but not elaborated.
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 |
|---|---|---|---|
| path | Yes | ||
| newString | Yes | ||
| oldString | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose whether the operation is destructive, how replacements are handled (e.g., first occurrence or all), or error conditions like missing oldString. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence). While it is front-loaded, it sacrifices necessary detail for brevity. It is not verbose, but under-specification reduces overall effectiveness.
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 tool with 3 required parameters, no output schema, and no annotations, the description fails to provide essential context such as behavior on missing file, replacement scope, or response format. It is incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning to the three parameters. It does not explain if oldString supports regex, whether newString can be empty, or how path is resolved. The agent must infer everything from names alone.
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 indicates the tool performs partial replacement on a file, which distinguishes it from file_write (whole file overwrite) and file_delete. It is specific enough for a simple patch operation.
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 file_write or command_exec. There is no mention of prerequisites or suitability, leaving the agent without decision context.
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 |
|---|---|---|---|
| path | Yes | 文件路径（相对项目根目录或绝对路径） | |
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as error handling, encoding, or whether it returns raw content or lines.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise but lacks structure. It could be improved by separating purpose, parameters, and output.
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 no output schema and no annotations, the description should specify return format (e.g., file content as string, lines, or raw bytes). It is incomplete for a file read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema coverage, the description should explain limit and offset parameters, but it does not mention any parameters. The schema descriptions for limit and offset are also missing.
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 (read) and resource (project file content). It distinguishes from sibling tools like file_list and file_write, but lacks detail on output format.
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 on when to use this tool versus alternatives like file_list or log_read. No mention of preconditions or exclusions.
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 |
|---|---|---|---|
| glob | No | 文件匹配模式 | **/* |
| lines | No | ||
| keyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral details but only says 'search content', omitting any specifics about case sensitivity, search scope, or limitations.
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?
Single clear sentence, highly concise. However, the brevity sacrifices necessary detail.
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 3 parameters, no output schema, and no annotations, the description is severely incomplete, failing to explain how glob patterns or line counts work.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (glob has description), and the tool description adds no information about parameters keyword or lines.
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 '在项目文件中搜索内容' (Search content in project files) clearly states the action and resource, distinguishing it from sibling tools like file_read or file_list.
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 on when to use this tool versus alternatives, such as log_search or command_exec. No preconditions or contexts provided.
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 |
|---|---|---|---|
| path | Yes | ||
| append | No | ||
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states 'write or create' but does not explain overwrite vs. append behavior, side effects, or requirements (e.g., permissions). The existence of an 'append' parameter is not mentioned.
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 (one sentence). While brevity is valued, it sacrifices essential details. For a tool with 3 parameters and no annotations, more structure would improve clarity.
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 (3 parameters, no output schema, no annotations), the description is insufficient. It does not explain return values, error handling, or behavior when the file exists. The tool's full capabilities are not conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no parameter-level details beyond the schema. The parameter names (path, content, append) are self-explanatory, but no format, constraints, or usage tips are given. The description misses the chance to clarify the role of 'append'.
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 ('write or create') and resource ('project files'). It is distinct from sibling tools like file_read, file_delete, etc. However, it does not elaborate on whether writing overwrites or appends, which could be ambiguous.
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 on when to use this tool versus alternatives. No when-to-use, when-not-to-use, or exclusion criteria are provided. The agent must infer usage solely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出项目日志文件
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | 日志通道名，对应配置中的 logChannels，留空使用 default | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description omits details about output format, scope, ordering, or side effects. For a list tool, key behaviors like whether it lists filenames or full paths are not disclosed.
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?
Single sentence, no redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal but covers the basics. Lacks details on output, default channel behavior, and relationship to sibling tools. Adequate for a simple list tool but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (channel parameter described). The description adds no extra meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出项目日志文件' clearly states the action (list) and resource (project log files), distinguishing it from sibling tools like log_read or log_search that imply reading or searching content.
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 on when to use this tool versus alternatives (e.g., log_search). It lacks context about typical use cases or prerequisites.
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 |
|---|---|---|---|
| path | Yes | 日志文件绝对路径或相对项目根目录的路径 | |
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as side effects, permissions, or handling of large files. It simply says 'read' without elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words, but it is under-specified. It could benefit from more detail without becoming verbose.
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?
Missing explanation of return values (no output schema), and does not mention how limit/offset are applied. Incomplete for a tool with three parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (path described), but the description adds no information about limit or offset. The description fails to compensate for the low schema coverage.
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 it reads a specified log file, distinguishing it from general file reads (file_read) and log listing (log_list). However, it could be more explicit about what 'reading' entails.
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 provided on when to use this tool vs alternatives like log_search or log_list. Missing context for appropriate usage.
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 |
|---|---|---|---|
| level | No | 日志级别，如 error、warning、info | |
| lines | No | ||
| channel | No | default | |
| keyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as destructive potential, required permissions, rate limits, or side effects. The description is too minimal to convey behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is underspecified and lacks structure for a tool with 4 parameters. While it is concise, it sacrifices necessary detail, making it unhelpful.
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 4 parameters, no output schema, and no annotations, the description is grossly incomplete. It does not explain the return format, pagination, filtering logic, or any behavioral nuances needed for 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?
Schema coverage is only 25% (only 'level' has a description in the schema). The description does not add any meaning beyond the schema. It fails to explain the meaning or constraints of parameters like 'keyword', 'lines', or 'channel', which are critical for correct invocation.
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 searches for keywords in project logs. However, it does not differentiate from the sibling tool 'log_search_system', which also searches logs but presumably system logs. The verb 'search' and resource 'project logs' are specific enough but lack 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?
No guidance is provided on when to use this tool versus alternatives like 'log_search_system' or 'log_list'. The description does not include any context about appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索系统日志（journalctl）
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | ||
| keyword | No | ||
| service | Yes | 服务名 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It does not disclose whether the tool is read-only, requires specific permissions, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. However, it is overly minimal and could include more detail without becoming verbose.
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?
With 3 parameters and no output schema, the description lacks information about search behavior, output format, filtering capabilities, or error conditions. Incomplete for an effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'service' described). The description adds no additional meaning for 'lines' or 'keyword'. It does not compensate for the low coverage.
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 '搜索系统日志（journalctl）' clearly indicates searching system logs using journalctl, distinguishing it from general log search tools like log_search.
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 on when to use this tool versus alternatives such as log_search or log_list. No usage context or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
分析内存占用，找出占用内存最高的进程和 OOM 风险
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. It states the tool analyzes memory and finds OOM risk but fails to mention whether it is read-only, requires permissions, or produces side effects. The description is too brief for adequate 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 concise sentence that front-loads the key functionality. It is efficient and to the point, with no wasted 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?
Given the tool has no parameters, no annotations, and no output schema, the description must stand alone. It covers the main purpose but does not specify return format, output details, or runtime behavior. It is adequate but incomplete for a fully self-contained description.
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, and schema coverage is 100% by default. According to guidelines, baseline score is 4. The description correctly adds no parameter information since none 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?
Description clearly states the tool analyzes memory usage, finds top memory-consuming processes, and assesses OOM risk. It is a specific verb+resource combination, though it does not explicitly differentiate among siblings, which are all distinct in function.
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 does not mention context, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取 Nginx 配置文件
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Nginx 配置文件路径 | /etc/nginx/nginx.conf |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation but does not explicitly state that it is non-destructive. With no annotations, the description carries full burden, but the behavior is straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) but could include more useful details without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description is adequate but does not mention return format or expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameter 'path' with a description and default. The tool description does not add additional meaning beyond what is already in the schema.
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 'read' and the resource 'Nginx configuration file'. However, it does not distinguish this from sibling tools like nginx_config_test or nginx_reload.
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 such as file_read or config_audit. The description lacks context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
测试 Nginx 配置文件语法
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states 'test syntax' with no disclosure of side effects, return values, or success/failure behavior. More detail is needed for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one line), but it lacks depth. It serves the purpose but could include more detail without being verbose.
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 no output schema and no annotations, the description is too brief. It does not explain return values, success/failure indicators, or any side effects, which are needed for a tool with minimal supporting metadata.
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?
No parameters exist, and schema coverage is 100%. The description adds no parameter info, but with zero parameters, the baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '测试 Nginx 配置文件语法' (test Nginx configuration file syntax), which is a specific verb and resource. It distinguishes from siblings like nginx_config_read (read) and nginx_reload (reload).
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 explicit guidance on when to use this tool versus alternatives, but the purpose implies it should be used before reloading to validate syntax. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
重载 Nginx 配置
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits (e.g., whether reload causes downtime, requires specific permissions, or how it interacts with running state).
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?
Single sentence is very concise and front-loaded, but underspecified for an agent; lacks structured guidance typical of tool descriptions.
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 zero parameters and no output schema, description is minimal but sufficient for a simple reload action. However, it does not differentiate from sibling tools like nginx_config_test or provide operational context.
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?
No parameters exist, so baseline score of 4 applies. Description adds no parameter information, but this is acceptable as schema covers all.
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?
Description clearly states verb 'reload' and resource 'Nginx configuration', distinguishing it from sibling tools like nginx_config_read and nginx_config_test.
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 on when to use this tool versus alternatives (e.g., nginx_config_test before reloading), no context on prerequisites or expected conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查看项目概览：技术栈、Git 状态、分支、最近提交
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates a read operation but does not disclose behavioral traits such as side effects, performance characteristics, or whether it requires a specific working directory. Description adds minimal behavioral context beyond listing outputs.
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?
Single sentence that is front-loaded with the core purpose. Every word is informative; no wasted content.
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 tool with no parameters and no output schema, the description adequately covers the expected output. However, it does not specify any preconditions or whether it works on any project, leaving some ambiguity.
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?
No parameters exist (0 params), so baseline is 4. The description adds meaning beyond the empty schema by explaining what the tool does, but there is no parameter information to enhance.
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?
Description is clear and specific: 'View project overview: tech stack, Git status, branches, recent commits.' It uses a specific verb and resource, and distinguishes from sibling tools which are mostly system administration utilities.
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 provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查看指定服务状态（nginx、php-fpm、mysql、redis 等）
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | 服务名，如 nginx、php-fpm、mysql、redis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates a read-only operation ('view status'), but omits details such as whether elevated permissions are needed, what happens if the service doesn't exist, or the output format. The description is too brief to fully inform the agent of 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 concise sentence, with no unnecessary words. It efficiently conveys the core purpose and example services. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate. It lists example services and implies the action. However, it lacks an explanation of the output (e.g., whether it returns a simple running/stopped status or detailed info), and no context is given for how the status is determined. With many sibling tools, more completeness would help disambiguation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter description lists example values. The tool description repeats these examples but adds no new semantic information (e.g., case sensitivity, allowed values beyond examples). As coverage is high, the baseline of 3 is appropriate; the description does not enhance understanding beyond the schema.
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 checks the status of specified services like nginx, php-fpm, mysql, redis, using a specific verb '查看' (view). It effectively distinguishes from sibling tools that read configs (nginx_config_read) or analyze system resources (disk_analysis, memory_analysis). However, it does not clarify what aspects of status are returned (e.g., running state, version), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that system_info might also show service status, nor does it state when not to use it (e.g., when needing detailed logs). This lack of context makes it harder for an agent to choose correctly among siblings.
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 |
|---|---|---|---|
| type | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation (查看/view) with no side effects. Without annotations, it provides basic transparency but lacks details on permissions, rate limits, or potential performance impacts. The behavior is simple enough that the description is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys the tool's purpose with no wasted words. It is appropriately concise for a straightforward information tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main domain areas but lacks context on output format, default behavior, and distinction from sibling tools. Given the simple parameter and lack of annotations, the description is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions. The description lists the info domains (CPU, memory, etc.) which overlap with the enum values, but it does not explain how the 'type' parameter controls output (e.g., selecting a subset vs. all). The agent must infer parameter usage from the tool name and enum values alone.
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 views system CPU, memory, disk, load, and process information. It uses a specific verb (查看/view) and resource (system info). However, it does not explicitly differentiate from sibling tools like memory_analysis or disk_analysis that offer more targeted views.
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 on when to use this tool versus alternative tools (e.g., memory_analysis, disk_analysis). The description does not specify contexts, prerequisites, or when not to use it, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0certbot_installcertbot_renewcommand_execconfig_auditconfirm_executedisk_analysisfile_deletefile_listfile_patchfile_readfile_searchfile_writelog_listlog_readlog_searchlog_search_systemmemory_analysisnginx_config_readnginx_config_testnginx_reloadproject_overviewservice_statussystem_infoMost tools target distinct resources and actions (file, log, nginx, certbot, system), but there is potential confusion between command_exec and confirm_execute, as both handle confirmation for certain operations. Additionally, system_info overlaps partially with memory_analysis and disk_analysis, though they offer deeper analysis.
Tool names consistently use snake_case and mostly follow an object_action pattern (e.g., file_read, log_search, nginx_reload). However, some actions are verbs (install, exec, delete) while others are nouns (analysis, overview, status, info), and 'confirm_execute' uses two verbs without a clear object, reducing consistency.
With 23 tools, the set is on the higher end of the appropriate range but still well-scoped for server operations. Each tool has a specific purpose, and the count is justified by the breadth of tasks covered (files, logs, nginx, certbot, system analysis).
The tool set covers core server operations: file CRUD, logging, nginx configuration and reload, certbot installation and renewal, and system analysis. Minor gaps exist, such as no certbot revocation, no tool for restarting services beyond nginx, and no direct git deployment tools beyond status checking.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/GT-dinuo/server-ops-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
