@leadbay/mcp 0.39.1 → 0.39.2

package/dist/bin.js

@@ -6731,7 +6731,7 @@ prose paragraph. Full recipe below.
 
 Build a single-call mixed-mode itinerary for a field sales tour. Combines \`leadbay_pull_followups\` (Monitor leads in the city \u2014 known accounts) with \`leadbay_pull_leads\` (Discover wishlist \u2014 new prospects, then client-side filtered by city) so the agent can answer the canonical #3630 US1 ask: *"I'm visiting Limoges in 4 days \u2014 propose 3 customers + 3 qualified prospects + 3 new high-potential discoveries."*
 
-**Geo resolution** is identical to \`leadbay_followups_map\`: pass \`city\` (any level from state down to neighborhood \u2014 state, *r\xE9gion*, county, city \u2014 the \`/geo/search\` resolver picks the best match), or a pre-resolved \`city_id\`. Ambiguous matches surface as \`status: "ambiguous_locations"\` + \`location_ambiguities[]\`; pick an id and re-call with \`city_id\`.
+**Geo resolution** is identical to \`leadbay_followups_map\`: pass \`city\` (any level from state down to neighborhood \u2014 state, *r\xE9gion*, county, city \u2014 the \`/geo/search\` resolver picks the best match), or a pre-resolved \`city_id\`. Ambiguous matches surface as \`status: "ambiguous_locations"\` + \`location_ambiguities[]\`; re-call with \`city_id\` set to the id you pick AND \`city\` set to that candidate's \`name\`. Both are needed: the id scopes the follow-ups, the name scopes the Discover leads, and with \`city_id\` alone \`discover_leads\` comes back empty.
 
 **One workspace = one country \u2014 a country name is NEVER a location filter.** The admin-area index holds no country nodes, so \`"France"\` matches the *commune of Francs* and \`"United States"\` matches *Statesboro*: the call is silently fenced to one village and every conclusion from it is wrong. City AND country named? Keep the city, drop the country.
 
@@ -6761,7 +6761,7 @@ not an itinerary. So for ANY country-level \`city\` \u2014 this workspace's own
 visiting and re-call with that. \`status: "country_level_location"\` carries the
 same instruction in its \`hint\`.
 
-**Counts**: \`followups_count\` (default 6 \u2014 generous so the agent can split into "customers + qualified" client-side) and \`discover_count\` (default 6 after client-side geo filter). The composite over-pulls Discover (30 raw) because the wishlist endpoint has no server-side geo filter \u2014 it then filters by \`location.city/state/country/full\` substring match against the requested city. The \`discover_filter_note\` string in the response tells the agent the match ratio so it can be honest about coverage ("matched 3/30 by city/state" vs. "matched 12/30").
+**Counts**: \`followups_count\` (default 6 \u2014 generous so the agent can split into "customers + qualified" client-side) and \`discover_count\` (default 6 after client-side geo filter). The composite over-pulls Discover (30 raw) because the wishlist endpoint has no server-side geo filter \u2014 it then keeps the leads whose own \`location.city\` names the requested city, and falls back to \`location.state\` only when no city matched (which is what a regional ask like "Texas" or "\xCEle-de-France" looks like). \`location.country\` is never consulted. \`discover_filter_note\` reports the ratio and which field carried it, so the agent can be honest about coverage. **When it says no Discover lead is in the city, say that** \u2014 return the Monitor half and offer \`leadbay_find_new_leads\` for that city. Never fill the gap with leads from elsewhere.
 
 **What \`tour_plan\` does NOT do**: it doesn't persist the tour as a campaign artifact. To do that \u2014 create a "Limoges Tour \u2013 May 24" campaign and attach the selected accounts \u2014 chain into \`leadbay_create_campaign({lead_ids: [...selected_ids], name: 'Limoges Tour \u2013 <date>'})\` after the user picks. See the \`leadbay_plan_tour_in_city\` prompt for the full end-to-end orchestrator.
 
@@ -14962,13 +14962,33 @@ var init_followups_map = __esm({
 });
 
 // ../core/dist/composite/tour-plan.js
-function cityMatches(lead, cityHint) {
-  if (!cityHint)
-    return true;
-  const hint = cityHint.toLowerCase();
-  const loc = lead?.location ?? {};
-  const haystacks = [loc.city, loc.state, loc.country, loc.full].filter((v) => typeof v === "string").map((v) => v.toLowerCase());
-  return haystacks.some((h) => h.includes(hint) || hint.includes(h));
+function normalizeGeo(value) {
+  return value.normalize("NFD").replace(/[\u0300-\u036f]/g, "").toLowerCase().replace(/[^a-z0-9]+/g, " ").trim();
+}
+function townName(value) {
+  return normalizeGeo(value).replace(ADMIN_PREFIX, "");
+}
+function cityHintCore(cityHint) {
+  const head = cityHint.split(",")[0] ?? "";
+  const expanded = expandAlias(head);
+  return { name: townName(expanded), isCity: expanded !== head };
+}
+function stateFieldOf(lead) {
+  const state = lead?.location?.state;
+  return typeof state === "string" ? normalizeGeo(state) : "";
+}
+function filterDiscoverByCity(leads, cityHint) {
+  const hint = cityHint ? cityHintCore(cityHint) : { name: "", isCity: false };
+  if (!hint.name)
+    return { leads, matchedOn: null };
+  const cityOf = (l) => typeof l?.location?.city === "string" ? townName(l.location.city) : "";
+  const byCity = leads.filter((l) => cityOf(l) === hint.name);
+  if (byCity.length > 0)
+    return { leads: byCity, matchedOn: "city" };
+  if (hint.isCity)
+    return { leads: [], matchedOn: "city" };
+  const byState = leads.filter((l) => stateFieldOf(l) === hint.name);
+  return { leads: byState, matchedOn: "state" };
 }
 function toMapLocation(lead, mode) {
   const pos = lead?.location?.pos;
@@ -15018,7 +15038,7 @@ function buildMap(monitorLeads, discoverLeads2) {
     }
   };
 }
-var DEFAULT_FOLLOWUPS_COUNT, DEFAULT_DISCOVER_COUNT, DISCOVER_OVER_PULL, tourPlan;
+var DEFAULT_FOLLOWUPS_COUNT, DEFAULT_DISCOVER_COUNT, DISCOVER_OVER_PULL, ADMIN_PREFIX, tourPlan;
 var init_tour_plan = __esm({
   "../core/dist/composite/tour-plan.js"() {
     "use strict";
@@ -15026,10 +15046,12 @@ var init_tour_plan = __esm({
     init_pull_leads();
     init_interactions();
     init_country_guard();
+    init_geo_helpers();
     init_tool_descriptions_generated();
     DEFAULT_FOLLOWUPS_COUNT = 6;
     DEFAULT_DISCOVER_COUNT = 6;
     DISCOVER_OVER_PULL = 30;
+    ADMIN_PREFIX = /^(?:city|town|village|borough|township|municipality) of /;
     tourPlan = {
       name: "leadbay_tour_plan",
       annotations: {
@@ -15049,7 +15071,7 @@ var init_tour_plan = __esm({
           },
           city_id: {
             type: "string",
-            description: "Pre-resolved admin_area id (numeric string). Bypasses the resolver."
+            description: "Pre-resolved admin_area id (numeric string). Bypasses the resolver. Pass `city` alongside it with the NAME of the area you picked: the id scopes the Monitor half, and the name is the only thing that can scope the Discover half, which has no server-side geo filter. With `city_id` alone, `discover_leads` comes back empty."
           },
           followups_count: {
             type: "number",
@@ -15156,7 +15178,13 @@ var init_tour_plan = __esm({
         const discoverCount = params.discover_count ?? DEFAULT_DISCOVER_COUNT;
         const [followupsResult, leadsResult] = await Promise.allSettled([
           pullFollowups.execute(client, {
-            city: params.city,
+            // A pre-resolved id bypasses the resolver, which is what its own
+            // schema promises. Forwarding the free text alongside it sends the
+            // name back through /geo/search, and the name is the thing that was
+            // ambiguous — so an agent recovering from `ambiguous_locations` by
+            // picking an id would be handed the same ambiguity again. Here the
+            // free text stays behind and scopes the Discover half instead.
+            city: params.city_id ? void 0 : params.city,
             city_id: params.city_id,
             count: followupsCount
           }, ctx),
@@ -15170,7 +15198,7 @@ var init_tour_plan = __esm({
               location_ambiguities: r.location_ambiguities,
               monitor_leads: [],
               discover_leads: [],
-              discover_filter_note: "City was ambiguous; pick an id and re-call to proceed.",
+              discover_filter_note: "City was ambiguous; re-call with `city_id` set to the id you pick AND `city` set to that candidate's `name`. The id scopes the follow-ups; the name is what scopes the Discover leads.",
               map_locations: [],
               map_summary: {
                 total_leads: 0,
@@ -15194,13 +15222,27 @@ var init_tour_plan = __esm({
         if (leadsResult.status === "rejected") {
           ctx?.logger?.warn?.(`tour_plan: pull_leads failed: ${leadsResult.reason?.message ?? leadsResult.reason}`);
         }
-        const filtered = rawDiscover.filter((l) => cityMatches(l, params.city));
+        const cityName = params.city && !/^\d+$/.test(params.city.trim()) ? params.city : void 0;
+        const knownId = params.city_id ?? (cityName ? void 0 : params.city);
+        const idOnly = Boolean(knownId) && !cityName;
+        const { leads: filtered, matchedOn } = idOnly ? { leads: [], matchedOn: null } : filterDiscoverByCity(rawDiscover, cityName);
         const discoverLeads2 = filtered.slice(0, discoverCount);
         const pulledLensId = leadsResult.status === "fulfilled" ? leadsResult.value?.lens?.id : null;
         if (pulledLensId != null) {
           reportLeadInteractions(client, pulledLensId, discoverLeads2.map((l) => l.id), ["LEAD_SEEN"], ctx?.logger);
         }
-        const filterNote = params.city ? `Matched ${filtered.length}/${rawDiscover.length} Discover leads to '${params.city}'; returning top ${discoverLeads2.length}.` : `No city filter applied; returning top ${discoverLeads2.length} Discover leads.`;
+        let filterNote;
+        if (idOnly) {
+          filterNote = `Discover leads need the NAME of the place, and this call passed an area id (${knownId}) and no name. Re-call with \`city\` set to the name of that area, keeping \`city_id\` so the Monitor half stays on the area you picked. The follow-ups below are already scoped to it.`;
+        } else if (!cityName) {
+          filterNote = `No city filter applied; returning top ${discoverLeads2.length} Discover leads.`;
+        } else if (matchedOn === null) {
+          filterNote = `No usable city filter in '${params.city}'; returning top ${discoverLeads2.length} Discover leads.`;
+        } else if (filtered.length === 0) {
+          filterNote = `No Discover lead in the active lens is in '${params.city}' (checked ${rawDiscover.length} candidates by city, then by state/region). Say so; do NOT present leads from elsewhere as if they were in '${params.city}'.`;
+        } else {
+          filterNote = `Matched ${filtered.length}/${rawDiscover.length} Discover leads to '${params.city}' by ${matchedOn === "city" ? "city" : "state/region"}; returning top ${discoverLeads2.length}.`;
+        }
         return {
           city: params.city ?? null,
           city_id: params.city_id ?? null,
@@ -31336,7 +31378,7 @@ var OAUTH_BASE_URLS = {
     fr: "https://staging.api.leadbay.app"
   }
 };
-var VERSION = "0.39.1";
+var VERSION = "0.39.2";
 var HELP = `
 leadbay-mcp ${VERSION} \u2014 Leadbay Model Context Protocol server
 

package/dist/http-server.js

@@ -9679,7 +9679,7 @@ prose paragraph. Full recipe below.
 
 Build a single-call mixed-mode itinerary for a field sales tour. Combines \`leadbay_pull_followups\` (Monitor leads in the city \u2014 known accounts) with \`leadbay_pull_leads\` (Discover wishlist \u2014 new prospects, then client-side filtered by city) so the agent can answer the canonical #3630 US1 ask: *"I'm visiting Limoges in 4 days \u2014 propose 3 customers + 3 qualified prospects + 3 new high-potential discoveries."*
 
-**Geo resolution** is identical to \`leadbay_followups_map\`: pass \`city\` (any level from state down to neighborhood \u2014 state, *r\xE9gion*, county, city \u2014 the \`/geo/search\` resolver picks the best match), or a pre-resolved \`city_id\`. Ambiguous matches surface as \`status: "ambiguous_locations"\` + \`location_ambiguities[]\`; pick an id and re-call with \`city_id\`.
+**Geo resolution** is identical to \`leadbay_followups_map\`: pass \`city\` (any level from state down to neighborhood \u2014 state, *r\xE9gion*, county, city \u2014 the \`/geo/search\` resolver picks the best match), or a pre-resolved \`city_id\`. Ambiguous matches surface as \`status: "ambiguous_locations"\` + \`location_ambiguities[]\`; re-call with \`city_id\` set to the id you pick AND \`city\` set to that candidate's \`name\`. Both are needed: the id scopes the follow-ups, the name scopes the Discover leads, and with \`city_id\` alone \`discover_leads\` comes back empty.
 
 **One workspace = one country \u2014 a country name is NEVER a location filter.** The admin-area index holds no country nodes, so \`"France"\` matches the *commune of Francs* and \`"United States"\` matches *Statesboro*: the call is silently fenced to one village and every conclusion from it is wrong. City AND country named? Keep the city, drop the country.
 
@@ -9709,7 +9709,7 @@ not an itinerary. So for ANY country-level \`city\` \u2014 this workspace's own
 visiting and re-call with that. \`status: "country_level_location"\` carries the
 same instruction in its \`hint\`.
 
-**Counts**: \`followups_count\` (default 6 \u2014 generous so the agent can split into "customers + qualified" client-side) and \`discover_count\` (default 6 after client-side geo filter). The composite over-pulls Discover (30 raw) because the wishlist endpoint has no server-side geo filter \u2014 it then filters by \`location.city/state/country/full\` substring match against the requested city. The \`discover_filter_note\` string in the response tells the agent the match ratio so it can be honest about coverage ("matched 3/30 by city/state" vs. "matched 12/30").
+**Counts**: \`followups_count\` (default 6 \u2014 generous so the agent can split into "customers + qualified" client-side) and \`discover_count\` (default 6 after client-side geo filter). The composite over-pulls Discover (30 raw) because the wishlist endpoint has no server-side geo filter \u2014 it then keeps the leads whose own \`location.city\` names the requested city, and falls back to \`location.state\` only when no city matched (which is what a regional ask like "Texas" or "\xCEle-de-France" looks like). \`location.country\` is never consulted. \`discover_filter_note\` reports the ratio and which field carried it, so the agent can be honest about coverage. **When it says no Discover lead is in the city, say that** \u2014 return the Monitor half and offer \`leadbay_find_new_leads\` for that city. Never fill the gap with leads from elsewhere.
 
 **What \`tour_plan\` does NOT do**: it doesn't persist the tour as a campaign artifact. To do that \u2014 create a "Limoges Tour \u2013 May 24" campaign and attach the selected accounts \u2014 chain into \`leadbay_create_campaign({lead_ids: [...selected_ids], name: 'Limoges Tour \u2013 <date>'})\` after the user picks. See the \`leadbay_plan_tour_in_city\` prompt for the full end-to-end orchestrator.
 
@@ -17373,13 +17373,34 @@ var followupsMap = {
 var DEFAULT_FOLLOWUPS_COUNT = 6;
 var DEFAULT_DISCOVER_COUNT = 6;
 var DISCOVER_OVER_PULL = 30;
-function cityMatches(lead, cityHint) {
-  if (!cityHint)
-    return true;
-  const hint = cityHint.toLowerCase();
-  const loc = lead?.location ?? {};
-  const haystacks = [loc.city, loc.state, loc.country, loc.full].filter((v) => typeof v === "string").map((v) => v.toLowerCase());
-  return haystacks.some((h) => h.includes(hint) || hint.includes(h));
+function normalizeGeo(value) {
+  return value.normalize("NFD").replace(/[\u0300-\u036f]/g, "").toLowerCase().replace(/[^a-z0-9]+/g, " ").trim();
+}
+var ADMIN_PREFIX = /^(?:city|town|village|borough|township|municipality) of /;
+function townName(value) {
+  return normalizeGeo(value).replace(ADMIN_PREFIX, "");
+}
+function cityHintCore(cityHint) {
+  const head = cityHint.split(",")[0] ?? "";
+  const expanded = expandAlias(head);
+  return { name: townName(expanded), isCity: expanded !== head };
+}
+function stateFieldOf(lead) {
+  const state = lead?.location?.state;
+  return typeof state === "string" ? normalizeGeo(state) : "";
+}
+function filterDiscoverByCity(leads, cityHint) {
+  const hint = cityHint ? cityHintCore(cityHint) : { name: "", isCity: false };
+  if (!hint.name)
+    return { leads, matchedOn: null };
+  const cityOf = (l) => typeof l?.location?.city === "string" ? townName(l.location.city) : "";
+  const byCity = leads.filter((l) => cityOf(l) === hint.name);
+  if (byCity.length > 0)
+    return { leads: byCity, matchedOn: "city" };
+  if (hint.isCity)
+    return { leads: [], matchedOn: "city" };
+  const byState = leads.filter((l) => stateFieldOf(l) === hint.name);
+  return { leads: byState, matchedOn: "state" };
 }
 function toMapLocation(lead, mode) {
   const pos = lead?.location?.pos;
@@ -17448,7 +17469,7 @@ var tourPlan = {
       },
       city_id: {
         type: "string",
-        description: "Pre-resolved admin_area id (numeric string). Bypasses the resolver."
+        description: "Pre-resolved admin_area id (numeric string). Bypasses the resolver. Pass `city` alongside it with the NAME of the area you picked: the id scopes the Monitor half, and the name is the only thing that can scope the Discover half, which has no server-side geo filter. With `city_id` alone, `discover_leads` comes back empty."
       },
       followups_count: {
         type: "number",
@@ -17555,7 +17576,13 @@ var tourPlan = {
     const discoverCount = params.discover_count ?? DEFAULT_DISCOVER_COUNT;
     const [followupsResult, leadsResult] = await Promise.allSettled([
       pullFollowups.execute(client, {
-        city: params.city,
+        // A pre-resolved id bypasses the resolver, which is what its own
+        // schema promises. Forwarding the free text alongside it sends the
+        // name back through /geo/search, and the name is the thing that was
+        // ambiguous — so an agent recovering from `ambiguous_locations` by
+        // picking an id would be handed the same ambiguity again. Here the
+        // free text stays behind and scopes the Discover half instead.
+        city: params.city_id ? void 0 : params.city,
         city_id: params.city_id,
         count: followupsCount
       }, ctx),
@@ -17569,7 +17596,7 @@ var tourPlan = {
           location_ambiguities: r.location_ambiguities,
           monitor_leads: [],
           discover_leads: [],
-          discover_filter_note: "City was ambiguous; pick an id and re-call to proceed.",
+          discover_filter_note: "City was ambiguous; re-call with `city_id` set to the id you pick AND `city` set to that candidate's `name`. The id scopes the follow-ups; the name is what scopes the Discover leads.",
           map_locations: [],
           map_summary: {
             total_leads: 0,
@@ -17593,13 +17620,27 @@ var tourPlan = {
     if (leadsResult.status === "rejected") {
       ctx?.logger?.warn?.(`tour_plan: pull_leads failed: ${leadsResult.reason?.message ?? leadsResult.reason}`);
     }
-    const filtered = rawDiscover.filter((l) => cityMatches(l, params.city));
+    const cityName = params.city && !/^\d+$/.test(params.city.trim()) ? params.city : void 0;
+    const knownId = params.city_id ?? (cityName ? void 0 : params.city);
+    const idOnly = Boolean(knownId) && !cityName;
+    const { leads: filtered, matchedOn } = idOnly ? { leads: [], matchedOn: null } : filterDiscoverByCity(rawDiscover, cityName);
     const discoverLeads2 = filtered.slice(0, discoverCount);
     const pulledLensId = leadsResult.status === "fulfilled" ? leadsResult.value?.lens?.id : null;
     if (pulledLensId != null) {
       reportLeadInteractions(client, pulledLensId, discoverLeads2.map((l) => l.id), ["LEAD_SEEN"], ctx?.logger);
     }
-    const filterNote = params.city ? `Matched ${filtered.length}/${rawDiscover.length} Discover leads to '${params.city}'; returning top ${discoverLeads2.length}.` : `No city filter applied; returning top ${discoverLeads2.length} Discover leads.`;
+    let filterNote;
+    if (idOnly) {
+      filterNote = `Discover leads need the NAME of the place, and this call passed an area id (${knownId}) and no name. Re-call with \`city\` set to the name of that area, keeping \`city_id\` so the Monitor half stays on the area you picked. The follow-ups below are already scoped to it.`;
+    } else if (!cityName) {
+      filterNote = `No city filter applied; returning top ${discoverLeads2.length} Discover leads.`;
+    } else if (matchedOn === null) {
+      filterNote = `No usable city filter in '${params.city}'; returning top ${discoverLeads2.length} Discover leads.`;
+    } else if (filtered.length === 0) {
+      filterNote = `No Discover lead in the active lens is in '${params.city}' (checked ${rawDiscover.length} candidates by city, then by state/region). Say so; do NOT present leads from elsewhere as if they were in '${params.city}'.`;
+    } else {
+      filterNote = `Matched ${filtered.length}/${rawDiscover.length} Discover leads to '${params.city}' by ${matchedOn === "city" ? "city" : "state/region"}; returning top ${discoverLeads2.length}.`;
+    }
     return {
       city: params.city ?? null,
       city_id: params.city_id ?? null,
@@ -28619,7 +28660,7 @@ function parseWriteEnv(env = process.env) {
 }
 
 // src/http-server.ts
-var VERSION = true ? "0.39.1" : "0.0.0-dev";
+var VERSION = true ? "0.39.2" : "0.0.0-dev";
 var PORT = Number(process.env.PORT ?? 8080);
 var HOST = process.env.HOST ?? "0.0.0.0";
 var logger = {

package/dist/installer-electron.js

@@ -1805,7 +1805,7 @@ var init_installer_gui = __esm({
     init_install_dxt();
     init_install_shared();
     init_oauth();
-    VERSION = true ? "0.39.1" : "0.0.0-dev";
+    VERSION = true ? "0.39.2" : "0.0.0-dev";
     MESSAGES = {
       en: {
         installer: {

package/dist/installer-gui.js

@@ -1068,7 +1068,7 @@ async function oauthLogin(opts) {
 }
 
 // installer/installer-gui.ts
-var VERSION = true ? "0.39.1" : "0.0.0-dev";
+var VERSION = true ? "0.39.2" : "0.0.0-dev";
 var MESSAGES = {
   en: {
     installer: {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leadbay/mcp",
-  "version": "0.39.1",
+  "version": "0.39.2",
   "mcpName": "io.github.leadbay/leadbay-mcp",
   "description": "Model Context Protocol (MCP) server for Leadbay — AI lead discovery, qualification, and enrichment for Claude Desktop, Cursor, and Claude Code.",
   "type": "module",