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., "@AX Local Operations MCP Server search for 'TODO' in the /src directory and show the results"
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.
版本 2.8.0 · Node.js ≥ 18 · Windows / macOS / Linux
为大模型应用提供安全的本地操作能力：文件读写、行级编辑、搜索、比较、哈希、权限、压缩、监控、命令执行和任务管理。
{
"mcpServers": {
"ax_local_operations": {
"command": "npx",
"args": ["-y", "ax-local-operations-mcp"]
}
}
}npm install -g ax-local-operations-mcp{
"mcpServers": {
"ax_local_operations": {
"command": "ax-local-operations-mcp"
}
}
}安装时会自动运行交互式向导设置默认工作目录。
也可在对话中临时指定：当前的工作目录是：/path/to/project
Related MCP server: MCP Shell Server
工具名 | 说明 | 平台 |
| 文件读写、列出、创建目录、删除 | 全平台 |
| 行级编辑（插入、删除、替换、追加） | 全平台 |
| 正则/关键词内容搜索 | 全平台 |
| 文件差异对比 | 全平台 |
| MD5/SHA256 等哈希计算 | 全平台 |
| 权限读写（chmod / attrib / icacls） | 全平台 |
| 压缩/解压（zip/tar/gzip） | 全平台¹ |
| 文件/目录变更监控 | 全平台 |
| 执行系统命令（pwsh / bash） | 全平台 |
| 任务创建与跟踪 | 全平台 |
| 时间查询与格式化 | 全平台 |
| 持久化环境信息存储 | 全平台 |
| 工作目录管理 | 全平台 |
| sudo 无密码配置助手 | Linux 专用 |
¹ Windows 需要
zip/unzip/tar/gzip在 PATH 中（Git Bash、WSL 或手动安装）。
路径安全：securityValidator.resolveAndAssert() 阻止路径逃逸；拒绝路径中的隐藏目录组件（如 ../.hidden/file），但允许 .env 等点文件。
命令安全：仅拦截不可恢复的极危险命令（如 format C:、rm -rf /）；Agent 全控授权模式下无警告摩擦。
工作目录注入：index.js 会在每次工具调用前自动注入 working_directory，工具无需手动传入。
# 对话中临时切换
当前的工作目录是：/path/to/project
# 通过工具持久化
workspace_manager: set /path/to/project
workspace_manager: getnpm start # 启动 MCP 服务器
node test/runTests.js # 运行完整测试套件（报告写入 test/reports/）
node test/integrationTest.js # 注册表与平台集成测试
npm run release # semantic-release（需 Conventional Commits）创建 tools/newTool.js，导出带 constructor(securityValidator) 和 async handle(args) 的类。
在 tools/registry.js 中导入、实例化、添加描述符。
详见 tools/tools_dev_guide.md。
平台 | 支持状态 |
Windows 10/11 | ✅ 完全支持（PowerShell 7 / pwsh） |
macOS | ✅ 完全支持 |
Linux | ✅ 完全支持（含 sudo_config） |
MIT
环境记忆：读取、更新和获取环境变量。环境变量存储在 ~/.local_file_operations/.env 文件中。
示例：读取全部 { "operation": "read", "output_format": "json" } 示例：设置变量 { "operation": "update", "key": "PROJECT_PATH", "value": "/project" }
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | 操作：read(读取全部)、update(更新/新增)、get(获取指定) | |
| key | No | 环境变量键名 | |
| value | No | 环境变量值 | |
| output_format | No | 输出格式：text(纯文本)、json(结构化JSON)、both(两者兼有) |
| Name | Required | Description |
|---|---|---|
| key | No | 环境变量键 |
| value | No | 环境变量值 |
| operation | No | 执行的操作 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide critical behavioral hints: destructiveHint=true (indicating potential data modification) and readOnlyHint=false (confirming write capability). The description adds useful context by specifying the storage location ('~/.local_file_operations/.env 文件中'), which isn't covered by annotations. However, it doesn't disclose additional behavioral traits like whether updates are persistent, if there are rate limits, or what happens on conflicts. No contradiction with annotations exists.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by specific examples. Each sentence earns its place by providing actionable information. However, the mix of Chinese and English in the examples slightly affects readability, and the structure could be more polished with clearer separation between description and examples.
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 moderate complexity (4 parameters, destructive operations) and rich structured data (100% schema coverage, annotations, output schema exists), the description is reasonably complete. It covers the purpose, storage location, and provides usage examples. Since an output schema exists, the description doesn't need to explain return values. The main gap is lack of explicit guidance on when to use versus sibling tools, but overall it provides sufficient context for an agent to operate 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%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it provides example usage patterns that illustrate how parameters combine (e.g., operation='read' with output_format='json'), but doesn't explain parameter semantics beyond what the schema's descriptions and enums already provide. This meets the baseline for high 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 the tool's purpose: '读取、更新和获取环境变量' (read, update, and get environment variables), which is a specific verb+resource combination. It distinguishes itself from sibling tools like file_edit or file_operation by focusing specifically on environment variables stored in a specific file. However, it doesn't explicitly differentiate between 'read' and 'get' operations beyond what the schema provides.
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 implied usage through examples: it shows when to use 'read' (to read all variables) and 'update' (to set a variable). However, it doesn't explicitly state when to use this tool versus alternatives like file_edit (which could potentially edit the .env file directly) or provide clear exclusions. The examples give context but lack explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
命令执行：在系统中执行shell命令。支持管道、重定向，集成命令策略评估和sudo配置。
示例：列出文件 { "command": "ls -la", "output_format": "json" } 示例：带工作目录执行 { "command": "npm test", "working_directory": "/project", "timeout_ms": 120000 }
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | 要执行的系统命令，支持管道和重定向 | |
| working_directory | No | 工作目录路径，所有相对路径以此为基础解析 | |
| confirm | No | 确认执行高风险命令，需要在 warn 策略下设为 true | |
| timeout_ms | No | 超时时间（毫秒），防止命令长时间阻塞，默认60000 | |
| stdout_max | No | stdout最大输出长度，超出会被截断，默认4000 | |
| stderr_max | No | stderr最大输出长度，超出会被截断，默认2000 | |
| output_format | No | 输出格式：text(纯文本)、json(结构化JSON)、both(两者兼有) |
| Name | Required | Description |
|---|---|---|
| cwd | No | 工作目录 |
| status | No | 执行状态：ok/error/need_confirm |
| stderr | No | 错误输出 |
| stdout | No | 标准输出 |
| command | No | 执行的命令 |
| exit_code | No | 进程退出码 |
| truncated | No | 输出是否被截断 |
| duration_ms | No | 执行耗时（毫秒） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it mentions support for pipes and redirection, integration with command policy evaluation, and sudo configuration. Annotations indicate destructiveHint=true, which aligns with the tool's nature as a command executor, and the description doesn't contradict this. However, it lacks details on rate limits, authentication needs, or specific error behaviors.
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 front-loaded with the core purpose in the first sentence, followed by key features and two concise examples. Each sentence adds value, such as clarifying capabilities and providing usage scenarios, though the examples could be integrated more seamlessly into the text.
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 (destructive operation with 7 parameters) and the presence of annotations and an output schema, the description is reasonably complete. It covers the tool's purpose, key features, and examples, though it could benefit from more explicit usage guidelines and behavioral details like error handling or security considerations.
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 100% schema description coverage, the input schema fully documents all 7 parameters. The description provides examples that illustrate usage (e.g., command with output_format, working_directory with timeout_ms) but doesn't add significant semantic meaning beyond what's already in the schema descriptions. This meets the baseline for high 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 the tool's purpose as '在系统中执行shell命令' (execute shell commands in the system) with specific capabilities like supporting pipes and redirection. It distinguishes itself from sibling tools like file operations or task management by focusing on raw command execution, though it doesn't explicitly contrast with alternatives like sudo_config.
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 mentions integration with command policy evaluation and sudo configuration, it doesn't specify scenarios where this tool is preferred over other tools like task_manager or sudo_config, nor does it outline prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
文件压缩/解压：支持ZIP、TAR、GZ、TAR.GZ格式。使用spawn安全参数，防止命令注入。
示例：压缩目录 { "operation": "compress", "source": "project", "destination": "backup.zip", "format": "zip" } 示例：解压文件 { "operation": "extract", "source": "archive.tar.gz", "destination": "./extracted" }
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | 操作类型：compress(压缩)、extract(解压) | |
| source | Yes | 源文件或源目录路径 | |
| destination | No | 目标文件或目标目录路径 | |
| format | No | 压缩格式：zip、tar、gz、tar.gz | |
| output_format | No | 输出格式：text(纯文本)、json(结构化JSON)、both(两者兼有) |
| Name | Required | Description |
|---|---|---|
| format | No | 压缩格式 |
| source | No | 源路径 |
| operation | No | 压缩/解压操作 |
| destination | No | 目标路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it mentions security measures ('使用spawn安全参数，防止命令注入' - using spawn security parameters to prevent command injection) and provides concrete usage examples. While annotations already indicate destructiveHint=true and readOnlyHint=false, the description enhances understanding with practical implementation details.
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 perfectly structured: a clear purpose statement, security note, and two practical examples. Every sentence earns its place with no wasted words. The information is front-loaded with the core functionality stated first.
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 (archive operations with security considerations), rich annotations (destructiveHint=true, etc.), 100% schema coverage, and the presence of an output schema, the description is complete enough. It covers purpose, security, formats, and usage patterns without needing to explain return values (handled by 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?
With 100% schema description coverage, the input schema already thoroughly documents all 5 parameters. The description provides example usage showing parameter combinations but doesn't add significant semantic meaning beyond what's in the schema descriptions. The baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '文件压缩/解压' (file compression/decompression) with specific supported formats (ZIP, TAR, GZ, TAR.GZ). It distinguishes from sibling tools like file_edit, file_hash, and file_operation by focusing exclusively on archive operations, not general file manipulation or analysis.
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 clear context for when to use this tool (compressing or extracting archives in specific formats) and includes practical examples. However, it doesn't explicitly state when NOT to use it or mention alternatives among sibling tools, such as when file_operation might be more appropriate for non-archive file operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
文件差异比较：比较两个文件的差异，以文本或JSON格式输出差异统计和详细对比。
示例：比较两个文件 { "file1": "a.js", "file2": "b.js", "output_format": "json" }
| Name | Required | Description | Default |
|---|---|---|---|
| file1 | Yes | 第一个比较文件路径 | |
| file2 | Yes | 第二个比较文件路径 | |
| output_format | No | 输出格式：text(纯文本)、json(结构化JSON)、both(两者兼有) |
| Name | Required | Description |
|---|---|---|
| file1 | No | 源文件路径 |
| file2 | No | 目标文件路径 |
| identical | No | 文件是否完全相同 |
| diff_stats | No | 差异统计 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context about output formats (text, JSON, or both) and that it provides '差异统计和详细对比' (difference statistics and detailed comparison), which goes beyond annotations. No contradiction with annotations exists.
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 appropriately concise with two sentences: one stating the purpose and output, and one providing an example. The example is helpful but could be more integrated. The structure is front-loaded with the core functionality, though it could be slightly more polished in flow.
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 moderate complexity, rich annotations, 100% schema coverage, and presence of an output schema, the description is reasonably complete. It covers what the tool does and output formats, though it lacks usage guidelines and deeper behavioral context. The output schema likely handles return values, so the description doesn't need to explain them.
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%, with all parameters well-documented in the schema. The description adds minimal value beyond the schema, only mentioning output formats in the example without additional semantic context. The baseline of 3 is appropriate since the schema carries the full burden of 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: '比较两个文件的差异' (compare differences between two files) with specific output formats. It distinguishes from siblings like file_edit (editing), file_hash (hashing), and file_search (searching), but doesn't explicitly contrast with file_operation which might be more generic. The description is specific about what it does but could more explicitly differentiate from similar file operations.
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 when file_compare is appropriate versus other file tools like file_operation or file_search, nor does it specify prerequisites or constraints. The example shows usage but doesn't provide contextual decision-making guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
文件行级编辑：在指定位置删除、插入、替换或追加内容。操作前自动备份原文件。
示例：删除第 3-5 行 { "operation": "delete_lines", "path": "test.js", "start_line": 3, "end_line": 5 } 示例：插入内容到第 2 行后 { "operation": "insert_lines", "path": "test.js", "start_line": 2, "content": "new line" }
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | 编辑操作：delete_lines(删除行)、insert_lines(插入行)、replace_lines(替换行)、append_lines(追加行) | |
| path | Yes | 文件或目录的绝对路径，或相对于 working_directory 的相对路径 | |
| start_line | No | 起始行号（从1开始） | |
| end_line | No | 结束行号（从1开始） | |
| content | No | 要写入或追加的文件内容 | |
| output_format | No | 输出格式：text(纯文本)、json(结构化JSON)、both(两者兼有) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it mentions automatic backup before operations, which is crucial for safety given destructiveHint=true. Annotations already indicate it's destructive, non-idempotent, and not read-only, but the backup detail enhances transparency. No contradiction with annotations exists.
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 appropriately sized and front-loaded, starting with the core purpose and key behavioral detail (automatic backup). The examples are relevant but could be slightly more concise. Overall, it avoids unnecessary verbosity while being informative.
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 (destructive operations with 6 parameters) and lack of output schema, the description is reasonably complete. It covers purpose, key behavior (backup), and usage examples. However, it could benefit from mentioning error handling or output details to fully compensate for the missing 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?
With 100% schema description coverage, the schema fully documents all parameters. The description provides examples that illustrate usage of parameters like operation, path, start_line, end_line, and content, but does not add significant meaning beyond what the schema already specifies. This meets the baseline for high 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 the tool's purpose as '文件行级编辑' (file line-level editing) with specific operations: delete, insert, replace, or append content. It distinguishes itself from sibling tools like file_operation, file_compare, and file_search by focusing on line-level modifications rather than general operations, comparisons, or searches.
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 clear context for usage with examples for delete and insert operations, implying when to use this tool for line-level edits. However, it does not explicitly state when not to use it or mention alternatives among sibling tools (e.g., using file_operation for non-line-level edits or file_compare for comparisons).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
文件哈希计算：使用MD5、SHA1、SHA256或SHA512算法计算文件哈希值，用于完整性验证。
示例：计算 SHA256 { "path": "package.json", "algorithm": "sha256", "output_format": "json" }
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 文件或目录的绝对路径，或相对于 working_directory 的相对路径 | |
| algorithm | No | 哈希算法：md5、sha1、sha256、sha512 | |
| output_format | No | 输出格式：text(纯文本)、json(结构化JSON)、both(两者兼有) |
| Name | Required | Description |
|---|---|---|
| hash | No | 计算得到的哈希值 |
| path | No | 文件路径 |
| algorithm | No | 使用的哈希算法 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds context about the tool's purpose (integrity verification) and includes an example that demonstrates parameter usage, which helps clarify behavior beyond the annotations. No contradiction with annotations exists.
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 front-loaded with the core purpose in the first sentence, followed by an example. It's appropriately sized with no redundant information. The example is helpful but could be slightly more concise; overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations (readOnlyHint, idempotentHint, etc.), 100% schema coverage, and the presence of an output schema, the description is complete enough. It explains the tool's purpose and provides an example, which complements the structured data without needing to detail return values (handled by output schema) or repeat schema 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?
Schema description coverage is 100%, with all parameters well-documented in the input schema (path, algorithm, output_format). The description mentions the algorithms and includes an example with parameters, but doesn't add significant meaning beyond what the schema already provides. Baseline 3 is appropriate given high 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 the tool's purpose: '文件哈希计算：使用MD5、SHA1、SHA256或SHA512算法计算文件哈希值，用于完整性验证' (File hash calculation: uses MD5, SHA1, SHA256 or SHA512 algorithms to calculate file hash values for integrity verification). It specifies the verb ('计算' - calculate), resource ('文件哈希值' - file hash values), and distinguishes it from sibling tools like file_compare or file_search by focusing on hash computation rather than comparison or searching.
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 usage for '完整性验证' (integrity verification), which provides some context for when to use this tool. However, it doesn't explicitly state when to choose this over alternatives (e.g., vs. file_compare for content comparison) or any prerequisites. The example shows a specific use case but lacks broader guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
文件操作：读取、写入、列出目录、创建目录、删除文件或目录。支持工作目录解析和相对路径。
示例：读取文件 { "operation": "read", "path": "src/index.js", "output_format": "json" } 示例：写入文件 { "operation": "write", "path": "test.txt", "content": "Hello", "output_format": "text" }
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | 要执行的操作类型 | |
| path | No | 文件或目录的绝对路径，或相对于 working_directory 的相对路径 | |
| working_directory | No | 工作目录路径，所有相对路径以此为基础解析 | |
| content | No | 要写入或追加的文件内容 | |
| max_size | No | 最大文件大小限制（字节），默认 10485760 (10MB) | |
| output_format | No | 输出格式：text(纯文本)、json(结构化JSON)、both(两者兼有) |
| Name | Required | Description |
|---|---|---|
| path | No | 文件/目录绝对路径 |
| size | No | 文件大小（字节） |
| action | No | 执行的操类型 |
| content | No | 读取的文件内容 |
| created | No | 是否创建成功 |
| deleted | No | 是否删除成功 |
| entries | No | 目录列表 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, readOnlyHint=false, etc., covering safety aspects. The description adds useful context about working directory resolution and relative paths, which isn't in annotations. However, it doesn't mention rate limits, authentication needs, or specific behavioral traits like error handling. No contradiction with annotations exists.
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 front-loaded with a clear purpose statement followed by concise examples. Every sentence serves a purpose: the first defines operations and features, and the examples illustrate usage. It's appropriately sized for a multi-operation tool, though slightly verbose in Chinese.
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 (6 parameters, multiple operations) and rich annotations/output schema, the description is reasonably complete. It covers the core functionality and includes examples. However, it lacks guidance on tool selection among siblings, which is a gap given the many file-related alternatives on the server.
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%, so parameters are well-documented in the schema. The description adds minimal value beyond examples showing operation and path usage, but doesn't explain parameter interactions or edge cases. With high schema coverage, baseline 3 is appropriate as the description doesn't significantly enhance parameter understanding.
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 performs file operations (read, write, list directory, create directory, delete) with support for working directory resolution and relative paths. It's specific about the operations but doesn't explicitly differentiate from sibling tools like file_edit, file_archive, or file_permissions, which likely handle overlapping file system functionality.
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_edit, file_archive, or file_search. It includes usage examples but doesn't specify contexts, prerequisites, or exclusions. This leaves the agent without clear decision-making criteria among the many file-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
跨平台文件权限管理：Unix系统使用chmod，Windows系统使用icacls。支持递归设置。
示例：设置文件权限 { "path": "script.sh", "mode": "755" } 示例：递归设置目录权限 { "path": "project", "mode": "644", "recursive": true, "max_depth": 3 }
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 文件或目录的绝对路径，或相对于 working_directory 的相对路径 | |
| mode | No | 文件权限模式，如 "755"(rwxr-xr-x)、"644"(rw-r--r--) | |
| permissions | No | Windows权限设置对象 | |
| recursive | No | 是否递归处理子目录 | |
| max_depth | No | 最大递归深度，0表示不递归，默认8 | |
| output_format | No | 输出格式：text(纯文本)、json(结构化JSON)、both(两者兼有) |
| Name | Required | Description |
|---|---|---|
| mode | No | 设置的权限模式 |
| path | No | 文件/目录路径 |
| changed | No | 权限是否更改成功 |
| recursive | No | 是否递归处理 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it specifies platform-specific implementations (chmod for Unix, icacls for Windows), mentions recursive capability, and provides concrete examples. While annotations already indicate destructiveHint=true and idempotentHint=true, the description provides practical implementation details that help the agent understand behavioral nuances.
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 efficient: a clear purpose statement followed by two concrete examples that demonstrate key functionality. Every sentence earns its place by showing practical usage. The bilingual nature (Chinese purpose + examples) is appropriate for the context.
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 (6 parameters, destructive operation, cross-platform), the description provides good context with platform specifics and examples. With annotations covering safety aspects (destructive, idempotent) and an output schema existing, the description focuses appropriately on practical usage. The main gap is lack of explicit guidance on platform detection or when to use permissions object versus mode.
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 100% schema description coverage, the schema already documents all 6 parameters thoroughly. The description provides examples showing how parameters like path, mode, recursive, and max_depth work together, but doesn't add significant semantic value beyond what's in the schema descriptions. The examples are helpful but don't fundamentally enhance parameter 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's purpose as '跨平台文件权限管理' (cross-platform file permission management) with specific verbs for Unix (chmod) and Windows (icacls). It distinguishes from siblings like file_edit or file_operation by focusing specifically on permissions. However, it doesn't explicitly differentiate from all possible sibling tools in the 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 usage through platform-specific examples (Unix chmod, Windows icacls) and mentions recursive capability, but doesn't provide explicit guidance on when to use this tool versus alternatives like sudo_config or other file_* tools. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
文件内容搜索：在目录中搜索匹配正则表达式的内容。支持文件类型过滤、深度限制、超时控制和忽略模式。
示例：搜索 JS 文件中的函数定义 { "search_path": "src", "pattern": "function\s+\w+", "file_types": "js,ts" } 示例：忽略 node_modules 搜索 { "search_path": ".", "pattern": "TODO", "ignore": ["node_modules", "*.log"] }
| Name | Required | Description | Default |
|---|---|---|---|
| search_path | Yes | 搜索起始目录路径 | |
| pattern | Yes | 正则表达式搜索模式 | |
| file_types | No | 逗号分隔的文件扩展名列表，如 "js,ts,json" | |
| case_sensitive | No | 是否区分大小写搜索 | |
| max_results | No | 最大结果数量，超过会截断，默认100 | |
| max_depth | No | 最大递归深度，0表示不递归，默认8 | |
| timeout_ms | No | 超时时间（毫秒），防止命令长时间阻塞，默认60000 | |
| ignore | No | 要忽略的文件/目录模式列表，支持通配符如 "*.log"、"node_modules" | |
| output_format | No | 输出格式：text(纯文本)、json(结构化JSON)、both(两者兼有) |
| Name | Required | Description |
|---|---|---|
| matches | No | 匹配数量 |
| results | No | 搜索结果 |
| timed_out | No | 是否超时 |
| truncated | No | 结果是否被截断 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond what annotations provide. While annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, the description reveals practical constraints: '超时控制' (timeout control) for preventing long blocks, '深度限制' (depth limits) for recursion control, and '忽略模式' (ignore patterns) for filtering. This gives the agent important operational context not captured in 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?
The description is perfectly structured and concise. The first sentence clearly states the core purpose, followed by bullet-point style features, then two practical examples that demonstrate different use cases. Every sentence earns its place by providing either essential functionality explanation or concrete usage guidance.
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 (9 parameters, regex search functionality), rich annotations (4 hints), and the existence of an output schema, the description is complete enough. It covers the core purpose, key features, and provides practical examples. With output schema handling return values and annotations covering safety/behavioral hints, the description focuses appropriately on usage guidance rather than repeating structured 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?
With 100% schema description coverage, the input schema already documents all 9 parameters thoroughly. The description doesn't add significant semantic meaning beyond what's in the schema - it mentions the same capabilities (file type filtering, depth limits, timeout control, ignore patterns) but doesn't provide additional syntax, format details, or usage nuances. This meets the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('文件内容搜索' - file content search) and resources ('在目录中搜索匹配正则表达式的内容' - search in directories for content matching regular expressions). It distinguishes from sibling tools like file_edit (editing) or file_operation (general operations) by focusing specifically on content pattern matching within files.
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 clear context through two usage examples showing when to use this tool (searching JS files for function definitions, searching for TODOs while ignoring certain directories). However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among siblings, though the examples imply it's for content pattern matching rather than file operations like file_archive or file_permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
文件监控：监控文件或目录的创建、删除、修改事件。支持递归监控和深度限制。
示例：监控目录变化 { "path": "src", "events": "create,delete,modify", "duration": 60 } 示例：递归监控 { "path": "project", "events": "modify", "recursive": true, "max_depth": 3 }
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 文件或目录的绝对路径，或相对于 working_directory 的相对路径 | |
| events | No | 监控的事件类型，可选值：create(创建)、delete(删除)、modify(修改)，逗号分隔 | |
| duration | No | 监控持续时间（秒），0表示持续监控直到手动停止 | |
| recursive | No | 是否递归处理子目录 | |
| max_depth | No | 最大递归深度，0表示不递归，默认8 | |
| output_format | No | 输出格式：text(纯文本)、json(结构化JSON)、both(两者兼有) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide safety information (readOnlyHint=true, destructiveHint=false), but the description adds valuable behavioral context: it mentions recursive monitoring capability, depth limitations, and the concept of duration-based monitoring (including '0表示持续监控直到手动停止' - 0 means continuous monitoring until manually stopped). This goes beyond what annotations provide about the tool's operational 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 well-structured with a clear purpose statement followed by practical examples. Every sentence serves a purpose - the first explains functionality, the examples demonstrate usage patterns. It could be slightly more concise but remains efficient and front-loaded with essential 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?
For a monitoring tool with good annotations and complete schema coverage, the description provides adequate context. It explains the tool's behavior, shows usage patterns, and addresses key operational aspects. The main gap is the lack of output schema, but the description compensates somewhat by mentioning output_format parameter options.
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 100% schema description coverage, the schema already documents all 6 parameters thoroughly. The description's examples illustrate parameter usage patterns but don't add significant semantic meaning beyond what's in the schema. The baseline score of 3 is appropriate when schema coverage 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 tool's purpose with specific verbs ('监控' - monitor) and resources ('文件或目录' - files or directories), listing the exact event types (create, delete, modify). It distinguishes itself from sibling tools like file_operation or file_edit by focusing on monitoring rather than manipulation.
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 usage examples that imply when to use this tool (for monitoring file system events), but it doesn't explicitly state when NOT to use it or mention alternatives among sibling tools. The examples show different monitoring scenarios but lack explicit guidance about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Linux Sudo无密码配置管理：生成、安装、测试和管理sudoers配置。支持dry-run演练模式。
示例：检查sudo状态 { "action": "status" } 示例：生成配置 { "action": "generate", "username": "user", "scope": "limited", "dry_run": true }
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 操作：status(状态)、generate(生成)、install(安装)、remove(移除)、list(列表)、test(测试)、recommendations(建议) | |
| username | No | 用户名 | |
| scope | No | sudo配置范围：limited(有限)、extended(扩展)、full(完全) | |
| commands | No | 允许无密码执行的命令列表 | |
| config_name | No | 配置文件名称 | |
| dry_run | No | 演练模式，只显示操作而不实际执行 | |
| output_format | No | 输出格式：text(纯文本)、json(结构化JSON)、both(两者兼有) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it mentions 'dry-run演练模式' (dry-run practice mode) which clarifies the tool's testing capability, and the examples demonstrate practical usage patterns. The annotations already indicate destructiveHint=true (which matches the tool's sudo configuration management nature), but the description usefully adds the '支持dry-run演练模式' (supports dry-run practice mode) qualification. No contradiction with annotations exists.
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 appropriately concise with two sentences: one stating the core purpose and features, and another providing concrete examples. The examples are front-loaded with practical scenarios. While efficient, the Chinese/English mixing and example formatting could be slightly cleaner, but overall it's well-structured without 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?
For a complex tool with 7 parameters, destructiveHint=true annotation, and no output schema, the description provides adequate but not comprehensive context. It covers the main purpose and includes examples, but doesn't explain important aspects like what 'install' actually does to the system, how 'remove' works, or what format the output takes. The lack of output schema means the description should ideally address return values more explicitly.
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 100% schema description coverage, the input schema already documents all 7 parameters thoroughly with descriptions and enums. The description adds minimal parameter semantics beyond the schema - it only mentions 'dry_run' in the second example and implies 'action', 'username', and 'scope' usage through examples. This meets the baseline of 3 since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'Linux Sudo无密码配置管理：生成、安装、测试和管理sudoers配置' (Linux Sudo passwordless configuration management: generate, install, test, and manage sudoers configurations). It specifies the verb 'manage' and resource 'sudoers configurations' with the key feature of passwordless operation. However, it doesn't explicitly differentiate from sibling tools like execute_command or file_permissions that might also interact with system configurations.
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 implied usage through the two examples showing specific action scenarios (checking status and generating configs). It mentions 'dry-run演练模式' (dry-run practice mode) which gives some context about when to use that feature. However, there's no explicit guidance on when to choose this tool versus alternatives like execute_command for sudo operations or file_edit for manual sudoers file changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
任务管理：创建、更新、完成、列出和清空任务。支持优先级、截止日期、子任务和进度跟踪。
示例：创建任务 { "operation": "create", "model_name": "claude", "title": "完成文档", "priority": "high" } 示例：更新进度 { "operation": "update", "model_name": "claude", "task_id": "xxx", "progress": 50 }
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | 操作类型：create(创建)、read(读取)、update(更新)、delete(删除)、list(列表) | |
| model_name | Yes | 模型名称，用于任务隔离存储 | |
| task_id | No | 任务ID，用于更新或完成特定任务 | |
| title | No | 任务标题 | |
| description | No | 任务详细描述 | |
| priority | No | 任务优先级：low(低)、medium(中)、high(高)、urgent(紧急) | |
| due_date | No | 任务截止日期，ISO 8601格式 | |
| progress | No | 任务完成进度（0-100） | |
| subtasks | No | 子任务列表 | |
| output_format | No | 输出格式：text(纯文本)、json(结构化JSON)、both(两者兼有) |
| Name | Required | Description |
|---|---|---|
| tasks | No | 任务列表 |
| operation | No | 执行的操作 |
| created_task_id | No | 创建的任务ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it mentions support for '优先级、截止日期、子任务和进度跟踪' (priority, due dates, subtasks, and progress tracking), which clarifies behavioral capabilities. Annotations indicate destructiveHint=true (consistent with operations like clear), but the description doesn't contradict them—it complements by detailing what operations are available.
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 reasonably concise with two sentences and examples, but it could be more front-loaded. The first sentence lists operations, and the second adds features, but the examples are helpful yet slightly verbose. It's adequate but not optimally 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 complexity (10 parameters, multiple operations) and rich annotations/output schema, the description provides a good overview. It covers key operations and features, though it could better integrate with the structured data. The examples enhance understanding, making it fairly complete for 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?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description doesn't add significant semantic details beyond the schema, but the examples illustrate usage of some parameters (e.g., operation, model_name, title, priority, progress). This meets the baseline for high 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 the tool's purpose as '任务管理：创建、更新、完成、列出和清空任务' (Task management: create, update, complete, list, and clear tasks), which is specific about the operations it supports. However, it doesn't distinguish this tool from its siblings (all file and system tools), 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 mentions features like priority and due dates but doesn't explain context or prerequisites. The examples show usage patterns but don't offer explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
时间工具：获取当前时间，支持多种格式输出（ISO、UNIX、RFC3339、本地格式）。
示例：获取 ISO 格式 { "format": "iso", "output_format": "json" } 示例：获取指定时区 { "format": "locale", "time_zone": "Asia/Shanghai", "output_format": "text" }
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | 时间格式：iso(ISO 8601)、unix(UNIX时间戳秒)、unix_ms(毫秒)、rfc3339(RFC 3339)、locale(本地格式) | |
| include_milliseconds | No | 是否包含毫秒 | |
| time_zone | No | IANA时区名称，如 "Asia/Shanghai" | |
| output_format | No | 输出格式：text(纯文本)、json(结构化JSON)、both(两者兼有) |
| Name | Required | Description |
|---|---|---|
| format | No | 时间格式 |
| time_zone | No | 使用的时区 |
| timestamp | No | 格式化后的时间字符串 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable context beyond annotations by specifying it '获取当前时间' (gets current time) and showing example outputs (JSON/text). It doesn't contradict annotations - getting current time aligns with read-only, non-destructive behavior. However, it doesn't mention rate limits, authentication needs, or edge cases.
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 appropriately concise with two sentences stating purpose and two examples. It's front-loaded with the core functionality. The Chinese examples are clear but could be slightly more structured. Every sentence serves a purpose - no 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 the tool's low complexity (simple time retrieval), rich annotations (readOnly, idempotent, etc.), 100% schema coverage, and existence of an output schema, the description is reasonably complete. It covers the core functionality and provides examples. For a read-only utility tool with good structured data, this description provides adequate 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?
Schema description coverage is 100%, with all parameters well-documented in the schema. The description provides two examples that illustrate parameter combinations but doesn't add semantic meaning beyond what the schema already explains. The examples show practical usage but don't clarify parameter interactions or constraints not 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 tool's purpose: '获取当前时间，支持多种格式输出' (get current time, supports multiple output formats). It specifies the verb (get/获取) and resource (current time/当前时间), and distinguishes it from sibling tools which are mostly file/process management tools. However, it doesn't explicitly differentiate from potential time-related siblings (none exist in the provided 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 provides two usage examples but offers no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when-not-to-use scenarios, or comparison with other tools. The examples show parameter usage but don't establish context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes with clear boundaries, such as file_edit for line-level editing versus file_operation for basic file operations. However, there is some overlap between file_operation and file_edit, as both handle file modifications, which could cause minor confusion. Overall, the descriptions help differentiate them effectively.
All tool names follow a consistent snake_case pattern with a clear verb_noun structure, such as execute_command, file_compare, and task_manager. There are no deviations or mixed conventions, making the naming predictable and easy to understand across the entire set.
With 13 tools, the count is reasonable for a local operations server covering file management, system commands, and task tracking. It is slightly on the higher side but well-scoped, as each tool addresses a specific operational need without obvious redundancy, though it could be streamlined.
The tool set provides comprehensive coverage for local operations, including file handling, command execution, environment management, and task tracking. Minor gaps exist, such as no direct tool for network operations or process management, but core workflows are well-supported, allowing agents to perform most common tasks effectively.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AndersHsueh/Ax-LocalTools-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server