@sellable/mcp 0.1.55 → 0.1.57

package/dist/tools/leads.d.ts

@@ -314,6 +314,7 @@ export declare const leadToolDefinitions: ({
             filters: {
                 type: string;
                 description: string;
+                items?: undefined;
                 properties?: undefined;
             };
             companyFilters: {
@@ -473,6 +474,59 @@ export declare const leadToolDefinitions: ({
             filters: {
                 type: string;
                 description: string;
+                items: {
+                    type: string;
+                    properties: {
+                        type: {
+                            type: string;
+                        };
+                        values: {
+                            type: string;
+                            items: {
+                                type: string;
+                                properties: {
+                                    id: {
+                                        type: string;
+                                    };
+                                    text: {
+                                        type: string;
+                                    };
+                                    selectionType: {
+                                        type: string;
+                                        enum: string[];
+                                    };
+                                    parent: {
+                                        type: string;
+                                        properties: {
+                                            id: {
+                                                type: string;
+                                            };
+                                        };
+                                    };
+                                };
+                                required: string[];
+                            };
+                        };
+                        rangeValue: {
+                            type: string;
+                            properties: {
+                                min: {
+                                    type: string;
+                                };
+                                max: {
+                                    type: string;
+                                };
+                            };
+                            required: string[];
+                        };
+                        selectedSubFilter: {
+                            anyOf: {
+                                type: string;
+                            }[];
+                        };
+                    };
+                    required: string[];
+                };
                 properties?: undefined;
             };
             keywords: {
@@ -1347,6 +1401,7 @@ export declare const leadToolDefinitions: ({
                         };
                     };
                 };
+                items?: undefined;
             };
             page: {
                 type: string;
@@ -2015,6 +2070,7 @@ export declare const leadToolDefinitions: ({
 })[];
 export declare function searchApollo(input: ApolloSearchInput): Promise<unknown>;
 export declare function searchSalesNav(input: SalesNavSearchInput): Promise<unknown>;
+export declare function normalizeSalesNavSearchInput(input: SalesNavSearchInput): SalesNavSearchInput;
 export declare function searchProspeo(input: ProspeoSearchInput): Promise<any>;
 export declare function loadCsvDomains(input: LoadCsvDomainsInput): Promise<{
     ok: boolean;

package/dist/tools/leads.js

@@ -32,6 +32,46 @@ const prospeoFilterValueSchema = {
         exclude: { type: "array", items: { type: "string" } },
     },
 };
+const salesNavFilterValueSchema = {
+    type: "object",
+    properties: {
+        id: { type: "string" },
+        text: { type: "string" },
+        selectionType: {
+            type: "string",
+            enum: ["INCLUDED", "EXCLUDED"],
+        },
+        parent: {
+            type: "object",
+            properties: {
+                id: { type: "string" },
+            },
+        },
+    },
+    required: ["id", "text", "selectionType"],
+};
+const salesNavFilterSchema = {
+    type: "object",
+    properties: {
+        type: { type: "string" },
+        values: {
+            type: "array",
+            items: salesNavFilterValueSchema,
+        },
+        rangeValue: {
+            type: "object",
+            properties: {
+                min: { type: "number" },
+                max: { type: "number" },
+            },
+            required: ["min", "max"],
+        },
+        selectedSubFilter: {
+            anyOf: [{ type: "string" }, { type: "number" }],
+        },
+    },
+    required: ["type"],
+};
 const prospeoRangeFilterSchema = {
     type: "object",
     description: "Numeric range filter (min/max)",
@@ -540,7 +580,8 @@ export const leadToolDefinitions = [
             properties: {
                 filters: {
                     type: "array",
-                    description: "Sales Nav filter array",
+                    description: "Sales Nav filter array. Pass filter objects, not JSON strings.",
+                    items: salesNavFilterSchema,
                 },
                 keywords: {
                     type: "string",
@@ -1312,7 +1353,30 @@ export async function searchSalesNav(input) {
         campaignOfferId: input?.campaignOfferId,
     });
     const api = getApi();
-    return api.post(`/api/v3/sales-nav/search`, input);
+    return api.post(`/api/v3/sales-nav/search`, normalizeSalesNavSearchInput(input));
+}
+export function normalizeSalesNavSearchInput(input) {
+    return {
+        ...input,
+        filters: normalizeSalesNavFilters(input.filters),
+    };
+}
+function normalizeSalesNavFilters(filters) {
+    return filters.map((filter, index) => {
+        if (typeof filter !== "string") {
+            return filter;
+        }
+        try {
+            const parsed = JSON.parse(filter);
+            if (!parsed || typeof parsed !== "object" || Array.isArray(parsed)) {
+                throw new Error("not an object");
+            }
+            return parsed;
+        }
+        catch {
+            throw new Error(`Invalid Sales Nav filter at index ${index}. Pass filter objects, not JSON strings.`);
+        }
+    });
 }
 export async function searchProspeo(input) {
     if (input?.campaignOfferId) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.55",
+  "version": "0.1.57",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

package/skills/create-campaign-v2/SKILL.md

@@ -423,7 +423,7 @@ should test for this campaign. Those can run in parallel and usually take
   batching is available, batch independent tool reads/lookups only. If real
   parallel execution is not available or not allowed, run the same DAG
   sequentially and use honest copy: `I’ll tighten the filter first, then draft
-  the message from the same sample.` Never say `kicking off two workstreams`,
+the message from the same sample.` Never say `kicking off two workstreams`,
   `in parallel`, or `background` unless parallel branches were actually
   launched.
 - Never run a downstream stage until the active `flow.v2.json` step's
@@ -574,14 +574,25 @@ Required behavior:
   - Branch C: Prospeo / domains only when the campaign has a domain/account
     path or the user supplied domains. Estimate email/contact scale and call out
     weaker LinkedIn activity.
-  If the host cannot run these branches in parallel, run them sequentially and
-  do not claim they ran in parallel. If only one source angle is credible, say
-  that and run the best primary source plus one cheap fallback/quality check
-  when available. For Signals-first campaigns, search multiple Signals keyword
-  lanes and fetch top-post engagers in parallel when tool batching allows it.
-  For Sales Nav-first or Prospeo/account-first campaigns, run multiple preview
-  lanes for that provider in parallel and use Signals only as a warmth/quality
-  check when relevant
+    If the host cannot run these branches in parallel, run them sequentially and
+    do not claim they ran in parallel. If only one source angle is credible, say
+    that and run the best primary source plus one cheap fallback/quality check
+    when available. For Signals-first campaigns, search multiple Signals keyword
+    lanes and fetch top-post engagers in parallel when tool batching allows it.
+    For Sales Nav-first or Prospeo/account-first campaigns, run multiple preview
+    lanes for that provider in parallel and use Signals only as a warmth/quality
+    check when relevant
+- after every Sales Nav preview, validate that filters actually applied before
+  using the lane in `lead-review.md`: `searchUrl` should include filters, the
+  first page should match the intended roles/companies, and the result count
+  should be plausible. If Sales Nav returns a giant unfiltered pool, drops the
+  filters, or errors after one clean retry, call it out as a provider/tool
+  issue and do not recommend Sales Nav.
+- when the brief or user names target roles, Sales Nav must preserve those role
+  names through `CURRENT_TITLE` lookups. Do not use broad seniority as a
+  substitute for role intent. VP Sales, VP Revenue, CRO, Head of Growth, and
+  similar targets should stay visible in the filter recipe and the source
+  explanation.
 - for Signals-first campaigns, raw post search volume is only inventory, not
   lead volume. `492 post results` means matching LinkedIn posts found across
   keyword lanes; it does not mean 492 prospects. The source decision must name

package/skills/create-campaign-v2/references/watch-link-handoff.md

@@ -40,7 +40,7 @@ must contain:
 - a plain confirmation that the campaign was created and the approved brief was
   saved
 - a one-line orientation sentence: `Open this to watch lead sourcing, rubric
-  scoring, and messaging populate live.`
+scoring, and messaging populate live.`
 - the `watchUrl` captured from the `create_campaign` response
 
 Example skeleton:

package/skills/find-leads/SKILL.md

@@ -275,6 +275,10 @@ Use first when LinkedIn activity plus tighter role / company filters matter.
 
 - Always call `lookup_sales_nav_filter` before dynamic filters.
 - Start with a broad-but-reasonable baseline: company size + core roles + core industries.
+- If the campaign gives specific target role names, preserve them with
+  `CURRENT_TITLE` lookups. Seniority filters are supporting constraints, not a
+  substitute for target roles. Example: VP Sales / VP Revenue / Head of Growth
+  should use title filters, not only `SENIORITY_LEVEL: Vice President`.
 - For reply-likelihood-first outbound, Sales Nav is the second choice after Signals: use it when the TAM is not active enough on LinkedIn, when Signals cannot sustain enough good fits, or when the targeting thesis depends on tighter role/company control than Signals can provide.
 - For InMail or LinkedIn-send motions, establish the baseline TAM first, then test a `POSTED_ON_LINKEDIN` slice when the pool can still sustain a campaign.
 - Treat recent posters as a preferred first-send slice, not just a nice-to-have proxy. When the recently-posted slice still yields enough projected good fits, prefer it because reply / acceptance performance is usually materially better than the cold full-TAM pool.
@@ -293,6 +297,13 @@ Use first when LinkedIn activity plus tighter role / company filters matter.
 - When you fall back from the recently-posted slice, say clearly that the posted filter was tested, explain why it was dropped, and keep the best non-posted lane as the source of truth.
 - Use `RECENTLY_CHANGED_JOBS` when job-change activity is part of the targeting thesis.
 - If quality is poor, tighten the lane with role, industry, seniority, geography, or activity filters.
+- After each Sales Nav preview, sanity-check the result before using it in the
+  decision: the returned `searchUrl` should include filters, the first page
+  should visibly match the intended roles and companies, and the count should
+  be plausible. If filters did not apply, the search errors, or the total looks
+  obviously unfiltered, retry once with clean filter objects. If it still fails,
+  mark Sales Nav as a provider/tool issue and do not include it as a winning
+  source.
 - If quality is good but scale is too small, widen the lane by adding/removing roles, expanding industries, widening headcount bands, or relaxing activity constraints.
 - Use as many smart refinement steps as needed within the remaining probe budget instead of returning the first under-scaled recipe.
 - If the lane is meant to support scalable outbound, do not stop at a merely borderline workable result when obvious expansion steps remain.

package/skills/providers/sales-nav.md

@@ -50,6 +50,13 @@ Example search name: "Active CXOs at 201-500 companies"
 2. LOOKUP DYNAMIC FILTERS - Get IDs for geography, industry, titles, etc.
    Before using ANY dynamic filter, you MUST call lookup_sales_nav_filter.
 
+   When the campaign names target roles, use CURRENT_TITLE lookups for those
+   role names. Seniority alone is not enough. For example, "VP Sales / VP
+   Revenue / Head of Growth" should become title filters plus seniority, not
+   only `SENIORITY_LEVEL: Vice President`, because generic VP seniority pulls
+   business development, partnerships, marketing, operations, and other noisy
+   roles.
+
    Dynamic filters (REQUIRE lookup):
 
    - REGION: "United States", "California", "London"
@@ -114,6 +121,7 @@ NEVER do these:
 
 <filter_format>
 ALL filter values MUST include id, text, and selectionType.
+Pass `filters` as an array of objects. Do not stringify filters as JSON.
 
 CORRECT:
 
@@ -145,6 +153,21 @@ WRONG:
 
 </filter_format>
 
+<result_validation>
+After every `search_sales_nav` call, sanity-check the returned result before
+using it in a source decision:
+
+- `searchUrl` should include a `filters:List(...)` query, not only `keywords`.
+- The sample rows should visibly match the intended role/company lane.
+- The total result count should be plausible for the filters used.
+
+If filters did not apply, the search errors, or the result count is obviously
+unfiltered, do not present Sales Nav as a valid lane. Retry once with clean
+filter objects if the issue was formatting. If it still fails, say plainly:
+"Sales Nav did not apply the filters cleanly, so I’m not using it for this
+decision." Then continue with Signals or Prospeo if they have usable evidence.
+</result_validation>
+
 <static_filters>
 These filters need NO lookup - use these IDs directly: