@leadbay/mcp 0.23.6 → 0.23.7

package/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog — @leadbay/mcp
 
+## 0.23.7 — 2026-06-25
+
+Field-sales tour always renders the map (product#3779).
+
+- **`leadbay_plan_tour_in_city` / `leadbay_tour_plan`** — a plain-language tour intent ("I'm visiting Jacksonville in 3 days — who should I go see?") now deterministically routes to the tour tool (no longer leaks to `leadbay_pull_leads`), builds the mixed tour (known accounts + fresh prospects), and **proactively offers to plot it on a map** — every run, without the user asking. On acceptance it renders via `places_map_display_v0` (or the place-card carousel on hosts without the widget).
+- **Server-shaped `map_locations[]`** — leads are pre-shaped server-side (`{name, address, latitude, longitude, notes}`, badge in `notes`) plus a `map_summary`, so the agent never hand-builds the widget payload and passes coordinates through verbatim (no fabricated pins/addresses). Each stop is badged ★ Customer / ★ Qualified / ✦ New from real history fields (`epilogue_status` / `last_prospecting_action_at` / `last_monitor_action_at`). Guards against a `"null"`-string contact name.
+
 ## 0.23.6 — 2026-06-25
 
 Geographic filter on Discover lenses (product#3759).

package/dist/bin.js

@@ -6117,7 +6117,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
 | \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
 | \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
 
@@ -6435,7 +6435,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
 | \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
 | \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
 
@@ -6691,7 +6691,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
 | \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
 | \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
 
@@ -7307,7 +7307,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
 | \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
 | \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
 
@@ -7439,7 +7439,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
 | \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
 | \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
 
@@ -7573,11 +7573,11 @@ email. Do NOT paste the email body into chat prose alongside.
 
 ---
 
-Prepare a single-lead outreach brief: the full \`lead\` block (score, \`split_ai_summary\`, \`location\`, \`size\`, \`phone_numbers\`, \`website\`, \`description\`, \`social_urls\`, \`social_presence\`), the \`recommended_contact\` (always in the post-enrichment shape \u2014 \`contact_id\`, \`first_name\`, \`last_name\`, \`job_title\`, \`email\`, \`phone_number\`, \`linkedin_page\`, \`is_org_contact\` \u2014 with nulls where data isn't yet enriched), \`additional_contacts_count\`, and an \`enrichment\` block describing async state.
+Prepare a single-lead outreach brief: the full \`lead\` block (score, \`split_ai_summary\`, \`location\`, \`size\`, \`phone_numbers\`, \`website\`, \`description\`, \`social_urls\`, \`social_presence\`), the \`recommended_contact\` in post-enrichment shape (\`contact_id\`, names, \`job_title\`, \`email\`, \`phone_number\`, \`linkedin_page\`, \`is_org_contact\` \u2014 nulls where not yet enriched), \`additional_contacts_count\`, and an \`enrichment\` block describing async state.
 
 Optionally trigger contact enrichment in-flight with \`enrich:true\`. Enrichment is async (~60s). **Self-polling pattern (no separate tool needed):** re-call \`leadbay_prepare_outreach(leadId)\` without \`enrich\`; check \`enrichment.complete\`. When \`complete: true\`, the recommended contact now carries \`email\` and/or \`phone_number\`.
 
-The first call to this tool on a lead records a \`LEAD_VIEWED\`-style prospecting action server-side (one per lead per session \u2014 deduped) so the lead ages out of the Discover "new" view.
+The first call on a lead records a \`LEAD_VIEWED\`-style prospecting action server-side (deduped, one per lead per session) so it ages out of the Discover "new" view.
 
 IRON LAW \u2014 OUTCOME AFTER OUTREACH. The moment the user reports outreach happened ("I sent it", "she didn't pick up", "left a voicemail", "they replied", a forwarded email thread, a calendar invite), you MUST (1) call leadbay_report_outreach with verification (gmail_message_id, calendar_event_id, or the user's literal one-sentence confirmation as user_confirmed.ref) AND (2) ask the user about the outcome and set epilogue_status to one of the 4 canonical values: EPILOGUE_INTEREST_VALIDATED_OR_MEETING_PLANED ("Meeting booked"), EPILOGUE_COULD_NOT_REACH_STILL_TRYING ("Trying to reach"), EPILOGUE_NOT_INTERESTED_LOST ("Not interested"), EPILOGUE_STILL_CHASING ("In progress"). Use the user-facing labels in dialogue ("What's the outcome \u2014 meeting booked, trying to reach, not interested, or in progress?"); never say "epilogue" out loud. Skipping this step silently de-ranks every future follow-up suggestion because pull_followups depends on honest, current outcomes.
 
@@ -7592,7 +7592,7 @@ WHEN NOT TO USE: across many leads \u2014 use leadbay_enrich_titles for bulk; fo
 
 Route every draft through \`message_compose_v1\` (Claude's email composer). Above it, emit ONE short markdown context paragraph: score callout + sector fit + linked contact name + bare phone/email pills. Do NOT paste the email body into chat prose alongside \u2014 the composer IS the visual.
 
-Variant shape: 1\u20133 entries. Labels describe **strategy** ("Push for alignment", "Reference the M&A signal", "Soft intro \u2014 peer reference"), not tone. \`kind: "email"\` requires \`subject\`; phone/call openers use \`kind: "other"\` with the opener in \`body\`.
+Variant shape: 1\u20133 entries. Labels describe **strategy** ("Push for alignment", "Reference the M&A signal"), not tone. \`kind: "email"\` requires \`subject\`; phone/call openers use \`kind: "other"\` with the opener in \`body\`.
 
 ## GATE \u2014 PREFER BUILT-IN HOST WIDGETS
 
@@ -7602,7 +7602,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
 | \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
 | \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
 
@@ -7931,7 +7931,7 @@ Trigger phrases: "show me leads", "show me new leads", "show me today's leads",
 
 **Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
 
-Do NOT use for: "leads I should follow up with" \u2192 \`leadbay_pull_followups\`; "I'm going to <city>" \u2192 \`leadbay_followups_map\`; "leads I should reach out to" \u2192 \`leadbay_pull_followups\`; "leads to get back to" \u2192 \`leadbay_pull_followups\`; "leads to contact today" \u2192 \`leadbay_pull_followups\`; "should I contact" \u2192 \`leadbay_pull_followups\`; "reconnect with" \u2192 \`leadbay_pull_followups\`; "re-engage" \u2192 \`leadbay_pull_followups\`.
+Do NOT use for: "leads I should follow up with" \u2192 \`leadbay_pull_followups\`; "I'm going to <city>" \u2192 \`leadbay_tour_plan\`; "I'm in <city> next week \u2014 who's worth meeting" \u2192 \`leadbay_tour_plan\`; "who should I meet in <city>" \u2192 \`leadbay_tour_plan\`; "visiting <city> \u2014 who's worth meeting / seeing" \u2192 \`leadbay_tour_plan\`; "leads I should reach out to" \u2192 \`leadbay_pull_followups\`; "leads to get back to" \u2192 \`leadbay_pull_followups\`; "leads to contact today" \u2192 \`leadbay_pull_followups\`; "should I contact" \u2192 \`leadbay_pull_followups\`; "reconnect with" \u2192 \`leadbay_pull_followups\`; "re-engage" \u2192 \`leadbay_pull_followups\`.
 
 Prefer when: fresh Discover leads; if a lens is named, pass \`lensId\` and pin it
 
@@ -7942,6 +7942,7 @@ Examples that SHOULD invoke this tool:
 Examples that should NOT invoke this tool (sound similar, route elsewhere):
 - "Which leads should I follow up with this week?"
 - "I'm flying to Berlin Thursday \u2014 who should I meet?"
+- "I'm in San Francisco next Tuesday \u2014 who's worth meeting?"
 - "Show me leads I should reach out to today."
 - "Who should I get back to today?"
 - "Leads I should contact today."
@@ -9139,7 +9140,7 @@ WHEN NOT TO USE: the user wants a lead list (leadbay_pull_leads / leadbay_pull_f
 `;
     leadbay_tour_plan = `## WHEN TO USE
 
-Trigger phrases: "visiting <city> in <N> days", "field tour in <city>", "plan a tour in <city>", "who should I meet in <city>", "customers plus prospects in <city>", "tour itinerary".
+Trigger phrases: "visiting <city> in <N> days", "I'm in <city> next week / Tuesday \u2014 who's worth meeting", "I'm going to <city> \u2014 who should I see", "who's worth meeting in <city>", "field tour in <city>", "plan a tour in <city>", "who should I meet in <city>", "customers plus prospects in <city>", "tour itinerary".
 
 **Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
 
@@ -9149,6 +9150,7 @@ Prefer when: user wants known accounts plus new discoveries in one geographic it
 
 Examples that SHOULD invoke this tool:
 - "I'm flying to Limoges in 4 days \u2014 give me 3 customers, 3 qualified prospects, and 3 new high-potential."
+- "I'm in San Francisco next Tuesday. Who's worth meeting?"
 - "Plan my tour next Tuesday in Lyon: known accounts plus discoveries."
 - "Build a mixed itinerary for Berlin \u2014 I want both follow-ups and fresh leads."
 
@@ -9159,16 +9161,18 @@ Examples that should NOT invoke this tool (sound similar, route elsewhere):
 
 ## RENDER (quick)
 
-Route the union of monitor_leads + discover_leads into
-\`places_map_display_v0\` \u2014 same recipe as followups_map (lat/lng
-split, full address, short notes). Tag each entry's notes with a
-mode badge: "\u2605 Customer" / "\u2605 Qualified" / "\u2726 New" (split Monitor
-by last_monitor_action; Discover = New). Below the widget: one
-intro sentence + per-group chat-prose list with LinkedIn-linked
-contact names.
+Present the leads grouped by mode (\u2605 Customer / \u2605 Qualified / \u2726 New),
+then ALWAYS offer to plot them on a map ("Want me to put these on a
+map?"). On yes (or if the user asked for a map up front), render it:
+pass \`map_locations\` verbatim into \`places_map_display_v0\`, or on a
+host without the widget emit one \`### Company \xB7 City, State\` place-card
+block per lead so the host's address carousel renders. Never a flat
+prose paragraph. Full recipe below.
 
 ---
 
+**BEFORE YOU CALL \u2014 clarify scope with a tap-to-answer question.** A field tour is high-intent, so unless the user already said it, ASK first (via \`ask_user_input_v0\` / \`AskUserQuestion\` \u2014 whichever is in your tool set) and wait for the answer before calling this tool: (1) **Who to include?** \u2014 "Mix \u2014 known accounts + fresh prospects" (default) / "Only my known accounts" / "Only fresh new prospects"; (2) **Enrich contacts with no phone/email?** \u2014 "Yes, enrich the top stops" / "No, just plan". Map answers to args: only-known \u2192 \`discover_count: 0\`; only-new \u2192 \`followups_count: 0\`; mix \u2192 defaults; enrich=yes \u2192 after planning, run \`leadbay_enrich_titles\` / \`leadbay_prepare_outreach(enrich:true)\` on top stops missing a channel. Skip the question only if the request already states scope ("plan a tour of just my new leads" \u2192 only-new, don't ask). Do NOT skip straight to building + mapping without this.
+
 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 admin level \u2014 city, state, country, region \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\`.
@@ -9179,21 +9183,30 @@ Build a single-call mixed-mode itinerary for a field sales tour. Combines \`lead
 
 ---
 
-## RENDER \u2014 host-native map widget (REQUIRED, preferred)
+## RENDER \u2014 present the leads, then OFFER the map (render on yes)
+
+First present the leads grouped by mode as a tight per-lead list (badge + company + city + best contact). Then **ALWAYS offer the map** as the next step \u2014 "Want me to put these on a map?" \u2014 and render it only when the user accepts (or asked for a map in their original message). The map is mandatory to *offer* on every tour; it is *rendered* on acceptance.
+
+When rendering, use the **two-step host flow** \u2014 this is what produces a real interactive street map instead of a schematic neighborhood scatter:
 
-Identical to \`leadbay_followups_map\`. Pass the union \`monitor_leads + discover_leads\` into \`places_map_display_v0\`. The mode information goes in the per-lead \`notes\` string as a **leading badge**:
+1. **\`places_search\` first, once per lead.** For each entry in \`map_locations\`, call \`places_search\` with a natural query built from the lead's \`name\` + \`address\` (the full street address, e.g. "Brooklyn Brewery, 79 N 11th St, Brooklyn, NY"). This resolves a real \`place_id\` + verified coordinates/ratings from the host's place index. Run them up front (resolve all stops first), as the host's own guidance prescribes.
+2. **\`places_map_display_v0\` second**, fed the resolved places. Use **Itinerary mode** for a tour (multi-stop, route order, optional arrival times / stop durations) \u2014 a field-sales day IS an itinerary; Markers mode is only for a plain "show me X on a map". Carry each lead's mode badge (\u2605/\u2726) + one-line pitch from \`map_locations[i].notes\` into the place's note.
 
-- \`\u2605 Customer\` \u2014 Monitor lead with an existing \`last_monitor_action\` history (engaged / past interaction).
-- \`\u2605 Qualified\` \u2014 Monitor lead with a high \`ai_agent_lead_score\` or \`score\` but no recent action.
+Do NOT skip \`places_search\` and push raw \`latitude\`/\`longitude\` straight into the display widget \u2014 that's exactly what falls back to the schematic relative scatter (dots by neighborhood, no streets). The \`map_locations\` array already gives you everything \`places_search\` needs (\`name\`, full \`address\`, \`latitude\`, \`longitude\`, badge-tagged \`notes\`); do NOT shorten the address to just the city.
+
+For reference, the badge the server already applied to each \`notes\`:
+
+- \`\u2605 Customer\` \u2014 Monitor lead with prior engagement history (\`epilogue_status\`, \`last_prospecting_action_at\`, or \`last_monitor_action_at\` set).
+- \`\u2605 Qualified\` \u2014 Monitor lead with a high score but no recent action.
 - \`\u2726 New\` \u2014 Discover lead from \`discover_leads\`.
 
-Then the rest of the notes string follows the standard recipe: ONE sentence, sector/fit + contact ask, bare phone + email auto-linkified. Example:
+Example of a server-built \`notes\` string you pass through unchanged:
 
 \`\`\`
 \u2726 New \u2014 Strong mid-size hardware distributor fit. Reach Marie Dupont, Sales Director: +33 5 55 12 34 56, m.dupont@example.fr.
 \`\`\`
 
-Skip any lead whose \`location.pos\` is null (no lat/lng \u2192 no pin) \u2014 list them as a "+ N leads without coordinates" footer below the widget.
+Leads without coordinates are already omitted from \`map_locations\`. Use \`map_summary.leads_without_coords\` to footnote "+ N leads without coordinates" below the widget \u2014 no need to re-count.
 
 ## Chat prose AFTER the widget (where markdown DOES render)
 
@@ -9201,9 +9214,17 @@ Group the leads into THREE sections (Customers / Qualified Prospects / New Disco
 
 If the user said something like "3+3+3", honor that split. If \`followups_count\` returned fewer Customers than asked, fill from Qualified.
 
-## RENDER \u2014 fallback for hosts without \`places_map_display_v0\`
+## RENDER \u2014 fallback for hosts without \`places_map_display_v0\` (still a map, never a prose list)
 
-Emit per-lead markdown blocks grouped by mode, in the standard place-card-friendly format (\`### **Company** \xB7 City, State\`, mode badge + score, contact line, channel lines). Hosts that auto-detect addresses (Claude.ai web, cowork) build their own carousel from these blocks.
+When the widget isn't in your tool set (e.g. Claude Desktop), you MUST still produce a map by emitting one place-card block per \`map_locations\` entry in EXACTLY this shape \u2014 the \`### Company \xB7 City, State\` heading with the address is what makes the host auto-detect it and render its own Google-Place-card carousel:
+
+\`\`\`
+### <Company Name> \xB7 <City>, <State>
+
+<\u2605 Customer | \u2605 Qualified | \u2726 New> \u2014 <one-sentence fit>. Reach **[<Contact>](<LinkedIn URL>)**, <role>. \u260E <bare phone>.
+\`\`\`
+
+Group the blocks by mode (Customers \u2192 Qualified \u2192 New). A flat narrative paragraph ("Brooklyn Brewery \u2014 Broadway, 10018 (Midtown). Contact: \u2026") does NOT auto-detect into cards and is WRONG \u2014 the per-lead heading with the city is mandatory.
 
 ## GATE \u2014 PREFER BUILT-IN HOST WIDGETS
 
@@ -9213,7 +9234,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
 | \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
 | \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
 
@@ -9232,7 +9253,7 @@ WHEN TO USE: the user signals a *mixed* tour-planning intent \u2014 they want bo
 
 WHEN NOT TO USE: if the user only wants follow-ups (use \`leadbay_followups_map\`), only wants new leads (use \`leadbay_pull_leads\`), wants research on one specific account (\`leadbay_research_lead_by_id\`), or wants to persist the tour as a campaign artifact (chain into \`leadbay_create_campaign\` after this).
 
-**Response envelope**: \`{city, city_id, monitor_leads, discover_leads, discover_filter_note, _meta}\` on happy path; \`{status: "ambiguous_locations", location_ambiguities, ...}\` when the passed \`city\` matched multiple admin areas.
+**Response envelope**: \`{city, city_id, monitor_leads, discover_leads, discover_filter_note, map_locations, map_summary, _meta}\` on happy path; \`{status: "ambiguous_locations", location_ambiguities, ...}\` when the passed \`city\` matched multiple admin areas.
 
 ---
 `;
@@ -15057,6 +15078,54 @@ function cityMatches(lead, cityHint) {
   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 toMapLocation(lead, mode) {
+  const pos = lead?.location?.pos;
+  const valid = Array.isArray(pos) && pos.length === 2 && pos.every((n) => typeof n === "number");
+  if (!valid)
+    return null;
+  const loc = lead.location;
+  const c = lead.recommended_contact;
+  const cleanName = (v) => typeof v === "string" && v.trim() && v.trim().toLowerCase() !== "null" ? v.trim() : "";
+  const fullName = c ? [cleanName(c.first_name), cleanName(c.last_name)].filter(Boolean).join(" ") : "";
+  const role = cleanName(c?.job_title) ? `, ${cleanName(c?.job_title)}` : "";
+  const angle = lead.split_ai_summary?.next_step ?? lead.split_ai_summary?.approach_angle ?? lead.short_description ?? "Worth a visit";
+  let reach;
+  if (c && fullName && c.phone_number) {
+    reach = `Reach ${fullName}${role}: ${c.phone_number}${c.email ? `, ${c.email}` : ""}.`;
+  } else if (c && fullName && c.email) {
+    reach = `Reach ${fullName}${role}: ${c.email}.`;
+  } else if (c && fullName) {
+    reach = `Reach ${fullName} (enrich a channel).`;
+  } else {
+    reach = "Enrich a contact to reach this account.";
+  }
+  const notes = `${mode} \u2014 ${angle}. ${reach}`.slice(0, 280);
+  return {
+    name: lead.name,
+    address: loc.full ?? [loc.city, loc.state, loc.country].filter(Boolean).join(", "),
+    latitude: pos[0],
+    longitude: pos[1],
+    notes
+  };
+}
+function hasMonitorHistory(lead) {
+  return Boolean(lead?.epilogue_status || lead?.last_prospecting_action_at || lead?.last_monitor_action_at);
+}
+function buildMap(monitorLeads, discoverLeads2) {
+  const mapLocations = [
+    ...monitorLeads.map((l) => toMapLocation(l, hasMonitorHistory(l) ? "\u2605 Customer" : "\u2605 Qualified")),
+    ...discoverLeads2.map((l) => toMapLocation(l, "\u2726 New"))
+  ].filter((m) => m !== null);
+  const totalLeads = monitorLeads.length + discoverLeads2.length;
+  return {
+    map_locations: mapLocations,
+    map_summary: {
+      total_leads: totalLeads,
+      leads_with_coords: mapLocations.length,
+      leads_without_coords: totalLeads - mapLocations.length
+    }
+  };
+}
 var DEFAULT_FOLLOWUPS_COUNT, DEFAULT_DISCOVER_COUNT, DISCOVER_OVER_PULL, tourPlan;
 var init_tour_plan = __esm({
   "../core/dist/composite/tour-plan.js"() {
@@ -15118,6 +15187,20 @@ var init_tour_plan = __esm({
             type: "string",
             description: "Human-readable summary of the client-side geo filter applied to Discover leads (e.g. 'matched 3/30 by city/state')."
           },
+          map_locations: {
+            type: "array",
+            description: "Pre-shaped entries for `places_map_display_v0` \u2014 pass each one verbatim ({name, address, latitude, longitude, notes}); the mode badge (\u2605 Customer / \u2605 Qualified / \u2726 New) is already in `notes`. Do NOT reshape or re-derive from `location.pos`. One entry per lead with valid coordinates; coordinate-less leads are omitted and counted in `map_summary`.",
+            items: { type: "object" }
+          },
+          map_summary: {
+            type: "object",
+            description: "Deterministic coverage counts so the agent can footnote '+ N leads without coordinates' without re-counting.",
+            properties: {
+              total_leads: { type: "number" },
+              leads_with_coords: { type: "number" },
+              leads_without_coords: { type: "number" }
+            }
+          },
           status: {
             type: "string",
             description: "'ambiguous_locations' when the passed `city` matched multiple admin areas \u2014 pick an id from location_ambiguities and re-call with city_id."
@@ -15134,7 +15217,7 @@ var init_tour_plan = __esm({
             }
           }
         },
-        required: ["monitor_leads", "discover_leads"]
+        required: ["monitor_leads", "discover_leads", "map_locations"]
       },
       execute: async (client, params, ctx) => {
         const followupsCount = params.followups_count ?? DEFAULT_FOLLOWUPS_COUNT;
@@ -15156,6 +15239,12 @@ var init_tour_plan = __esm({
               monitor_leads: [],
               discover_leads: [],
               discover_filter_note: "City was ambiguous; pick an id and re-call to proceed.",
+              map_locations: [],
+              map_summary: {
+                total_leads: 0,
+                leads_with_coords: 0,
+                leads_without_coords: 0
+              },
               city: params.city ?? null,
               city_id: params.city_id ?? null,
               _meta: {
@@ -15182,6 +15271,7 @@ var init_tour_plan = __esm({
           monitor_leads: monitorLeads,
           discover_leads: discoverLeads2,
           discover_filter_note: filterNote,
+          ...buildMap(monitorLeads, discoverLeads2),
           _meta: {
             region: client.region,
             latency_ms: client.lastMeta?.latency_ms ?? null
@@ -23666,44 +23756,80 @@ GATE \u2014 DEFER TO TOOL RENDERING. When you call a Leadbay composite that ship
 If the prompt's body and the tool's RENDERING appear to conflict, the tool's RENDERING wins for the structural layout; the prompt's voice wins for the commentary that surrounds it.
 
 
-# PHASE 1 \u2014 BUILD THE ITINERARY
+# PHASE 1 \u2014 CLARIFY SCOPE FIRST (ask before building)
+
+Before calling \`leadbay_tour_plan\`, ask me what the tour should cover \u2014 a field tour is high-intent and the scope changes what lands on the map. Use your host's interactive question widget (\`ask_user_input_v0\` in Claude chat \u2014 \`{questions:[{question, type:"single_select", options:[\u2026]}]}\`; or \`AskUserQuestion\` in cowork / Claude Code \u2014 \`{questions:[{question, header, multiSelect, options:[{label, description}]}]}\`). Ask at most 2 short tap-to-answer questions:
+
+1. **Who to include?** \u2014 options: "Mix \u2014 known accounts + fresh prospects" (default), "Only my known accounts (follow-ups)", "Only fresh new prospects".
+2. **Enrich contacts that have no phone/email?** \u2014 options: "Yes, enrich the top stops", "No, just plan the tour".
+
+Skip a question only if I already answered it in my request (e.g. "plan a tour of just my new leads in NYC" \u2192 who-to-include is already "only new"; don't re-ask). If I gave the full scope up front, skip PHASE 1 entirely and go to PHASE 2.
+
+Map my answers to the \`leadbay_tour_plan\` call:
+- **Mix** \u2192 defaults (\`followups_count: 6, discover_count: 6\`).
+- **Only known accounts** \u2192 \`discover_count: 0\`.
+- **Only new prospects** \u2192 \`followups_count: 0\`.
+- **Enrich = yes** \u2192 after the tour is planned (PHASE 2), call \`leadbay_enrich_titles\` / \`leadbay_prepare_outreach(enrich:true)\` on the top stops that have no \`recommended_contact\` channel, before drafting outreach.
+
+# PHASE 2 \u2014 BUILD THE ITINERARY
 
-Call \`leadbay_tour_plan({city: "{{arg:city}}"})\` with the default counts (6 follow-ups + 6 discover). If the response is \`status: "ambiguous_locations"\`, surface the candidates and ask me to pick one, then re-call with \`city_id\`.
+Call \`leadbay_tour_plan({city: "{{arg:city}}", \u2026scope from PHASE 1})\`. If the response is \`status: "ambiguous_locations"\`, surface the candidates and ask me to pick one, then re-call with \`city_id\`.
 
-Split the returned \`monitor_leads\` into two buckets client-side using \`last_monitor_action\`:
+Split the returned \`monitor_leads\` into two buckets client-side using their engagement-history fields:
 
-- **Customers** \u2014 leads with any \`last_monitor_action\` history (CONTACTED, MEETING_BOOKED, etc.). Treat as known accounts with prior engagement.
-- **Qualified prospects** \u2014 leads with high \`ai_agent_lead_score\` (or \`score\`) but no recent action.
+- **Customers** \u2014 leads with prior engagement history: any of \`epilogue_status\`, \`last_prospecting_action_at\`, or \`last_monitor_action_at\` is set. Treat as known accounts with prior interaction.
+- **Qualified prospects** \u2014 leads with a high \`ai_agent_lead_score\` (or \`score\`) but none of those history fields set (scored, not yet worked).
 
 \`discover_leads\` are the **New** bucket.
 
 Aim for a 3+3+3 split if possible. If the customers bucket has fewer than 3, fill from qualified. If discover_filter_note indicates a low match ratio for the city, mention it: "Only N/30 fresh leads matched your city" \u2014 better honest than padded.
 
-# PHASE 2 \u2014 RENDER THE MAP
+# PHASE 3 \u2014 PRESENT THE ITINERARY + OFFER THE MAP
 
-Route the union of \`monitor_leads + discover_leads\` into \`places_map_display_v0\` (when the host exposes it). Per-lead \`notes\` string:
+Show the planned tour as a concise per-lead list grouped by mode (Customers \u2192 Qualified \u2192 New), each line carrying its \`\u2605\`/\`\u2726\` badge, the company, city, and best contact. Keep it tight \u2014 this is the summary, not the map.
 
-- \`\u2605 Customer \u2014 <one-sentence sector + why-now>. Reach <name>, <role>: <bare phone>, <bare email>.\`
-- \`\u2605 Qualified \u2014 <one-sentence>. Reach <name>...\`
-- \`\u2726 New \u2014 <one-sentence>. Reach <name>...\`
+Then **ALWAYS offer the map as the immediate next step** \u2014 a tour is inherently geographic, so the map is the natural payoff. End the turn with a single clear proposal:
+
+> **Want me to put these <N> stops on a map?** I'll plot them so you can see the route for your <city> day.
+
+Make it a genuine yes/no offer (route it through \`ask_user_input_v0\` / \`AskUserQuestion\` when that's in your tool set, so it's a tappable choice; otherwise the one-line question above). Do NOT render the map yet, and do NOT bury the offer \u2014 proposing the map is mandatory on every tour, for BOTH "plan a prospecting tour in <city>" and "who's worth meeting in <city>" phrasings. If the user already said "show me on a map" / "give me the map" in their request, skip the offer and go straight to PHASE 4 (render).
+
+# PHASE 4 \u2014 RENDER THE MAP (when the user accepts, or asked for it up front)
+
+When the user says yes (or asked for the map in their original message), render it now. Two ways \u2014 you MUST do one, never a flat prose paragraph:
+
+**Path A \u2014 \`places_search\` + \`places_map_display_v0\` are in your tool set.** Use the **two-step** host flow (this is what draws a real street map, not a schematic scatter):
+
+1. **\`places_search\` first, once per lead** \u2014 query = each \`map_locations\` entry's \`name\` + full street \`address\` (e.g. "Brooklyn Brewery, 79 N 11th St, Brooklyn, NY"). Resolve all stops up front to get real \`place_id\`s + verified coords/ratings.
+2. **\`places_map_display_v0\` second**, fed those resolved places, in **Itinerary mode** (a tour is a multi-stop route \u2014 show order, optionally arrival times / stop durations). Carry each lead's \u2605/\u2726 badge + one-line pitch from its \`notes\` into the place note.
+
+Do NOT push raw \`latitude\`/\`longitude\` straight into the display widget without \`places_search\` \u2014 that degrades to the neighborhood-dot scatter. \`map_locations\` already carries \`name\`, full \`address\`, coords, and badge-tagged \`notes\`; don't shorten the address to the city.
+
+**Path B \u2014 the widget is NOT in your tool set (e.g. Claude Desktop).** Emit one **place-card block per lead** in EXACTLY this shape so the chat host auto-detects the address and renders its own Google-Place-card map carousel \u2014 the \`### Company \xB7 City, State\` heading + address is what triggers it:
+
+\`\`\`
+### <Company Name> \xB7 <City>, <State>
+
+<\u2605 Customer | \u2605 Qualified | \u2726 New> \u2014 <one-sentence why-it-fits>. Reach **[<Contact name>](<LinkedIn URL>)**, <role>. \u260E <bare phone>.
+\`\`\`
 
-Skip leads with \`location.pos === null\` (no coordinates \u2192 no pin) \u2014 list them as "+ N leads without coordinates" below the widget.
+One block per lead in \`map_locations\`, grouped by mode. Pull company, city/state, badge, and contact straight from the tool response. A flat paragraph like "Brooklyn Brewery \u2014 Broadway, 10018 (Midtown). Best contact: \u2026" does NOT auto-detect and is WRONG \u2014 the per-lead heading with the city is mandatory.
 
-Below the widget, emit a chat-prose summary grouped by mode (Customers / Qualified / New), with LinkedIn-linked contact name + bare phone/email pills per lead. Use the canonical \`linking/contact-linkedin\` rules.
+Coordinate-less leads are already omitted from \`map_locations\`; footnote them with \`map_summary.leads_without_coords\` ("+ N leads without coordinates").
 
-# PHASE 3 \u2014 DRAFT IN-AREA OUTREACH (optional, ask first)
+# PHASE 5 \u2014 DRAFT IN-AREA OUTREACH (optional, ask first)
 
 After the map, ask me ONCE: "Want me to draft 'I'll be in {{arg:city}}{{arg:date_paren}}' outreach for the top accounts?" If I say yes, for each of the top 3 leads (1 Customer / 1 Qualified / 1 New), call \`leadbay_prepare_outreach(leadId)\` and route the draft through \`message_compose_v1\` with a single variant labeled "In-area visit" \u2014 body opens with the visit context, references the AI-summary angle, ends with a clear ask (15-min coffee / on-site stopover).
 
 Serialize the prepare_outreach calls (max 3 in parallel \u2014 see the long-running-tools rule).
 
-# PHASE 4 \u2014 PERSIST AS A CAMPAIGN (optional, ask first)
+# PHASE 6 \u2014 PERSIST AS A CAMPAIGN (optional, ask first)
 
 After drafts, ask me ONCE: "Save these 9 accounts as a campaign called '**{{arg:city}} Tour{{arg:date_dash}}**'?" If I say yes, call \`leadbay_create_campaign({lead_ids: [...all_nine_lead_ids], name: "{{arg:city}} Tour{{arg:date_dash}}"})\`. Surface the returned \`id\` + \`name\` as a confirmation line, and offer the NEXT STEPS chip "View progression" (which routes to \`leadbay_campaign_progression\`).
 
 If I declined the campaign step, end the turn \u2014 the map + drafts are enough for an ad-hoc trip.
 
-# PHASE 5 \u2014 STOP
+# PHASE 7 \u2014 STOP
 
 Done. The map is the surface; the drafts are the action; the campaign is the persistence layer for managerial follow-up after the trip.
 `;
@@ -24302,7 +24428,7 @@ var PROMPT_META = {
   leadbay_followup_check_in: { "name": "leadbay_followup_check_in", "short_description": 'Follow-up check-in: surface KNOWN leads from the Monitor view needing\nre-engagement. Trigger on "follow up", "already known leads", "what\'s\noverdue", "before my trip", "who should I re-engage". Do NOT trigger on\n"show me today\'s leads", "my morning check-in", "run my check-in",\n"I do this every day", "every morning" \u2014 those go to\n`leadbay_daily_check_in`.\n', "arguments": [], "expected_calls": ["leadbay_pull_followups", "leadbay_research_lead_by_id", "leadbay_prepare_outreach"], "failure_modes": ["Calls leadbay_pull_leads (the Discover entry point) instead of leadbay_pull_followups \u2014 these are different data sources; the Discover queue does NOT contain Monitor's known-but-cold pipeline", 'Iterates pages of leadbay_pull_leads filtering by engagement_count to "fake" a follow-up view (a real bug observed in 0.9.0 \u2014 the right move is to call pull_followups directly)', "Replaces the canonical pull_followups table layout with prose per row (the per-tool RENDERING block is the structural contract; commentary belongs above or below)", 'Skips the cross-mode pivot offer at the end ("Want to see NEW leads from your wishlist instead?" routes to leadbay_pull_leads)'] },
   leadbay_import_file: { "name": "leadbay_import_file", "short_description": "Import a user-supplied CSV/file into Leadbay through five phases with\nevidence gates \u2014 scan, derive, resolve identities, preserve & commit,\nthen optionally qualify and report. The job is to maximize how many\nrows the Leadbay system actually ingests and matches.\n", "arguments": [{ "name": "file", "description": "Path or user-visible name of the CSV/file to import. If omitted, use the file the user attached or referenced.", "required": false }, { "name": "instruction", "description": 'Additional user goal, e.g. "then qualify the leads", "preserve owner phone as a custom field", or "only import restaurants in Manhattan".', "required": false }], "expected_calls": ["leadbay_resolve_import_rows", "leadbay_list_mappable_fields", "leadbay_create_custom_field", "leadbay_import_leads", "leadbay_import_and_qualify", "leadbay_add_note", "leadbay_import_status"], "failure_modes": ["Picks LEADBAY_ID from score alone, name-only, fuzzy-name-only, root-domain-only, brand-only, postcode-only, or city-only evidence", "Drops meaningful business notes or CRM record links instead of preserving them as custom fields or lead notes", "Treats a consumer mailbox domain (gmail.com, hotmail.com, ...) as the company domain", "Skips deriving company_domain from a business email when no website column exists (this kills match rate)", "Skips the COLUMN PRESERVATION PLAN byproduct before importing", "Skips the DECISION LOG byproduct before writing LEADBAY_ID", "Returns the imported records WITHOUT writing LEADBAY_ID values back into the user's file (leaves the user no audit trail of what matched)", "Fabricates leadIds, contact emails, or mapping IDs not present in the file or a tool response"] },
   leadbay_log_outreach: { "name": "leadbay_log_outreach", "short_description": "Log outreach (an email I sent, a call I made, a meeting I had) on a\nspecific lead. Captures verification so the SDR pipeline trusts the entry.\n", "arguments": [{ "name": "lead_id", "description": "The lead UUID. Get it from leadbay_pull_leads or leadbay_research_lead_by_id.", "required": true }, { "name": "summary", "description": "1-2 sentences describing what I did (e.g. 'Sent intro email to CTO citing recent Hornsea contract').", "required": true }], "expected_calls": ["leadbay_report_outreach"], "failure_modes": ["Calls leadbay_report_outreach without first collecting a verification source", "Fabricates a gmail_message_id or calendar_event_id (the human team treats verification as canonical)", "Records outreach to a different lead_id than the one the user supplied", "Skips the dry_run step when the user is unsure what would be sent"] },
-  leadbay_plan_tour_in_city: { "name": "leadbay_plan_tour_in_city", "short_description": "Plan a field sales tour: in one flow, surface follow-ups + fresh\nDiscover leads in the target city via `leadbay_tour_plan`, render\nto a map, draft in-area outreach via `leadbay_prepare_outreach`,\nand optionally persist the selected accounts as a named campaign\nvia `leadbay_create_campaign`. Closes #3630 US1 end-to-end.\n", "arguments": [{ "name": "city", "description": "City or region the user is visiting (e.g. 'Limoges', 'Bay Area'). Used as the geo filter for both Monitor and Discover lookups.", "required": true }, { "name": "date", "description": "When the visit is (e.g. 'May 24', 'next Thursday'). Surfaced in the outreach drafts as 'I'll be in <city> on <date>'.", "required": false }], "expected_calls": ["leadbay_tour_plan", "leadbay_research_lead_by_id", "leadbay_prepare_outreach", "leadbay_create_campaign"], "failure_modes": ["Calls leadbay_followups_map (Monitor-only) instead of leadbay_tour_plan \u2014 loses the Discover (fresh-lead) half that the user explicitly asked for", "Calls leadbay_pull_leads then drops the geo filter \u2014 returns the lens-wide wishlist instead of city-relevant fresh leads", 'Skips the campaign-persist step ("would you like to save these as a tour?") \u2014 leaves the rep with a one-shot map but no follow-up artifact', "Creates a campaign WITHOUT asking the user first \u2014 the persist step is high-intent; offer it, don't assume", "Fabricates lead_ids when seeding the campaign instead of using the ids returned by tour_plan"] },
+  leadbay_plan_tour_in_city: { "name": "leadbay_plan_tour_in_city", "short_description": 'Use whenever the user names a city they\'ll be in and asks who to see\n\u2014 "I\'m in SF next Tuesday, who\'s worth meeting?", "I\'m going to Berlin\n\u2014 who should I visit?", "plan my <city> tour". Any in-person/visit\nintent tied to a place routes here, NOT to `leadbay_pull_leads`. It\nsurfaces follow-ups + fresh Discover leads in the city via\n`leadbay_tour_plan`, ALWAYS offers to plot them on a map (rendering it\non yes), then offers outreach drafts + campaign persistence.\n', "arguments": [{ "name": "city", "description": "City or region the user is visiting (e.g. 'Limoges', 'Bay Area'). Used as the geo filter for both Monitor and Discover lookups.", "required": true }, { "name": "date", "description": "When the visit is (e.g. 'May 24', 'next Thursday'). Surfaced in the outreach drafts as 'I'll be in <city> on <date>'.", "required": false }], "expected_calls": ["leadbay_tour_plan", "leadbay_research_lead_by_id", "leadbay_prepare_outreach", "leadbay_create_campaign"], "failure_modes": ["Calls leadbay_followups_map (Monitor-only) instead of leadbay_tour_plan \u2014 loses the Discover (fresh-lead) half that the user explicitly asked for", "Calls leadbay_pull_leads then drops the geo filter \u2014 returns the lens-wide wishlist instead of city-relevant fresh leads", 'Skips the campaign-persist step ("would you like to save these as a tour?") \u2014 leaves the rep with a one-shot map but no follow-up artifact', "Creates a campaign WITHOUT asking the user first \u2014 the persist step is high-intent; offer it, don't assume", "Fabricates lead_ids when seeding the campaign instead of using the ids returned by tour_plan"] },
   leadbay_prospecting_overview: { "name": "leadbay_prospecting_overview", "short_description": `Orientation for working with Leadbay from any host \u2014 discovery vs.
 follow-up, the outreach loop, outcome recording, imports, pushback /
 snooze, and the connected-outreach-tool registry. Trigger when the
@@ -24324,7 +24450,7 @@ var PROMPT_CATALOG_BULLETS = {
   leadbay_followup_check_in: `- \`leadbay_followup_check_in\`: Follow-up check-in: surface KNOWN leads from the Monitor view needing re-engagement. Trigger on "follow up", "already known leads", "what's overdue", "before my trip", "who should I re-engage". Do NOT trigger on "show me today's leads", "my morning check-in", "run my check-in", "I do this every day", "every morning" \u2014 those go to \`leadbay_daily_check_in\`.`,
   leadbay_import_file: `- \`leadbay_import_file\` (optional args: file, instruction): Import a user-supplied CSV/file into Leadbay through five phases with evidence gates \u2014 scan, derive, resolve identities, preserve & commit, then optionally qualify and report. The job is to maximize how many rows the Leadbay system actually ingests and matches.`,
   leadbay_log_outreach: `- \`leadbay_log_outreach\` (required args: lead_id, summary): Log outreach (an email I sent, a call I made, a meeting I had) on a specific lead. Captures verification so the SDR pipeline trusts the entry.`,
-  leadbay_plan_tour_in_city: `- \`leadbay_plan_tour_in_city\` (required args: city; optional args: date): Plan a field sales tour: in one flow, surface follow-ups + fresh Discover leads in the target city via \`leadbay_tour_plan\`, render to a map, draft in-area outreach via \`leadbay_prepare_outreach\`, and optionally persist the selected accounts as a named campaign via \`leadbay_create_campaign\`. Closes #3630 US1 end-to-end.`,
+  leadbay_plan_tour_in_city: `- \`leadbay_plan_tour_in_city\` (required args: city; optional args: date): Use whenever the user names a city they'll be in and asks who to see \u2014 "I'm in SF next Tuesday, who's worth meeting?", "I'm going to Berlin \u2014 who should I visit?", "plan my <city> tour". Any in-person/visit intent tied to a place routes here, NOT to \`leadbay_pull_leads\`. It surfaces follow-ups + fresh Discover leads in the city via \`leadbay_tour_plan\`, ALWAYS offers to plot them on a map (rendering it on yes), then offers outreach drafts + campaign persistence.`,
   leadbay_prospecting_overview: `- \`leadbay_prospecting_overview\`: Orientation for working with Leadbay from any host \u2014 discovery vs. follow-up, the outreach loop, outcome recording, imports, pushback / snooze, and the connected-outreach-tool registry. Trigger when the conversation involves Leadbay leads, prospecting, pipeline, follow-up, outreach, or lens / ICP \u2014 anything from "show me my leads" to "what should I follow up on" to "I'll send via lemlist".`,
   leadbay_qualify_top_n: `- \`leadbay_qualify_top_n\` (optional args: count): Bulk-qualify the top N un-qualified leads in the active lens. Uses leadbay_bulk_qualify_leads with a sensible default budget.`,
   leadbay_refine_audience: `- \`leadbay_refine_audience\` (required args: instruction): Refine the kind of leads Leadbay surfaces beyond firmographics, with a free-text instruction. Handles the clarification round-trip if the new prompt is ambiguous.`,
@@ -27591,7 +27717,7 @@ var OAUTH_BASE_URLS = {
     fr: "https://staging.api.leadbay.app"
   }
 };
-var VERSION = "0.23.6";
+var VERSION = "0.23.7";
 var HELP = `
 leadbay-mcp ${VERSION} \u2014 Leadbay Model Context Protocol server
 

package/dist/http-server.js

@@ -625,44 +625,80 @@ GATE \u2014 DEFER TO TOOL RENDERING. When you call a Leadbay composite that ship
 If the prompt's body and the tool's RENDERING appear to conflict, the tool's RENDERING wins for the structural layout; the prompt's voice wins for the commentary that surrounds it.
 
 
-# PHASE 1 \u2014 BUILD THE ITINERARY
+# PHASE 1 \u2014 CLARIFY SCOPE FIRST (ask before building)
 
-Call \`leadbay_tour_plan({city: "{{arg:city}}"})\` with the default counts (6 follow-ups + 6 discover). If the response is \`status: "ambiguous_locations"\`, surface the candidates and ask me to pick one, then re-call with \`city_id\`.
+Before calling \`leadbay_tour_plan\`, ask me what the tour should cover \u2014 a field tour is high-intent and the scope changes what lands on the map. Use your host's interactive question widget (\`ask_user_input_v0\` in Claude chat \u2014 \`{questions:[{question, type:"single_select", options:[\u2026]}]}\`; or \`AskUserQuestion\` in cowork / Claude Code \u2014 \`{questions:[{question, header, multiSelect, options:[{label, description}]}]}\`). Ask at most 2 short tap-to-answer questions:
 
-Split the returned \`monitor_leads\` into two buckets client-side using \`last_monitor_action\`:
+1. **Who to include?** \u2014 options: "Mix \u2014 known accounts + fresh prospects" (default), "Only my known accounts (follow-ups)", "Only fresh new prospects".
+2. **Enrich contacts that have no phone/email?** \u2014 options: "Yes, enrich the top stops", "No, just plan the tour".
 
-- **Customers** \u2014 leads with any \`last_monitor_action\` history (CONTACTED, MEETING_BOOKED, etc.). Treat as known accounts with prior engagement.
-- **Qualified prospects** \u2014 leads with high \`ai_agent_lead_score\` (or \`score\`) but no recent action.
+Skip a question only if I already answered it in my request (e.g. "plan a tour of just my new leads in NYC" \u2192 who-to-include is already "only new"; don't re-ask). If I gave the full scope up front, skip PHASE 1 entirely and go to PHASE 2.
+
+Map my answers to the \`leadbay_tour_plan\` call:
+- **Mix** \u2192 defaults (\`followups_count: 6, discover_count: 6\`).
+- **Only known accounts** \u2192 \`discover_count: 0\`.
+- **Only new prospects** \u2192 \`followups_count: 0\`.
+- **Enrich = yes** \u2192 after the tour is planned (PHASE 2), call \`leadbay_enrich_titles\` / \`leadbay_prepare_outreach(enrich:true)\` on the top stops that have no \`recommended_contact\` channel, before drafting outreach.
+
+# PHASE 2 \u2014 BUILD THE ITINERARY
+
+Call \`leadbay_tour_plan({city: "{{arg:city}}", \u2026scope from PHASE 1})\`. If the response is \`status: "ambiguous_locations"\`, surface the candidates and ask me to pick one, then re-call with \`city_id\`.
+
+Split the returned \`monitor_leads\` into two buckets client-side using their engagement-history fields:
+
+- **Customers** \u2014 leads with prior engagement history: any of \`epilogue_status\`, \`last_prospecting_action_at\`, or \`last_monitor_action_at\` is set. Treat as known accounts with prior interaction.
+- **Qualified prospects** \u2014 leads with a high \`ai_agent_lead_score\` (or \`score\`) but none of those history fields set (scored, not yet worked).
 
 \`discover_leads\` are the **New** bucket.
 
 Aim for a 3+3+3 split if possible. If the customers bucket has fewer than 3, fill from qualified. If discover_filter_note indicates a low match ratio for the city, mention it: "Only N/30 fresh leads matched your city" \u2014 better honest than padded.
 
-# PHASE 2 \u2014 RENDER THE MAP
+# PHASE 3 \u2014 PRESENT THE ITINERARY + OFFER THE MAP
+
+Show the planned tour as a concise per-lead list grouped by mode (Customers \u2192 Qualified \u2192 New), each line carrying its \`\u2605\`/\`\u2726\` badge, the company, city, and best contact. Keep it tight \u2014 this is the summary, not the map.
+
+Then **ALWAYS offer the map as the immediate next step** \u2014 a tour is inherently geographic, so the map is the natural payoff. End the turn with a single clear proposal:
+
+> **Want me to put these <N> stops on a map?** I'll plot them so you can see the route for your <city> day.
+
+Make it a genuine yes/no offer (route it through \`ask_user_input_v0\` / \`AskUserQuestion\` when that's in your tool set, so it's a tappable choice; otherwise the one-line question above). Do NOT render the map yet, and do NOT bury the offer \u2014 proposing the map is mandatory on every tour, for BOTH "plan a prospecting tour in <city>" and "who's worth meeting in <city>" phrasings. If the user already said "show me on a map" / "give me the map" in their request, skip the offer and go straight to PHASE 4 (render).
+
+# PHASE 4 \u2014 RENDER THE MAP (when the user accepts, or asked for it up front)
+
+When the user says yes (or asked for the map in their original message), render it now. Two ways \u2014 you MUST do one, never a flat prose paragraph:
+
+**Path A \u2014 \`places_search\` + \`places_map_display_v0\` are in your tool set.** Use the **two-step** host flow (this is what draws a real street map, not a schematic scatter):
+
+1. **\`places_search\` first, once per lead** \u2014 query = each \`map_locations\` entry's \`name\` + full street \`address\` (e.g. "Brooklyn Brewery, 79 N 11th St, Brooklyn, NY"). Resolve all stops up front to get real \`place_id\`s + verified coords/ratings.
+2. **\`places_map_display_v0\` second**, fed those resolved places, in **Itinerary mode** (a tour is a multi-stop route \u2014 show order, optionally arrival times / stop durations). Carry each lead's \u2605/\u2726 badge + one-line pitch from its \`notes\` into the place note.
 
-Route the union of \`monitor_leads + discover_leads\` into \`places_map_display_v0\` (when the host exposes it). Per-lead \`notes\` string:
+Do NOT push raw \`latitude\`/\`longitude\` straight into the display widget without \`places_search\` \u2014 that degrades to the neighborhood-dot scatter. \`map_locations\` already carries \`name\`, full \`address\`, coords, and badge-tagged \`notes\`; don't shorten the address to the city.
 
-- \`\u2605 Customer \u2014 <one-sentence sector + why-now>. Reach <name>, <role>: <bare phone>, <bare email>.\`
-- \`\u2605 Qualified \u2014 <one-sentence>. Reach <name>...\`
-- \`\u2726 New \u2014 <one-sentence>. Reach <name>...\`
+**Path B \u2014 the widget is NOT in your tool set (e.g. Claude Desktop).** Emit one **place-card block per lead** in EXACTLY this shape so the chat host auto-detects the address and renders its own Google-Place-card map carousel \u2014 the \`### Company \xB7 City, State\` heading + address is what triggers it:
 
-Skip leads with \`location.pos === null\` (no coordinates \u2192 no pin) \u2014 list them as "+ N leads without coordinates" below the widget.
+\`\`\`
+### <Company Name> \xB7 <City>, <State>
+
+<\u2605 Customer | \u2605 Qualified | \u2726 New> \u2014 <one-sentence why-it-fits>. Reach **[<Contact name>](<LinkedIn URL>)**, <role>. \u260E <bare phone>.
+\`\`\`
+
+One block per lead in \`map_locations\`, grouped by mode. Pull company, city/state, badge, and contact straight from the tool response. A flat paragraph like "Brooklyn Brewery \u2014 Broadway, 10018 (Midtown). Best contact: \u2026" does NOT auto-detect and is WRONG \u2014 the per-lead heading with the city is mandatory.
 
-Below the widget, emit a chat-prose summary grouped by mode (Customers / Qualified / New), with LinkedIn-linked contact name + bare phone/email pills per lead. Use the canonical \`linking/contact-linkedin\` rules.
+Coordinate-less leads are already omitted from \`map_locations\`; footnote them with \`map_summary.leads_without_coords\` ("+ N leads without coordinates").
 
-# PHASE 3 \u2014 DRAFT IN-AREA OUTREACH (optional, ask first)
+# PHASE 5 \u2014 DRAFT IN-AREA OUTREACH (optional, ask first)
 
 After the map, ask me ONCE: "Want me to draft 'I'll be in {{arg:city}}{{arg:date_paren}}' outreach for the top accounts?" If I say yes, for each of the top 3 leads (1 Customer / 1 Qualified / 1 New), call \`leadbay_prepare_outreach(leadId)\` and route the draft through \`message_compose_v1\` with a single variant labeled "In-area visit" \u2014 body opens with the visit context, references the AI-summary angle, ends with a clear ask (15-min coffee / on-site stopover).
 
 Serialize the prepare_outreach calls (max 3 in parallel \u2014 see the long-running-tools rule).
 
-# PHASE 4 \u2014 PERSIST AS A CAMPAIGN (optional, ask first)
+# PHASE 6 \u2014 PERSIST AS A CAMPAIGN (optional, ask first)
 
 After drafts, ask me ONCE: "Save these 9 accounts as a campaign called '**{{arg:city}} Tour{{arg:date_dash}}**'?" If I say yes, call \`leadbay_create_campaign({lead_ids: [...all_nine_lead_ids], name: "{{arg:city}} Tour{{arg:date_dash}}"})\`. Surface the returned \`id\` + \`name\` as a confirmation line, and offer the NEXT STEPS chip "View progression" (which routes to \`leadbay_campaign_progression\`).
 
 If I declined the campaign step, end the turn \u2014 the map + drafts are enough for an ad-hoc trip.
 
-# PHASE 5 \u2014 STOP
+# PHASE 7 \u2014 STOP
 
 Done. The map is the surface; the drafts are the action; the campaign is the persistence layer for managerial follow-up after the trip.
 `;
@@ -1261,7 +1297,7 @@ var PROMPT_META = {
   leadbay_followup_check_in: { "name": "leadbay_followup_check_in", "short_description": 'Follow-up check-in: surface KNOWN leads from the Monitor view needing\nre-engagement. Trigger on "follow up", "already known leads", "what\'s\noverdue", "before my trip", "who should I re-engage". Do NOT trigger on\n"show me today\'s leads", "my morning check-in", "run my check-in",\n"I do this every day", "every morning" \u2014 those go to\n`leadbay_daily_check_in`.\n', "arguments": [], "expected_calls": ["leadbay_pull_followups", "leadbay_research_lead_by_id", "leadbay_prepare_outreach"], "failure_modes": ["Calls leadbay_pull_leads (the Discover entry point) instead of leadbay_pull_followups \u2014 these are different data sources; the Discover queue does NOT contain Monitor's known-but-cold pipeline", 'Iterates pages of leadbay_pull_leads filtering by engagement_count to "fake" a follow-up view (a real bug observed in 0.9.0 \u2014 the right move is to call pull_followups directly)', "Replaces the canonical pull_followups table layout with prose per row (the per-tool RENDERING block is the structural contract; commentary belongs above or below)", 'Skips the cross-mode pivot offer at the end ("Want to see NEW leads from your wishlist instead?" routes to leadbay_pull_leads)'] },
   leadbay_import_file: { "name": "leadbay_import_file", "short_description": "Import a user-supplied CSV/file into Leadbay through five phases with\nevidence gates \u2014 scan, derive, resolve identities, preserve & commit,\nthen optionally qualify and report. The job is to maximize how many\nrows the Leadbay system actually ingests and matches.\n", "arguments": [{ "name": "file", "description": "Path or user-visible name of the CSV/file to import. If omitted, use the file the user attached or referenced.", "required": false }, { "name": "instruction", "description": 'Additional user goal, e.g. "then qualify the leads", "preserve owner phone as a custom field", or "only import restaurants in Manhattan".', "required": false }], "expected_calls": ["leadbay_resolve_import_rows", "leadbay_list_mappable_fields", "leadbay_create_custom_field", "leadbay_import_leads", "leadbay_import_and_qualify", "leadbay_add_note", "leadbay_import_status"], "failure_modes": ["Picks LEADBAY_ID from score alone, name-only, fuzzy-name-only, root-domain-only, brand-only, postcode-only, or city-only evidence", "Drops meaningful business notes or CRM record links instead of preserving them as custom fields or lead notes", "Treats a consumer mailbox domain (gmail.com, hotmail.com, ...) as the company domain", "Skips deriving company_domain from a business email when no website column exists (this kills match rate)", "Skips the COLUMN PRESERVATION PLAN byproduct before importing", "Skips the DECISION LOG byproduct before writing LEADBAY_ID", "Returns the imported records WITHOUT writing LEADBAY_ID values back into the user's file (leaves the user no audit trail of what matched)", "Fabricates leadIds, contact emails, or mapping IDs not present in the file or a tool response"] },
   leadbay_log_outreach: { "name": "leadbay_log_outreach", "short_description": "Log outreach (an email I sent, a call I made, a meeting I had) on a\nspecific lead. Captures verification so the SDR pipeline trusts the entry.\n", "arguments": [{ "name": "lead_id", "description": "The lead UUID. Get it from leadbay_pull_leads or leadbay_research_lead_by_id.", "required": true }, { "name": "summary", "description": "1-2 sentences describing what I did (e.g. 'Sent intro email to CTO citing recent Hornsea contract').", "required": true }], "expected_calls": ["leadbay_report_outreach"], "failure_modes": ["Calls leadbay_report_outreach without first collecting a verification source", "Fabricates a gmail_message_id or calendar_event_id (the human team treats verification as canonical)", "Records outreach to a different lead_id than the one the user supplied", "Skips the dry_run step when the user is unsure what would be sent"] },
-  leadbay_plan_tour_in_city: { "name": "leadbay_plan_tour_in_city", "short_description": "Plan a field sales tour: in one flow, surface follow-ups + fresh\nDiscover leads in the target city via `leadbay_tour_plan`, render\nto a map, draft in-area outreach via `leadbay_prepare_outreach`,\nand optionally persist the selected accounts as a named campaign\nvia `leadbay_create_campaign`. Closes #3630 US1 end-to-end.\n", "arguments": [{ "name": "city", "description": "City or region the user is visiting (e.g. 'Limoges', 'Bay Area'). Used as the geo filter for both Monitor and Discover lookups.", "required": true }, { "name": "date", "description": "When the visit is (e.g. 'May 24', 'next Thursday'). Surfaced in the outreach drafts as 'I'll be in <city> on <date>'.", "required": false }], "expected_calls": ["leadbay_tour_plan", "leadbay_research_lead_by_id", "leadbay_prepare_outreach", "leadbay_create_campaign"], "failure_modes": ["Calls leadbay_followups_map (Monitor-only) instead of leadbay_tour_plan \u2014 loses the Discover (fresh-lead) half that the user explicitly asked for", "Calls leadbay_pull_leads then drops the geo filter \u2014 returns the lens-wide wishlist instead of city-relevant fresh leads", 'Skips the campaign-persist step ("would you like to save these as a tour?") \u2014 leaves the rep with a one-shot map but no follow-up artifact', "Creates a campaign WITHOUT asking the user first \u2014 the persist step is high-intent; offer it, don't assume", "Fabricates lead_ids when seeding the campaign instead of using the ids returned by tour_plan"] },
+  leadbay_plan_tour_in_city: { "name": "leadbay_plan_tour_in_city", "short_description": 'Use whenever the user names a city they\'ll be in and asks who to see\n\u2014 "I\'m in SF next Tuesday, who\'s worth meeting?", "I\'m going to Berlin\n\u2014 who should I visit?", "plan my <city> tour". Any in-person/visit\nintent tied to a place routes here, NOT to `leadbay_pull_leads`. It\nsurfaces follow-ups + fresh Discover leads in the city via\n`leadbay_tour_plan`, ALWAYS offers to plot them on a map (rendering it\non yes), then offers outreach drafts + campaign persistence.\n', "arguments": [{ "name": "city", "description": "City or region the user is visiting (e.g. 'Limoges', 'Bay Area'). Used as the geo filter for both Monitor and Discover lookups.", "required": true }, { "name": "date", "description": "When the visit is (e.g. 'May 24', 'next Thursday'). Surfaced in the outreach drafts as 'I'll be in <city> on <date>'.", "required": false }], "expected_calls": ["leadbay_tour_plan", "leadbay_research_lead_by_id", "leadbay_prepare_outreach", "leadbay_create_campaign"], "failure_modes": ["Calls leadbay_followups_map (Monitor-only) instead of leadbay_tour_plan \u2014 loses the Discover (fresh-lead) half that the user explicitly asked for", "Calls leadbay_pull_leads then drops the geo filter \u2014 returns the lens-wide wishlist instead of city-relevant fresh leads", 'Skips the campaign-persist step ("would you like to save these as a tour?") \u2014 leaves the rep with a one-shot map but no follow-up artifact', "Creates a campaign WITHOUT asking the user first \u2014 the persist step is high-intent; offer it, don't assume", "Fabricates lead_ids when seeding the campaign instead of using the ids returned by tour_plan"] },
   leadbay_prospecting_overview: { "name": "leadbay_prospecting_overview", "short_description": `Orientation for working with Leadbay from any host \u2014 discovery vs.
 follow-up, the outreach loop, outcome recording, imports, pushback /
 snooze, and the connected-outreach-tool registry. Trigger when the
@@ -1283,7 +1319,7 @@ var PROMPT_CATALOG_BULLETS = {
   leadbay_followup_check_in: `- \`leadbay_followup_check_in\`: Follow-up check-in: surface KNOWN leads from the Monitor view needing re-engagement. Trigger on "follow up", "already known leads", "what's overdue", "before my trip", "who should I re-engage". Do NOT trigger on "show me today's leads", "my morning check-in", "run my check-in", "I do this every day", "every morning" \u2014 those go to \`leadbay_daily_check_in\`.`,
   leadbay_import_file: `- \`leadbay_import_file\` (optional args: file, instruction): Import a user-supplied CSV/file into Leadbay through five phases with evidence gates \u2014 scan, derive, resolve identities, preserve & commit, then optionally qualify and report. The job is to maximize how many rows the Leadbay system actually ingests and matches.`,
   leadbay_log_outreach: `- \`leadbay_log_outreach\` (required args: lead_id, summary): Log outreach (an email I sent, a call I made, a meeting I had) on a specific lead. Captures verification so the SDR pipeline trusts the entry.`,
-  leadbay_plan_tour_in_city: `- \`leadbay_plan_tour_in_city\` (required args: city; optional args: date): Plan a field sales tour: in one flow, surface follow-ups + fresh Discover leads in the target city via \`leadbay_tour_plan\`, render to a map, draft in-area outreach via \`leadbay_prepare_outreach\`, and optionally persist the selected accounts as a named campaign via \`leadbay_create_campaign\`. Closes #3630 US1 end-to-end.`,
+  leadbay_plan_tour_in_city: `- \`leadbay_plan_tour_in_city\` (required args: city; optional args: date): Use whenever the user names a city they'll be in and asks who to see \u2014 "I'm in SF next Tuesday, who's worth meeting?", "I'm going to Berlin \u2014 who should I visit?", "plan my <city> tour". Any in-person/visit intent tied to a place routes here, NOT to \`leadbay_pull_leads\`. It surfaces follow-ups + fresh Discover leads in the city via \`leadbay_tour_plan\`, ALWAYS offers to plot them on a map (rendering it on yes), then offers outreach drafts + campaign persistence.`,
   leadbay_prospecting_overview: `- \`leadbay_prospecting_overview\`: Orientation for working with Leadbay from any host \u2014 discovery vs. follow-up, the outreach loop, outcome recording, imports, pushback / snooze, and the connected-outreach-tool registry. Trigger when the conversation involves Leadbay leads, prospecting, pipeline, follow-up, outreach, or lens / ICP \u2014 anything from "show me my leads" to "what should I follow up on" to "I'll send via lemlist".`,
   leadbay_qualify_top_n: `- \`leadbay_qualify_top_n\` (optional args: count): Bulk-qualify the top N un-qualified leads in the active lens. Uses leadbay_bulk_qualify_leads with a sensible default budget.`,
   leadbay_refine_audience: `- \`leadbay_refine_audience\` (required args: instruction): Refine the kind of leads Leadbay surfaces beyond firmographics, with a free-text instruction. Handles the clarification round-trip if the new prompt is ambiguous.`,
@@ -7210,7 +7246,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
 | \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
 | \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
 
@@ -7528,7 +7564,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
 | \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
 | \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
 
@@ -7784,7 +7820,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
 | \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
 | \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
 
@@ -8400,7 +8436,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
 | \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
 | \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
 
@@ -8532,7 +8568,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
 | \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
 | \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
 
@@ -8666,11 +8702,11 @@ email. Do NOT paste the email body into chat prose alongside.
 
 ---
 
-Prepare a single-lead outreach brief: the full \`lead\` block (score, \`split_ai_summary\`, \`location\`, \`size\`, \`phone_numbers\`, \`website\`, \`description\`, \`social_urls\`, \`social_presence\`), the \`recommended_contact\` (always in the post-enrichment shape \u2014 \`contact_id\`, \`first_name\`, \`last_name\`, \`job_title\`, \`email\`, \`phone_number\`, \`linkedin_page\`, \`is_org_contact\` \u2014 with nulls where data isn't yet enriched), \`additional_contacts_count\`, and an \`enrichment\` block describing async state.
+Prepare a single-lead outreach brief: the full \`lead\` block (score, \`split_ai_summary\`, \`location\`, \`size\`, \`phone_numbers\`, \`website\`, \`description\`, \`social_urls\`, \`social_presence\`), the \`recommended_contact\` in post-enrichment shape (\`contact_id\`, names, \`job_title\`, \`email\`, \`phone_number\`, \`linkedin_page\`, \`is_org_contact\` \u2014 nulls where not yet enriched), \`additional_contacts_count\`, and an \`enrichment\` block describing async state.
 
 Optionally trigger contact enrichment in-flight with \`enrich:true\`. Enrichment is async (~60s). **Self-polling pattern (no separate tool needed):** re-call \`leadbay_prepare_outreach(leadId)\` without \`enrich\`; check \`enrichment.complete\`. When \`complete: true\`, the recommended contact now carries \`email\` and/or \`phone_number\`.
 
-The first call to this tool on a lead records a \`LEAD_VIEWED\`-style prospecting action server-side (one per lead per session \u2014 deduped) so the lead ages out of the Discover "new" view.
+The first call on a lead records a \`LEAD_VIEWED\`-style prospecting action server-side (deduped, one per lead per session) so it ages out of the Discover "new" view.
 
 IRON LAW \u2014 OUTCOME AFTER OUTREACH. The moment the user reports outreach happened ("I sent it", "she didn't pick up", "left a voicemail", "they replied", a forwarded email thread, a calendar invite), you MUST (1) call leadbay_report_outreach with verification (gmail_message_id, calendar_event_id, or the user's literal one-sentence confirmation as user_confirmed.ref) AND (2) ask the user about the outcome and set epilogue_status to one of the 4 canonical values: EPILOGUE_INTEREST_VALIDATED_OR_MEETING_PLANED ("Meeting booked"), EPILOGUE_COULD_NOT_REACH_STILL_TRYING ("Trying to reach"), EPILOGUE_NOT_INTERESTED_LOST ("Not interested"), EPILOGUE_STILL_CHASING ("In progress"). Use the user-facing labels in dialogue ("What's the outcome \u2014 meeting booked, trying to reach, not interested, or in progress?"); never say "epilogue" out loud. Skipping this step silently de-ranks every future follow-up suggestion because pull_followups depends on honest, current outcomes.
 
@@ -8685,7 +8721,7 @@ WHEN NOT TO USE: across many leads \u2014 use leadbay_enrich_titles for bulk; fo
 
 Route every draft through \`message_compose_v1\` (Claude's email composer). Above it, emit ONE short markdown context paragraph: score callout + sector fit + linked contact name + bare phone/email pills. Do NOT paste the email body into chat prose alongside \u2014 the composer IS the visual.
 
-Variant shape: 1\u20133 entries. Labels describe **strategy** ("Push for alignment", "Reference the M&A signal", "Soft intro \u2014 peer reference"), not tone. \`kind: "email"\` requires \`subject\`; phone/call openers use \`kind: "other"\` with the opener in \`body\`.
+Variant shape: 1\u20133 entries. Labels describe **strategy** ("Push for alignment", "Reference the M&A signal"), not tone. \`kind: "email"\` requires \`subject\`; phone/call openers use \`kind: "other"\` with the opener in \`body\`.
 
 ## GATE \u2014 PREFER BUILT-IN HOST WIDGETS
 
@@ -8695,7 +8731,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
 | \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
 | \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
 
@@ -9024,7 +9060,7 @@ Trigger phrases: "show me leads", "show me new leads", "show me today's leads",
 
 **Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
 
-Do NOT use for: "leads I should follow up with" \u2192 \`leadbay_pull_followups\`; "I'm going to <city>" \u2192 \`leadbay_followups_map\`; "leads I should reach out to" \u2192 \`leadbay_pull_followups\`; "leads to get back to" \u2192 \`leadbay_pull_followups\`; "leads to contact today" \u2192 \`leadbay_pull_followups\`; "should I contact" \u2192 \`leadbay_pull_followups\`; "reconnect with" \u2192 \`leadbay_pull_followups\`; "re-engage" \u2192 \`leadbay_pull_followups\`.
+Do NOT use for: "leads I should follow up with" \u2192 \`leadbay_pull_followups\`; "I'm going to <city>" \u2192 \`leadbay_tour_plan\`; "I'm in <city> next week \u2014 who's worth meeting" \u2192 \`leadbay_tour_plan\`; "who should I meet in <city>" \u2192 \`leadbay_tour_plan\`; "visiting <city> \u2014 who's worth meeting / seeing" \u2192 \`leadbay_tour_plan\`; "leads I should reach out to" \u2192 \`leadbay_pull_followups\`; "leads to get back to" \u2192 \`leadbay_pull_followups\`; "leads to contact today" \u2192 \`leadbay_pull_followups\`; "should I contact" \u2192 \`leadbay_pull_followups\`; "reconnect with" \u2192 \`leadbay_pull_followups\`; "re-engage" \u2192 \`leadbay_pull_followups\`.
 
 Prefer when: fresh Discover leads; if a lens is named, pass \`lensId\` and pin it
 
@@ -9035,6 +9071,7 @@ Examples that SHOULD invoke this tool:
 Examples that should NOT invoke this tool (sound similar, route elsewhere):
 - "Which leads should I follow up with this week?"
 - "I'm flying to Berlin Thursday \u2014 who should I meet?"
+- "I'm in San Francisco next Tuesday \u2014 who's worth meeting?"
 - "Show me leads I should reach out to today."
 - "Who should I get back to today?"
 - "Leads I should contact today."
@@ -10232,7 +10269,7 @@ WHEN NOT TO USE: the user wants a lead list (leadbay_pull_leads / leadbay_pull_f
 `;
 var leadbay_tour_plan = `## WHEN TO USE
 
-Trigger phrases: "visiting <city> in <N> days", "field tour in <city>", "plan a tour in <city>", "who should I meet in <city>", "customers plus prospects in <city>", "tour itinerary".
+Trigger phrases: "visiting <city> in <N> days", "I'm in <city> next week / Tuesday \u2014 who's worth meeting", "I'm going to <city> \u2014 who should I see", "who's worth meeting in <city>", "field tour in <city>", "plan a tour in <city>", "who should I meet in <city>", "customers plus prospects in <city>", "tour itinerary".
 
 **Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
 
@@ -10242,6 +10279,7 @@ Prefer when: user wants known accounts plus new discoveries in one geographic it
 
 Examples that SHOULD invoke this tool:
 - "I'm flying to Limoges in 4 days \u2014 give me 3 customers, 3 qualified prospects, and 3 new high-potential."
+- "I'm in San Francisco next Tuesday. Who's worth meeting?"
 - "Plan my tour next Tuesday in Lyon: known accounts plus discoveries."
 - "Build a mixed itinerary for Berlin \u2014 I want both follow-ups and fresh leads."
 
@@ -10252,16 +10290,18 @@ Examples that should NOT invoke this tool (sound similar, route elsewhere):
 
 ## RENDER (quick)
 
-Route the union of monitor_leads + discover_leads into
-\`places_map_display_v0\` \u2014 same recipe as followups_map (lat/lng
-split, full address, short notes). Tag each entry's notes with a
-mode badge: "\u2605 Customer" / "\u2605 Qualified" / "\u2726 New" (split Monitor
-by last_monitor_action; Discover = New). Below the widget: one
-intro sentence + per-group chat-prose list with LinkedIn-linked
-contact names.
+Present the leads grouped by mode (\u2605 Customer / \u2605 Qualified / \u2726 New),
+then ALWAYS offer to plot them on a map ("Want me to put these on a
+map?"). On yes (or if the user asked for a map up front), render it:
+pass \`map_locations\` verbatim into \`places_map_display_v0\`, or on a
+host without the widget emit one \`### Company \xB7 City, State\` place-card
+block per lead so the host's address carousel renders. Never a flat
+prose paragraph. Full recipe below.
 
 ---
 
+**BEFORE YOU CALL \u2014 clarify scope with a tap-to-answer question.** A field tour is high-intent, so unless the user already said it, ASK first (via \`ask_user_input_v0\` / \`AskUserQuestion\` \u2014 whichever is in your tool set) and wait for the answer before calling this tool: (1) **Who to include?** \u2014 "Mix \u2014 known accounts + fresh prospects" (default) / "Only my known accounts" / "Only fresh new prospects"; (2) **Enrich contacts with no phone/email?** \u2014 "Yes, enrich the top stops" / "No, just plan". Map answers to args: only-known \u2192 \`discover_count: 0\`; only-new \u2192 \`followups_count: 0\`; mix \u2192 defaults; enrich=yes \u2192 after planning, run \`leadbay_enrich_titles\` / \`leadbay_prepare_outreach(enrich:true)\` on top stops missing a channel. Skip the question only if the request already states scope ("plan a tour of just my new leads" \u2192 only-new, don't ask). Do NOT skip straight to building + mapping without this.
+
 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 admin level \u2014 city, state, country, region \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\`.
@@ -10272,21 +10312,30 @@ Build a single-call mixed-mode itinerary for a field sales tour. Combines \`lead
 
 ---
 
-## RENDER \u2014 host-native map widget (REQUIRED, preferred)
+## RENDER \u2014 present the leads, then OFFER the map (render on yes)
+
+First present the leads grouped by mode as a tight per-lead list (badge + company + city + best contact). Then **ALWAYS offer the map** as the next step \u2014 "Want me to put these on a map?" \u2014 and render it only when the user accepts (or asked for a map in their original message). The map is mandatory to *offer* on every tour; it is *rendered* on acceptance.
 
-Identical to \`leadbay_followups_map\`. Pass the union \`monitor_leads + discover_leads\` into \`places_map_display_v0\`. The mode information goes in the per-lead \`notes\` string as a **leading badge**:
+When rendering, use the **two-step host flow** \u2014 this is what produces a real interactive street map instead of a schematic neighborhood scatter:
 
-- \`\u2605 Customer\` \u2014 Monitor lead with an existing \`last_monitor_action\` history (engaged / past interaction).
-- \`\u2605 Qualified\` \u2014 Monitor lead with a high \`ai_agent_lead_score\` or \`score\` but no recent action.
+1. **\`places_search\` first, once per lead.** For each entry in \`map_locations\`, call \`places_search\` with a natural query built from the lead's \`name\` + \`address\` (the full street address, e.g. "Brooklyn Brewery, 79 N 11th St, Brooklyn, NY"). This resolves a real \`place_id\` + verified coordinates/ratings from the host's place index. Run them up front (resolve all stops first), as the host's own guidance prescribes.
+2. **\`places_map_display_v0\` second**, fed the resolved places. Use **Itinerary mode** for a tour (multi-stop, route order, optional arrival times / stop durations) \u2014 a field-sales day IS an itinerary; Markers mode is only for a plain "show me X on a map". Carry each lead's mode badge (\u2605/\u2726) + one-line pitch from \`map_locations[i].notes\` into the place's note.
+
+Do NOT skip \`places_search\` and push raw \`latitude\`/\`longitude\` straight into the display widget \u2014 that's exactly what falls back to the schematic relative scatter (dots by neighborhood, no streets). The \`map_locations\` array already gives you everything \`places_search\` needs (\`name\`, full \`address\`, \`latitude\`, \`longitude\`, badge-tagged \`notes\`); do NOT shorten the address to just the city.
+
+For reference, the badge the server already applied to each \`notes\`:
+
+- \`\u2605 Customer\` \u2014 Monitor lead with prior engagement history (\`epilogue_status\`, \`last_prospecting_action_at\`, or \`last_monitor_action_at\` set).
+- \`\u2605 Qualified\` \u2014 Monitor lead with a high score but no recent action.
 - \`\u2726 New\` \u2014 Discover lead from \`discover_leads\`.
 
-Then the rest of the notes string follows the standard recipe: ONE sentence, sector/fit + contact ask, bare phone + email auto-linkified. Example:
+Example of a server-built \`notes\` string you pass through unchanged:
 
 \`\`\`
 \u2726 New \u2014 Strong mid-size hardware distributor fit. Reach Marie Dupont, Sales Director: +33 5 55 12 34 56, m.dupont@example.fr.
 \`\`\`
 
-Skip any lead whose \`location.pos\` is null (no lat/lng \u2192 no pin) \u2014 list them as a "+ N leads without coordinates" footer below the widget.
+Leads without coordinates are already omitted from \`map_locations\`. Use \`map_summary.leads_without_coords\` to footnote "+ N leads without coordinates" below the widget \u2014 no need to re-count.
 
 ## Chat prose AFTER the widget (where markdown DOES render)
 
@@ -10294,9 +10343,17 @@ Group the leads into THREE sections (Customers / Qualified Prospects / New Disco
 
 If the user said something like "3+3+3", honor that split. If \`followups_count\` returned fewer Customers than asked, fill from Qualified.
 
-## RENDER \u2014 fallback for hosts without \`places_map_display_v0\`
+## RENDER \u2014 fallback for hosts without \`places_map_display_v0\` (still a map, never a prose list)
+
+When the widget isn't in your tool set (e.g. Claude Desktop), you MUST still produce a map by emitting one place-card block per \`map_locations\` entry in EXACTLY this shape \u2014 the \`### Company \xB7 City, State\` heading with the address is what makes the host auto-detect it and render its own Google-Place-card carousel:
 
-Emit per-lead markdown blocks grouped by mode, in the standard place-card-friendly format (\`### **Company** \xB7 City, State\`, mode badge + score, contact line, channel lines). Hosts that auto-detect addresses (Claude.ai web, cowork) build their own carousel from these blocks.
+\`\`\`
+### <Company Name> \xB7 <City>, <State>
+
+<\u2605 Customer | \u2605 Qualified | \u2726 New> \u2014 <one-sentence fit>. Reach **[<Contact>](<LinkedIn URL>)**, <role>. \u260E <bare phone>.
+\`\`\`
+
+Group the blocks by mode (Customers \u2192 Qualified \u2192 New). A flat narrative paragraph ("Brooklyn Brewery \u2014 Broadway, 10018 (Midtown). Contact: \u2026") does NOT auto-detect into cards and is WRONG \u2014 the per-lead heading with the city is mandatory.
 
 ## GATE \u2014 PREFER BUILT-IN HOST WIDGETS
 
@@ -10306,7 +10363,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
 | \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
 | \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
 
@@ -10325,7 +10382,7 @@ WHEN TO USE: the user signals a *mixed* tour-planning intent \u2014 they want bo
 
 WHEN NOT TO USE: if the user only wants follow-ups (use \`leadbay_followups_map\`), only wants new leads (use \`leadbay_pull_leads\`), wants research on one specific account (\`leadbay_research_lead_by_id\`), or wants to persist the tour as a campaign artifact (chain into \`leadbay_create_campaign\` after this).
 
-**Response envelope**: \`{city, city_id, monitor_leads, discover_leads, discover_filter_note, _meta}\` on happy path; \`{status: "ambiguous_locations", location_ambiguities, ...}\` when the passed \`city\` matched multiple admin areas.
+**Response envelope**: \`{city, city_id, monitor_leads, discover_leads, discover_filter_note, map_locations, map_summary, _meta}\` on happy path; \`{status: "ambiguous_locations", location_ambiguities, ...}\` when the passed \`city\` matched multiple admin areas.
 
 ---
 `;
@@ -15670,6 +15727,54 @@ function cityMatches(lead, cityHint) {
   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 toMapLocation(lead, mode) {
+  const pos = lead?.location?.pos;
+  const valid = Array.isArray(pos) && pos.length === 2 && pos.every((n) => typeof n === "number");
+  if (!valid)
+    return null;
+  const loc = lead.location;
+  const c = lead.recommended_contact;
+  const cleanName = (v) => typeof v === "string" && v.trim() && v.trim().toLowerCase() !== "null" ? v.trim() : "";
+  const fullName = c ? [cleanName(c.first_name), cleanName(c.last_name)].filter(Boolean).join(" ") : "";
+  const role = cleanName(c?.job_title) ? `, ${cleanName(c?.job_title)}` : "";
+  const angle = lead.split_ai_summary?.next_step ?? lead.split_ai_summary?.approach_angle ?? lead.short_description ?? "Worth a visit";
+  let reach;
+  if (c && fullName && c.phone_number) {
+    reach = `Reach ${fullName}${role}: ${c.phone_number}${c.email ? `, ${c.email}` : ""}.`;
+  } else if (c && fullName && c.email) {
+    reach = `Reach ${fullName}${role}: ${c.email}.`;
+  } else if (c && fullName) {
+    reach = `Reach ${fullName} (enrich a channel).`;
+  } else {
+    reach = "Enrich a contact to reach this account.";
+  }
+  const notes = `${mode} \u2014 ${angle}. ${reach}`.slice(0, 280);
+  return {
+    name: lead.name,
+    address: loc.full ?? [loc.city, loc.state, loc.country].filter(Boolean).join(", "),
+    latitude: pos[0],
+    longitude: pos[1],
+    notes
+  };
+}
+function hasMonitorHistory(lead) {
+  return Boolean(lead?.epilogue_status || lead?.last_prospecting_action_at || lead?.last_monitor_action_at);
+}
+function buildMap(monitorLeads, discoverLeads2) {
+  const mapLocations = [
+    ...monitorLeads.map((l) => toMapLocation(l, hasMonitorHistory(l) ? "\u2605 Customer" : "\u2605 Qualified")),
+    ...discoverLeads2.map((l) => toMapLocation(l, "\u2726 New"))
+  ].filter((m) => m !== null);
+  const totalLeads = monitorLeads.length + discoverLeads2.length;
+  return {
+    map_locations: mapLocations,
+    map_summary: {
+      total_leads: totalLeads,
+      leads_with_coords: mapLocations.length,
+      leads_without_coords: totalLeads - mapLocations.length
+    }
+  };
+}
 var tourPlan = {
   name: "leadbay_tour_plan",
   annotations: {
@@ -15721,6 +15826,20 @@ var tourPlan = {
         type: "string",
         description: "Human-readable summary of the client-side geo filter applied to Discover leads (e.g. 'matched 3/30 by city/state')."
       },
+      map_locations: {
+        type: "array",
+        description: "Pre-shaped entries for `places_map_display_v0` \u2014 pass each one verbatim ({name, address, latitude, longitude, notes}); the mode badge (\u2605 Customer / \u2605 Qualified / \u2726 New) is already in `notes`. Do NOT reshape or re-derive from `location.pos`. One entry per lead with valid coordinates; coordinate-less leads are omitted and counted in `map_summary`.",
+        items: { type: "object" }
+      },
+      map_summary: {
+        type: "object",
+        description: "Deterministic coverage counts so the agent can footnote '+ N leads without coordinates' without re-counting.",
+        properties: {
+          total_leads: { type: "number" },
+          leads_with_coords: { type: "number" },
+          leads_without_coords: { type: "number" }
+        }
+      },
       status: {
         type: "string",
         description: "'ambiguous_locations' when the passed `city` matched multiple admin areas \u2014 pick an id from location_ambiguities and re-call with city_id."
@@ -15737,7 +15856,7 @@ var tourPlan = {
         }
       }
     },
-    required: ["monitor_leads", "discover_leads"]
+    required: ["monitor_leads", "discover_leads", "map_locations"]
   },
   execute: async (client, params, ctx) => {
     const followupsCount = params.followups_count ?? DEFAULT_FOLLOWUPS_COUNT;
@@ -15759,6 +15878,12 @@ var tourPlan = {
           monitor_leads: [],
           discover_leads: [],
           discover_filter_note: "City was ambiguous; pick an id and re-call to proceed.",
+          map_locations: [],
+          map_summary: {
+            total_leads: 0,
+            leads_with_coords: 0,
+            leads_without_coords: 0
+          },
           city: params.city ?? null,
           city_id: params.city_id ?? null,
           _meta: {
@@ -15785,6 +15910,7 @@ var tourPlan = {
       monitor_leads: monitorLeads,
       discover_leads: discoverLeads2,
       discover_filter_note: filterNote,
+      ...buildMap(monitorLeads, discoverLeads2),
       _meta: {
         region: client.region,
         latency_ms: client.lastMeta?.latency_ms ?? null
@@ -23888,7 +24014,7 @@ function parseWriteEnv(env = process.env) {
 }
 
 // src/http-server.ts
-var VERSION = true ? "0.23.6" : "0.0.0-dev";
+var VERSION = true ? "0.23.7" : "0.0.0-dev";
 var PORT = Number(process.env.PORT ?? 8080);
 var HOST = process.env.HOST ?? "0.0.0.0";
 var sseSessions = /* @__PURE__ */ new Map();

package/dist/installer-electron.js

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

package/dist/installer-gui.js

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leadbay/mcp",
-  "version": "0.23.6",
+  "version": "0.23.7",
   "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",