ToolBox MCP Server
툴박스 MCP 서버
AI 기반 자동화 도구 개발 플랫폼은 다음을 제공합니다.
🧩 모듈형 아키텍처 - src/tools 디렉토리를 통한 도구 핫 리로딩 🤖 AI 지원 - 자연어를 도구 템플릿으로 변환하는 AI 엔진 🚀 엔터프라이즈급 기능 - MongoDB/Redis/SSH와 같은 프로덕션 환경 서비스 통합 🔄 실시간 업데이트 - buildReload_tool 통한 다운타임 없는 배포
지엑스피1
기여하다
Related MCP server: Jachy MCP Server
특징
도구
전체 도구 사양과 자세한 설명서를 보려면 TOOL.md를 방문하세요.
자원
리소스는 도구 실행의 결과로 동적으로 생성됩니다. 예를 들어, create_note 도구는 URI를 통해 액세스할 수 있는 노트 리소스를 생성합니다.
워크플로 도구
workflow_tool 여러 도구를 연결하여 복잡한 워크플로를 조율하는 강력한 도구입니다. 다음을 지원합니다.
직렬 및 병렬 실행: 도구를 순차적 또는 병렬 방식으로 실행합니다.
거래 관리: 오류 처리를 위한 보상 메커니즘을 통해 거래를 관리합니다.
상세 보고: 각 단계의 상태, 실행 시간, 결과를 포함하여 워크플로 실행에 대한 상세 보고서를 생성합니다.
사용자 정의 가능한 출력: 워크플로 실행 보고서를 저장할 출력 파일을 지정합니다.
프롬프트
summarize_notes:create_note도구를 사용하여 생성된 노트의 요약을 생성합니다.
개발 가이드
새로운 도구 추가
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:#333세부적인 개발 프로세스
템플릿 생성:
src/tools/디렉토리에 새 도구 파일을 생성합니다.AI 검증: 매개변수 스키마 준수 여부를 자동으로 확인합니다.
테스트 생성: 기능 설명을 기반으로 테스트 케이스를 생성합니다.
보안 검토: 정적 코드 분석 및 종속성 검사
지속적인 통합: GitHub Actions를 통한 자동 배포
전체 개발 가이드 보기: prompt.md 기존 구현 참조: 도구 예제
개발
종속성 설치:
npm install서버를 빌드하세요:
npm run build자동 재빌드를 사용한 개발의 경우:
npm run watch마켓플레이스 제출
Claude Desktop을 위한 완벽한 통합 자동화 툴킷
설치
Claude Desktop 애플리케이션과 통합하려면 다음 서버 구성을 추가하세요.
macOS:
~/Library/Application Support/Claude/claude_desktop_config.json윈도우:
%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": []
}핵심 가치
🚀 package.json 구성을 활용한 엔터프라이즈급 자동화 제공:
글로벌 CLI 도구 설치(
tbx명령)워크플로 스케줄링 엔진
다중 플랫폼 지원(Windows/macOS)
하이브리드 클라우드 배포 기능(MongoDB/Redis/SSH)
🔧 개발자 친화적
강력한 형식의 TypeScript 구현
실시간 디버깅 지원(--inspect 플래그)
VSCode 디버깅 구성 템플릿
핫 리로딩 메커니즘:
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:#333buildReload_tool호출하여 구현합니다.다운타임 없는 업데이트
자동 종속성 트리 구문 분석
버전 호환성 확인
샌드박스 환경 테스트
디버깅
MCP 서버 디버깅은 stdio 통신 때문에 까다로울 수 있습니다. 다음은 몇 가지 방법입니다.
🚧 면책 조항
민감한 데이터
민감한 데이터가 포함된 컨테이너를 구성하지 마세요. 여기에는 API 키, 데이터베이스 비밀번호 등이 포함됩니다.
LLM이 로컬 컴퓨터에서 실행되고 있지 않는 한, LLM과 교환되는 모든 민감한 데이터는 본질적으로 손상될 가능성이 있습니다.
법적 책임 ⚠️
⚠️ 이 도구는 MIT 라이선스에 따라 "있는 그대로" 제공되며 어떠한 보증도 없습니다.
⚠️ 개발자는 직접/간접적 손해에 대해 책임을 지지 않습니다.
⚠️ 부적절한 컨테이너 구성으로 인한 모든 위험은 사용자에게 있습니다.
⚠️ 불법적이거나 파괴적인 사용은 엄격히 금지됩니다.
⚠️ 전체 약관은 라이선스를 참조하세요.
Node.js Inspector:
--inspect=9229플래그로 서버를 시작합니다.
node --inspect=9229 build/index.js그런 다음 chrome://inspect 로 이동하여 Chrome DevTools를 사용하여 서버에 연결합니다.
MCP Inspector:
inspectornpm 스크립트를 통해 접근 가능한 전용 디버깅 도구인 MCP Inspector를 활용하세요.VSCode 디버깅
VSCode로 디버깅하려면 다음 구성으로 .vscode/launch.json 파일을 만드세요.
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "attach",
"name": "ToolBox",
"address": "localhost",
"port": 9229,
"localRoot": "${workspaceFolder}"
}
]
}그런 다음 --inspect=9229 플래그로 서버를 시작하고 VSCode 디버거를 연결합니다.
Available Tools
17 toolsbuildReload_toolD
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
calculator_toolD
| 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 |
TDQS
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.
cli_toolD
| Name | Required | Description | Default |
|---|---|---|---|
| command | No | 要执行的单行命令 | |
| commands | No | 要执行的多行命令序列 (与 'command' 互斥) | |
| mode | No | 执行模式: sync (同步阻塞), async (异步非阻塞) | sync |
| timeout | No | 命令执行的超时时间(秒) | |
| cwd | No | 命令执行的工作目录 (绝对路径) | |
| platform | No | 强制指定执行命令的操作系统环境 | auto |
| safe_mode | No | 是否启用危险命令过滤 |
TDQS
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.
compress_toolD
| 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 |
TDQS
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.
create_noteD
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Note title | |
| content | Yes | Note content |
TDQS
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.
excel_toolD
| 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 |
TDQS
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.
fileSystem_toolD
| 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 |
TDQS
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.
gemini_image_toolD
| 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 |
TDQS
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.
image_toolD
| 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) |
TDQS
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.
log_toolD
| 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) |
TDQS
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.
mongo_toolD
| 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 }) |
TDQS
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.
redis_toolD
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | 要执行的 Redis 命令 (例如, 'GET', 'SET') | |
| args | No | 命令的参数列表 (例如: ["mykey", "myvalue"]) |
TDQS
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.
schedule_toolD
| 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) |
TDQS
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.
sftp_toolD
| 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 |
TDQS
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.
ssh_toolD
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | Yes | SSH server name | |
| command | Yes | Command to execute |
TDQS
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.
time_toolD
| 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. |
TDQS
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.
workflow_toolD
| 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) |
TDQS
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
10 tool updates
v1.0.0- Changed
calculator_tool51 fields changed- changed
Input schema / descriptionPrevious value: -"Calculator tool supporting various math operations."New value: +"A powerful universal calculator supporting basic expressions, statistics, geometry, finance, logic, number theory, combinatorics, probability, set theory, and complex numbers." - changed
Input schema / properties / calculation_type / enumPrevious value: -[ - "evaluate_expression", - "calculate_function", - "calculate_statistics", - "perform_geometry", - "perform_financial_math", - "perform_logic_operations", - "perform_number_theory", - "perform_combinatorics", - "calculate_probability", - "perform_set_theory", - "perform_complex_number" -]New value: +[ + "evaluate_expression", + "calculate_statistics", + "perform_geometry", + "perform_financial_math", + "perform_logic_operations", + "perform_number_theory", + "perform_combinatorics", + "calculate_probability", + "perform_set_theory", + "perform_complex_number" +] - removed
Input schema / properties / combinatorics_operation / descriptionRemoved value: -"The type of combinatorics operation." - added
Input schema / properties / complex_aAdded value: +{ + "description": "First complex number (e.g., '3 + 4i').", + "type": "string" +} - removed
Input schema / properties / complex_a_imaginaryRemoved value: -{ - "description": "The imaginary part of the first complex number.", - "type": "number" -} - removed
Input schema / properties / complex_a_realRemoved value: -{ - "description": "The real part of the first complex number.", - "type": "number" -} - added
Input schema / properties / complex_bAdded value: +{ + "description": "Second complex number (e.g., '1 - 2i').", + "type": "string" +} - removed
Input schema / properties / complex_b_imaginaryRemoved value: -{ - "description": "The imaginary part of the second complex number (if needed).", - "type": "number" -} - removed
Input schema / properties / complex_b_realRemoved value: -{ - "description": "The real part of the second complex number (if needed).", - "type": "number" -} - removed
Input schema / properties / complex_number_operation / descriptionRemoved value: -"The type of complex number operation." - removed
Input schema / properties / data_points / descriptionRemoved value: -"The array of data points." - removed
Input schema / properties / data_set_x / descriptionRemoved value: -"The dataset X for bivariate statistics." - removed
Input schema / properties / data_set_y / descriptionRemoved value: -"The dataset Y for bivariate statistics." - changed
Input schema / properties / expression / descriptionPrevious value: -"The mathematical expression to calculate."New value: +"The mathematical expression to evaluate (for 'evaluate_expression')." - removed
Input schema / properties / financial_math_operation / descriptionRemoved value: -"The type of financial math calculation to perform." - removed
Input schema / properties / function_argumentRemoved value: -{ - "description": "The argument value for the function.", - "type": "number" -} - removed
Input schema / properties / function_nameRemoved value: -{ - "description": "The name of the function to calculate.", - "type": "string" -} - added
Input schema / properties / future_valueAdded value: +{ + "type": "number" +} - removed
Input schema / properties / geometry_operation / descriptionRemoved value: -"The type of geometric calculation to perform." - removed
Input schema / properties / heightRemoved value: -{ - "description": "The height.", - "type": "number" -} - removed
Input schema / properties / length / descriptionRemoved value: -"The length." - removed
Input schema / properties / logic_operation / descriptionRemoved value: -"The type of logic operation to perform." - removed
Input schema / properties / n_compounding_periods / descriptionRemoved value: -"The number of compounding periods." - removed
Input schema / properties / n_value / descriptionRemoved value: -"The n value." - removed
Input schema / properties / number_a / descriptionRemoved value: -"The first number." - removed
Input schema / properties / number_b / descriptionRemoved value: -"The second number (if needed)." - removed
Input schema / properties / number_theory_modulus / descriptionRemoved value: -"The modulus for modular exponentiation." - removed
Input schema / properties / number_theory_operation / descriptionRemoved value: -"The type of number theory operation." - removed
Input schema / properties / operand_a / descriptionRemoved value: -"The first operand." - removed
Input schema / properties / operand_b / descriptionRemoved value: -"The second operand." - removed
Input schema / properties / precision_level / descriptionRemoved value: -"Calculation precision level." - removed
Input schema / properties / principal / descriptionRemoved value: -"The principal amount." - removed
Input schema / properties / probability_a / descriptionRemoved value: -"The probability of event A (between 0 and 1)." - removed
Input schema / properties / probability_a_given_b / descriptionRemoved value: -"The conditional probability of A given B (between 0 and 1)." - removed
Input schema / properties / probability_b / descriptionRemoved value: -"The probability of event B (between 0 and 1)." - removed
Input schema / properties / probability_b_given_a / descriptionRemoved value: -"The conditional probability of B given A (between 0 and 1)." - removed
Input schema / properties / probability_operation / descriptionRemoved value: -"The type of probability calculation." - removed
Input schema / properties / r_value / descriptionRemoved value: -"The r value (if needed)." - removed
Input schema / properties / radius / descriptionRemoved value: -"The radius of the circle." - changed
Input schema / properties / rate / descriptionPrevious value: -"The interest rate (percentage)."New value: +"Interest rate as a percentage (e.g., 5 for 5%)." - removed
Input schema / properties / set_a / descriptionRemoved value: -"The first set." - added
Input schema / properties / set_a / items / anyOfAdded value: +[ + { + "type": "number" + }, + { + "type": "string" + } +] - removed
Input schema / properties / set_a / items / typeRemoved value: -"number" - removed
Input schema / properties / set_b / descriptionRemoved value: -"The second set." - added
Input schema / properties / set_b / items / anyOfAdded value: +[ + { + "type": "number" + }, + { + "type": "string" + } +] - removed
Input schema / properties / set_b / items / typeRemoved value: -"number" - removed
Input schema / properties / set_theory_operation / descriptionRemoved value: -"The type of set theory operation." - removed
Input schema / properties / side / descriptionRemoved value: -"The side length of the cube." - removed
Input schema / properties / statistics_operation / descriptionRemoved value: -"The type of statistical calculation to perform." - changed
Input schema / properties / time / descriptionPrevious value: -"The time (in years)."New value: +"Time in years." - removed
Input schema / properties / width / descriptionRemoved value: -"The width."
- Changed
cli_tool9 fields changed- changed
Input schema / descriptionPrevious value: -"CLI executor with sync/async modes and timeout."New value: +"执行CLI命令,支持同步/异步模式、超时和安全过滤。" - changed
Input schema / properties / command / descriptionPrevious value: -"Single-line command content"New value: +"要执行的单行命令" - changed
Input schema / properties / commands / descriptionPrevious value: -"Multi-line command sequence (mutually exclusive with 'command')"New value: +"要执行的多行命令序列 (与 'command' 互斥)" - changed
Input schema / properties / cwd / descriptionPrevious value: -"Working directory (absolute or relative to build/)"New value: +"命令执行的工作目录 (绝对路径)" - changed
Input schema / properties / mode / descriptionPrevious value: -"Execution mode: sync - synchronous blocking, async - asynchronous non-blocking"New value: +"执行模式: sync (同步阻塞), async (异步非阻塞)" - changed
Input schema / properties / platform / descriptionPrevious value: -"Force execution context (win32, linux)"New value: +"强制指定执行命令的操作系统环境" - changed
Input schema / properties / safe_mode / descriptionPrevious value: -"Enable dangerous command filtering"New value: +"是否启用危险命令过滤" - changed
Input schema / properties / timeout / defaultPrevious value: -30New value: +60 - changed
Input schema / properties / timeout / descriptionPrevious value: -"Command timeout in seconds"New value: +"命令执行的超时时间(秒)"
- Changed
excel_tool7 fields changed- changed
Input schema / descriptionPrevious value: -"Read and write Excel/CSV files"New value: +"Read and write Excel (xlsx) and CSV files, and convert from JSON." - removed
Input schema / properties / chunkSizeRemoved value: -{ - "default": 1000, - "description": "Chunk size (rows) for streaming", - "type": "number" -} - changed
Input schema / properties / filePath / descriptionPrevious value: -"Absolute path to the file"New value: +"Absolute path to the input file" - changed
Input schema / properties / format / descriptionPrevious value: -"File format: xlsx, xls, csv"New value: +"File format: xlsx, csv" - changed
Input schema / properties / format / enumPrevious value: -[ - "xlsx", - "xls", - "csv" -]New value: +[ + "xlsx", + "csv" +] - added
Input schema / properties / outputFilePathAdded value: +{ + "description": "Absolute path to the output file (required for write and convert actions)", + "type": "string" +} - removed
Input schema / properties / streamRemoved value: -{ - "default": false, - "description": "Enable streaming for large files", - "type": "boolean" -}
- Changed
fileSystem_tool12 fields changed- changed
Input schema / descriptionPrevious value: -"Cross-platform file system management tool."New value: +"一个强大的文件系统工具,用于执行读、写、复制、移动、删除、列表等操作。" - added
Input schema / properties / contentAdded value: +{ + "description": "要写入文件的内容 (用于 'write' 操作)", + "type": "string" +} - changed
Input schema / properties / fileMode / descriptionPrevious value: -"File mode (permissions) in octal format (e.g., 755)"New value: +"文件模式(权限),使用八进制格式 (例如, 755)" - changed
Input schema / properties / gid / descriptionPrevious value: -"Group ID for chown operation"New value: +"用于 chown 操作的组 ID" - changed
Input schema / properties / operation / descriptionPrevious value: -"File system operation (read, write, copy, etc.)"New value: +"要执行的文件系统操作 (例如: read, write, copy)" - changed
Input schema / properties / overwrite / descriptionPrevious value: -"Overwrite existing files during copy/move"New value: +"在 copy/move 操作中覆盖已存在的文件" - removed
Input schema / properties / platformOverrideRemoved value: -{ - "default": "auto", - "description": "Override platform for OS behavior simulation", - "enum": [ - "auto", - "linux", - "win32", - "darwin" - ], - "type": "string" -} - changed
Input schema / properties / recursive / descriptionPrevious value: -"Recursively apply operation to directories"New value: +"递归地对目录应用操作" - changed
Input schema / properties / showHidden / descriptionPrevious value: -"Include hidden files/directories in list/listDetails"New value: +"在 list/listDetails 中包含隐藏文件/目录" - changed
Input schema / properties / sourcePath / descriptionPrevious value: -"Absolute path to source"New value: +"源文件的绝对路径" - changed
Input schema / properties / targetPath / descriptionPrevious value: -"Absolute path to target (required for copy/move)"New value: +"目标文件的绝对路径 (用于 copy/move 操作)" - changed
Input schema / properties / uid / descriptionPrevious value: -"User ID for chown operation"New value: +"用于 chown 操作的用户 ID"
- Changed
image_tool8 fields changed- changed
Input schema / descriptionPrevious value: -"Compress images, batch process files/dirs."New value: +"A powerful image processing tool that supports format conversion, resizing, quality compression, and can batch process directories." - changed
Input schema / namePrevious value: -"img_tool"New value: +"image_tool" - added
Input schema / properties / compressionLevelAdded value: +{ + "default": 6, + "description": "PNG compression level (0-9, defaults to 6)", + "maximum": 9, + "minimum": 0, + "type": "number" +} - changed
Input schema / properties / format / descriptionPrevious value: -"Output format"New value: +"Output format (optional, keeps original if not specified)" - removed
Input schema / properties / modeRemoved value: -{ - "default": "sync", - "description": "Execution mode (sync or async)", - "enum": [ - "sync", - "async" - ], - "type": "string" -} - changed
Input schema / properties / outputPath / descriptionPrevious value: -"Output directory path (defaults to source)"New value: +"Output directory path. Defaults to a new file (e.g., 'source.processed.jpg') or a new directory (e.g., 'source_processed')." - changed
Input schema / properties / quality / defaultPrevious value: -75New value: +80 - changed
Input schema / properties / quality / descriptionPrevious value: -"Compression quality (1-100, defaults to 75)"New value: +"Compression quality for JPEG/WebP/AVIF/TIFF (1-100, defaults to 80)"
- Changed
log_tool1 field changed- changed
Input schema / requiredPrevious value: -[ - "pageSize", - "page" -]New value: +[]
- Added
mongo_tool - Added
redis_tool - Changed
time_tool10 fields changed- changed
Input schema / descriptionPrevious value: -"Get current time"New value: +"Get and convert time, supporting timezones, formatting, and timestamp operations." - added
Input schema / properties / actionAdded value: +{ + "description": "The operation to perform.", + "enum": [ + "get_current_time", + "format_time", + "from_timestamp", + "to_timestamp" + ], + "type": "string" +} - removed
Input schema / properties / formatRemoved value: -{ - "description": "Time format (iso, timestamp, local, custom)", - "enum": [ - "iso", - "timestamp", - "local", - "custom" - ], - "type": "string" -} - added
Input schema / properties / format_optionsAdded value: +{ + "description": "Formatting options for the time string, based on Intl.DateTimeFormat.", + "properties": { + "day": { + "enum": [ + "numeric", + "2-digit" + ], + "type": "string" + }, + "hour": { + "enum": [ + "numeric", + "2-digit" + ], + "type": "string" + }, + "minute": { + "enum": [ + "numeric", + "2-digit" + ], + "type": "string" + }, + "month": { + "enum": [ + "numeric", + "2-digit", + "long", + "short", + "narrow" + ], + "type": "string" + }, + "second": { + "enum": [ + "numeric", + "2-digit" + ], + "type": "string" + }, + "timeZoneName": { + "enum": [ + "long", + "short" + ], + "type": "string" + }, + "year": { + "enum": [ + "numeric", + "2-digit" + ], + "type": "string" + } + }, + "type": "object" +} - removed
Input schema / properties / patternRemoved value: -{ - "description": "Custom format pattern (required if format=custom)", - "type": "string" -} - removed
Input schema / properties / targetTimezoneRemoved value: -{ - "description": "Target timezone for timestamp conversion (e.g., America/New_York)", - "type": "string" -} - added
Input schema / properties / time_strAdded value: +{ + "description": "An ISO 8601 time string (e.g., '2025-03-15T10:00:00Z'). Required for 'format_time' and 'to_timestamp'.", + "type": "string" +} - changed
Input schema / properties / timestamp / descriptionPrevious value: -"Timestamp to convert"New value: +"Unix timestamp in milliseconds. Required for 'from_timestamp'." - changed
Input schema / properties / timezone / descriptionPrevious value: -"Timezone (e.g., Asia/Shanghai)"New value: +"The target timezone (e.g., 'UTC', 'America/New_York', 'Asia/Shanghai')." - changed
Input schema / requiredPrevious value: -[]New value: +[ + "action" +]
- Changed
workflow_tool2 fields changed- added
Input schema / properties / parallelAdded value: +{ + "default": false, + "description": "If true, executes all steps in parallel.", + "type": "boolean" +} - removed
Input schema / properties / steps / items / properties / parallelRemoved value: -{ - "default": false, - "description": "Execute in parallel", - "type": "boolean" -}
15 tool updates
- First observed
buildReload_tool - First observed
calculator_tool - First observed
cli_tool - First observed
compress_tool - First observed
create_note - First observed
excel_tool - First observed
fileSystem_tool - First observed
gemini_image_tool - First observed
image_tool - First observed
log_tool - First observed
schedule_tool - First observed
sftp_tool - First observed
ssh_tool - First observed
time_tool - First observed
workflow_tool
TDQS
Scored across 17 tools
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.
Maintenance
Related MCP Connectors
- mcp-serverOAuthcom.make
Give your AI agents the tools to build, manage, and run automation workflows.
- SkilderOAuthai.skilder
One place to build, share, and govern the skills and tools your AI agents use at work.
- AxiomOAuthcom.axiomide
The marketplace where agents don't just use tools — they build, publish, and compose new ones.
- agentpmtOAuthcom.agentpmt
AI agent marketplace for automated employees, workflows, skills, and tool orchestration.
Related MCP Servers
- AlicenseAqualityFmaintenanceEnables AI models to dynamically create and execute their own custom tools through a meta-function architecture, supporting JavaScript, Python, and Shell runtimes with sandboxed security and human approval flows.510MIT
- FlicenseAqualityDmaintenanceA centralized automation hub that provides a unified interface for AI agents to interact with various services, currently featuring Discord forum post creation. It offers an extensible TypeScript architecture designed for easily adding new tool domains and integrating with platforms like Claude Desktop and Cursor.1-
- FlicenseNot gradedqualityDmaintenanceAll-in-one automation platform for AI agents, providing browser automation, API testing, debugging, and testing tools via the MCP protocol.3-
- FlicenseNot gradedqualityDmaintenanceEnables AI agents to execute tools securely with Docker isolation, tier-based permissions, and feature flags, providing a centralized tool registry and MCP server.-