Generates Docker Compose configuration and Dockerfiles for API and frontend services.
Scaffolds a FastAPI backend with async SQLAlchemy and Pydantic v2.
Generates CI/CD pipelines using GitHub Actions for deployment to Azure or Render.com.
Scaffolds an HTMX frontend with Tailwind CSS.
Includes NGINX configuration for serving the React frontend in production.
Configures PostgreSQL database with Docker Compose and includes pgAdmin.
Scaffolds a React frontend with Vite and TypeScript.
Generates a Render.com blueprint for deployment of personal projects.
Scaffolds SQLAlchemy models and database configuration.
Includes Tailwind CSS configuration and styling for HTMX frontend.
Scaffolds TypeScript configuration for React frontend.
Scaffolds Vite configuration for React frontend.
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., "@project-scaffold Create a new personal project called 'recipe-box' with an HTMX frontend."
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.
An MCP server that scaffolds full-stack projects with consistent structure, Docker setup, CI/CD pipelines, and database configuration. Built with FastMCP.
Alpha — This project is under active development. APIs and generated output may change between versions. Contributions are welcome! See CONTRIBUTING.md.
Every scaffolded project comes with:
FastAPI backend with async SQLAlchemy and Pydantic v2
PostgreSQL database with Docker Compose (includes pgAdmin)
Frontend — React (Vite + TypeScript) or HTMX (Tailwind CSS)
Alembic database migrations (optional)
JWT authentication boilerplate (optional)
CI/CD — GitHub Actions for Azure, or Render.com blueprint
Makefile with common dev commands
Related MCP server: Kroki MCP
Project type | Frontend | Deploy target | Repo structure |
|
| Azure (App Service + Static Web Apps) | Multi-repo (API + frontend) |
|
| Azure (App Service) | Single repo |
|
| Render.com | Multi-repo (API + frontend) |
|
| Render.com | Single repo |
Python 3.12+
uv (recommended) or pip
pip install git+https://github.com/dawiegriesel/mcp-dev.gituv pip install git+https://github.com/dawiegriesel/mcp-dev.gitgit clone https://github.com/dawiegriesel/mcp-dev.git
cd mcp-dev
uv syncFor development dependencies (pytest, ruff):
uv sync --extra devclaude mcp add project-scaffold -- uvx --from "git+https://github.com/dawiegriesel/mcp-dev.git" project-scaffoldOr if installed locally:
claude mcp add project-scaffold -- uv run --directory /path/to/mcp-dev project-scaffoldFor local development, create a .mcp.json in the repo root to register the server automatically when you open the repo in Claude Code — no manual claude mcp add needed:
{
"mcpServers": {
"project-scaffold": {
"command": "uv",
"args": ["run", "--directory", "/your/local/path/mcp-dev", "project-scaffold"]
}
}
}Replace the --directory value with your actual clone path. This file is gitignored to avoid committing local paths.
Add this to your Claude Desktop config file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"project-scaffold": {
"command": "uvx",
"args": [
"--from", "git+https://github.com/dawiegriesel/mcp-dev.git",
"project-scaffold"
]
}
}
}Run the server with stdio transport (the default):
project-scaffoldOr without installing:
uvx --from "git+https://github.com/dawiegriesel/mcp-dev.git" project-scaffoldThe server exposes five tools via MCP:
list_templatesReturns all available project template combinations and their default stack.
create_projectScaffolds a complete project. Configuration options:
Parameter | Required | Default | Description |
| yes | — | Project name (lowercase, hyphens allowed) |
| yes | — |
|
| yes | — |
|
| yes | — | Parent directory for the project folder |
| no |
| Short project description |
| no | derived from name | Database name |
| no |
| Include JWT auth boilerplate |
| no |
| Include Alembic migrations |
| no |
| Local dev API port |
| no |
| Local dev frontend port (React only) |
add_componentAdds a component to an existing scaffolded project. Supported components:
api_router — FastAPI router with full CRUD endpoints, plus auto-generated model and schema if fields are provided
db_model — SQLAlchemy model with matching Pydantic schemas
Components not yet implemented: frontend_page, github_action, docker_service.
validate_projectChecks that a scaffolded project has all expected files. Reports any missing files.
get_project_infoReads the .scaffold.json metadata from an existing project and returns its configuration.
Once the MCP server is installed, you can use natural language to scaffold and extend projects. Here are some example prompts to get started:
Create a new personal project called "recipe-box" with an HTMX frontend. Put it in ~/projects. Include auth and migrations.
Scaffold a work project named "inventory-tracker" with a React frontend in ~/work. No auth needed but include Alembic.
I want to start a new side project called "budget-app". It should be a simple server-rendered app I can deploy to Render. Create it in ~/dev.
What project templates are available?
Add a "products" API router to my project at ~/projects/recipe-box with fields: title (str), prep_time (int), servings (int), instructions (text).
Add a database model called "category" with fields name (str) and description (text) to ~/projects/recipe-box.
I need a new "orders" endpoint in my inventory-tracker project. It should have fields for customer_name (str), total (float), and fulfilled (bool).
Check if my project at ~/projects/recipe-box has all the expected files.
What's the configuration for the project in ~/work/inventory-tracker?
Validate the project structure at ~/dev/budget-app and tell me if anything is missing.
my-app/
├── Makefile
├── README.md
├── .env.example
├── docker-compose.yml
├── docker-compose.override.yml
├── .scaffold.json
├── my-app-api/
│ ├── pyproject.toml
│ ├── Dockerfile
│ ├── app/
│ │ ├── main.py
│ │ ├── config.py
│ │ ├── database.py
│ │ ├── models/
│ │ ├── schemas/
│ │ ├── routers/
│ │ └── auth/ (optional)
│ ├── alembic/ (optional)
│ ├── tests/
│ └── .github/workflows/
└── my-app-frontend/
├── package.json
├── vite.config.ts
├── Dockerfile
├── nginx.conf
├── src/
│ ├── App.tsx
│ ├── api/
│ ├── pages/
│ ├── components/
│ └── styles/
└── .github/workflows/my-app/
├── Makefile
├── README.md
├── .env.example
├── docker-compose.yml
├── pyproject.toml
├── Dockerfile
├── .scaffold.json
├── app/
│ ├── main.py
│ ├── config.py
│ ├── database.py
│ ├── models/
│ ├── schemas/
│ ├── routers/
│ ├── templates/
│ │ ├── base.html
│ │ ├── index.html
│ │ └── partials/
│ ├── static/css/
│ └── auth/ (optional)
├── alembic/ (optional)
└── tests/# Lint
uv run ruff check src/
# Format
uv run ruff format src/
# Test
uv run pytestThis repo includes a docs-pre-commit Claude agent (.claude/agents/docs-pre-commit.md). When working in Claude Code, it triggers automatically before commits to update CHANGELOG.md, README.md, and CLAUDE.md to reflect the changes being committed.
To trigger it manually, tell Claude: "Update the documentation before I commit."
src/project_scaffold/
├── __main__.py # Entry point — runs mcp.run()
├── server.py # FastMCP server with 5 tool definitions + main()
├── models.py # Pydantic models (ProjectConfig, ComponentConfig)
├── config.py # Constants, type maps, template paths
├── generator.py # Core engine — renders Jinja2 templates to disk
├── renderers/
│ └── api.py # Component generators (add_router, add_model)
└── templates/ # Jinja2 templates (included in package)
├── api/ # FastAPI backend
├── frontend/react/ # React + Vite + TypeScript
├── frontend/htmx/ # HTMX + Tailwind
├── docker/ # Docker Compose
├── cicd/azure/ # GitHub Actions for Azure
├── cicd/render/ # Render.com blueprint
├── alembic/ # Database migrations
└── common/ # README, Makefile, .env, .gitignoreAdd a new component to an existing scaffolded project. Supports adding API routers, database models with matching schemas, frontend pages, GitHub Action workflows, or Docker services.
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Add a new component' implies mutation, but the description does not disclose side effects, file system changes, required permissions, or reversibility. This is a significant gap for a tool that modifies an existing project.
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?
Two sentences, front-loaded with the primary action, no redundant wording. 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?
The tool supports multiple component types, but the description gives no specifics on prerequisites, behavioral effects of adding each type, or post-addition steps. With no annotations and only a brief overview, the description is incomplete for a mutating tool of this 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 description coverage is 0%. The description does not explain the 'config' parameter or its nested fields (project_dir, component, name, fields). Although the schema itself contains property descriptions, the tool description fails to compensate for the zero coverage and adds no parameter-level meaning.
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 'Add a new component to an existing scaffolded project' with a specific verb and resource. It enumerates supported component types (API routers, database models, frontend pages, GitHub Actions, Docker services), distinguishing it from sibling tools like create_project and configure_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?
The description provides clear context: it is for adding to an existing project, implying it is not for creating new projects. However, it does not explicitly state when not to use this tool or name alternative tools for new project creation or configuration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns structured questions for configuring a new project. Call this FIRST when a user wants to create a project. Present the questions to the user, collect their answers, then call create_project with the full configuration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns questions and does not itself create the project (by directing to call create_project afterward). This implies a non-mutating behavior, though it doesn't explicitly state 'no side effects' or mention permissions. The sequential flow makes the behavior transparent enough for the agent.
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 concise: three sentences, each earning its place. The first states the core function, the second gives the critical usage instruction, and the third provides the next step. No filler or repetition, and the most important information is front-loaded.
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 simplicity (no parameters, output schema present), the description is complete. It explains the purpose, the when-to-use, and the follow-up action. The output schema handles return value details, and the description doesn't need to explain them. The workflow is fully captured.
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?
The input schema has zero parameters, so the baseline is 4 per guidelines. The description adds no parameter info, but no parameters exist, so nothing is missing. The description's focus on workflow adequately compensates for any potential ambiguity.
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's function: 'Returns structured questions for configuring a new project.' It uses a specific verb ('returns') and resource ('structured questions'), and distinguishes itself from siblings by explicitly positioning it as the first step before create_project, unlike list_templates or other tools.
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 gives explicit when-to-use guidance: 'Call this FIRST when a user wants to create a project.' It also provides the full workflow: present questions, collect answers, then call create_project. This clearly separates it from alternatives and instructs the agent on sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scaffold a complete new project with API, frontend, database config, Docker setup, and CI/CD pipeline. Returns a summary of created files and next steps.
Set use_current_dir=True to scaffold directly into output_dir instead of creating a new subdirectory.
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It explains the key use_current_dir behavior and notes that a summary of created files is returned. However, it omits potential side effects like file creation in existing directories (unless empty), overwrite risks, or permission requirements, which are relevant for a scaffold tool.
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 three sentences, front-loaded with the main purpose, followed by a concise behavior note. Each sentence adds value: the scaffold summary, the return value, and the use_current_dir exception. No wasted words.
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, the description provides a good high-level overview of what is scaffolded and the return value. The output schema exists (though not shown), so return values need not be detailed. It lacks a bit of depth on prerequisites or side effects, but for a complex scaffold tool, it is reasonably 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% since the description does not explain the config object or its many sub-parameters. The description only mentions output_dir and use_current_dir indirectly. The schema itself has detailed descriptions, but the description fails to compensate for the low coverage, leaving the agent to rely solely on the schema for all config semantics.
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 starts with a specific verb ('Scaffold') and clearly identifies the resource: a complete new project including API, frontend, database config, Docker, and CI/CD. It distinguishes itself from sibling tools like configure_project and add_component by focusing on initial project creation.
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 for creating new projects, and the use_current_dir note provides a conditional usage detail. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'use configure_project to modify an existing project'), nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an existing scaffolded project and return its configuration, including project type, frontend type, deployment target, and list of components.
| Name | Required | Description | Default |
|---|---|---|---|
| project_dir | Yes | Absolute path to the project root to inspect |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly says 'Read' and lists the returned configuration fields (project type, frontend type, deployment target, components), making it clear this is a non-mutating inspection tool. However, it does not mention error behavior or edge cases (e.g., if the project does not exist), so it is transparent but not exhaustive.
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, well-structured sentence that front-loads the key verb and resource. It is concise, contains no redundant information, and every part contributes to understanding the tool's function.
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 simple read-only tool with one parameter and an output schema, the description is sufficiently complete. It explains what the tool does, what it returns, and implies the prerequisite that the project must already exist. It does not elaborate on failure modes, but these are not essential given the tool's simplicity and the availability of an output schema.
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?
The input schema has 100% coverage for the single parameter, project_dir, with a clear description ('Absolute path to the project root to inspect'). The tool description does not add anything beyond the schema for the parameter itself; it focuses on return values, which are already covered by the output schema. Thus, the baseline score of 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's purpose: 'Read an existing scaffolded project and return its configuration'. It is specific with a verb ('Read') and resource ('scaffolded project'), and it distinguishes from siblings like create_project, configure_project, and add_component by establishing a read-only inspection role.
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 for reading an existing project's configuration, but it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. It says 'existing scaffolded project', which hints at a prerequisite, but no direct guidance or mention of sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available project template combinations and their descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates the tool returns a list of templates and their descriptions, and the verb 'List' implicitly signals a read-only operation appropriate for this query tool. However, it does not explicitly mention side-effect-freeness or other behavioral nuances.
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 of about 8 words, front-loading the action and resource. Every word contributes meaning, with no filler or redundant 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?
The tool is simple (no parameters, no annotations) and has an output schema, so the description only needs to convey the scope and output type. 'List all available project template combinations and their descriptions' fully satisfies this requirement, making the tool adequately described.
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?
The input schema has zero parameters, so the baseline is 4. The description adds no parameter details because none are needed; it simply states that all templates are listed, which is consistent with the empty schema.
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 uses the specific verb 'List' with the resource 'all available project template combinations' and includes output details ('their descriptions'), clearly stating the tool's function. It distinguishes itself from sibling tools like configure_project and create_project by focusing solely on enumeration.
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 phrase 'all available' implies the tool is used for discovery before project configuration or creation, but there is no explicit guidance on when to use it versus alternatives. It neither mentions exclusions nor names specific sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate that a scaffolded project has all expected files and correct structure. Reports missing files and suggests fixes.
| Name | Required | Description | Default |
|---|---|---|---|
| project_dir | Yes | Absolute path to the project root to validate |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool reports missing files and suggests fixes, which conveys the non-destructive output behavior. However, it does not explicitly state that it makes no changes to the project, which would be a valuable clarification for a validation tool. The absence of an explicit 'read-only' claim leaves a minor ambiguity.
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 two concise sentences, front-loaded with the main purpose and followed by output details. Every word adds value; there is no redundancy or filler, making it highly efficient for an agent to parse.
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?
The tool is simple (one param, no nested objects) and has an output schema, so the description does not need to detail return values. It sufficiently conveys the tool's role in the project lifecycle relative to siblings. A note about typical invocation timing (e.g., after create_project) could enhance completeness, but the current description is adequate for the tool's 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?
The schema covers 100% of the single parameter with a clear description ('Absolute path to the project root to validate'). The tool description adds minimal extra meaning beyond the schema, only implying that the project is scaffolded. This meets the baseline for high schema coverage but does not enrich parameter understanding further.
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 clear, specific action ('Validate that a scaffolded project has all expected files and correct structure') and names the resource ('scaffolded project'). It also adds detail about the outcome ('Reports missing files and suggests fixes'), which distinguishes it from sibling tools like create_project or configure_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?
The context of use is clear: it is for validating a scaffolded project, implying it should be used after scaffolding. It does not explicitly exclude alternatives or state when not to use, but the read-only validation nature is evident from the verb 'validate' and the mention of reporting, which sufficiently differentiates it from creation/configuration tools.
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.3.3add_componentconfigure_projectcreate_projectget_project_infolist_templatesvalidate_projectEach tool targets a distinct phase or aspect of project scaffolding: configure_project gathers requirements, list_templates shows options, create_project generates the project, add_component extends it, validate_project checks structure, and get_project_info inspects configuration. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun snake_case pattern: configure_project, list_templates, create_project, add_component, validate_project, get_project_info. This makes the tool set predictable and easy to navigate.
With 6 tools, the server is well-scoped for its purpose. Each tool covers a necessary step in the scaffolding workflow without redundancy or bloat.
The tool set covers the full scaffold lifecycle: template discovery, project configuration, creation, component addition, validation, and inspection. While update/delete operations are missing, they are not expected for a scaffold generator, making the surface complete for its domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A MCP server built for developers enabling Git based project management with project and personal…
Create, deploy, and operate MCP servers directly from your GitHub repositories.
Build, deploy, and host full-stack web apps from any MCP client. DB, auth, storage, cron included.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dawiegriesel/mcp-dev'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
