The MCP JSON Maker server is a comprehensive JSON management tool that enables AI to create, manage, batch generate, and export JSON data and templates with high performance and precision.
Complete CRUD Operations: Perform full create, read, update, and delete operations on JSON data and templates with advanced filtering, sorting, and statistics capabilities.
Node-Level Editing: Modify specific parts of JSON documents using precise paths (e.g., users.0.name, config.database.0.host) with operations like set, add, remove, and update.
Batch JSON Generation: Generate large quantities of JSON data (up to 10,000 items at 1,000 items/second) using templates, dynamic rules, data type definitions, constraints, and field variations (e.g., {'name': ['张三', '李四']}).
Multi-Format Export: Export JSON data to files in JSON, JSONL, or CSV formats with options for pretty printing, custom file paths, and automatic directory creation.
Advanced Features: Template management, rules engine for dynamic generation, data organization by tags/time/size, and millisecond-level search speeds with support for unlimited items.
Developer-Friendly: Detailed input schemas, comprehensive error handling, and debugging information for seamless integration.
Distributed as an npm package (@zb2947244682/mcp-json-maker) that can be installed and run directly via npx for JSON manipulation and generation tasks
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., "@MCP JSON Maker create a JSON template for user profiles with name, age, and email fields"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
这是一个强大的 MCP (Model Context Protocol) 工具，专门为AI提供JSON构建、编辑和批量生成能力。它允许AI创建、管理、编辑和批量生成JSON数据，支持多种输出格式和高级规则引擎。
NPM 仓库地址: @zb2947244682/mcp-json-maker
Related MCP server: Divide and Conquer MCP Server
此 MCP 服务提供了完整的JSON管理系统：
item_operations - 通用工具，支持JSON和模板的完整CRUD操作
创建、获取、列表、编辑、删除、统计
支持节点级操作（如 users.0.name）
智能参数验证和错误提示
batch_generate_json - 根据模板和规则批量生成JSON数据
支持基于现有模板生成
支持规则引擎动态生成
支持数据类型定义、约束条件和变化选项
export_to_file - 将JSON数据导出到文件
支持多种格式：JSON、JSONL、CSV
支持绝对路径和相对路径
支持指定行号插入内容
自动创建目录结构
快速创建标准化的JSON结构
批量生成测试数据
支持复杂的嵌套结构
根据规则批量生成数据
支持数据变化和约束
高效的数据转换和导出
节点级精确编辑
支持数组和对象操作
完整的版本控制
JSON到CSV转换
JSON到JSONL转换
支持美化输出
将以下配置添加到您的 Cursor mcp.json 文件中：
{
"mcp-json-maker": {
"command": "npx",
"args": [
"-y",
"@zb2947244682/mcp-json-maker@latest"
]
}
}您可以通过以下命令直接从命令行运行此 MCP 项目：
npx @zb2947244682/mcp-json-maker@latest如果您在本地开发环境中使用，可以将以下配置添加到您的 Cursor mcp.json 文件中：
{
"mcp-json-maker": {
"command": "node",
"args": ["D:\\Codes\\MCPRepo\\mcp-json-maker\\index.js"]
}
}{
"id": "唯一标识",
"name": "JSON名称",
"content": "JSON内容对象",
"description": "描述信息",
"tags": ["标签1", "标签2"],
"size": "内容大小",
"createdAt": "创建时间",
"updatedAt": "更新时间"
}{
"id": "唯一标识",
"name": "模板名称",
"content": "模板JSON结构",
"description": "模板描述",
"variables": ["变量1", "变量2"],
"category": "分类",
"createdAt": "创建时间",
"updatedAt": "更新时间"
}{
"structure": "JSON结构描述",
"data_types": {
"field1": "string",
"field2": "number",
"field3": "array"
},
"constraints": {
"field1": {"min": 1, "max": 100},
"field2": {"pattern": "^[^@]+@[^@]+\\.[^@]+$"}
},
"variations": {
"field1": ["选项1", "选项2", "选项3"],
"field2": ["城市1", "城市2", "城市3"]
}
}✅ 完整的CRUD操作支持
✅ 节点级精确编辑
✅ 智能批量生成
✅ 多格式文件导出
✅ 规则引擎支持
✅ 模板管理系统
✅ 友好的中文界面
✅ 完善的错误处理
✅ 高性能内存存储
✅ 自动路径处理
响应时间: 1-3ms
支持JSON数: 无限制
支持模板数: 无限制
批量生成速度: 1000个/秒
搜索速度: 毫秒级
内存占用: 最小化
{
"tool": "item_operations",
"parameters": {
"action": "create",
"item_type": "json",
"name": "用户配置",
"content": "{\"name\": \"张三\", \"age\": 25, \"email\": \"zhangsan@example.com\"}",
"description": "用户基本信息配置",
"tags": ["user", "config", "test"]
}
}{
"tool": "item_operations",
"parameters": {
"action": "edit",
"item_type": "json",
"id": "your_json_id",
"path": "age",
"operation": "set",
"value": 26
}
}{
"tool": "batch_generate_json",
"parameters": {
"count": 5,
"rules": {
"structure": "用户信息结构，包含姓名、年龄、邮箱等字段",
"data_types": {
"name": "string",
"age": "number",
"email": "string"
},
"constraints": {
"age": {"min": 18, "max": 65}
},
"variations": {
"name": ["张三", "李四", "王五", "赵六", "钱七"],
"city": ["北京", "上海", "广州", "深圳", "杭州"]
}
},
"output_format": "array"
}
}{
"tool": "export_to_file",
"parameters": {
"json_ids": ["id1", "id2", "id3"],
"file_path": "D:/data/users.json",
"format": "json",
"pretty_print": true
}
}支持复杂的嵌套路径操作：
简单字段："name"
嵌套对象："user.profile.age"
数组元素："users.0.name"
混合路径："config.database.0.host"
set - 设置值
add - 添加元素（数组操作）
remove - 删除值
update - 更新对象属性
JSON - 标准JSON格式，支持美化输出
JSONL - 每行一个JSON对象
CSV - 逗号分隔值（支持扁平结构）
一个工具完成多种相关操作
参数复用最大化
智能默认值设置
条件参数设计
详细的参数说明和示例
友好的错误提示和解决建议
完整的操作指导
丰富的调试信息
数据持久化支持
高级规则引擎
语义分析功能
数据导入功能
多用户支持
权限管理
版本控制
协作编辑
欢迎提交 Issue 和 Pull Request 来改进这个项目！
本项目采用 MIT 许可证。
让AI拥有强大的JSON构建和管理能力，构建智能的数据处理系统！ 🚀
根据模板和规则批量生成JSON数据。支持基于现有模板生成或根据规则动态生成。适用于测试数据生成、批量数据处理等场景。
| Name | Required | Description | Default |
|---|---|---|---|
| count | Yes | 生成数量：要生成的JSON数量，建议从少量开始测试 | |
| output_format | No | 输出格式：array(批量保存)、individual(单独保存，每个JSON独立) | array |
| rules | Yes | 生成规则：定义JSON生成的具体规则和约束 | |
| template_id | No | 模板ID：可选，如果提供则基于现有模板生成。使用item_operations工具查看可用模板 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions support for template-based and rule-based generation, but doesn't describe critical behaviors like whether this is a read-only or mutating operation, what permissions are required, rate limits, error handling, or what the output looks like. For a tool with no annotations and complex parameters, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured in two sentences. The first sentence states the core purpose, and the second provides usage scenarios. There's no wasted text, and it's front-loaded with the main functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain what the tool returns, how errors are handled, or behavioral constraints. For a data generation tool with significant parameter complexity, more context is needed to help an agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, mentioning '基于现有模板生成或根据规则动态生成' (generate based on existing templates or dynamically based on rules), which loosely maps to 'template_id' and 'rules' parameters. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '根据模板和规则批量生成JSON数据' (batch generate JSON data based on templates and rules). It specifies the verb (generate), resource (JSON data), and scope (batch). However, it doesn't explicitly differentiate from sibling tools like 'export_to_file' or 'item_operations', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: '适用于测试数据生成、批量数据处理等场景' (suitable for test data generation, batch data processing, etc.). This implies when to use the tool, but it doesn't explicitly state when NOT to use it or mention alternatives like sibling tools. The guidance is helpful but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
将JSON数据导出到指定文件，支持多种格式和插入位置。支持绝对路径和相对路径，自动创建不存在的目录。
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | 目标文件路径：支持绝对路径(如'D:/data/export.json')或相对路径(如'./output/export.json')。相对路径相对于当前工作目录 | |
| format | No | 输出格式：json(标准JSON格式)、jsonl(每行一个JSON)、csv(逗号分隔值，仅支持扁平结构) | json |
| insert_line | No | 插入行号：从1开始，指定在文件的第几行插入内容。不指定则覆盖整个文件 | |
| json_ids | Yes | JSON ID列表：要导出的JSON的ID数组。使用item_operations工具查看可用的JSON ID | |
| pretty_print | No | 是否美化输出：true(格式化缩进)、false(紧凑格式) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses some behavioral traits like automatic directory creation and support for absolute/relative paths, but it doesn't cover critical aspects such as whether this is a destructive operation (e.g., file overwriting), error handling, permissions needed, or rate limits. For a write operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded and efficient. Every sentence adds value: the first states the core purpose and key features, and the second provides practical details on path handling and directory creation, with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a write operation with 5 parameters, no annotations, and no output schema), the description is incomplete. It lacks information on behavioral aspects like destructiveness, error handling, and output format details. Without annotations or an output schema, the description should do more to compensate, but it falls short, leaving gaps for a tool that modifies files.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning '支持多种格式和插入位置' (supports multiple formats and insertion positions), which loosely relates to 'format' and 'insert_line' parameters, but doesn't provide additional syntax or meaning. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('导出' meaning export) and resource ('JSON数据' meaning JSON data) to a file, specifying the action and target. It distinguishes from siblings by focusing on file export rather than JSON generation (batch_generate_json) or item operations (item_operations). However, it doesn't explicitly mention that it's for writing/creating files, which could be slightly more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning support for multiple formats and insertion positions, and it references item_operations for viewing JSON IDs, providing some context. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., batch_generate_json for creating JSON vs. exporting existing JSON), and no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通用工具，用于创建、获取、列表、编辑、删除JSON或模板，以及获取统计信息。支持完整的CRUD操作和高级查询功能。
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 操作类型：create(创建)、get(获取)、list(列表)、edit(编辑)、delete(删除)、stats(统计) | |
| category | No | 分类：模板的分类，如'user'、'product'、'config'等 | |
| content | No | 内容：JSON字符串，必须是有效的JSON格式。示例：{"key":"value"} | |
| description | No | 描述：项目的详细说明，帮助理解项目用途 | |
| filter_tags | No | 标签筛选：只显示包含指定标签的JSON，如['user', 'active'] | |
| filter_type | No | 类型筛选：all(全部)、generated(批量生成)、manual(手动创建) | |
| id | No | 项目ID：用于get、edit、delete操作，必须是已存在的ID | |
| index | No | 数组索引：add/remove操作时的位置索引，从0开始。不指定则添加到末尾或删除第一个 | |
| item_type | No | 项目类型：json(JSON数据) 或 template(模板)，除stats外都需要指定 | |
| limit | No | 列表限制：返回的最大项目数量，默认20，最大100 | |
| name | No | 名称：创建时的项目名称，建议使用有意义的描述性名称 | |
| operation | No | 编辑操作：set(设置值)、add(添加元素)、remove(删除)、update(更新对象) | |
| path | No | 节点路径：编辑JSON时的路径，支持点号分隔。示例：'users.0.name'、'config.database.host' | |
| sort_by | No | 排序方式：createdAt(创建时间)、updatedAt(更新时间)、name(名称)、size(大小) | |
| tags | No | 标签：JSON项目的分类标签，如['user', 'config', 'test'] | |
| value | No | 新值：要设置、添加或更新的值。可以是任何类型：字符串、数字、数组、对象等 | |
| variables | No | 变量：模板中的变量名列表，如['name', 'age', 'email'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'CRUD operations' and 'advanced query', but fails to describe critical behaviors like authentication needs, rate limits, error handling, or what 'stats' returns. For a tool with 17 parameters and multiple actions, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists capabilities ('create, get, list, edit, delete, stats') and mentions 'CRUD operations and advanced query'. However, it's front-loaded with a broad claim ('通用工具') and could be more structured to highlight key use cases or differentiate from siblings, making it adequate but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (17 parameters, 6 actions), no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error conditions, or behavioral nuances like how 'edit' with 'operation' works. The agent must rely heavily on the input schema, leaving gaps in understanding the tool's full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 17 parameters thoroughly with descriptions and enums. The description adds no additional parameter semantics beyond what's in the schema, such as explaining dependencies between parameters (e.g., 'id' is required for 'get' but not 'create'). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs 'CRUD operations and advanced query functions' on 'JSON or templates', which gives a general purpose. However, it's vague about what specific resources it operates on ('JSON or templates' is broad) and doesn't distinguish from sibling tools like 'batch_generate_json' or 'export_to_file'—it's unclear when to use this versus those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings ('batch_generate_json', 'export_to_file'). The description mentions 'advanced query function' but doesn't specify contexts or exclusions, leaving the agent to infer usage from the parameter schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0batch_generate_jsonexport_to_fileitem_operationsThe tools have distinct primary purposes—batch generation, file export, and CRUD operations—but 'item_operations' is overly broad and could overlap with the others, especially since it handles JSON/template CRUD which might include generation or export-like functions. Descriptions help clarify, but the boundaries are somewhat fuzzy.
The naming is mixed: 'batch_generate_json' and 'export_to_file' follow a verb_noun pattern, but 'item_operations' uses a vague noun-based style. This inconsistency makes the set less predictable, though the names are still readable and not chaotic.
With 3 tools, the count is reasonable for a JSON-focused server, though it feels slightly thin for covering all aspects of JSON manipulation. Each tool appears to serve a distinct role, so it's well-scoped but could benefit from more granularity in some areas.
The tools cover key areas: generation, export, and CRUD operations, providing good lifecycle coverage for JSON data. However, there are minor gaps, such as no dedicated tool for JSON validation or transformation, which agents might need to work around using the existing tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Validate and convert JSONL fine-tuning data across 11 AI providers. 13 tools.
300+ deterministic data utilities for AI agents: validate, normalize, parse, match, redact.
Turn any PDF into structured JSON via AI + OCR: invoices, bank statements, contracts.
Deterministic JSON repair, validate, example-gen, schema-coerce for agents. Zero LLM, sub-10ms.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zb2947244682/mcp-json-maker'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
