init-app-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_init_app_command_metadataA | First step: return init-app command metadata, flags, values, and workflow. |
| list_project_blueprintsA | List every web and specialized project type supported by init-app. |
| recommend_init_app_flagsB | Second step: derive supported init-app flags and clarification questions from a user query. |
| build_init_app_commandB | Final step: validate confirmed user selections and return an init-app command without running it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.