@elitedcs/ghl-mcp 3.45.0 → 3.46.0

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "@elitedcs/ghl-mcp",
-  "version": "3.45.0",
+  "version": "3.46.0",
   "mcpName": "io.github.drjerryrelth/ghl-command",
-  "description": "GoHighLevel MCP Server for Claude. 218 tools — full CRM, automation, marketing control, account-wide workflow audit, and the only programmatic GHL workflow builder, now multi-tenant across client accounts.",
+  "description": "GoHighLevel MCP Server for Claude. 220 tools — full CRM, automation, marketing control, account-wide workflow audit, live funnel-capture verification, and the only programmatic GHL workflow builder, now multi-tenant across client accounts.",
   "main": "dist/index.js",
   "bin": {
     "ghl-mcp": "dist/index.js"

package/templates/external-funnel/README.md

@@ -42,7 +42,21 @@ The executor returns what you plug into the Worker config + form:
    TURNSTILE_SECRET`.
 5. `wrangler deploy` → point your form at the Worker URL.
 
+## Why a bridge and not a raw GHL inbound-webhook
+A GHL **inbound-webhook-triggered workflow runs *contactless*** — unless that
+workflow has a Create/Update Contact action with every payload field mapped, GHL
+runs the whole thing into the void: tags fire on nobody, emails send to no one,
+the execution log still shows green, and **no contact is ever created.** The lead
+silently evaporates. This bridge avoids that entire failure class by creating the
+contact itself via `/contacts/upsert` (the contacts API, not a trigger), then
+adding the tag — so your workflow always fires on a **real contact**. If you ever
+wire a raw inbound webhook instead, it MUST start with a mapped Create/Update
+Contact action or it's a paper shredder.
+
 ## Safety built in
+- **Lead is actually created** — the bridge writes the contact through the
+  contacts API and only reports success on a 2xx from GHL (not a thank-you page).
+  See "Why a bridge…" above for the contactless-webhook trap this sidesteps.
 - **Secret stays server-side** — the token lives only as a Cloudflare secret, never
   in the browser.
 - **Spam gate** — honeypot field (`_hp`) + Cloudflare Turnstile. **Strongly enable
@@ -64,6 +78,23 @@ what you want. If you need returning submitters re-enrolled, set `RE_ENROLL=true
 (the Worker removes + re-adds the tag) AND enable re-enrollment on the workflow.
 Confirm the behavior on your account before relying on it.
 
+## Verify after deploy (the form is not proof)
+A live form, a success toast, and a green workflow run are **not** verification —
+a funnel can show every happy signal while the contact never lands. Before you
+call it done, prove it on the **real production URL** (not the worker in isolation,
+not a local deploy):
+1. **Happy path → backend truth.** Submit the live form with a real email, wait
+   ~60s, then `search_contacts` for it. No contact = your form is a paper shredder.
+2. **Field persistence — check directly.** Open the created contact and confirm
+   each custom field actually saved. A wrong/stale field id makes upsert succeed
+   while silently dropping that value. This is why the wiring bundle gives you
+   **verified GHL field IDs** — send those, never guessed names/keys.
+3. **Duplicate-contact retest.** Submit the SAME email twice. Correct result: one
+   contact (upsert deduped), fields updated, no error. A second contact or a
+   false failure means dedup is broken — catch it before real traffic does.
+4. **Booking, if you wired it.** A reachable calendar URL is not proof. Book one
+   real test ("burner") appointment through it and confirm it lands in GHL.
+
 ## Compliance
 If your workflow sends SMS/email, your external form MUST collect explicit consent
 (a checkbox + clear copy). Define a **consent custom field** in your Blueprint plan