packkit-mcp
OfficialServer 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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_generatorsA | START HERE. Lists every Packkit generator (a language target — e.g. javascript, python, go) with its maturity and protocol capabilities. Pick the generator whose language matches what the user wants, then call list_presets and get_generator_schema for it before generating. |
| list_presetsA | List the presets a generator offers (e.g. ts-lib, react-lib, node-service for javascript; py-lib, py-cli for python), each with a description and maturity. Experimental presets are hidden unless includeExperimental is true. Choose a preset that matches the shape the user wants instead of guessing. |
| get_generator_schemaA | Return a generator's full option schema — every option, its choices and defaults — as JSON. Read this before passing a |
| generate_projectA | Generate a project with a generator. By default it PREVIEWS (returns the file tree, stack summary and deployment contract without touching disk); pass write: true to scaffold the files under /. Existing files are never overwritten unless force is set. Call list_presets / get_generator_schema first. |
| plan_upgradeA | Plan a re-scaffold of an existing project against the current templates: a three-way diff (baseline vs on-disk vs freshly generated) that separates template changes from the user's own edits, so nothing is clobbered. Reports the plan only — it writes nothing. Requires a generator that supports baseline-upgrade. |
| compose_fullstackA | Compose two projects — a static frontend and an HTTP service backend, from ANY generators — into one fullstack repo (apps/web + apps/server) with a fullstack deployment contract and a docker-compose. Language-neutral: e.g. a "javascript" react-app frontend + a "python" py-service (or "go" go-service) backend. By default PREVIEWS; pass write: true to scaffold under /. |
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 6 tools
Each tool has a clear role in the generation workflow: listing generators, listing presets, reading schemas, generating, planning upgrades, and composing fullstack apps. list_presets and get_generator_schema are close in purpose, but their descriptions make the distinction clear enough.
All six tools use a consistent verb_noun snake_case pattern: list_generators, list_presets, get_generator_schema, generate_project, plan_upgrade, compose_fullstack. There are no mixed naming conventions or vague verbs.
Six tools is well-scoped for a project generation server. Each tool covers a distinct stage of the workflow without redundancy or bloat.
The set covers discovery, configuration, generation, upgrade planning, and fullstack composition well. The one notable gap is that plan_upgrade only reports a plan with no corresponding apply/execute tool, leaving upgrade execution as a manual or indirect step.