conduyt-mcp 4.105.1 → 4.105.2

package/README.md

@@ -2,7 +2,7 @@
 
 MCP server for [Conduyt CRM](https://conduyt.app) — expose your CRM as AI-accessible tools. Covers the core CRM surface (contacts, deals, pipelines, custom fields, automations, messaging, and more); use `conduyt_api_catalog` to discover the full set of 600+ REST endpoints.
 
-## 378 Tools
+## 383 Tools
 
 ### Discovery
 | Tool | Description |
@@ -91,6 +91,13 @@ MCP server for [Conduyt CRM](https://conduyt.app) — expose your CRM as AI-acce
 | `conduyt_publish_automation` | Push draft actions to live |
 | `conduyt_resolve_names` | Convert tag/pipeline/user names to UUIDs |
 
+### Lead distribution (read-only)
+| Tool | Description |
+|------|-------------|
+| `conduyt_get_distribution_step` | One Distribution step's live table: team, Receiving, tiers, caps, this step's counts, the queue and the next lead (or preview an unsaved table) |
+| `conduyt_list_distribution_steps` | Every workflow step in Distribution mode (Settings > Lead Routing) |
+| `conduyt_list_assignment_reasons` | The assignment reasons, resolved: by deal, contact, step, person, outcome, days |
+
 ### Workflow Sandbox
 | Tool | Description |
 |------|-------------|

package/dist/register-all.js

@@ -49,6 +49,7 @@ import { registerSmartViewTools } from "./tools/smart-views.js";
 import { registerAccountExportTools } from "./tools/account-exports.js";
 import { registerLifecycleTools } from "./tools/lifecycle.js";
 import { registerLeadPoolTools } from "./tools/lead-pool.js";
+import { registerLeadDistributionTools } from "./tools/lead-distribution.js";
 import { registerReplyCaptureTools } from "./tools/reply-capture.js";
 import { registerCallFlowTools } from "./tools/call-flows.js";
 import { registerProjectBlueTools } from "./tools/project-blue.js";
@@ -112,6 +113,7 @@ export function registerAllTools(server, client) {
     registerAccountExportTools(server, client);
     registerLifecycleTools(server, client);
     registerLeadPoolTools(server, client);
+    registerLeadDistributionTools(server, client);
     registerReplyCaptureTools(server, client);
     registerCallFlowTools(server, client);
     registerProjectBlueTools(server, client);

package/dist/tool-annotations.js

@@ -9,6 +9,10 @@ export const TOOL_ANNOTATIONS = {
     conduyt_api_catalog: ro("Get API Catalog"),
     conduyt_check_permissions: ro("Check Permissions"),
     conduyt_search: ro("Search CRM Records"),
+    // (#996 UI) lead distribution reads (the step table, the Settings overview, the reasons); the draft preview POST writes nothing
+    conduyt_get_distribution_step: ro("Get Distribution Step"),
+    conduyt_list_distribution_steps: ro("List Distribution Steps"),
+    conduyt_list_assignment_reasons: ro("List Assignment Reasons"),
     conduyt_mcp_coverage: ro("Get MCP Coverage Matrix"),
     conduyt_list_contacts: ro("List Contacts"),
     conduyt_count_contacts: ro("Count Contacts"),

package/dist/tools/lead-distribution.d.ts

@@ -0,0 +1,28 @@
+import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
+import { ConduytClient } from "../client.js";
+/**
+ * (#996 UI, tri-surface parity) the READ side of lead distribution (the assign_to_user step's "distribution" mode: tiers, caps
+ * per hour / day / week / month, an overflow), the same reads the step editor, Settings > Lead Routing and the assignment
+ * history use. All three write nothing; the table itself is edited through the workflow (conduyt_update_automation, the
+ * step's config) exactly as before.
+ *   conduyt_get_distribution_step     GET /automations/{id}/distribution?node_id= (the step as the runner executes it), or with
+ *                                     `config` POST /automations/{id}/distribution (an unsaved draft table, still read-only)
+ *   conduyt_list_distribution_steps   GET /automations/distribution-steps
+ *   conduyt_list_assignment_reasons   GET /activities/assignment-reasons
+ */
+export declare const ASSIGNMENT_OUTCOMES: readonly ["assigned", "catch_all", "contact_owner", "kept", "pool", "nobody"];
+/** the query string the reasons route reads (repeated user_id / outcome, the rest once) */
+export declare function assignmentReasonsQuery(p: {
+    deal_id?: string;
+    contact_id?: string;
+    automation_id?: string;
+    node_id?: string;
+    user_ids?: string[];
+    outcomes?: string[];
+    activity_ids?: string[];
+    from?: string;
+    to?: string;
+    per_page?: number;
+    cursor?: string;
+}): string;
+export declare function registerLeadDistributionTools(server: McpServer, client: ConduytClient): void;

package/dist/tools/lead-distribution.js

@@ -0,0 +1,62 @@
+import { z } from "zod";
+import { formatResult } from "../client.js";
+/**
+ * (#996 UI, tri-surface parity) the READ side of lead distribution (the assign_to_user step's "distribution" mode: tiers, caps
+ * per hour / day / week / month, an overflow), the same reads the step editor, Settings > Lead Routing and the assignment
+ * history use. All three write nothing; the table itself is edited through the workflow (conduyt_update_automation, the
+ * step's config) exactly as before.
+ *   conduyt_get_distribution_step     GET /automations/{id}/distribution?node_id= (the step as the runner executes it), or with
+ *                                     `config` POST /automations/{id}/distribution (an unsaved draft table, still read-only)
+ *   conduyt_list_distribution_steps   GET /automations/distribution-steps
+ *   conduyt_list_assignment_reasons   GET /activities/assignment-reasons
+ */
+export const ASSIGNMENT_OUTCOMES = ["assigned", "catch_all", "contact_owner", "kept", "pool", "nobody"];
+const day = z.string().regex(/^\d{4}-\d{2}-\d{2}$/, "a calendar day, YYYY-MM-DD");
+/** the query string the reasons route reads (repeated user_id / outcome, the rest once) */
+export function assignmentReasonsQuery(p) {
+    const q = new URLSearchParams();
+    for (const k of ["deal_id", "contact_id", "automation_id", "node_id", "from", "to", "cursor"])
+        if (p[k])
+            q.set(k, p[k]);
+    for (const a of [...new Set(p.activity_ids ?? [])])
+        q.append("activity_id", a);
+    for (const u of [...new Set(p.user_ids ?? [])])
+        q.append("user_id", u);
+    for (const o of [...new Set(p.outcomes ?? [])])
+        q.append("outcome", o);
+    if (p.per_page !== undefined)
+        q.set("per_page", String(p.per_page));
+    return q.toString();
+}
+export function registerLeadDistributionTools(server, client) {
+    server.tool("conduyt_get_distribution_step", "Read ONE Distribution step's live table (assign_to_user with mode \"distribution\"), read-only: the team (a member group's active members, or the listed people, flagged when someone left the account), each person's Receiving status, tier (highest / high / low / lowest, absent = high), own caps (a period present overrides the team default; null = own unlimited; absent = inherits) and effective caps per hour / day / week / month, THIS step's assignment counts for the current periods (the account timezone, the week from Monday), the ordered queue (`order` 1 = next; `skipped` = away, not_on_account or the period whose cap is reached; `zeroCap` = a cap of 0, never gets leads), the next lead from the workflow dry run's own plan (`next.reason` is the exact reason line the step would write; `next.dryRun` the dry run's line), `problems` in plain English (a person who left, the catch-all removed). Without `config` it reads the step as the runner executes it (the published graph, else the draft; 404 when the workflow has no Distribution step with that node_id; 422 when the stored table does not read). With `config` (the step's whole assign_to_user config, mode \"distribution\") it previews that unsaved table instead and writes nothing (400 when it does not read). Permission automations.view; a deal-less API key gets 404 (every Distribution workflow assigns deals).", {
+        automation_id: z.string().uuid().describe("The workflow (automation) id"),
+        node_id: z.string().min(1).max(200).describe("The step's node id in the graph (a linear workflow's action id, else #<index>)"),
+        config: z.record(z.unknown()).optional().describe("Optional: an unsaved assign_to_user config to preview (mode \"distribution\", groupId OR userIds, tiers, caps, overflow, applyTo deal | both)"),
+    }, async ({ automation_id, node_id, config }) => formatResult(config
+        ? await client.post(`/api/v1/automations/${automation_id}/distribution`, { nodeId: node_id, config })
+        : await client.get(`/api/v1/automations/${automation_id}/distribution?node_id=${encodeURIComponent(node_id)}`)));
+    server.tool("conduyt_list_distribution_steps", "Settings > Lead Routing, \"Distribution in workflows\" (read-only): every workflow step running the assign_to_user Distribution mode, from the graph the runner executes, with its team (group name, or the count of picked people), receivingNow / total, who gets the next lead (`next`, the dry run's plan), the overflow (pool, none, or the catch-all person), assignedToday (this step's assignments since the account's midnight) and `problem` when the stored table would fail at run time. An aggregate: at most 200 steps (meta.max_steps) from at most 200 workflows (meta.max_workflows), newest changed first; meta.truncated says more exist (either cap). This is NOT the older account-wide Lead Routing Rules router (/api/v1/lead-routing). Permission automations.view; a deal-less API key is served an empty list.", {}, async () => formatResult(await client.get("/api/v1/automations/distribution-steps")));
+    server.tool("conduyt_list_assignment_reasons", "The lead distribution reasons (activities of type assignment_reason), newest first, read-only, each resolved: `reason` (the exact line, e.g. \"Assigned to Heather Henson: tier highest, 3 of 10 today\" or \"Sent to the pool: everyone was off or at cap\"), `outcome` (assigned, catch_all, contact_owner, kept, pool, nobody), the person, the deal and contact, the workflow and step (`automation`, `nodeId`, `stepLabel`), tier and today's count, `skipped` (who was passed over: a cap period, or away = not receiving leads) and `ledgerId` (the assignment_ledger row the assignment counted toward the caps; null for the overflow outcomes that assign nobody). Every reason sits on BOTH the deal and its contact, so contact_id gives the contact's whole routing history across its deals. Filters: deal_id, contact_id, automation_id + node_id (one step's history; node_id needs automation_id), user_ids (up to 50 distinct), outcomes, activity_ids (up to 100 distinct: the reasons of activities you already hold), from / to (days in the account timezone). A kept outcome's person is the owner the card stayed with. per_page 1-100 (default 25); pass meta.nextCursor as cursor for the next page. Permission activities.view, the caller's visible contacts and deals only.", {
+        deal_id: z.string().uuid().optional(),
+        contact_id: z.string().uuid().optional(),
+        automation_id: z.string().uuid().optional().describe("The workflow; with node_id, one step's history"),
+        node_id: z.string().min(1).max(200).optional().describe("The step's node id (needs automation_id)"),
+        // (r2, Codex r1 P3) repeats are removed BEFORE the caps, as the route does (50 people, 100 activities)
+        user_ids: z.array(z.string().uuid()).optional().describe("Only reasons that assigned (or kept) one of these people; up to 50 distinct"),
+        outcomes: z.array(z.enum(ASSIGNMENT_OUTCOMES)).optional(),
+        activity_ids: z.array(z.string().uuid()).optional().describe("The reasons of these assignment_reason activities (a feed resolving the rows it loaded); up to 100 distinct"),
+        from: day.optional().describe("First day, YYYY-MM-DD, in the account timezone"),
+        to: day.optional().describe("Last day, YYYY-MM-DD, in the account timezone (inclusive)"),
+        per_page: z.number().int().min(1).max(100).optional(),
+        cursor: z.string().min(1).optional().describe("meta.nextCursor of the previous page"),
+    }, async (p) => {
+        if (p.node_id && !p.automation_id)
+            throw new Error("node_id needs automation_id (a step belongs to one workflow)");
+        if (new Set(p.user_ids ?? []).size > 50)
+            throw new Error("user_ids takes at most 50 distinct people");
+        if (new Set(p.activity_ids ?? []).size > 100)
+            throw new Error("activity_ids takes at most 100 distinct activities");
+        return formatResult(await client.get(`/api/v1/activities/assignment-reasons?${assignmentReasonsQuery(p)}`));
+    });
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "conduyt-mcp",
-  "version": "4.105.1",
+  "version": "4.105.2",
   "mcpName": "com.conduyt/mcp",
   "description": "MCP server for Conduyt CRM — expose CRM operations as AI-accessible tools",
   "type": "module",

package/scripts/coverage-matrix.json

@@ -1,10 +1,10 @@
 {
-  "generatedAt": "2026-11-05T07:30:55.402Z",
-  "toolCount": 380,
-  "totalEndpoints": 1143,
+  "generatedAt": "2026-11-05T14:27:30.253Z",
+  "toolCount": 383,
+  "totalEndpoints": 1150,
   "counts": {
-    "covered": 333,
-    "excluded": 351,
+    "covered": 337,
+    "excluded": 354,
     "planned": 459,
     "uncategorized": 0
   },
@@ -305,6 +305,12 @@
       "status": "planned",
       "reason": "activity detail reads beyond the log tools"
     },
+    "GET /api/v1/activities/assignment-reasons": {
+      "status": "covered",
+      "tools": [
+        "conduyt_list_assignment_reasons"
+      ]
+    },
     "GET /api/v1/activity/export.csv": {
       "status": "covered",
       "tools": [
@@ -355,6 +361,14 @@
       "status": "excluded",
       "reason": "super-admin platform operations (Conduyt staff only)"
     },
+    "GET /api/v1/admin/external-deletions": {
+      "status": "excluded",
+      "reason": "super-admin platform operations (Conduyt staff only)"
+    },
+    "POST /api/v1/admin/external-deletions/:id/replay": {
+      "status": "excluded",
+      "reason": "super-admin platform operations (Conduyt staff only)"
+    },
     "POST /api/v1/admin/impersonate": {
       "status": "excluded",
       "reason": "super-admin platform operations (Conduyt staff only)"
@@ -701,6 +715,18 @@
       "status": "planned",
       "reason": "automation subroutes beyond the workflow-builder tools (step-logs detail, node ops)"
     },
+    "GET /api/v1/automations/:id/distribution": {
+      "status": "covered",
+      "tools": [
+        "conduyt_get_distribution_step"
+      ]
+    },
+    "POST /api/v1/automations/:id/distribution": {
+      "status": "covered",
+      "tools": [
+        "conduyt_get_distribution_step"
+      ]
+    },
     "POST /api/v1/automations/:id/dry-run": {
       "status": "covered",
       "tools": [
@@ -750,6 +776,12 @@
       "status": "planned",
       "reason": "automation subroutes beyond the workflow-builder tools (step-logs detail, node ops)"
     },
+    "GET /api/v1/automations/distribution-steps": {
+      "status": "covered",
+      "tools": [
+        "conduyt_list_distribution_steps"
+      ]
+    },
     "GET /api/v1/automations/events": {
       "status": "planned",
       "reason": "automation subroutes beyond the workflow-builder tools (step-logs detail, node ops)"
@@ -2068,6 +2100,10 @@
       "status": "excluded",
       "reason": "CRON_SECRET-gated infrastructure jobs; never key-callable"
     },
+    "GET /api/v1/cron/reap-expired-sessions": {
+      "status": "excluded",
+      "reason": "CRON_SECRET-gated infrastructure jobs; never key-callable"
+    },
     "GET /api/v1/cron/reap-orphaned-executions": {
       "status": "excluded",
       "reason": "CRON_SECRET-gated infrastructure jobs; never key-callable"