mern-mcp는 기존 코드베이스 내부에 전체 MERN 스택 CRUD 리소스를 스캐폴딩하기 위한 오픈소스 Model Context Protocol(MCP) 서버로, 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
팀은 일반적으로 또 다른 범용 코드 생성기가 필요하지 않습니다. 프로젝트를 검사하고, 기존 폴더 구조를 따르고, 반복 가능한 CRUD 슬라이스를 만들고, 맹목적인 쓰기를 피할 수 있는 로컬 MCP 도구가 필요합니다. mern-mcp는 그 실용적인 워크플로우에 초점을 맞춥니다.
이미 Next.js, Node.js 또는 MongoDB용 MCP가 있더라도 그 도구들은 보통 프레임워크나 데이터베이스 수준에서 도움을 줍니다. mern-mcp는 모델, 서비스, 컨트롤러, 라우트, 검증기, 클라이언트 API, 훅, 폼, 목록 뷰, 상세 뷰, 통합 패치 등 전체 리소스 워크플로우를 한 곳에서 처리하기 때문에 유용합니다. 어시스턴트에게 각 계층을 별도로 연결하도록 요청하는 대신, 개발자는 한 번에 전체 CRUD 슬라이스를 스캐폴딩하고 계획을 검토한 후 비즈니스 로직으로 더 빨리 넘어갈 수 있습니다. 이는 반복적인 설정 작업을 줄이고, 통합 단계 누락을 줄이며, 일상적인 풀스택 개발을 훨씬 덜 지루하게 만듭니다.
다음과 같은 경우에 특히 유용합니다:
리소스 스키마에서 MERN CRUD API와 React UI를 스캐폴딩하려는 경우
Mongoose 모델, Express 컨트롤러, 서비스, 라우트, 검증기를 생성하려는 경우
React 폼, 목록 뷰, 상세 뷰, 훅, 공유 타입, API 모듈을 생성하려는 경우
MCP 호환 코딩 어시스턴트가 내 저장소 안에서 리소스를 생성하도록 하려는 경우
적용 전에 파일 변경 사항을 미리 보려는 경우
필드 추가 및 삭제 워크플로우로 생성된 리소스를 시간이 지나며 관리하려는 경우
모노레포 또는 분리된 서버/클라이언트 프로젝트를 지원하려는 경우
mern-mcp가 생성하는 것각 리소스에 대해 mern-mcp는 다음을 생성할 수 있습니다:
서버 모델 파일
서버 서비스 파일
서버 컨트롤러 파일
서버 라우트 파일
검증이 활성화된 경우 서버 검증기 파일
JWT 인증이 활성화된 경우 인증 미들웨어 파일
클라이언트 공유 타입 파일
클라이언트 API 모듈
클라이언트 데이터 훅
클라이언트 폼 컴포넌트
클라이언트 목록 컴포넌트
클라이언트 상세 컴포넌트
일반적인 생성 경로는 다음과 같습니다:
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 파일에 새 라우트 등록
감지된 스토어 형태가 지원되는 경우 Redux 스토어에 리듀서 등록
npm install
npm run build컴파일된 MCP 서버를 대상 MERN 프로젝트에 대해 실행합니다:
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를 사용하는 모노레포 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/projectMCP 서버가 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 /workspaceDocker화된 서버를 MCP 클라이언트에 등록하려면 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.
