@ductape/mcp 0.2.27 → 0.2.29

package/dist/index.js

@@ -780,19 +780,24 @@ ALL params are passed as a JSON array in positional order matching the SDK signa
   databases.migration.rollback [migrations, count?]
   databases.migration.history []
   databases.migration.status [migrations]
-  databases.action.create [{ tag: "product:database:action", name, tableName, operation: "query"|"insert"|"update"|"delete"|"upsert"|"aggregate"|"rawSql", template: { where?, select?, limit?, offset?, orderBy?, records?, query?, params?, ... }, description?, filterTemplate? }]
+  databases.action.create [{ tag: "product:database:action", name, description, tableName, operation: "query"|"insert"|"update"|"delete"|"aggregate"|"count", template, filterTemplate? }]
     ← ADMINISTRATIVE (access key required). FORBIDDEN via ductape_execute (publishable key) —
-      use ductape_cli("db actions create -f action.json") instead. tag MUST be fully qualified
+      use ductape_cli("db actions create --action-file action.json") instead. tag MUST be fully qualified
       "product_tag:database_tag:action_tag" — a 2-part "database:action" shorthand only resolves
       inside a long-lived process that already has that product's builder cached, never in a
       fresh CLI/MCP call. This is pure metadata registration; it never connects to the live
       database, so it does NOT require the database to be reachable at call time.
+      MongoDB query example: { operation: "query", template: { where: { email: "{{email}}" } } }
+      Placeholders are {{name}}, never $Input{name}. For the exact manifest call
+      ductape_schema({ module: "product", method: "databases.action.create" }).
   databases.action.update [{ tag, name?, description?, template?, filterTemplate? }]
-    ← ADMINISTRATIVE. Use ductape_cli("db actions update --tag <tag> -f patch.json").
+    ← ADMINISTRATIVE. Use ductape_cli("db actions update --tag <tag> --action-file patch.json").
   databases.action.fetch  [action_tag]  ← read-only, safe via ductape_execute
   databases.action.fetchAll [database_tag]  ← read-only, safe via ductape_execute.
     NOTE: the method is fetchAll — "action.list" is not a callable method on this sub-object.
   databases.action.delete [action_tag]  ← ADMINISTRATIVE. Use ductape_cli("db actions delete <tag>").
+  databases.execute [{ product, env, database, action, input, session? }]  ← synchronous saved-action execution
+    CLI: ductape db actions execute --action-file execute.json --json
   databases.action.dispatch [{ product, env, database, action, input, schedule? }]  ← CALL ductape_generate_payload FIRST (operation_family="database", method="dispatch", targets={database: "db_tag", table: "table_name"}) — requires redisUrl in ductape initialization
   databases.dispatch [{ product, env, database, action, input, schedule? }]  ← CALL ductape_generate_payload FIRST (operation_family="database", method="dispatch", targets={database: "db_tag", table: "table_name"}) — requires redisUrl in ductape initialization
   databases.beginTransaction [{ product, env, database, isolationLevel?: "READ_COMMITTED"|"REPEATABLE_READ"|"SERIALIZABLE" }]
@@ -853,6 +858,13 @@ ALL params are passed as a JSON array in positional order matching the SDK signa
   graph.getAction    [actionTag, graphTag?, productTag?]
   graph.updateAction [actionTag, updates, graphTag?, productTag?]
   graph.deleteAction [actionTag, graphTag?, productTag?]
+  graph.action.create [{ product, graph|graphTag, name, description?, operation, query, parameters? }]
+  graph.action.update [{ product, graph|graphTag, action|actionTag, name?, description?, query?, parameters? }]
+  graph.action.fetch  [{ product, graph|graphTag, action|actionTag }]
+  graph.action.fetchAll [{ product, graph|graphTag }]
+  graph.action.delete [{ product, graph|graphTag, action|actionTag }]
+  graph.action.execute [{ product, env, graph, action, input }]
+  graph.action.dispatch [{ product, env, graph, event, input, schedule? }]
   graph.beginTransaction [options?]
   graph.commitTransaction [transaction]
   graph.rollbackTransaction [transaction]
@@ -887,6 +899,12 @@ ALL params are passed as a JSON array in positional order matching the SDK signa
   vector.deleteIndex    [{ product, env, vector, name }]
   vector.listIndexes    [{ product, env, vector }]
   vector.count          [{ product, env, vector, namespace? }]
+  vector.actions.create [{ product, vector, actionTag, name, operation, template, description?, parameters? }]
+  vector.actions.update [{ product, vector, actionTag, name?, description?, template?, parameters? }]
+  vector.actions.fetch  [{ product, vector, actionTag }]
+  vector.actions.fetchAll [{ product, vector }]
+  vector.actions.delete [{ product, vector, actionTag }]
+  vector.actions.execute [{ product, env, vector, action, input }]
 
 ━━━ MODULE: features ━━━
   Feature definitions are code-first. Use features.define in application source; do not call
@@ -918,7 +936,8 @@ ALL params are passed as a JSON array in positional order matching the SDK signa
       // ctx.step(tag, fn, rollback?, opts?)  – define a durable step
       // ctx.api.run({ app, action, input }) – call an app action (NOT 'event' -- that field name
       //   only applies to ctx.database/ctx.notification/ctx.storage below, never ctx.api/ctx.action)
-      // ctx.database.query/insert/update/delete({ database, event, ... })
+      // ctx.database.execute({ database, action, input }) for a saved database action
+      // ctx.database.query/insert/update/delete({ database, table, ... }) for direct operations
       // ctx.graph.execute({ graph, action, input })
       // ctx.notification.send/email/push/sms({ notification, event, ... })
       // ctx.storage.upload/download({ storage, event, input })
@@ -2409,22 +2428,24 @@ DUCTAPE DATABASE ACTIONS
 
 A database action is a saved, parameterized query or mutation template (with {{placeholder}}
 fields) stored on a database component and executed by tag at runtime. This is what
-ctx.database.query/insert/update/delete inside a Feature step actually calls via its
-\`event\` field — Features do NOT accept the top-level {table, where} shape that
-sdk.databases.query/insert/update use outside of a Feature.
+ctx.database.execute inside a Feature step invokes a saved action through its \`action\` field.
+Direct ctx.database.query/insert/update/delete calls retain their normal {table, where, data, ...}
+shape and do not resolve a saved action.
 
 Create/update/delete are ADMINISTRATIVE (access key) — FORBIDDEN through ductape_execute
 (publishable key). Use ductape_cli, same as every other admin resource:
-  ductape_cli("db actions create -f action.json")
-    File: { tag: "product:database:action", name, tableName,
-             operation: "query"|"insert"|"update"|"delete"|"upsert"|"aggregate"|"rawSql",
-             template: { where?, select?, limit?, offset?, orderBy?, records?, query?, params? },
-             description?, filterTemplate? }
+  ductape_cli("db actions create --action-file action.json")
+    File: { tag: "product:database:action", name, description, tableName,
+             operation: "query"|"insert"|"update"|"delete"|"aggregate"|"count",
+             template, filterTemplate? }
+    MongoDB query: { operation: "query", template: { where: { email: "{{email}}" } } }
+    Placeholders use {{name}}, never $Input{name}. Call
+    ductape_schema({ module: "product", method: "databases.action.create" }) for the exact shape.
     tag MUST be fully qualified "product_tag:database_tag:action_tag" — the SDK's 2-part
     "database:action" shorthand only works inside one already-warm process, never a fresh CLI call.
     This is pure metadata registration — it does not connect to the live database, so the
     database does not need to be reachable at creation time.
-  ductape_cli("db actions update --tag <tag> -f patch.json")
+  ductape_cli("db actions update --tag <tag> --action-file patch.json")
   ductape_cli("db actions delete <tag>")
 
 List/fetch are read-only and safe via ductape_execute:
@@ -2433,6 +2454,15 @@ List/fetch are read-only and safe via ductape_execute:
   ductape_execute("databases.action.fetch",  ["product_tag:database_tag:action_tag"])
 
 Dispatch an action at runtime:
+  Synchronous execution:
+  ductape_execute("databases.execute", [{
+    product: "my-product", env: "prd", database: "core-db",
+    action: "get-active-users", input: { status: "active" }
+  }])
+  CLI equivalent:
+  ductape_cli("db actions execute --action-file execute.json --json")
+
+Deferred or scheduled execution:
   → CALL ductape_generate_payload FIRST to get the canonical input shape.
   ductape_execute("databases.action.dispatch", [{
     product: "my-product",
@@ -2861,8 +2891,8 @@ Run an action at runtime:
 In a Ductape feature handler, call the registered action through:
   await ctx.api.run({ app: "<app_tag>", action: "<action_tag>", input: { ... } })
 ctx.api is the supported feature-context surface (also described as ctx.action in older code).
-NEVER use 'event' as the field name here -- that is only correct for ctx.database/ctx.notification/
-ctx.storage steps. ctx.api.run's real field is 'action'; passing 'event' instead silently produces
+NEVER use 'event' as the field name here -- that is only correct for ctx.notification/ctx.storage
+steps. ctx.api.run and ctx.database.execute both use 'action'; passing 'event' instead produces
 an unset step and fails feature compilation with "did not record a portable operation".
 There is no ctx.apps, ctx.integrations, or generic external-HTTP feature surface.
 
@@ -3903,9 +3933,9 @@ Synchronous multi-step Feature (no Event, schedule, sleep, signal, or external s
     },
     handler: async (ctx) => {
       const validated = await ctx.step('validate-orders', () =>
-        ctx.database.execute({ database: 'orders-db', event: 'validate-orders', input: ctx.input }));
+        ctx.database.execute({ database: 'orders-db', action: 'validate-orders', input: ctx.input }));
       return ctx.step('resolve-orders', () =>
-        ctx.database.execute({ database: 'orders-db', event: 'resolve-orders', input: validated }));
+        ctx.database.execute({ database: 'orders-db', action: 'resolve-orders', input: validated }));
     },
   });
 This is a valid Feature despite requiring no signal and producing no Event. Its qualification comes
@@ -3919,9 +3949,9 @@ Define a feature (write this into the project's source files — do NOT use feat
     name: "Onboard User",
     handler: async (ctx) => {
       const account = await ctx.step("create-account", async () =>
-        ctx.database.insert({ database: "core-db", event: "insert-user",
+        ctx.database.insert({ database: "core-db", table: "users",
           data: { userId: ctx.input.userId, email: ctx.input.email } }),
-        async (result) => ctx.database.delete({ database: "core-db", event: "delete-user",
+        async (result) => ctx.database.delete({ database: "core-db", table: "users",
           where: { id: result.id } })   // rollback
       );
 
@@ -5016,9 +5046,9 @@ SAVED GRAPH ACTION ASSET AND CLI CONTRACT:
   Validate without mutation:
     ductape graph validateAction -f ductape/graphs/discovery-graph/actions/upsert-product-v1.action.json --json
   Create and persist against the linked product:
-    ductape graph createAction -f ductape/graphs/discovery-graph/actions/upsert-product-v1.action.json --json
+    ductape graph actions create --action-file ductape/graphs/discovery-graph/actions/upsert-product-v1.action.json --json
   Read back with graph.getAction/listActions before relying on it. In-place updates use:
-    ductape graph updateAction -f <patch.json> --json
+    ductape graph actions update --action-file <patch.json> --json
   where patch.json is { "actionTag":"upsert-product-v1", "graphTag":"discovery-graph", "updates":{...} }.
   Updating name does not change the stored tag. For breaking query/input/result changes, create a new
   name/tag such as V2 and migrate callers; use updateAction for compatible corrections only.
@@ -5044,6 +5074,11 @@ EXACT CODE-FIRST VECTOR CONTEXT:
   Product/env and the Feature's inherited session are supplied by the executor. Do not serialize
   them into the Feature definition. Note the deliberate naming: ctx.vector.query uses values for
   the embedding, while the lower-level ductape.vector.query runtime facade uses vector.
+  Register reusable vector actions administratively, then read them back before compiling Features:
+    ductape vector actions create --action-file vector-action.json --json
+    ductape vector actions get <action-tag> --vector <vector-tag> --json
+  Update/delete/list use the same \`ductape vector actions\` surface. At runtime the SDK namespace is
+  \`ductape.vector.actions.*\` (plural), while Feature reuse is singular \`ctx.vector.execute(...)\`.
   Vertex AI Vector Search stores and searches supplied vectors. It does NOT generate embeddings.
   Do not claim that a Vertex Vector Search index embeds text.
 

package/package.json

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