Scaffolds React projects specifically using Create React App, with optional TypeScript support.
Scaffolds Django projects (including REST and CMS variants), with configurable Python version, Docker, and tests.
Scaffolds Express.js backend projects.
Scaffolds FastAPI projects with Uvicorn or Gunicorn, including options for Docker and test setup.
Scaffolds Fastify backend projects.
Scaffolds Flask projects (including REST and SQLAlchemy variants), with configurable Python version, Docker, and tests.
Scaffolds NestJS backend projects.
Scaffolds Next.js projects with App Router or Pages Router, configured for React SSR/SSG.
Scaffolds Nuxt.js 3 projects for Vue SSR/SSG.
Scaffolds React projects using Vite or Create React App, with optional TypeScript support.
Scaffolds generic Spring framework projects.
Scaffolds Spring Boot projects with Maven, supporting customizable Java version, Spring Boot version, and Maven coordinates.
Scaffolds vanilla Vite projects or Vite with TypeScript, supporting React, Vue, and other frameworks.
Click on "Deploy 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., "@Builder-Proj-MCP Server create a new React project with TypeScript"
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.
A powerful Model Context Protocol (MCP) server for building project structures with various frameworks. This tool helps you quickly scaffold projects for Spring Boot, React, Vue, Next.js, Nuxt.js, FastAPI, Django, Flask, Express, Fastify, NestJS, and more.
During daily vibe coding, building projects with different tech stacks often requires using different tools and command combinations, which can lead to unnecessary token overhead. Builder Project MCP Server provides a unified interface that allows you to quickly scaffold project structures by invoking a series of tools, thereby improving development efficiency.
Related MCP server: Splytin MCP Project Generator
Multiple Framework Support: Build projects for various tech stacks
TypeScript Support: Full TypeScript implementation
Flexible Configuration: Customize project options
MCP Protocol: Integrates seamlessly with MCP-compatible clients
spring-boot - Spring Boot with Maven
spring - Generic Spring framework
spring-mvc - Spring MVC
spring-webflux - Spring WebFlux
react - React with Vite
react-vite - React with Vite
react-cra - React with Create React App
vue - Vue 3 with Vite
vue3 - Vue 3
vue-vite - Vue with Vite
vite - Vanilla Vite
vite-vanilla - Vanilla Vite
vite-ts - Vite with TypeScript
next - Next.js with App Router
nextjs - Next.js
next-app - Next.js App Router
next-pages - Next.js Pages Router
nuxt - Nuxt.js 3
nuxt3 - Nuxt.js 3
fastapi - FastAPI with Uvicorn
fastapi-uvicorn - FastAPI with Uvicorn
fastapi-gunicorn - FastAPI with Gunicorn
django - Django
django-rest - Django REST Framework
django-cms - Django CMS
flask - Flask
flask-rest - Flask REST API
flask-sqlalchemy - Flask with SQLAlchemy
express - Express.js
fastify - Fastify
nestjs - NestJS
The easiest way to use Builder Project MCP Server is via npx, which downloads and runs the package automatically:
# Run directly with npx
npx builder-proj-mcp# Clone the repository
git clone <repository-url>
cd builder-proj-mcp
# Install dependencies
npm install
# Build the project
npm run buildYou can also install it globally to use it from anywhere:
# Install globally
npm install -g builder-proj-mcp
# Run the server
builder-proj-mcpAdd to your MCP client configuration:
Using npx (Recommended):
{
"mcpServers": {
"builder-proj": {
"command": "npx",
"args": ["builder-proj-mcp"]
}
}
}Using local installation:
{
"mcpServers": {
"builder-proj": {
"command": "node",
"args": ["path/to/builder-proj-mcp/dist/index.js"]
}
}
}Build a new project with specified framework.
Parameters:
projectName (string, required): Name of the project to create
projectType (string, optional): Type of project (web, api, mobile, desktop)
framework (string, required): Framework to use
options (object, optional): Additional configuration options
Example:
// Create a React project
{
"projectName": "my-react-app",
"framework": "react",
"options": {
"typescript": true
}
}
// Create a Spring Boot project
{
"projectName": "my-spring-app",
"framework": "spring-boot",
"options": {
"javaVersion": "17",
"springBootVersion": "3.2.0",
"groupId": "com.example"
}
}
// Create a FastAPI project
{
"projectName": "my-api",
"framework": "fastapi",
"options": {
"pythonVersion": "3.11",
"docker": true,
"tests": true
}
}List all supported frameworks for project creation.
Example:
{
"name": "list_frameworks"
}javaVersion: Java version (default: "17")
springBootVersion: Spring Boot version (default: "3.2.0")
groupId: Maven groupId (default: "com.example")
artifactId: Maven artifactId (default: projectName)
typescript: Use TypeScript (default: true)
pythonVersion: Python version (default: "3.11")
docker: Include Docker configuration (default: true)
tests: Include test setup (default: true)
builder-proj-mcp/
├── src/
│ ├── builders/
│ │ ├── spring-boot-builder.ts
│ │ ├── react-builder.ts
│ │ ├── vue-builder.ts
│ │ ├── fastapi-builder.ts
│ │ ├── django-builder.ts
│ │ ├── flask-builder.ts
│ │ ├── vite-builder.ts
│ │ └── index.ts
│ ├── types.ts
│ └── index.ts
├── package.json
├── tsconfig.json
└── README.md# Run in development mode
npm run dev
# Build for production
npm run build
# Start the server
npm startThe project follows a builder pattern with the following components:
ProjectBuilder Interface: Defines the contract for all builders
BuilderFactory: Manages and provides access to all builders
Framework Builders: Individual implementations for each framework
MCP Server: Handles tool registration and request processing
Contributions are welcome! Please feel free to submit a Pull Request.
MIT
For issues and questions, please open an issue on the repository.
Build a new project with specified framework. Supported frameworks: spring-boot, spring, spring-mvc, spring-webflux, react, react-vite, react-cra, vue, vue3, vue-vite, fastapi, fastapi-uvicorn, fastapi-gunicorn, django, django-rest, django-cms, flask, flask-rest, flask-sqlalchemy, vite, vite-vanilla, vite-ts, express, express-ts, express-rest, fastify, fastify-ts, fastify-rest, nestjs, nest, nestjs-rest, nestjs-graphql, next, nextjs, next-app, next-pages, nuxt, nuxt3
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | Yes | Name of the project to create | |
| projectType | No | Type of project (e.g., web, api, mobile) | |
| framework | Yes | Framework to use. Options: spring-boot, spring, spring-mvc, spring-webflux, react, react-vite, react-cra, vue, vue3, vue-vite, fastapi, fastapi-uvicorn, fastapi-gunicorn, django, django-rest, django-cms, flask, flask-rest, flask-sqlalchemy, vite, vite-vanilla, vite-ts, express, express-ts, express-rest, fastify, fastify-ts, fastify-rest, nestjs, nest, nestjs-rest, nestjs-graphql, next, nextjs, next-app, next-pages, nuxt, nuxt3 | |
| options | No | Additional options for the project builder |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose creation side effects (overwriting, directory creation), permission requirements, or resource impact. Only the action 'build' is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a list. It is front-loaded with the purpose and concise with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested options, many frameworks), the description is insufficient. It does not explain return values, behavior on failure, or what 'building' entails (e.g., scaffolding).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description repeats the framework list but adds no extra meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a new project with a specified framework. The verb 'build' and resource 'project' are explicit. However, it does not differentiate from sibling tool 'list_frameworks', which simply lists frameworks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or limitations. The description merely states what it does without context for when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all supported frameworks for project creation
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any behavioral traits beyond the purpose, such as caching, rate limits, or response structure.
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?
Single sentence, no extraneous words, completely focused.
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?
Adequate for a parameterless list tool, but lacks mention of output format or potential pagination, though likely not needed.
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?
No parameters exist, so schema coverage is 100%. The description adds no param info, which is acceptable.
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?
Clearly states the action ('List') and resource ('supported frameworks for project creation'). Distinct from sibling tool 'build_project'.
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?
Usage is implied (list before building), but no explicit guidance on when to use vs alternatives or prerequisites.
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.
v1.0.7build_projectlist_frameworksScored across 2 tools
The two tools have completely distinct purposes: build_project creates a project with a specified framework, while list_frameworks simply lists available frameworks. There is no overlap or ambiguity.
Both tools follow a consistent verb_noun pattern: build_project and list_frameworks. The naming is clear and predictable.
With only 2 tools, the server is minimal for its purpose of project scaffolding. While it covers the essential actions (list and build), the tool count feels thin and could benefit from additional tools like delete_project or update_project.
The tool set covers the core workflow: listing available frameworks and building a project. It misses operations like project deletion or configuration, but for a simple scaffolding server, it is reasonably complete.
A MCP server built for developers enabling Git based project management with project and personal…
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
MCP server for generating rough-draft project plans from natural-language prompts.
The official MCP Server for the Mux API
