mern-mcp 是一个开源的模型上下文协议（MCP）服务器，用于在现有代码库中搭建完整的 MERN 全栈 CRUD 资源，并直接支持 Claude Code 和 Codex CLI 的配置。它可以生成 MongoDB 和 Mongoose 模型、Express 服务和路由、React 客户端模块，以及将新资源接入真实应用所需的连接代码，并采用更安全的"先预览后应用"工作流。
如果你正在寻找用于 MERN 全栈开发的 MCP 服务器、MongoDB Express React Node.js CRUD 生成器、Mongoose 加 Express 样板代码生成器，或可与 AI 编码助手配合使用的 React 管理后台脚手架工具，本仓库正是为此而构建的。
目录： 为什么有用 · 生成的文件 · 安装 · 配置 · Claude Code · Codex CLI · Docker · MCP 工具 · 示例 · 项目风格 · 自然语言 · 预览工作流 · 适用人群
Related MCP server: MCP Terminal & Git Server
团队通常并不需要另一个通用代码生成器。他们需要的是一个本地 MCP 工具，能够检查项目、遵循现有目录结构、创建可复用的 CRUD 切片，并避免盲目写入。mern-mcp 正是专注于这种实用工作流。
即使你已经有针对 Next.js、Node.js 或 MongoDB 的 MCP 工具，这些工具通常只在框架或数据库层面提供帮助。mern-mcp 之所以有用，是因为它在一个地方处理完整的资源工作流：模型、服务、控制器、路由、验证器、客户端 API、hooks、表单、列表视图、详情视图以及集成补丁。开发者无需让助手逐层分别接线，而可以一次性搭建整个 CRUD 切片、审查计划，然后更快地进入业务逻辑。这减少了重复的搭建工作，降低了遗漏集成步骤的风险，让日常的全栈开发不再那么繁琐。
当你想要以下功能时，它尤其有用：
根据资源模式搭建 MERN CRUD API 和 React UI
生成 Mongoose 模型、Express 控制器、服务、路由和验证器
生成 React 表单、列表视图、详情视图、hooks、共享类型和 API 模块
让兼容 MCP 的编码助手在你自己的仓库中创建资源
在应用更改之前预览文件变更
通过添加字段和删除工作流长期管理已生成的资源
支持 monorepo 或分离的服务器与客户端项目
mern-mcp 生成什么对于每个资源，mern-mcp 可以生成：
服务器模型文件
服务器服务文件
服务器控制器文件
服务器路由文件
启用验证时的服务器验证器文件
启用 JWT 认证时的认证中间件文件
客户端共享类型文件
客户端 API 模块
客户端数据 hook
客户端表单组件
客户端列表组件
客户端详情组件
典型的生成路径如下所示：
server/models/product.model.ts
server/services/product.service.ts
server/controllers/product.controller.ts
server/routes/product.routes.ts
server/validators/product.validator.ts
client/types/product.types.ts
client/api/product.api.ts
client/hooks/useProduct.ts
client/components/ProductForm.tsx
client/components/ProductList.tsx
client/components/ProductDetail.tsx规划器还可以在检测到受支持的模式时修补现有文件：
在服务器入口文件中挂载新的 Express 路由
在 React Router 文件中注册新路由
在检测到受支持的 store 结构时在 Redux store 中注册 reducer
npm install
npm run build针对目标 MERN 项目运行编译后的 MCP 服务器：
node dist/index.js --project-root /absolute/path/to/target-project本地开发：
npm run dev -- --project-root /absolute/path/to/target-project在目标项目根目录创建 mern-mcp.config.json。
使用 React Query 的 monorepo TypeScript 项目示例：
{
"structure": "monorepo",
"language": "typescript",
"reactStack": "react-query",
"validation": "zod",
"auth": "none",
"rbac": false,
"paths": {
"serverRoot": "./server",
"clientRoot": "./client",
"serverEntry": "index.ts",
"clientRouter": "router.tsx"
}
}使用 Redux 和 JWT 认证的分离客户端与服务器应用示例：
{
"structure": "separate",
"language": "typescript",
"reactStack": "redux",
"validation": "both",
"auth": "jwt",
"paths": {
"serverRoot": "./server",
"clientRoot": "./client",
"modelsDir": "src/models",
"servicesDir": "src/services",
"controllersDir": "src/controllers",
"routesDir": "src/routes",
"validatorsDir": "src/validators",
"middlewareDir": "src/middleware",
"componentsDir": "src/components",
"hooksDir": "src/hooks",
"apiDir": "src/api",
"typesDir": "src/types",
"serverEntry": "src/index.ts",
"clientRouter": "src/router.tsx",
"clientStore": "src/store.ts"
}
}所有产物目录都可以通过 paths 覆盖。
安装依赖并构建本仓库：
npm install
npm run build在你要搭建的目标 MERN 项目中创建 mern-mcp.config.json。
将 MCP 服务器添加到 Claude Code：
claude mcp add mern-mcp -- node /absolute/path/to/mern-mcp/dist/index.js --project-root /absolute/path/to/project确认服务器在 Claude Code 中可用。
在应用模式下使用 scaffold_resource 之前，先使用 preview_scaffold。
安装依赖并构建本仓库：
npm install
npm run build在你要搭建的目标 MERN 项目中创建 mern-mcp.config.json。
将 MCP 服务器添加到 Codex CLI：
codex mcp add mern-mcp --command node --args /absolute/path/to/mern-mcp/dist/index.js --project-root /absolute/path/to/project确认 MCP 服务器已列在 Codex 中。
先使用 preview_scaffold，检查生成的计划，然后复用返回的 previewHash 进行应用模式。
如果你不想在宿主机上直接安装 Node.js，可以在 Docker 中运行 mern-mcp。
从本仓库构建镜像：
docker build -t mern-mcp .确保目标 MERN 项目包含 mern-mcp.config.json。
运行容器并将目标项目挂载到其中：
docker run --rm -i \
-v /absolute/path/to/target-project:/workspace \
mern-mcp \
--project-root /workspace如果你想在 MCP 客户端中注册 Docker 化的服务器，请使用 Docker 作为命令并传入相同的参数。
示例形式：
docker run --rm -i -v /absolute/path/to/target-project:/workspace mern-mcp --project-root /workspace服务器当前注册了以下工具：
preview_scaffold
scaffold_resource
list_resources
add_field
delete_resource
preview_scaffold干运行一次搭建，在更改文件之前检查生成的写入计划。
scaffold_resource预览或应用某个资源的完整 MERN CRUD 搭建。
list_resources列出由清单管理的资源，并可选择扫描项目中未管理的资源。
add_field预览或应用在现有生成资源上添加新字段。
delete_resource预览或应用删除已生成的资源，并移除其清单记录。
对于 scaffold_resource、add_field 和 delete_resource，重要的输入包括：
mode："preview" 或 "apply"
previewHash：在 "apply" 模式下必填
conflictStrategy："abort"、"overwrite" 或 "skip"
产品资源的示例预览请求：
{
"resourceName": "Product",
"fields": [
{ "name": "title", "type": "string", "required": true },
{ "name": "price", "type": "number", "required": true },
{ "name": "inStock", "type": "boolean", "required": false }
],
"mode": "preview"
}预览后，复用返回的 previewHash 进行应用模式。
mern-mcp 支持以下维度的可配置 MERN 代码生成：
项目结构：monorepo 或 separate
语言：typescript 或 javascript
React 数据栈：plain、react-query、redux 或 axios
验证：zod、express-validator、both 或 none
认证：jwt 或 none
它还支持可配置路径，因此你可以将生成指向自定义目录，例如 src/models、src/routes、src/components 或 src/store.ts。
你可以通过两种方式搭建资源：
传入显式的字段模式。
传入自然语言描述，让规划器推断字段。
自然语言输入示例：
a blog post with title, body, author, tags这种输入风格会被解析为资源结构，其中 author 之类的术语可以变成 objectId 引用，tags 之类的术语可以变成字符串数组。
支持的字段类型包括：
string
number
boolean
date
objectId
支持的 UI 控件提示包括：
text
textarea
number
checkbox
date
select
multiselect
tags
本仓库最强大的部分之一是预览/应用契约。
preview 模式返回计划、产物、集成操作、冲突以及确定性的 previewHash
apply 模式要求匹配的 previewHash
未管理的文件冲突可以通过 abort、overwrite 或 skip 处理
生成的资源路径记录在 .mern-mcp-manifest.json 中
这为 AI 工具和人工操作员提供了一种更可控的代码搭建方式，而不会静默覆盖无关的工作。
mern-mcp 非常适合：
希望更快搭建资源的 MERN 全栈开发者
使用 MCP 的 AI 辅助编码工作流
构建重复管理后台和 CRUD 后台系统的代理机构
交付内部工具或 SaaS 控制面板的创业团队
维护一致约定的 TypeScript 和 JavaScript 团队
需要生成加集成（而不仅仅是零散代码模板）的开发者
人们通常使用以下短语搜索此类项目：
MERN 全栈的 MCP 服务器
MERN 全栈 CRUD 生成器
MongoDB Express React Node 脚手架工具
Mongoose 模型生成器
Express API 样板代码生成器
React Query CRUD 生成器
Redux CRUD 脚手架工具
MERN 应用的 AI 代码生成器
全栈 JavaScript 的本地 MCP 工具
全栈 TypeScript CRUD 脚手架
这些短语与本项目直接相关，因为该服务器直接生成这些产物和集成。
如果有人从美国、加拿大、英国、欧洲、中东、印度、孟加拉国、巴基斯坦、新加坡或澳大利亚搜索 MERN 全栈脚手架工具，答案都是一样的：mern-mcp 在你自己的项目中本地运行，不绑定到特定的云区域或托管平台。
这使得它适用于分布式工程团队、远程代理机构、创业团队、自由开发者以及来自纽约、多伦多、伦敦、柏林、迪拜、班加罗尔、达卡、新加坡或悉尼等城市的产品公司，只要项目使用 Node.js 和兼容 MCP 的客户端即可。
本仓库不仅仅是模板的堆砌。它包含：
可运行的 MCP 服务器
使用 Zod 的类型化输入模式
可配置的项目路径解析
基于 AST 的服务器和客户端注册集成补丁器
基于清单的资源管理
预览、应用、添加字段、列出和删除工作流
主要生命周期的测试和冒烟覆盖
这种组合与围绕 MERN 代码生成、MCP 工具、CRUD 脚手架、Express 路由生成、Mongoose 模型生成、React Query CRUD 辅助工具、Redux 脚手架和 TypeScript 全栈自动化的搜索直接相关。
npm run check
npm test
npm run build
npm run smokeMIT
Preview or apply a new field on an existing manifest-managed resource.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | preview | |
| field | Yes | ||
| previewHash | No | ||
| resourceName | Yes | ||
| conflictStrategy | No | abort |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full transparency burden, yet it only reveals the existence of two behavioral modes ('Preview or apply'). It fails to disclose the two-phase handshake workflow (preview returns a previewHash that apply requires), the implications of conflictStrategy values including the potentially destructive 'overwrite', or any safety caveats about modifying manifest-managed resources. The single sentence is the barest outline of behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The sentence is economically constructed, front-loading the action verb and fitting meaningful scoping in a single readable clause. However, 'appropriately sized' is questionable — for a tool with this much complexity, one sentence is arguably under-specification rather than genuine conciseness. On pure prose quality it's well-built, but it earns no credit for elegance at the expense of substance.
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?
This tool has a nested field object with ten properties, a two-phase preview/apply workflow, a conflict resolution strategy with potentially destructive values, a required previewHash handoff, and zero annotations or output schema describing any of it. The description needed to do significant heavy lifting and performs none of it. An agent cannot learn the workflow or safely invoke apply mode from this text alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description was obligated to compensate but names no parameters directly. 'Existing manifest-managed resource' loosely implies resourceName, but nothing explains the field structure, the preview/apply handoff via previewHash, or the conflictStrategy semantics. All five parameters, including the nested field object with its ten sub-properties, go entirely unexplained.
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 has a specific verb-object construction ('Preview or apply a new field') and a clear resource target ('an existing manifest-managed resource'). The 'manifest-managed' qualifier usefully distinguishes this from scaffolding new resources. However, differentiation from siblings like preview_scaffold or scaffold_resource is left implicit, not stated.
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 offers no explicit guidance on when to choose this tool over alternatives such as scaffold_resource or preview_scaffold. The 'preview or apply' phrasing hints at a workflow — run preview first, then apply — but never states that the preview output is needed as subsequent input (previewHash) or when each mode is appropriate. An agent must infer the intended usage pattern from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview or apply deletion for a manifest-managed generated resource.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | preview | |
| previewHash | No | ||
| resourceName | Yes | ||
| conflictStrategy | No | abort |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the dual-mode nature (preview vs. apply), which is useful, but it omits critical information about a destructive operation, such as irreversibility, cascading effects, idempotency, or whether it requires confirmation. The agent is left unaware of the consequences of 'apply' beyond a generic deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the primary action ('Preview or apply deletion') and adds the contextual qualifier. While it could be more detailed, the structure is clean and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with four parameters and zero annotations, the description is grossly insufficient. It fails to explain the meaning of 'preview' vs. 'apply' in practical terms, what 'conflictStrategy' does, or what happens to dependent resources. An agent cannot safely invoke this tool correctly with the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters, but it doesn't. It never defines 'resourceName', 'mode', 'previewHash', or 'conflictStrategy'. The enums and defaults in the schema are uninterpreted, and the description adds no semantic value about how these parameters affect behavior. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('delete') and resource ('manifest-managed generated resource'), distinguishing it from siblings like scaffold_resource or list_resources. It also introduces the preview/apply dual-mode behavior, which is a distinct attribute. Could be more explicit about the scope, but it's markedly better than a tautology.
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: use 'preview' to simulate deletion and 'apply' to execute it, which gives context but doesn't explicitly state when to choose this over alternatives or when not to use it. It doesn't mention any preconditions, confirmations, or relationship to preview_scaffold, leaving implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List manifest-managed resources and optionally scan for unmanaged ones.
| Name | Required | Description | Default |
|---|---|---|---|
| includeUnmanaged | No |
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 does convey the read-only listing intent and the optional unmanaged-scan behavior, which is genuinely useful context beyond the name. However, it does not disclose what the scan entails, what the return payload looks like, or what 'unmanaged' means concretely — meaningful gaps given there is zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler. The primary purpose leads, and the optional behavior is appended as a second clause. Nothing is wasted and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complexity is low — one optional boolean parameter, no output schema, no nested structures. For a simple list tool the description is largely sufficient: it states the main function and the one behavioral toggle. Minor omissions (return format, definition of 'unmanaged') are tolerable against the low complexity, though they keep it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does: 'optionally scan for unmanaged ones' maps semantically to the includeUnmanaged boolean (which defaults to true), giving the parameter purpose. But the description never names the parameter or explains the true-default implication, leaving the agent to infer the connection. It adds value but does not fully bridge the 0% coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and a precise resource ('manifest-managed resources'), plus an optional secondary behavior ('scan for unmanaged ones'). It is clearly distinguishable from its siblings (scaffold_resource, delete_resource, add_field, preview_scaffold), all of which are mutation tools, so an agent can separate read from write intent immediately.
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 read-versus-mutate distinction against the sibling tools is implied by the verb and resource, but the description never explicitly says 'use this when you need to enumerate resources, not when you need to modify them.' No alternatives are named, and no conditions selecting this tool over another are given. Adequate but left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview the generated files and integration edits for a MERN resource scaffold.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | preview | |
| fields | No | ||
| overrides | No | ||
| description | No | ||
| previewHash | No | ||
| resourceName | Yes | ||
| conflictStrategy | No | abort |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description says 'Preview' which suggests a read-only operation, but the input schema includes a 'mode' parameter with 'preview' and 'apply' values, indicating this tool can also apply changes. The description is misleading as it claims only preview but the tool supports apply. This is a behavioral gap and borderline contradiction with the schema (not annotations).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is easy to parse. It front-loads the verb and resource. It doesn't waste words. However, it omits crucial details about the mode parameter, which would have been valuable, but conciseness itself is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, nested objects, an apply mode that causes mutations, and no output schema, the description is insufficient. An agent needs to know when to use apply vs preview, what the preview output looks like, and how conflictStrategy works. The description only covers a fraction of the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter meaning. However, the description does not explain any parameter semantics. It doesn't clarify what 'previewHash' is, what 'conflictStrategy' does, or what 'overrides' affect. The baseline for 0% coverage is low, and the description adds nothing. Score 3 is generous; it could be 2, but the tool purpose is simple enough that resourceName is self-explanatory.
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 a specific verb ('Preview') and resource ('generated files and integration edits for a MERN resource scaffold'). It clearly distinguishes from sibling tools like scaffold_resource (which likely creates), but doesn't explicitly contrast with it. The term 'preview' implies no side effects, which is clear enough.
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 name 'preview_scaffold' and description imply this is for reviewing changes before applying them, but it doesn't explicitly state when to use it versus scaffold_resource or when not to use it. There is no mention of alternatives or conditions. The description implies usage but leaves the decision to the agent inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a full MERN CRUD slice for one resource and either preview or apply the write plan.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | preview | |
| fields | No | ||
| overrides | No | ||
| description | No | ||
| previewHash | No | ||
| resourceName | Yes | ||
| conflictStrategy | No | abort |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description only says 'Generate a full MERN CRUD slice' and 'preview or apply the write plan'. It does not disclose behavioral details like that applying will create/modify files, potential destructive actions, side effects, or the nature of the write plan. For a tool that can 'apply' changes, this lack of behavioral transparency is a notable 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 one sentence and conveys the key options (preview/apply) without extra fluff. It is concise and front-loaded with the core action. However, it does take a slight liberty with 'write plan' which is not defined elsewhere.
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 high complexity (7 params, nested objects, no output schema, no annotations), the description is far from complete. It doesn't mention the previewHash, conflictStrategy, or how to get a preview. It also doesn't clarify the relationship with sibling 'preview_scaffold'. A function this complex needs much more guidance on workflow, preconditions, and output expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. However, the description does not explain any of the parameters beyond hinting at 'resource' and 'write plan'. With 7 parameters including nested 'fields' and 'overrides', the agent receives very little guidance on what these mean or how to structure them. The enums for mode and conflictStrategy are partially self-explanatory, but the description adds no semantic value.
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 verb 'Generate' and resource 'full MERN CRUD slice' for a resource, and distinguishes between preview and apply modes. It is clear about the tool's core purpose. However, it doesn't explicitly differentiate from the sibling tool 'preview_scaffold', which appears to overlap with the preview mode mentioned.
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 'preview or apply the write plan', but it does not explicitly state when to use this tool versus alternatives like 'preview_scaffold'. It lacks guidance on when to choose preview vs apply or how this relates to 'add_field' or 'update_drive' (though siblings include 'list_resources', 'delete_resource', 'add_field'). The context is somewhat clear but no explicit exclusions or alternative routing is provided.
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.
v0.1.0add_fielddelete_resourcelist_resourcespreview_scaffoldscaffold_resourceScored across 5 tools
list_resources, delete_resource, and add_field are clearly distinct, but scaffold_resource already supports previewing or applying a write plan, making preview_scaffold semantically overlapping. Descriptions help clarify intent, but an agent could easily pick the wrong tool for a preview action.
All five tool names follow a verb_noun snake_case pattern: scaffold/list/preview/delete/add + resource/scaffold/field. The only minor variance is singular vs. plural objects (list_resources vs. delete_resource), but no convention mixing occurs.
Five tools is a reasonable scope for managing MERN scaffolds, not bloated. However, preview_scaffold is arguably redundant with scaffold_resource's preview mode, so the set is slightly looser than ideal.
The main lifecycle is covered: scaffold a resource, list resources, add a field, and delete a resource. There is no counterpart to remove or update fields, leaving add_field as a one-way operation and requiring workarounds like delete-and-rescaffold.
Discover and scaffold new apps by reusing code from your GitHub repositories.
327 dev tools via REST API and MCP. Generate Dockerfiles, schemas, K8s, APIs, and more.
Generate a typed SDK, CLI, and MCP server from any OpenAPI or GraphQL spec, and keep them current.
List, read, edit, and deploy your GenMB AI-generated apps from any MCP client.
