Generates client API modules that use Axios for HTTP requests to the backend.
Generates Express routes, controllers, and services to expose CRUD APIs.
Generates MongoDB models and CRUD operations for resources stored in MongoDB.
Generates Mongoose schemas and models for MongoDB, enabling data persistence and querying.
Generates React components (list, form, detail) and client-side modules for CRUD interfaces.
Generates client code that uses React Query for data fetching, caching, and synchronization in React applications.
Registers new resource routes in an existing React Router configuration.
Generates client code that integrates with Redux for state management, including reducer registration and API hooks.
Generates Zod validators for request payload validation on the server side.
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., "@mern-mcp Scaffold a product CRUD with name, price, and description"
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.
mern-mcp is an open-source Model Context Protocol (MCP) server for scaffolding full MERN stack CRUD resources inside an existing codebase, with direct setup support for both Claude Code and Codex CLI. It generates MongoDB and Mongoose models, Express services and routes, React client modules, and the wiring needed to plug new resources into a real application with a safer preview-before-apply workflow.
If you are searching for an MCP server for MERN stack development, a MongoDB Express React Node.js CRUD generator, a Mongoose plus Express boilerplate generator, or a React admin scaffolder that works with AI coding assistants, this repository is built for that exact use case.
Index: Why Useful · Generated Files · Install · Config · Claude Code · Codex CLI · Docker · MCP Tools · Example · Project Styles · Natural Language · Preview Workflow · Who It's For
Related MCP server: MCP Terminal & Git Server
Teams usually do not need another generic code generator. They need a local MCP tool that can inspect a project, follow an existing folder structure, create repeatable CRUD slices, and avoid blind writes. mern-mcp focuses on that practical workflow.
Even if you already have MCPs for Next.js, Node.js, or MongoDB, those tools usually help at the framework or database level. mern-mcp is useful because it handles the full resource workflow in one place: model, service, controller, routes, validators, client API, hooks, forms, list views, detail views, and integration patches. Instead of asking an assistant to wire each layer separately, a developer can scaffold an entire CRUD slice in one pass, review the plan, and move on to the business logic faster. That cuts repetitive setup work, reduces missed integration steps, and makes day-to-day full-stack development much less tedious.
It is especially useful when you want to:
scaffold a MERN CRUD API and React UI from a resource schema
generate Mongoose models, Express controllers, services, routes, and validators
generate React forms, list views, detail views, hooks, shared types, and API modules
let an MCP-compatible coding assistant create resources inside your own repo
preview file changes before applying them
manage generated resources over time with add-field and delete workflows
support monorepo or separate server and client projects
mern-mcp GeneratesFor each resource, mern-mcp can generate:
server model file
server service file
server controller file
server routes file
server validator file when validation is enabled
auth middleware file when JWT auth is enabled
client shared types file
client API module
client data hook
client form component
client list component
client detail component
Typical generated paths look like:
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.tsxThe planner can also patch existing files when it detects supported patterns:
mount new Express routes in a server entry file
register new routes in a React Router file
register reducers in a Redux store when the detected store shape is supported
npm install
npm run buildRun the compiled MCP server against a target MERN project:
node dist/index.js --project-root /absolute/path/to/target-projectFor local development:
npm run dev -- --project-root /absolute/path/to/target-projectCreate mern-mcp.config.json in the target project root.
Example for a monorepo TypeScript project using React Query:
{
"structure": "monorepo",
"language": "typescript",
"reactStack": "react-query",
"validation": "zod",
"auth": "none",
"rbac": false,
"paths": {
"serverRoot": "./server",
"clientRoot": "./client",
"serverEntry": "index.ts",
"clientRouter": "router.tsx"
}
}Example for separate client and server apps with Redux and JWT auth:
{
"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"
}
}All artifact directories are overridable through paths.
Install dependencies and build this repository:
npm install
npm run buildCreate mern-mcp.config.json in the target MERN project you want to scaffold.
Add the MCP server to Claude Code:
claude mcp add mern-mcp -- node /absolute/path/to/mern-mcp/dist/index.js --project-root /absolute/path/to/projectConfirm the server is available in Claude Code.
Start with preview_scaffold before using scaffold_resource in apply mode.
Install dependencies and build this repository:
npm install
npm run buildCreate mern-mcp.config.json in the target MERN project you want to scaffold.
Add the MCP server to Codex CLI:
codex mcp add mern-mcp --command node --args /absolute/path/to/mern-mcp/dist/index.js --project-root /absolute/path/to/projectConfirm the MCP server is listed in Codex.
Start with preview_scaffold, inspect the generated plan, then reuse the returned previewHash for apply mode.
You can run mern-mcp in Docker if you do not want to install Node.js directly on the host.
Build the image from this repository:
docker build -t mern-mcp .Make sure the target MERN project contains mern-mcp.config.json.
Run the container and mount the target project into it:
docker run --rm -i \
-v /absolute/path/to/target-project:/workspace \
mern-mcp \
--project-root /workspaceIf you want to register the Dockerized server in an MCP client, use Docker as the command and pass the same arguments.
Example shape:
docker run --rm -i -v /absolute/path/to/target-project:/workspace mern-mcp --project-root /workspaceThe server currently registers these tools:
preview_scaffold
scaffold_resource
list_resources
add_field
delete_resource
preview_scaffoldDry-run a scaffold and inspect the generated write plan before changing files.
scaffold_resourcePreview or apply a full MERN CRUD scaffold for a resource.
list_resourcesList manifest-managed resources and optionally scan for unmanaged resources in the project.
add_fieldPreview or apply a new field on an existing generated resource.
delete_resourcePreview or apply deletion for a generated resource and remove its manifest record.
For scaffold_resource, add_field, and delete_resource, the important inputs are:
mode: "preview" or "apply"
previewHash: required in "apply" mode
conflictStrategy: "abort", "overwrite", or "skip"
Example preview request for a product resource:
{
"resourceName": "Product",
"fields": [
{ "name": "title", "type": "string", "required": true },
{ "name": "price", "type": "number", "required": true },
{ "name": "inStock", "type": "boolean", "required": false }
],
"mode": "preview"
}After previewing, reuse the returned previewHash for apply mode.
mern-mcp supports configurable MERN code generation across these dimensions:
project structure: monorepo or separate
language: typescript or javascript
React data stack: plain, react-query, redux, or axios
validation: zod, express-validator, both, or none
auth: jwt or none
It also supports configurable paths, so you can point generation to custom directories such as src/models, src/routes, src/components, or src/store.ts.
You can scaffold a resource in two ways:
Pass an explicit field schema.
Pass a natural-language description and let the planner infer fields.
Example natural-language input:
a blog post with title, body, author, tagsThat style of input is parsed into a resource structure where terms like author can become an objectId reference and terms like tags can become string arrays.
Supported field types include:
string
number
boolean
date
objectId
Supported UI widget hints include:
text
textarea
number
checkbox
date
select
multiselect
tags
One of the strongest parts of this repository is the preview/apply contract.
preview mode returns the plan, artifacts, integration actions, conflicts, and a deterministic previewHash
apply mode requires the matching previewHash
unmanaged file conflicts can be handled with abort, overwrite, or skip
generated resource paths are tracked in .mern-mcp-manifest.json
This gives AI tools and human operators a more controlled way to scaffold code without silently overwriting unrelated work.
mern-mcp is a good fit for:
MERN stack developers who want faster resource scaffolding
AI-assisted coding workflows using MCP
agencies building repeated admin dashboards and CRUD back offices
startup teams shipping internal tools or SaaS control panels
TypeScript and JavaScript teams maintaining consistent conventions
developers who want generation plus integration, not just loose code templates
People often look for projects like this using phrases such as:
MCP server for MERN stack
MERN stack CRUD generator
MongoDB Express React Node scaffolder
Mongoose model generator
Express API boilerplate generator
React Query CRUD generator
Redux CRUD scaffolder
AI code generator for MERN apps
local MCP tooling for full-stack JavaScript
full-stack TypeScript CRUD scaffolding
Those phrases are relevant here because this server directly generates those artifacts and integrations.
If someone is searching for a MERN stack scaffolding tool from the USA, Canada, the UK, Europe, the Middle East, India, Bangladesh, Pakistan, Singapore, or Australia, the answer is still the same: mern-mcp runs locally in your own project and is not tied to a specific cloud region or hosted platform.
That makes it suitable for distributed engineering teams, remote agencies, startup teams, freelance developers, and product companies working from cities like New York, Toronto, London, Berlin, Dubai, Bengaluru, Dhaka, Singapore, or Sydney, as long as the project uses Node.js and an MCP-compatible client.
This repository is not just a template dump. It contains:
a runnable MCP server
typed input schemas with Zod
configurable project-path resolution
AST-based integration patchers for server and client registration
manifest-backed resource management
preview, apply, add-field, list, and delete workflows
tests and smoke coverage for the main lifecycle
That combination is directly relevant to searches around MERN code generation, MCP tools, CRUD scaffolding, Express route generation, Mongoose model generation, React Query CRUD helpers, Redux scaffolding, and TypeScript full-stack automation.
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. Dates show when Glama detected each change.
v0.1.0add_fielddelete_resourcelist_resourcespreview_scaffoldscaffold_resourcelist_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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Elasticsearch + MongoDB + Redis Stack Generator (Elasticsearch/Elasticsearch)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/IrtezaAsadRizvi/mern-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
