Translates Docker containerization requirements into the appropriate init-app production strategy when generating project scaffolding commands.
Selects the FastAPI web framework as the project blueprint when building init-app scaffolding commands.
Configures Gunicorn as the production WSGI server in generated init-app project commands.
Translates Kubernetes orchestration requirements into the appropriate init-app production strategy when generating project scaffolding commands.
Maps PostgreSQL database requirements to the init-app database option in generated scaffolding commands.
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., "@init-app-mcp I need a production REST API with PostgreSQL, Docker, and Kubernetes."
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 independent FastMCP server that helps MCP-compatible AI clients understand
the init-app CLI and construct valid commands from a user's project needs.
init-app-mcp does not import, install, or execute init-app. It owns a
versioned capability catalog and returns metadata, recommendations, and command
arguments only. The client or its user decides whether and where to run the
returned command.
Explains the init-app command contract and valid flags.
Lists supported web and specialized project blueprints.
Converts plain-English requirements into relevant, supported flag choices.
Validates confirmed choices and returns the exact command arguments.
Never creates files, starts processes, or runs shell commands.
Related MCP server: Ramoira MCP Server
Python 3.10 or later
MCP Python SDK v1 (mcp>=1,<2), which provides FastMCP
Install from a clone:
git clone https://github.com/ashmeet07/init-app-mcp.git
cd init-app-mcp
python -m pip install .For development:
python -m pip install -e ".[dev]"
python -m pytestConfigure an MCP client to use stdio transport:
{
"mcpServers": {
"init-app": {
"command": "init-app-mcp"
}
}
}If your client requires an absolute Python executable, use:
{
"mcpServers": {
"init-app": {
"command": "/absolute/path/to/python",
"args": ["-m", "init_app_mcp.server"]
}
}
}The default command starts a stdio MCP server, so it expects JSON-RPC messages from an MCP client such as VS Code. Do not press Enter after starting it in a terminal; a blank line is not a valid MCP request.
Use these commands to inspect the installed server manually instead:
.\.venv\Scripts\init-app-mcp.exe --list-tools
.\.venv\Scripts\init-app-mcp.exe --metadataTo run a local HTTP MCP endpoint for manual client testing, use:
.\.venv\Scripts\init-app-mcp.exe --transport streamable-http --port 8001It listens on http://127.0.0.1:8001/mcp. Choose another available port if
needed. Keep that terminal open while your
MCP client is connected. Press Ctrl+C to stop it.
Tool | Purpose |
| Returns the CLI contract, flag definitions, allowed values, and recommended workflow. |
| Lists all web and specialized project blueprints supported by the catalog. |
| Maps a user's natural-language requirements to suggested flags, reasoning, and follow-up questions. |
| Validates user-confirmed options and returns portable |
Call get_init_app_command_metadata to learn the command schema.
Call recommend_init_app_flags with the user's request.
Show the suggested flags and answer any follow-up questions with the user.
Call build_init_app_command using the confirmed values.
Present the final command for the user to run.
Example user request:
I need a production REST API with PostgreSQL, Docker, and Kubernetes.The recommendation tool suggests a selection similar to:
{
"framework": "fastapi",
"strategy": "production",
"database": "postgresql",
"server": "gunicorn",
"venv": true
}After the project name and output directory are confirmed, call
build_init_app_command. It returns arguments equivalent to:
init-app billing-api --framework fastapi --type production --db postgresql --venv y --server gunicorn --output-dir ./projectspython -m pytest
python -m py_compile src/init_app_mcp/server.py src/init_app_mcp/service.py src/init_app_mcp/catalog.pyContinuous integration runs this validation on Python 3.10 through 3.13 for
every pull request to main.
The project uses a source layout. Its capability catalog lives in
src/init_app_mcp/catalog.py; update that catalog and its tests whenever
init-app adds or changes CLI capabilities.
This package is intentionally advisory. It does not access a user's project
directory, execute init-app, write files, or invoke a shell. A compatible
client must obtain user confirmation before running any recommended command.
Before releasing a catalog update:
Compare src/init_app_mcp/catalog.py with the supported init-app CLI.
Update catalog tests for every new or changed flag or blueprint.
Run the development checks above and inspect --list-tools.
Open a pull request from feat to main and let CI pass before merging.
Distributed under the MIT License.
Final step: validate confirmed user selections and return an init-app command without running it.
| Name | Required | Description | Default |
|---|---|---|---|
| drf | No | ||
| venv | No | ||
| server | No | ||
| database | No | sqlite | |
| strategy | No | standard | |
| framework | No | fastapi | |
| output_dir | No | ||
| project_name | 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 behavioral disclosure burden. It does disclose a key trait: the command is returned but not executed, which implies no system mutation. However, it does not explain what 'validate' entails, whether invalid selections produce errors, or any side effects beyond command construction.
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 compact sentence with no filler. Key details are front-loaded: 'Final step', 'validate', 'return', and 'without running it' all appear early and each phrase 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?
For a tool with 8 parameters万余 and no annotations, the description provides only a high-level role. It omits parameter semantics, usage context relative to siblings, and validation behavior. The presence of an output schema reduces the need to explain return values, but the remaining gaps are significant.
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%, and the description adds no parameter-level meaning beyond saying 'confirmed user selections'. With 8 parameters and only the schema titles/defaults available, the description fails to compensate for the lack of parameter documentation.
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 action ('validate', 'return') and a clear resource ('init-app command'), and clarifies that it does not run the command. It distinguishes itself from siblings by framing this as the 'final step' in the workflow, though it does not explicitly name alternatives.
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 'Final step' and 'confirmed user selections' imply this tool should be used after other steps such as recommendation or metadata gathering. However, there is no explicit when-to-use versus when-not-to-use guidance, nor any mention of sibling tools like recommend_init_app_flags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
First step: return init-app command metadata, flags, values, and workflow.
| 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns metadata, flags, values, and workflow, clearly indicating a read-only operation. However, it does not disclose any potential edge cases, dependencies, or side effects, though the absence of parameters makes such details less critical. The description is functional but not rich in behavioral context.
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 that front-loads the key workflow label ('First step') and then enumerates the exact content returned. Every word contributes to the agent's understanding, and there is no wasted text.
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 no parameters and an output schema exists, the description provides sufficient context: it labels the tool as the initial step and lists the outputs (metadata, flags, values, workflow). It does not explain the workflow itself, but that is likely part of the output schema, so the description need not be more detailed. The minimal complexity makes this complete enough.
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 no properties, so parameter semantics are trivially complete. The rubric assigns a baseline of 4 for zero-parameter tools, and the description does not need to add parameter meaning. It appropriately avoids discussing parameters that do not exist.
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 verb and resource: 'return init-app command metadata, flags, values, and workflow.' It is specific about what the tool does and identifies the init-app command as its subject. However, it does not directly name sibling tools or highlight how it differs from them, so it stops short of the highest clarity level.
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 opens with 'First step,' which implies a recommended position in a workflow but gives no explicit guidance on when to choose this tool over siblings like build_init_app_command or recommend_init_app_flags. There are no stated alternatives or exclusions, leaving the agent to infer usage from the label 'First step.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every web and specialized project type supported by init-app.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. Saying 'List every' conveys exhaustive, unfiltered enumeration and the verb 'List' implies a read-only operation; this is sufficient for a zero-parameter list tool, though it does not mention performance or output-size caveats.
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?
One sentence, no filler, front-loaded verb and object. 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?
Given the zero-parameter schema and presence of an output schema, the description is nearly complete for calling the tool correctly. It could add one phrase about when to use it within the init-app flow, but no critical operational detail is missing.
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?
There are no parameters, and schema coverage is 100%, so there is nothing for the description to add. The baseline for a no-parameter tool is 4.
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 a specific verb ('List') and names a concrete resource ('every web and specialized project type supported by init-app'). This clearly distinguishes the tool from siblings that fetch metadata, recommend flags, or build commands.
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 purpose implies when to use it: whenever an agent needs the complete set of supported project types. However, it does not explicitly state when to prefer one sibling over another or mention any exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Second step: derive supported init-app flags and clarification questions from a user query.
| Name | Required | Description | Default |
|---|---|---|---|
| requirements | 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 behavioral disclosure burden. It conveys that the tool derives supported flags and may surface clarification questions, indicating a non-destructive analysis/computation operation. It does not explicitly state read-only behavior, determinism, or how ambiguity is handled, but the core behavior is visible.
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 short sentence with no filler, and the workflow position is front-loaded. It communicates the essential purpose without wasting tokens.
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?
There is an output schema, so return values do not need elaboration, and there is only one parameter. However, the description lacks pipeline context (what the first step is and how this output feeds build_init_app_command), and the requirement semantics are left vague.
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 explain the 'requirements' parameter. It only equates it with a 'user query,' which adds minimal meaning beyond the parameter name; it does not describe expected string format, level of detail, or how the query should be constructed.
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 names a specific verb ('derive') and outputs ('supported init-app flags and clarification questions') from a 'user query', making the tool's function identifiable. It also signals a workflow stage ('Second step'), which helps distinguish it from build_init_app_command, though it does not explicitly contrast with siblings.
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 only usage guidance is 'Second step,' which implies this belongs in a broader pipeline and gives some sense of when to call it. It does not state when to prefer this over get_init_app_command_metadata, list_project_blueprints, or build_init_app_command, nor does it provide exclusions or alternatives.
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.0build_init_app_commandget_init_app_command_metadatalist_project_blueprintsrecommend_init_app_flagsScored across 4 tools
Each tool has a distinct role in the workflow: metadata retrieval, blueprint listing, flag recommendation, and command construction. The descriptions clearly separate responsibilities, though 'recommend_init_app_flags' and 'build_init_app_command' could overlap slightly in purpose, but context disambiguates them.
All tools follow a verb_object pattern (get, list, recommend, build). The only deviation is 'list_project_blueprints' missing the 'init_app' domain qualifier that the other three share, which is a minor inconsistency in naming scope rather than syntax.
Four tools is an ideal size for a focused init-command helper. Each tool serves a clear step in the process without redundancy or unnecessary surface area, making the set well-scoped and easy to navigate.
The workflow is explicitly covered from metadata through blueprint listing, flag recommendation, and final command construction. The only notable gap is that there is no tool to actually execute the command, but this appears intentional for a command-builder server, so completeness is high for its stated purpose.
List, read, edit, and deploy your GenMB AI-generated apps from any MCP client.
The Instant MCP server is a wrapper around the Instant Platform SDK that enables creating, managing, and updating InstantDB applications directly within an editor. It provides tools for fetching rules files for LLMs, retrieving and pushing app schemas, managing permission rules, and executing database queries. Key capabilities include schema management (get-schema, push-schema), permission management (get-perms, push-perms), query execution, and listing recent query history.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
327 dev tools via REST API and MCP. Generate Dockerfiles, schemas, K8s, APIs, and more.
