mcp-v0.23.11

Windows .dxt sign-in now opens the browser reliably (product#3839).

• openInBrowser (Windows) — the auto-open resolved the moment cmd.exe was created, before its internal start builtin actually handed the URL to the default browser. So a silent no-op (no default-browser protocol association, a locked-down shell / AppLocker, a corrupt HKCR\http\shell\open) went undetected: browserOpenFailedAtBootstrap stayed false and the user was told "a browser may have opened" when nothing did. On Windows we now wait (bounded — 800ms for cmd start, 1200ms otherwise) for the launcher's exit code, treat a non-zero exit as failure, and fall through to rundll32 url.dll,FileProtocolHandler (no command interpreter — the same ShellExecute path Explorer uses, with an honest exit code) and finally PowerShell Start-Process. When every launcher fails, the AUTH_REQUIRED envelope honestly says the browser couldn't be opened and shows the clickable sign-in link. The #3801 &-quoting cmd start candidate is unchanged and still tried first. macOS/Linux keep resolve-on-spawn (the #3805 headless-hang fix — those launchers are the hand-off).
• bin.ts shutdown — the browserOpenInFlight teardown wait rose 1.5s → 3s so the multi-launcher Windows walk can finish dispatching before exit (the sibling bootstrap wait already allows 4s; the surfaced sign-in link is the fallback either way).

mcp-v0.23.10

A freshly-created lens no longer reads as "empty" (product#3833).

• leadbay_new_lens — creating a lens with criteria queues an asynchronous backend wishlist rebuild, so an immediate leadbay_pull_leads can read empty for a few seconds while it computes. The created result now carries computing_wishlist: true and a "leads stream in — pull in ~30s" message so the agent waits instead of reporting an empty lens. A criteria-less clone inherits the base lens's leads immediately (computing_wishlist: false).
• leadbay_pull_leads — on an EMPTY page where the backend reports the lens is still computing (computing_wishlist/computing_scores), next_steps now carries a single "Re-pull in ~30s" option (kind: repull_computing) instead of null, so the agent renders a wait-and-retry widget rather than "no leads." An empty page with nothing computing still returns null (a genuinely empty / over-narrow lens — no fabricated leads).
• Confirmed against leadbay/backend (POST /lenses/:id/filter → queueRefreshJob → RefreshLens) and a live probe on api-us: a bare clone shows leads instantly; a filtered clone shows computing_wishlist: true then settles within ~1–30s.

mcp-v0.23.9

MCP data plane now targets backend /1.6 (was /1.5).

• client — every request path is built from a single API_VERSION = "1.6" constant (exported as API_PREFIX). LeadbayClient (request / requestVoid / requestRawBinary + mock-mode paths) and bin.ts's login probe all reference it, so future backend version bumps are a one-line change. Verified live on api-us before shipping: /1.6 mirrors /1.5 across the full route surface probed (monitor, lenses, auth/login, kpi, geo) — identical status on every call. Tool-description prose and route-doc comments updated to /1.6 to match.

mcp-v0.23.8

Installer no longer hangs in Claude Cowork / headless terminals (product#3805).

• installer — the guided installer awaited a detached browser-opener that resolved only on the child's close event, which a detached process often never emits; with no overall timeout the process dangled until the host (Claude Cowork) killed it ("running… then timeout", intermittently). It now reuses the hardened openInBrowser (resolves on spawn, not close), no longer blocks GUI startup on the browser open, and bounds the run with a watchdog that exits cleanly with hosted-MCP instructions instead of hanging. The installer always tries to open the browser — it never guesses "headless" and refuses to start.
• Docs — README documents adding Leadbay on Claude web / Cowork web as a custom Connector (Customize → Connectors → Add custom connector, URL https://leadbay-mcp-prod.fly.dev/mcp; OAuth runs in-app), and the claude mcp add --transport http equivalent. Stale @0.16 install snippets corrected to @latest.

mcp-v0.23.7

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.

mcp-v0.23.6

Geographic filter on Discover lenses (product#3759).

• leadbay_new_lens / leadbay_adjust_audience now accept locations / exclude_locations — a geographic dimension on the Discover lens, mirroring the sector path. Free text (["Indre-et-Loire"], ["Texas"]) auto-resolves via /geo/search, or pass admin-area ids directly. Resolution happens first: ambiguous/unresolved text returns ambiguous_locations and the lens is not mutated (no half-built lens). Resolved ids merge into the lens filter as a location_ids criterion. Unblocks the "scope a territory → net-new accounts there" cockpit workflow — geography was previously settable only on the Monitor side.

mcp-v0.23.5

See CHANGELOG.md for details.

mcp-v0.23.4

See CHANGELOG.md for details.

mcp-v0.23.3

• Release plumbing only — no functional change. First release on the updated CI that also publishes fixed-name leadbay-latest.dxt / .mcpb assets, so the docs can link a stable …/releases/latest/download/leadbay-latest.dxt that always resolves to the current version.

mcp-v0.23.2

• Installer GUI shows the version (product#3799) — the installer and uninstaller GUI cards now display the MCP version (e.g. v0.23.2) as a small muted-grey footer. Sourced from the build-time __LEADBAY_MCP_VERSION__ define, so it tracks package.json with no manual upkeep.