@dypai-ai/mcp 1.5.3 → 1.5.5

package/package.json

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

package/src/index.js

@@ -166,7 +166,7 @@ const REMOTE_TOOLS = [
   // and fail to learn the contract. Mirrors the validation the remote does.
   {
     name: "manage_users",
-    description: `Manage authenticated users (better-auth backed).
+    description: `Manage authenticated users.
 
 Operations:
 - list:         Paginated user listing. Optional: search, limit (1-100, default 20), offset, sort_by, sort_order.
@@ -177,14 +177,14 @@ Operations:
 - delete:       Permanently remove a user (user_id).
 - ban / unban:  Block / unblock login (user_id; ban supports ban_reason and ban_expires_in seconds).
 
-NOTE: user IDs are TEXT (better-auth nanoids like "G1LIBXsbMLxUrs99ebCaL9X4auxW26AC"), NOT UUIDs.`,
+NOTE: user IDs are TEXT alphanumeric strings (~32 chars, like "G1LIBXsbMLxUrs99ebCaL9X4auxW26AC"), NOT UUIDs. They live in auth."user".id.`,
     inputSchema: {
       type: "object",
       properties: {
         project_id:        { type: "string", description: "Project UUID. Required for user tokens; auto-detected for project tokens." },
         operation:         { type: "string", enum: ["list", "get", "create", "set_password", "update_role", "delete", "ban", "unban"] },
         // Fields used by various operations
-        user_id:           { type: "string", description: "User ID (TEXT, better-auth nanoid). Required for: get, set_password, update_role, delete, ban, unban." },
+        user_id:           { type: "string", description: "User ID (TEXT alphanumeric, NOT a UUID; from auth.\"user\".id). Required for: get, set_password, update_role, delete, ban, unban." },
         email:             { type: "string", description: "User email. Required for: create." },
         password:          { type: "string", description: "User password (min 6 chars). Required for: create, set_password." },
         name:              { type: "string", description: "Display name. Optional for: create." },
@@ -477,7 +477,7 @@ const SERVER_INSTRUCTIONS = `You are building full-stack applications on the DYP
 - ❌ *"¿Prefieres Tailwind o CSS Modules?"*
 - ❌ Asking "which framework" unless the user explicitly says *"I want to compare platforms"* or *"what are my options"*.
 
-These are ALL dead signals: Next.js is already what DYPAI scaffolds. The DB is already PostgreSQL (via DYPAI engine). Auth is already better-auth (built in). Tailwind is already in the templates. Prisma / ORMs are not used — you write SQL directly in workflow endpoints.
+These are ALL dead signals: Next.js is already what DYPAI scaffolds. The DB is already PostgreSQL (via DYPAI engine). Auth is built in. Tailwind is already in the templates. Prisma / ORMs are not used — you write SQL directly in workflow endpoints.
 
 ## What to do when the user says "I want to build X"
 
@@ -485,10 +485,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. Templates cover common app types (gym, clinic, waitlist, saas dashboard, etc.).
-3. **If a template matches** → confirm with the user in one line, then \`create_project(name: "<their name>", template_slug: "<slug>")\`. Don't ask 15 questions about scope — the template IS the starting MVP, you can iterate from there.
-4. **If no template matches** → \`create_project(name: "<their name>", template_slug: "blank")\` and then build from scratch.
+3. **Decide: template or blank?** Default is **blank**. A template is only the right pick when the match is OBVIOUS and STRONG:
+   - ✅ User says *"app para mi gimnasio"* + there's \`gym-manager\` (exact domain + feature overlap) → template.
+   - ❌ User says *"algo para gestionar reservas"* + there's \`gym-manager\` (soft match, many interpretations) → **blank**. Don't assume they want the gym's specific schema (classes, memberships, check-ins) — they didn't ask for it.
+   - ❌ User is a dev with a concrete spec (*"crea un proyecto con estas 3 tablas y estos endpoints"*) → **blank**, always. Respect their design.
+   - ❌ No template returned at all → **blank**.
+4. **Call it** → \`create_project(name: "<their name>", template_slug: "<matched_slug>" | "blank")\`.
+   If you went with a template, acknowledge in ONE line what's included so the user can push back: *"Lo arranco con la plantilla X, que trae socios, clases y pagos. ¿Te vale o prefieres algo más simple?"*
+   If you went blank, just say: *"Arranco un proyecto en blanco y lo construimos a medida."*
 5. **After \`create_project\`** → ask for an absolute workspace path, then \`dypai_pull\` + \`manage_frontend(sync)\` (see next section).
 
+**The template system exists to save time when the fit is obvious, not to force-match every request.** When in doubt → blank is always correct. Iterating up from blank is cheaper than deleting 80% of a mismatched template.
+
 ## The one legit follow-up question
 
 After deciding to build on DYPAI, you may ask ONE question (not five) to size scope if the request is genuinely vague:
@@ -531,6 +539,8 @@ Before the first \`execute_sql\`, before the first file edit, before ANYTHING:
 1. **Look at the workspace.** Is there a \`dypai/\` folder? A \`src/\`? A \`package.json\`? If you're using a Read/ls tool, check now.
 2. **Missing backend (\`dypai/\` absent)?** You have no endpoint YAMLs, no \`schema.sql\`, no node catalog. Cannot write queries, cannot push, cannot reason about the schema.
 3. **Missing frontend (\`src/\` or \`package.json\` absent)?** You have no React/Vite/Next code. Cannot change the UI, cannot run \`npm install\`, cannot test locally.
+
+**Having \`src/\` on disk does NOT mean the backend is on disk.** \`dypai/\` is a SEPARATE folder. Check for \`dypai/schema.sql\` specifically — if it's missing, the backend isn't materialized, even if the frontend clearly is. This is the #1 trap in hosts that default to file-first workflows (Claude Code especially): they see \`src/\` + \`package.json\` and assume the project is complete. Always verify \`dypai/schema.sql\` exists before touching data, queries, or endpoints.
 4. **If either is missing → sync FIRST:**
    - Ask the user for an absolute workspace path if you don't have one (e.g. \`/Users/me/code/my-app\`).
    - Run \`dypai_pull(project_id, out_dir: <abs>/dypai)\` — materializes backend (endpoints, SQL, prompts, schema.sql, node-catalog.json).
@@ -851,7 +861,7 @@ Mental translations: "edge function" → workflow with one code node; "cron" →
 
 ## Common app recipes (one-liners)
 
-- **Auth-gated CRUD**: table with \`user_id UUID\`, jwt endpoints, SQL always filters by \`\${current_user_id}\`, frontend \`<ProtectedRoute>\`.
+- **Auth-gated CRUD**: table with \`user_id TEXT\` (auth IDs are TEXT, not UUID), jwt endpoints, SQL always filters by \`\${current_user_id}\`, frontend \`<ProtectedRoute>\`.
 - **Admin panel**: endpoints with \`allowed_roles: [admin]\`. Same SQL, no user filter (admin sees all). Promote via \`manage_users(update_role)\`.
 - **AI chat**: single endpoint with \`agent\` node + \`memory_key: "chat:\${current_user_id}"\`. Frontend \`dypai.api.stream()\`.
 - **Payments (Stripe)**: \`stripe\` node for ops. Webhook endpoint with \`trigger.webhook\` + \`stripe_webhook: true\` (auto-verifies signature).
@@ -879,7 +889,7 @@ SDK is pre-configured at \`src/lib/dypai.ts\` (or \`src/dypai.ts\`). Import \`dy
 
 - \`bulk_upsert\` — CSV/JSON → table. Seed data.
 - \`manage_domain\` — custom domains. \`add\` returns CNAME to configure. \`verify\` rechecks DNS/SSL. → \`search_docs("manage domain")\`.
-- \`manage_users\` / \`manage_roles\` — app-level RBAC (better-auth). Create/ban/assign roles.
+- \`manage_users\` / \`manage_roles\` — app-level RBAC. Create/ban/assign roles.
 - \`manage_schedules\` / \`manage_webhooks\` — pause/resume/history. To change the DEFINITION, edit the YAML and push.
 - \`manage_storage\` — buckets + objects. \`upload_file\` reads local path, signs URL, PUTs, registers. Max 100MB/file. → \`search_docs("file storage")\`.
 - \`manage_drafts\` — universal draft/publish. \`list\` before \`publish\` so the user sees what's shipping. \`discard\` to throw away. Always pair with \`dypai_test_endpoint(mode:'draft')\` before publish.

package/src/tools/sql-guard.js

@@ -18,7 +18,7 @@
 
 // Schemas the agent must not modify. SELECT against them stays allowed.
 const PROTECTED_SCHEMAS = new Set([
-  "auth",                // better-auth user/session tables — engine-owned
+  "auth",                // auth user/session tables — engine-owned
   "storage",             // file upload metadata — engine-owned
   "system",              // DYPAI internals (endpoints, credentials, etc.)
   "information_schema",  // PG metadata catalog

package/src/tools/sync/describe.js

@@ -127,7 +127,7 @@ export const dypaiDescribeTool = {
       placeholders_available: [
         "${input.<field>}  — request body / query params",
         "${nodes.<node_id>.<field>}  — output of a previous node",
-        "${current_user_id}  — uuid of the authenticated user (jwt auth only)",
+        "${current_user_id}  — id of the authenticated user (TEXT, NOT a UUID; jwt auth only)",
         "${current_user_role}  — role name of the authenticated user",
       ],
 

package/src/tools/sync/pull.js

@@ -206,7 +206,7 @@ output:
 #
 #   \${input.<field>}            — the request body / query params
 #   \${nodes.<id>.<field>}       — output of a previous node
-#   \${current_user_id}          — UUID of the JWT-authenticated user
+#   \${current_user_id}          — ID of the JWT-authenticated user (TEXT, NOT a UUID — match against TEXT columns)
 #   \${current_user_role}        — role name from the JWT
 #
 # Expressions inside placeholders work: arithmetic, comparisons, JS-ish.
@@ -218,8 +218,9 @@ output:
 #   plain object/array  →  binds as ::jsonb
 #   Date instance       →  binds as ::timestamptz
 #   text / int / bool   →  binds without an explicit cast (Postgres infers)
-# So you write SQL naturally — DON'T add '\${current_user_id}'::uuid manually.
-# Just write: WHERE user_id = \${current_user_id}
+# So you write SQL naturally — DON'T add type casts manually like
+# '\${input.product_id}'::uuid. Just write: WHERE id = \${input.product_id}
+# (and remember: \${current_user_id} is TEXT, so user_id columns must be TEXT too).
 workflow:
   nodes:
 

package/src/tools/sync/test-endpoint.js

@@ -243,7 +243,7 @@ export const dypaiTestEndpointTool = {
       },
       as_user: {
         type: "string",
-        description: "User UUID to impersonate. Required for jwt endpoints that read ${current_user_id}.",
+        description: "User ID to impersonate. Required for jwt endpoints that read ${current_user_id}. NOTE: user IDs are stored in auth.\"user\".id as a TEXT alphanumeric string (e.g. '9KxggvkPhgpYXITE6koY0vYWJqQzSwaw'), NOT a UUID. Discover IDs with manage_users(operation:'list') or execute_sql(\"SELECT id, email FROM auth.\\\"user\\\" LIMIT 5\"). Common mistake: passing a UUID copied from system.users or a business table.",
       },
       trace_mode: {
         type: "string",

package/src/tools/sync/validate.js

@@ -1175,7 +1175,7 @@ export async function runValidation(rootDir, projectId) {
             `    user_id TEXT NOT NULL,\\n` +
             `    created_at TIMESTAMPTZ DEFAULT NOW()\\n` +
             `  );" })\n` +
-            `IMPORTANT: user_id must be TEXT (not UUID) — better-auth's auth.user.id is a 32-char nanoid stored as TEXT. ` +
+            `IMPORTANT: user_id must be TEXT (not UUID) — auth.\"user\".id is a TEXT alphanumeric string (~32 chars). ` +
             `(Add other columns matching what your endpoint INSERTs.) ` +
             `schema.sql will auto-refresh after the DDL. Existing tables: ${knownTablesList}`,
         })