@ductape/mcp 0.2.24 → 0.2.26

package/dist/index.js

@@ -5442,11 +5442,14 @@ const DUCTAPE_FIRST_INSTRUCTIONS = 'Ductape-first: before writing custom code fo
     '(features.define + ctx.step) instead of an ad-hoc function chain — Features get durable ' +
     'steps, retries, and compensation for free. Route any call to an unreliable or swappable ' +
     'external provider (payment, email/SMS, any third-party API) through a Quota or Fallback with ' +
-    '2+ providers instead of one hardcoded call. Gate risky dependencies with Healthchecks. Treat ' +
-    'the ductape/ folder (features/, database/schema.json, notifications.json, events/) as the ' +
-    'source of truth: define there first, sync/apply, then write application code against it — ' +
-    'never the reverse. Invoke the "ductape-first-approach" prompt for the full doctrine with ' +
-    'concrete API shapes before scaffolding a new backend.';
+    '2+ providers instead of one hardcoded call. Gate risky dependencies with Healthchecks. Never ' +
+    'hardcode credentials — store them with secrets.create and reference them as $Secret{KEY} in ' +
+    'action, database, storage, and notification config. Apps, actions, and resources are meant ' +
+    'to be defined once and reused across products and environments — check what already exists ' +
+    'before creating something new. Treat the ductape/ folder (features/, database/schema.json, ' +
+    'notifications.json, events/) as the source of truth: define there first, sync/apply, then ' +
+    'write application code against it — never the reverse. Invoke the "ductape-first-approach" ' +
+    'prompt for the full doctrine with concrete API shapes before scaffolding a new backend.';
 // The detailed doctrine, invoked on demand via the "ductape-first-approach" prompt rather than
 // forced onto every session. Grounded in the actual module contracts this server exposes
 // (features, quotas, fallback, health, jobs) — keep it in sync with ductape_docs topics.
@@ -5467,12 +5470,25 @@ const DUCTAPE_FIRST_DOCTRINE = 'Follow this checklist before defaulting to plain
     'ductape/notifications.json + "ductape apply notifications", ductape/events/*.topic.json + ' +
     '"ductape apply events". Define the capability there first, then write application code that ' +
     'calls into it — never duplicate the logic inline.\n\n' +
-    '5. Before scaffolding any new resource, run ductape_schema to see the exact required fields, ' +
-    'and ductape_cli("products components list --product-tag <tag> --json") to see what already ' +
-    'exists so you extend rather than re-create.\n\n' +
+    '5. Secrets never live in code or plain config. Store every credential with secrets.create ' +
+    '(scoped and env-aware), then reference it as $Secret{KEY} wherever a credential is needed — ' +
+    'action auth headers, database/storage connection config, notification provider config. ' +
+    'Ductape resolves the reference server-side at call time; the literal value should never ' +
+    'appear in a file, a log, or a publishable-key/frontend context. Rotate with secrets.update, ' +
+    'never by hardcoding a replacement.\n\n' +
+    '6. Reuse before you rebuild. Apps, actions, database/storage/cache components, and cloud ' +
+    'connections are meant to be defined once and shared across every product and environment ' +
+    'that needs them, not recreated per project. Before scaffolding anything new, run ' +
+    'ductape_cli("products components list --product-tag <tag> --json"), ductape_cli("apps ' +
+    'list"), and ductape_cli("cloud connections list") to see what already covers the need, and ' +
+    'link or extend it instead of duplicating. The same applies to Functions ' +
+    '(ductape.functions.register/use) — register portable business logic once and reuse it across ' +
+    'every Feature that needs it. Call ductape_schema before constructing any new resource file, ' +
+    'so you match the exact required shape rather than guessing.\n\n' +
     'Default assumption for any backend built through this MCP server: orchestration goes through ' +
-    'Features, provider risk goes through Quotas/Fallback, and the ductape/ folder is what ships — ' +
-    'not a database table and a CRUD wrapper.';
+    'Features, provider risk goes through Quotas/Fallback, credentials go through Secrets, shared ' +
+    'capability goes through reuse, and the ductape/ folder is what ships — not a database table ' +
+    'and a CRUD wrapper.';
 async function main() {
     const { McpServer, StdioServerTransport } = await loadMcpSdk();
     const { version: mcpVersion } = createRequire(import.meta.url)('../package.json');
@@ -6130,24 +6146,33 @@ async function main() {
                 '  - Atlas (MongoDB Atlas) import flow — service identifier is "atlas-cluster" (required, not optional):\n' +
                 '    IMPORTANT: dbName is mandatory for every MongoDB env — see "MONGODB CLOUD CONNECTION RULE" in the\n' +
                 '    databases module above. The SDK enforces this at create time; omitting it throws a validation error.\n' +
+                '    An existing Atlas cluster is NEVER a blocker. Atlas has no concept of provisioning a new cluster\n' +
+                '    per database — a MongoDB "database" is just a named namespace inside a cluster, created on first\n' +
+                '    write. Any number of database components may point at the SAME cluster (same cloud connection,\n' +
+                '    same resource/cluster name) as long as each uses a DIFFERENT dbName. Needing a new database on a\n' +
+                '    cluster that already has one imported is the normal path, not a conflict — do not stop or ask\n' +
+                '    the user to provision a new cluster; just import again with a different dbName.\n' +
                 '    Step 1 — discover the cluster name:\n' +
                 '      ductape_cli("cloud resources list -f /tmp/atlas-list.json --json")\n' +
                 '      File: {"cloud": "<atlas-connection-tag>", "service": "atlas-cluster"}\n' +
                 '      Returns a list of clusters; note the "name" field (this is your resource identifier).\n' +
-                '    Step 2 — check if the database component already exists:\n' +
+                '    Step 2 — decide new database vs. repoint an existing one:\n' +
                 '      ductape_cli("resources databases list <product_tag> --json")\n' +
-                '      If a component already uses the same Atlas cluster, do NOT re-import — instead update it:\n' +
-                '        use ductape_cli resource update when supported; otherwise update it in Workbench\n' +
-                '      Add or change the dbName in the env\'s connection_url to switch databases on the same cluster.\n' +
-                '    Step 3 — import (only if no existing component uses this cluster):\n' +
+                '      Only skip importing when you want an EXISTING component (same product, env, and dbName) to\n' +
+                '      keep pointing at the same database — that is a repoint, not a new database, and should go\n' +
+                '      through ductape_cli resource update (or Workbench) instead of a fresh import.\n' +
+                '      Otherwise — including "same cluster, different database" — proceed to Step 3 with a new\n' +
+                '      component tag and a dbName distinct from every other component already on that cluster.\n' +
+                '    Step 3 — import (one entry per new database; reusing a cluster across components is expected):\n' +
                 '      Use import-persist-all with one entry per product env. Required fields per entry:\n' +
                 '        cloud (connection tag), service: "atlas-cluster", type: "databases",\n' +
                 '        product, component (new tag), env, resource (cluster name from Step 1),\n' +
-                '        dbName (the MongoDB database name to connect to — required for Atlas).\n' +
-                '      Example: [{"cloud":"atlas-tag","service":"atlas-cluster","type":"databases",\n' +
-                '        "product":"my-product","component":"core-db","env":"snd","resource":"Cluster0","dbName":"myapp_snd"},\n' +
+                '        dbName (the MongoDB database name to connect to — must be unique per cluster, not per workspace).\n' +
+                '      Example — a second database ("billing-db") added to the same cluster as an existing "core-db":\n' +
+                '      [{"cloud":"atlas-tag","service":"atlas-cluster","type":"databases",\n' +
+                '        "product":"my-product","component":"billing-db","env":"snd","resource":"Cluster0","dbName":"billing_snd"},\n' +
                 '        {"cloud":"atlas-tag","service":"atlas-cluster","type":"databases",\n' +
-                '        "product":"my-product","component":"core-db","env":"prd","resource":"Cluster0","dbName":"myapp_prd"}]\n' +
+                '        "product":"my-product","component":"billing-db","env":"prd","resource":"Cluster0","dbName":"billing_prd"}]\n' +
                 '  - Message broker / event broker import:\n' +
                 '    CLI accepts these aliases for the messageBrokers module: events, event, broker, brokers, message-brokers.\n' +
                 '    List existing brokers: ductape_cli("resources events list --json")\n' +

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ductape/mcp",
-  "version": "0.2.24",
+  "version": "0.2.26",
   "description": "MCP server that exposes Ductape SDK operations via the backend proxy",
   "type": "module",
   "main": "dist/index.js",