@ductape/mcp 0.1.20 → 0.1.21

package/dist/index.js

@@ -2063,25 +2063,44 @@ Import (register an EXISTING cloud resource):
   List topics on a broker:
     ductape_execute("messageBrokers.topics.list", [product_tag, "broker-tag"])
 
-━━━ RUNTIME: PRODUCE AND CONSUME ━━━
+━━━ STEP 3: PRODUCE AND CONSUME — WRITTEN IN APPLICATION CODE ━━━
 
-  Produce (publish a message):
-    → CALL ductape_generate_payload FIRST (operation_family="messaging", method="produce")
-    messageBrokers.produce [{ product, env, event: "broker_tag:topic_tag", message: { key: value } }]
-    Idempotent publish (deduplicates by key, default TTL 86400 s):
-      messageBrokers.publishIdempotent [{ product, env, event, message, idempotency_key, ttl? }]
+  There is NO admin command or file to declare producers/consumers.
+  There is NO "create producer" step before writing code.
+  Producers and consumers are registered automatically by the SDK the first time your code calls
+  produce/consume — you do not pre-declare them.
+
+  The entire producer/consumer contract is the code you write in your controllers or services:
 
-  Consume (subscribe):
-    messageBrokers.consume [{ product, env, event: "broker_tag:topic_tag",
-      callback: async (message) => { ... } }]
+  Produce (publish a message) — write in your service/controller:
+    → CALL ductape_generate_payload FIRST (operation_family="messaging", method="produce")
+    await ductape.events.produce({
+      product: "my-product",
+      env: "prd",
+      event: "broker_tag:topic_tag",   // "broker_tag:topic_tag" — always colon-separated
+      message: { key: value },
+    });
+    Idempotent publish (deduplicates by key):
+      await ductape.events.publishIdempotent({ product, env, event, message, idempotencyKey, idempotencyTtl? })
+
+  Consume (subscribe) — write in your service/controller:
+    await ductape.events.consume({
+      product: "my-product",
+      env: "prd",
+      event: "broker_tag:topic_tag",
+      callback: async (message) => { /* handle message */ },
+    });
     Callback errors are re-thrown so the broker can nack/retry.
 
-  Background dispatch with scheduling:
-    messageBrokers.dispatch [{ product, env, broker, event, input: { message },
-      schedule?: { start_at?, cron?, every?, limit?, endDate?, tz? } }]
+  Background dispatch with scheduling — write in your service/controller:
+    await ductape.events.dispatch({ product, env, broker, event, input: { message },
+      schedule?: { start_at?, cron?, every?, limit?, endDate?, tz? } })
     → CALL ductape_generate_payload FIRST (operation_family="messaging", method="dispatch")
 
-Event format string: "broker_tag:topic_tag" — always colon-separated.
+  For the four standard producer declarations (match-state, match-report, projection-updated,
+  notification), write these produce calls in the relevant application service methods — there is
+  no separate configuration file or CLI step. The SDK creates the producer metadata on first call.
+
 Message payload is AES-encrypted before the tracking API call — tracking never sees plaintext.
 
 ━━━ OBSERVABILITY ━━━

package/package.json

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

package/src/index.ts

@@ -2132,25 +2132,44 @@ Import (register an EXISTING cloud resource):
   List topics on a broker:
     ductape_execute("messageBrokers.topics.list", [product_tag, "broker-tag"])
 
-━━━ RUNTIME: PRODUCE AND CONSUME ━━━
+━━━ STEP 3: PRODUCE AND CONSUME — WRITTEN IN APPLICATION CODE ━━━
 
-  Produce (publish a message):
-    → CALL ductape_generate_payload FIRST (operation_family="messaging", method="produce")
-    messageBrokers.produce [{ product, env, event: "broker_tag:topic_tag", message: { key: value } }]
-    Idempotent publish (deduplicates by key, default TTL 86400 s):
-      messageBrokers.publishIdempotent [{ product, env, event, message, idempotency_key, ttl? }]
+  There is NO admin command or file to declare producers/consumers.
+  There is NO "create producer" step before writing code.
+  Producers and consumers are registered automatically by the SDK the first time your code calls
+  produce/consume — you do not pre-declare them.
+
+  The entire producer/consumer contract is the code you write in your controllers or services:
 
-  Consume (subscribe):
-    messageBrokers.consume [{ product, env, event: "broker_tag:topic_tag",
-      callback: async (message) => { ... } }]
+  Produce (publish a message) — write in your service/controller:
+    → CALL ductape_generate_payload FIRST (operation_family="messaging", method="produce")
+    await ductape.events.produce({
+      product: "my-product",
+      env: "prd",
+      event: "broker_tag:topic_tag",   // "broker_tag:topic_tag" — always colon-separated
+      message: { key: value },
+    });
+    Idempotent publish (deduplicates by key):
+      await ductape.events.publishIdempotent({ product, env, event, message, idempotencyKey, idempotencyTtl? })
+
+  Consume (subscribe) — write in your service/controller:
+    await ductape.events.consume({
+      product: "my-product",
+      env: "prd",
+      event: "broker_tag:topic_tag",
+      callback: async (message) => { /* handle message */ },
+    });
     Callback errors are re-thrown so the broker can nack/retry.
 
-  Background dispatch with scheduling:
-    messageBrokers.dispatch [{ product, env, broker, event, input: { message },
-      schedule?: { start_at?, cron?, every?, limit?, endDate?, tz? } }]
+  Background dispatch with scheduling — write in your service/controller:
+    await ductape.events.dispatch({ product, env, broker, event, input: { message },
+      schedule?: { start_at?, cron?, every?, limit?, endDate?, tz? } })
     → CALL ductape_generate_payload FIRST (operation_family="messaging", method="dispatch")
 
-Event format string: "broker_tag:topic_tag" — always colon-separated.
+  For the four standard producer declarations (match-state, match-report, projection-updated,
+  notification), write these produce calls in the relevant application service methods — there is
+  no separate configuration file or CLI step. The SDK creates the producer metadata on first call.
+
 Message payload is AES-encrypted before the tracking API call — tracking never sees plaintext.
 
 ━━━ OBSERVABILITY ━━━