@dypai-ai/mcp 1.5.15 → 1.5.16

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dypai-ai/mcp",
-  "version": "1.5.15",
+  "version": "1.5.16",
   "description": "DYPAI MCP Server — AI agent toolkit for building and deploying full-stack apps",
   "type": "module",
   "main": "src/index.js",

package/src/index.js

@@ -153,7 +153,7 @@ This stores classification metadata only. It does not create users, roles, login
     },
   },
   { name: "list_ai_models", description: "List only the DYPAI Managed AI models that are active for a project. Returns the project-gated OpenRouter model catalog priced in AI Credits per 1M tokens, RPM limit, max output tokens, active/available counts, billing metadata, and the exact node parameters to use. Call this before creating or editing an AI Agent node with DYPAI Managed models. Agents must not invent or use inactive model ids. Use provider='openrouter' and do NOT set credential_id; DYPAI uses the platform OpenRouter key and deducts usage from the organization's AI Credits.", inputSchema: { type: "object", properties: { project_id: { type: "string", description: "Project UUID whose plan and Model Gateway settings determine the active Managed AI catalog." } }, required: ["project_id"] } },
-  { name: "create_project", description: "Create a new DYPAI project (free plan). Creates a full project with database, engine, GitHub repo, and frontend hosting. BLOCKS by default until provisioning finishes (~60s typical, 120s max) — when it returns, the project_id is ready to use with execute_sql, endpoint tools, etc. Pass wait_until_ready:false for batch flows.\n\nName collision: if another project in the same org already uses the name (case-insensitive), returns {error:'name_taken', existing_project_id, suggestions:[...]}. Pick a different name or use the existing project.\n\nProject limits are enforced by the DYPAI API at organization/workspace scope according to the workspace plan. If it returns {error:'project_limit_reached'}, do not retry create_project; show list_projects for that organization and ask the user to reuse, archive/pause, upgrade the workspace to Pro, or add capacity.\n\nIMPORTANT: before calling, check for a matching Studio template with `search_project_templates`. Passing a `template_slug` can drop in ready-made UI, schema, endpoints, and agent instructions. Prefer Studio catalog slugs when the returned brief is a strong fit; legacy fallback bases (`private-admin`, `user-accounts`, `landing-admin`, `blank`) remain available when no catalog template fits.", inputSchema: { type: "object", properties: { name: { type: "string", description: "Project name (e.g. 'My Veterinary App')" }, organization_id: { type: "string", description: "Optional. Uses default org if omitted." }, description: { type: "string" }, template_slug: { type: "string", description: "RECOMMENDED. Template slug returned by search_project_templates. Use Studio catalog slugs when a strong template fits; legacy fallback bases remain supported when no catalog template fits." }, wait_until_ready: { type: "boolean", description: "If true (default), blocks until provisioning completes and the project is ready for all operations. If false, returns immediately with status='provisioning' — caller must poll get_project before using.", default: true } }, required: ["name"] } },
+  { name: "create_project", description: "Create a new DYPAI project (free plan). Creates a full project with database, engine, GitHub repo, and frontend hosting. BLOCKS by default until provisioning finishes (~60s typical, 120s max) — when it returns, the project_id is ready to use with execute_sql, endpoint tools, etc. Pass wait_until_ready:false for batch flows.\n\nName collision: if another project in the same org already uses the name (case-insensitive), returns {error:'name_taken', existing_project_id, suggestions:[...]}. Pick a different name or use the existing project.\n\nProject limits are enforced by the DYPAI API at organization/workspace scope according to the workspace plan. If it returns {error:'project_limit_reached'}, do not retry create_project; show list_projects for that organization and ask the user to reuse, archive/pause, upgrade the workspace to Pro, or add capacity.\n\nIMPORTANT: before calling, check for a matching Studio template with `search_project_templates`. Passing a `template_slug` can drop in ready-made UI, schema, endpoints, and agent instructions. Use only slugs returned by search_project_templates; do not invent legacy template slugs.", inputSchema: { type: "object", properties: { name: { type: "string", description: "Project name (e.g. 'My Veterinary App')" }, organization_id: { type: "string", description: "Optional. Uses default org if omitted." }, description: { type: "string" }, template_slug: { type: "string", description: "RECOMMENDED. Template slug returned by search_project_templates. Use only visible Studio catalog slugs." }, wait_until_ready: { type: "boolean", description: "If true (default), blocks until provisioning completes and the project is ready for all operations. If false, returns immediately with status='provisioning' — caller must poll get_project before using.", default: true } }, required: ["name"] } },
   { name: "get_app_credentials", description: "Lists available credentials in the current application. Returns API keys, anon key, service role key, and engine URL needed for SDK configuration.", inputSchema: { type: "object", properties: { project_id: { type: "string" } }, required: [] } },
 
   // ── Database ──────────────────────────────────────────────────────────────
@@ -496,7 +496,7 @@ endpoint YAML and \`dypai_push\`. This tool does NOT modify the definition.`,
   { name: "search_docs", description: "Search DYPAI documentation. Use this when unsure about SDK usage, auth patterns, workflow nodes, or platform features. Returns relevant documentation chunks.", inputSchema: { type: "object", properties: { query: { type: "string", description: "What you want to learn about" } }, required: ["query"] } },
   { name: "search_design_patterns", description: "Search compact DYPAI UI/design recipes. Use before designing substantial screens.", inputSchema: { type: "object", properties: { query: { type: "string", description: "Design need, with starter/domain/screen/style context when known." }, starter_slug: { type: "string", description: "Optional: private-admin, user-accounts, landing-admin, or blank." }, app_type: { type: "string", description: "Optional domain/app type." }, screen_type: { type: "string", description: "Optional screen/workflow." }, visual_style: { type: "string", description: "Optional style." }, category: { type: "string", description: "Optional category." }, limit: { type: "integer", default: 3, minimum: 1, maximum: 4 } }, required: ["query"] } },
   { name: "search_workflow_templates", description: "Search workflow templates by description. Returns ready-to-use workflow code for common patterns: CRUD operations, payment gateways, email sending, AI chatbots, data pipelines, etc.", inputSchema: { type: "object", properties: { query: { type: "string", description: "What the workflow should do (e.g. 'send email', 'stripe payment')" }, category: { type: "string", description: "Optional: AI, Database, Payments, Communication, Logic, Storage" } }, required: ["query"] } },
-  { name: "search_project_templates", description: "Search DYPAI Studio project templates by description. Studio catalog results are the primary source and return compact template briefs plus selection_guidance: recommended_slug, confidence, fallback_slug, and agent_rule. Legacy fallback bases are returned only when no Studio template is a strong fit.", inputSchema: { type: "object", properties: { query: { type: "string", description: "What kind of project starter you need, in the user's language (e.g. 'app para barberia con reservas', 'private admin dashboard', 'landing plus admin')" }, category: { type: "string", description: "Optional category/type filter." }, limit: { type: "integer", default: 5, minimum: 1, maximum: 10 }, include_drafts: { type: "boolean", default: false, description: "Internal/local testing only. Include draft Studio catalog templates." } }, required: ["query"] } },
+  { name: "search_project_templates", description: "Search visible DYPAI Studio project templates by description. Returns only the Studio catalog plus compact template briefs and selection_guidance: recommended_slug, confidence, fallback_slug, and agent_rule.", inputSchema: { type: "object", properties: { query: { type: "string", description: "What kind of project starter you need, in the user's language (e.g. 'app para barberia con reservas', 'private admin dashboard', 'landing plus admin')" }, category: { type: "string", description: "Optional category/type filter." }, limit: { type: "integer", default: 5, minimum: 1, maximum: 10 }, include_drafts: { type: "boolean", default: false, description: "Internal/local testing only. Include draft Studio catalog templates." } }, required: ["query"] } },
 ]
 
 // ── Server Instructions ──────────────────────────────────────────────────────
@@ -525,23 +525,18 @@ First reflex, always:
 
 1. **Acknowledge briefly** what they want to build (one short line, their language).
 2. **\`search_project_templates(query: "<keywords from their request>")\`** — keywords in their language. The Studio catalog returns compact briefs plus \`selection_guidance\`: recommended slug, confidence, fallback slug, and the rule for deciding.
-3. **Decide: Studio catalog template, legacy base, or blank.** Use \`selection_guidance\` explicitly:
+3. **Decide from the returned Studio catalog templates only.** Use \`selection_guidance\` explicitly:
    - confidence "strong": use \`recommended_slug\` if it does not contradict the user's plan.
    - confidence "medium": use it only if the user's answers confirm the same domain/workflow.
    - confidence "weak": do not auto-use it; use \`fallback_slug\`.
    - confidence "fallback": use \`recommended_slug\` unless the app plan clearly requires a different returned slug.
    - Strong fit: user says *"app para barberia con reservas"* and the result includes a booking/barber vertical with matching routes/endpoints. Use that template and preserve what it already has.
    - Strong fit: user asks for a broad business app and a matching vertical template says what to adapt and what not to rebuild. Use the template, then customize it.
-   - Weak fit: user says *"algo para gestionar reservas"* and only a very specific unrelated vertical matches softly. Use a safer legacy base or blank. Don't inherit domain-specific schema they did not ask for.
-   - Legacy bases are fallback defaults when no Studio catalog template fits:
-     - private/internal/admin/dashboard/backoffice/business management → \`private-admin\`
-     - end-user signup/login/customer/member portal/marketplace/SaaS accounts → \`user-accounts\`
-     - public landing/marketing site plus private admin → \`landing-admin\`
-     - no clear access pattern or explicitly custom/from scratch → \`blank\`
-   - Concrete spec: user is a dev with a concrete spec (*"crea un proyecto con estas 3 tablas y estos endpoints"*). Usually use **blank**, unless a Studio template exactly matches the requested product.
+   - Weak fit: user says *"algo para gestionar reservas"* and only a very specific unrelated vertical matches softly. Use \`fallback_slug\` from the Studio catalog guidance. Don't inherit domain-specific schema they did not ask for.
+   - Concrete spec: user is a dev with a concrete spec (*"crea un proyecto con estas 3 tablas y estos endpoints"*). Use the simplest returned Studio base unless a template exactly matches the requested product.
 4. **Call it** → \`create_project(name: "<their name>", template_slug: "<slug from search_project_templates>")\`.
    If you went with a catalog template, use its \`agent_brief\`: preserve \`already_included\`, follow \`adaptation_steps\`, and do not rebuild \`do_not_rebuild\`.
-   If you went blank, just say: *"Arranco un proyecto en blanco y lo construimos a medida."*
+   Do not invent or use legacy slugs that were not returned by search_project_templates.
 5. **After \`create_project\`** → ask for an absolute workspace path, then \`dypai_pull\` + \`manage_frontend(sync)\` (see next section).
 
 Before designing substantial UI (app shell, dashboard, login, tables/lists,
@@ -560,7 +555,7 @@ target workspace package.json and install them locally (never globally or in
 the MCP server). Then wire the kit into the app, apply SQL if needed, validate
 endpoints, and verify the frontend.
 
-**The template system exists to save time when the fit is obvious, not to force-match every request.** When in doubt → use the safest legacy base or blank. Iterating up from a smaller base is cheaper than deleting 80% of a mismatched template.
+**The template system exists to save time when the fit is obvious, not to force-match every request.** When in doubt → use the safest returned Studio base. Iterating up from a smaller base is cheaper than deleting 80% of a mismatched template.
 
 ## The one legit follow-up question
 
@@ -580,7 +575,7 @@ These (and only these) justify mentioning alternatives:
 
 ## If the client isn't web (mobile, desktop, game, extension)
 
-DYPAI builds the **backend** (DB, auth, API, storage, realtime) for any client. If the user asks for a native iOS/Android/desktop app: arranca un \`create_project(template_slug:"blank")\` para el backend y déjale claro que el cliente nativo lo construye él aparte (o le ayudas con el cliente fuera de DYPAI). No propongas "entonces usemos otra plataforma entera" — el backend encaja.
+DYPAI builds the **backend** (DB, auth, API, storage, realtime) for any client. If the user asks for a native iOS/Android/desktop app: use the simplest returned Studio template for the backend and make clear that the native client lives outside DYPAI Studio. Do not propose "then use another whole platform" — the backend fits.
 
 For everything else, **the stack is decided. Start building.**
 

package/src/tools/scaffold.js

@@ -20,8 +20,7 @@ Scaffolds a project directory with:
 - .env with engine URL
 
 Use search_project_templates first, then pass the returned template slug here.
-Prefer Studio catalog template slugs when a strong brief fits. Legacy fallback
-bases ("private-admin", "user-accounts", "landing-admin", "blank") remain available when no catalog template fits.`,
+Use only visible Studio catalog template slugs; do not invent legacy slugs.`,
 
   inputSchema: {
     type: "object",
@@ -36,14 +35,14 @@ bases ("private-admin", "user-accounts", "landing-admin", "blank") remain availa
       },
       template: {
         type: "string",
-        description: 'Template slug returned by search_project_templates. Studio catalog slugs are preferred; legacy fallback bases remain supported.',
-        default: "blank",
+        description: "Template slug returned by search_project_templates.",
+        default: "template-blank-mixed",
       },
     },
     required: ["directory", "project_id"],
   },
 
-  async execute({ directory, project_id, template = "blank" }) {
+  async execute({ directory, project_id, template = "template-blank-mixed" }) {
     if (existsSync(join(directory, "package.json"))) {
       return { error: `Directory already has a package.json. Pick an empty directory or a new name.` }
     }
@@ -140,7 +139,7 @@ bases ("private-admin", "user-accounts", "landing-admin", "blank") remain availa
       directory,
       files_created: created,
       dependencies_installed: installed,
-      template: template || "blank",
+      template: template || "template-blank-mixed",
       engine_url: engineUrl,
       sdk_client: "src/lib/dypai.ts",
       // Critical: dypai_pull without an absolute out_dir can land in $HOME