The ToolBox MCP Server is an AI-powered automation platform that orchestrates modular tools with enterprise-grade capabilities. With this server, you can:
Tool Development & Management: Add custom tools via src/tools with AI assistance, hot-reloading for zero-downtime updates
Workflow Orchestration: Chain multiple tools into serial/parallel workflows with transaction management, retries, and timeouts
File Operations: Manage files (read, write, copy, move, delete), compress/extract (ZIP, TAR, TAR.GZ), and process Excel/CSV files
Data Processing: Perform calculations (mathematical, statistical, financial), database operations (SQLite, Redis), and image processing (compression, resizing)
Remote Interactions: Execute SSH commands and transfer files via SFTP
Task Automation: Schedule one-time or recurring tasks
Integration: Connect with MongoDB, Redis, and SSH servers
Development Support: Debugging via Node.js Inspector, MCP Inspector, and VSCode
Supports automated deployment via GitHub Actions for continuous integration and version releases of tools
Incorporates Mermaid diagrams for visualizing tool workflows and development processes
Provides database integration for storing and retrieving data with MongoDB, supporting enterprise-grade capabilities for automation workflows
Provides runtime environment integration with debugging support via Node.js inspector protocol
Enables caching and data structure operations through Redis integration, supporting high-performance data access for tools and workflows
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., "@ToolBox MCP Server create a workflow to backup my database and send me a summary report"
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.
An AI-powered automation tool development platform, providing:
🧩 Modular Architecture - Tool hot-reloading via the src/tools directory
🤖 AI Assistance - AI engine for natural language to tool template conversion
🚀 Enterprise-Grade Capabilities - Integration of production environment services such as MongoDB/Redis/SSH
🔄 Real-time Updates - Zero-downtime deployment via buildReload_tool
graph LR
A[Developer] -->|Create| B(Tool Template)
B --> C{AI Verification}
C -->|Pass| D[Automatic Loading]
C -->|Fail| E[Human Review]
D --> F[API Exposure]
F --> G[Client Invocation]
style C fill:#4CAF50,stroke:#333Contributing Guidelines (English) Contributing Guidelines (中文)
Related MCP server: Jachy MCP Server
View the complete tool specifications and detailed documentation: TOOL.md
Resources are generated dynamically as a result of tool execution. For example, the create_note tool creates a note resource that can be accessed via its URI.
The workflow_tool is a powerful tool for orchestrating complex workflows by chaining together multiple tools. It supports:
Serial and Parallel Execution: Execute tools in a sequential or parallel manner.
Transaction Management: Manage transactions with compensation mechanisms for error handling.
Detailed Reporting: Generate detailed reports on workflow execution, including the status, execution time, and results of each step.
Customizable Output: Specify an output file to save the workflow execution report.
summarize_notes: Generates summaries of the notes created using the create_note tool.
graph TD
A[Create Tool Template] --> B{AI Automatic Verification}
B -->|Schema Validation| C[Generate Test Cases]
B -->|Risk Exists| D[Human Review]
C --> E[Unit Testing]
D -->|Approve| E
E --> F[Security Scanning]
F --> G[Build Integration]
G --> H[Version Release]
style A fill:#f9f,stroke:#333
style H fill:#4CAF50,stroke:#333Detailed Development Process
Template Creation: Create a new tool file in the src/tools/ directory
AI Verification: Automatically check the parameter Schema compliance
Test Generation: Generate test cases based on the function description
Security Review: Static code analysis and dependency checking
Continuous Integration: Automated deployment via GitHub Actions
View the complete development guide: prompt.md Refer to existing implementations: Tool Examples
Install dependencies:
npm installBuild the server:
npm run buildFor development with auto-rebuild:
npm run watch
A Seamless Integrated Automation Toolkit for Claude Desktop
To integrate with the Claude Desktop application, add the following server configuration to:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
// Cline MCP server configuration file
{
"command": "node",
"args": [
"--inspect=9229",
"/MCP/ToolBox/build/index.js"
],
"env": {
"MONGO_URI": "mongodb://user:password@host:port/db",
"MONGO_INDEX_OPS": "true",
"REDIS_URI": "redis://:password@host:port",
"SSH_server1_URI": "username:password@host:port",
"GEMINI_API_KEY":"GEMINI_API_KEY",
"SSEPORT": "8080" // Optional: If set, the server will use SSE transport on this port. Otherwise, it defaults to Stdio transport.
},
"disabled": false,
"autoApprove": []
}🚀 Enterprise-Grade Automation Leveraging package.json configuration, providing:
Global CLI tool installation (tbx command)
Workflow scheduling engine
Multi-platform support (Windows/macOS)
Hybrid cloud deployment capabilities (MongoDB/Redis/SSH)
🔧 Developer-Friendly
Strongly-typed TypeScript implementation
Real-time debugging support (--inspect flag)
VSCode debugging configuration template
Hot-reloading mechanism:
graph LR
A[Code Modification] --> B[buildReload_tool]
B --> C[Automatic Compilation]
C --> D[Security Verification]
D --> E[Tool Reloading]
style B fill:#4CAF50,stroke:#333Implemented by calling buildReload_tool:
Zero-downtime updates
Automatic dependency tree parsing
Version compatibility check
Sandbox environment testing
Debugging MCP servers can be challenging due to their stdio communication. Here are a few approaches:
🚧 Disclaimers
DO NOT CONFIGURE CONTAINERS WITH SENSITIVE DATA. This includes API keys, database passwords, etc.
Any sensitive data exchanged with the LLM is inherently compromised, unless the LLM is running on your local machine.
⚠️ The tool is provided "as-is" under MIT License without warranties
⚠️ Developer not liable for direct/indirect damages
⚠️ Users bear all risks from improper container configurations
⚠️ Any illegal or destructive usage is strictly prohibited
⚠️ See LICENSE for full terms
Node.js Inspector: Launch the server with the --inspect=9229 flag:
node --inspect=9229 build/index.jsThen, connect to the server using Chrome DevTools by navigating to chrome://inspect.
MCP Inspector: Utilize the MCP Inspector, a dedicated debugging tool accessible via the inspector npm script:
VSCode Debugging
To debug with VSCode, create a .vscode/launch.json file with the following configuration:
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "attach",
"name": "ToolBox",
"address": "localhost",
"port": 9229,
"localRoot": "${workspaceFolder}"
}
]
}Then, launch the server with the --inspect=9229 flag and attach the VSCode debugger.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| calculation_type | Yes | The type of calculation to perform. | |
| expression | No | The mathematical expression to evaluate (for 'evaluate_expression'). | |
| statistics_operation | No | ||
| data_points | No | ||
| data_set_x | No | ||
| data_set_y | No | ||
| geometry_operation | No | ||
| radius | No | ||
| length | No | ||
| width | No | ||
| side | No | ||
| financial_math_operation | No | ||
| principal | No | ||
| rate | No | Interest rate as a percentage (e.g., 5 for 5%). | |
| time | No | Time in years. | |
| n_compounding_periods | No | ||
| future_value | No | ||
| logic_operation | No | ||
| operand_a | No | ||
| operand_b | No | ||
| number_theory_operation | No | ||
| number_a | No | ||
| number_b | No | ||
| number_theory_modulus | No | ||
| combinatorics_operation | No | ||
| n_value | No | ||
| r_value | No | ||
| probability_operation | No | ||
| probability_a | No | ||
| probability_b | No | ||
| probability_a_given_b | No | ||
| probability_b_given_a | No | ||
| set_theory_operation | No | ||
| set_a | No | ||
| set_b | No | ||
| complex_number_operation | No | ||
| complex_a | No | First complex number (e.g., '3 + 4i'). | |
| complex_b | No | Second complex number (e.g., '1 - 2i'). | |
| precision_level | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| command | No | 要执行的单行命令 | |
| commands | No | 要执行的多行命令序列 (与 'command' 互斥) | |
| mode | No | 执行模式: sync (同步阻塞), async (异步非阻塞) | sync |
| timeout | No | 命令执行的超时时间（秒） | |
| cwd | No | 命令执行的工作目录 (绝对路径) | |
| platform | No | 强制指定执行命令的操作系统环境 | auto |
| safe_mode | No | 是否启用危险命令过滤 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action type: compress or extract | |
| sourcePath | Yes | Absolute path to source file/directory | |
| destinationPath | Yes | Absolute path to destination file/directory | |
| format | Yes | Compression format: zip, tar, tar.gz |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Note title | |
| content | Yes | Note content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: read, write, or convert_json_to_xlsx | |
| filePath | Yes | Absolute path to the input file | |
| outputFilePath | No | Absolute path to the output file (required for write and convert actions) | |
| format | Yes | File format: xlsx, csv | |
| data | No | Data to write (required for write action) | |
| options | No | Additional options |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | 要执行的文件系统操作 (例如: read, write, copy) | |
| sourcePath | Yes | 源文件的绝对路径 | |
| targetPath | No | 目标文件的绝对路径 (用于 copy/move 操作) | |
| content | No | 要写入文件的内容 (用于 'write' 操作) | |
| recursive | No | 递归地对目录应用操作 | |
| overwrite | No | 在 copy/move 操作中覆盖已存在的文件 | |
| showHidden | No | 在 list/listDetails 中包含隐藏文件/目录 | |
| fileMode | No | 文件模式（权限），使用八进制格式 (例如, 755) | |
| uid | No | 用于 chown 操作的用户 ID | |
| gid | No | 用于 chown 操作的组 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | generate_image: Generate new image, edit_image: Edit existing image | |
| prompt | Yes | Prompt for image generation/editing | |
| inputImage | No | Image path (required for edit_image) | |
| outputDir | Yes | Output directory path | |
| fileName | No | Output file name template | image-${year}_${month}_${day}_${hour}_${minute}_${second}.png |
| temperature | No | Temperature of the model | |
| topP | No | Top P of the model | |
| topK | No | Top K of the model | |
| maxOutputTokens | No | Maximum number of output tokens |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| sourcePath | Yes | Source file or directory path | |
| outputPath | No | Output directory path. Defaults to a new file (e.g., 'source.processed.jpg') or a new directory (e.g., 'source_processed'). | |
| quality | No | Compression quality for JPEG/WebP/AVIF/TIFF (1-100, defaults to 80) | |
| compressionLevel | No | PNG compression level (0-9, defaults to 6) | |
| resize | No | Resize options | |
| format | No | Output format (optional, keeps original if not specified) | |
| recursive | No | Process subdirectories recursively | |
| backupDir | No | Backup directory path (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Logs per page (1-100) | |
| page | No | Page number (>= 1) | |
| toolName | No | Regex to match tool name | |
| status | No | Log status (success or error) | |
| minDuration | No | Minimum duration (ms) | |
| maxDuration | No | Maximum duration (ms) | |
| startTime | No | Start time (ISO8601) | |
| endTime | No | End time (ISO8601) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| dbName | Yes | MongoDB 数据库名称 | |
| collectionName | No | MongoDB 集合名称 | |
| queryType | No | MongoDB 查询类型 | |
| operationType | No | 数据库管理操作类型 (索引/集合管理) | |
| where | No | 查询条件 (BSON/JSON 对象) | |
| data | No | 用于插入或替换的数据 (单个对象或对象数组) | |
| updateOperators | No | 更新操作符 (例如: { $set: { field: 'value' } }) | |
| pipeline | No | 聚合管道阶段 (对象数组) | |
| field | No | 用于 distinct 操作的字段名 | |
| indexes | No | 索引规范 (例如: { field: 1 }) | |
| newName | No | 用于 renameCollection 的新名称 | |
| bulkOperations | No | 批量写入操作数组 | |
| options | No | 其他选项 (例如: { sort: { field: -1 }, limit: 10 }) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | 要执行的 Redis 命令 (例如, 'GET', 'SET') | |
| args | No | 命令的参数列表 (例如: ["mykey", "myvalue"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action type (create/cancel/list) | |
| time | No | Absolute execution time (YYYY-MM-DD HH:mm:ss) | |
| delaySeconds | No | Delay execution by N seconds | |
| interval | No | Recurring interval pattern (e.g. 'every@5m') | |
| toolName | No | Tool to execute (e.g. 'time_tool') | |
| toolArgs | No | Parameters for the target tool | |
| id | No | Task ID (required for cancel) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | Yes | SSH server name | |
| action | Yes | Action: upload or download | |
| localPath | Yes | Local file path (absolute) | |
| remotePath | Yes | Remote file path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | Yes | SSH server name | |
| command | Yes | Command to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The operation to perform. | |
| time_str | No | An ISO 8601 time string (e.g., '2025-03-15T10:00:00Z'). Required for 'format_time' and 'to_timestamp'. | |
| timezone | No | The target timezone (e.g., 'UTC', 'America/New_York', 'Asia/Shanghai'). | |
| timestamp | No | Unix timestamp in milliseconds. Required for 'from_timestamp'. | |
| format_options | No | Formatting options for the time string, based on Intl.DateTimeFormat. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | Workflow definition version (e.g., '1.0.1') | 1.0 |
| parallel | No | If true, executes all steps in parallel. | |
| steps | Yes | List of workflow steps | |
| outputFile | No | Path to output file (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tools cover diverse domains (e.g., file operations, databases, utilities), but there is significant ambiguity due to vague naming and lack of descriptions. For example, 'image_tool' and 'gemini_image_tool' likely overlap in image-related tasks, while 'cli_tool', 'ssh_tool', and 'sftp_tool' could all involve command-line or remote operations without clear boundaries. The absence of descriptions exacerbates confusion, making it difficult for an agent to reliably choose the right tool for a specific need.
Naming conventions are inconsistent and chaotic. There is a mix of styles: some tools use snake_case (e.g., 'calculator_tool', 'create_note'), others use camelCase (e.g., 'fileSystem_tool'), and some have hybrid or irregular forms (e.g., 'buildReload_tool'). Verb usage varies widely, from generic terms like 'tool' to specific verbs like 'create', with no predictable pattern. This inconsistency makes the tool set harder to navigate and understand at a glance.
With 17 tools, the count is borderline high but not extreme, falling into the 16-25 range that feels heavy for a server named 'ToolBox MCP Server', which suggests a broad utility scope. While the number is reasonable for covering multiple domains, it risks being overwhelming without clear organization or descriptions. A more focused set might improve usability, but it doesn't reach the extreme mismatch of 50+ tools.
The tool set appears to cover various utility domains (e.g., file systems, databases, scheduling, images), but without descriptions, it's impossible to assess true coverage or identify obvious gaps. The lack of CRUD operations for many domains (e.g., no update/delete for notes or files) and the vague tool names suggest significant gaps in functionality. For instance, 'create_note' might exist, but without tools for reading or managing notes, workflows could hit dead ends, leading to potential agent failures.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give your AI agents the tools to build, manage, and run automation workflows.
One place to build, share, and govern the skills and tools your AI agents use at work.
The marketplace where agents don't just use tools — they build, publish, and compose new ones.
AI agent marketplace for automated employees, workflows, skills, and tool orchestration.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xiaoguomeiyitian/ToolBox'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
