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、フック、フォーム、一覧ビュー、詳細ビュー、統合パッチというリソースワークフロー全体を1か所で処理するからです。アシスタントに各レイヤーを個別に配線するよう依頼する代わりに、開発者はCRUDスライス全体を1回でスキャフォールドし、計画を確認して、より速くビジネスロジックに進むことができます。これにより、反復的なセットアップ作業が削減され、統合ステップの見落としが減り、日々のフルスタック開発の退屈さが大幅に軽減されます。
特に次のような場合に役立ちます：
リソーススキーマから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/projectClaude 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/projectCodexにMCPサーバーが一覧表示されていることを確認します。
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"
productリソースのプレビューリクエストの例：
{
"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 などのカスタムディレクトリに生成先を指定できます。
リソースのスキャフォールドには2つの方法があります：
明示的なフィールドスキーマを渡す。
自然言語の説明を渡して、プランナーにフィールドを推論させる。
自然言語入力の例：
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
このリポジトリの最も強力な部分の1つは、プレビュー/適用の契約です。
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.
