@elitedcs/ghl-mcp 3.13.1 → 3.15.0

package/CHANGELOG.md

@@ -1,5 +1,40 @@
 # Changelog
 
+## 3.15.0 — Email-template delete, rename, archive (Firebase-gated)
+
+**206 tools across 43 modules (+3). Manage email templates without leaving Claude.**
+
+Until now you could create and update email templates through the public API, but deleting or renaming one meant clicking through the GHL UI — the public bearer API 404s on both. Those mutations live on the internal API behind Firebase auth. Confirmed working 2026-05-24 against the MCP Testing sandbox and verified end-to-end (create → rename → archive → unarchive → delete, round-trip clean).
+
+### New tools (3, all require Firebase configured)
+
+- **`delete_email_template`** — hard delete a template by id. Irreversible. Breaks any workflow email action or draft campaign that references it.
+- **`rename_email_template`** — change a template's display title only; HTML content and sender settings untouched.
+- **`archive_email_template`** — archive (`archived: true`) or restore (`archived: false`) a template. Removes it from the active list without deleting it — the reversible alternative to delete.
+
+All three hit `backend.leadconnectorhq.com/emails/builder` with the workflow-builder Firebase token (the GHL UI persists via Firestore, but the REST routes exist server-side). Registered by `registerEmailBuilderInternalTools` in the internal-API block. `update_email_template`'s description now points at `rename_email_template` / `delete_email_template` instead of telling you to use the UI.
+
+## 3.14.0 — Multi-tenant Firebase: run the workflow builder in clients' accounts
+
+**203 tools across 43 modules (+2). The workflow builder is no longer single-company.**
+
+GHL Firebase refresh tokens are **company-scoped**. Until now `switch_location` swapped the per-location PIT key (public API) but never the Firebase auth, so the moment you switched into a client's GHL — even one where you're an admin user — every Firebase-gated tool (workflow builder, funnels, forms, pipelines, smart lists, reputation, email campaigns, memberships) returned 401. Those accounts were effectively read-only.
+
+Now one install can operate the workflow builder across multiple clients' GHL accounts.
+
+### How it works
+
+- **Per-company Firebase in the registry.** New `firebaseByCompany` map keyed by GHL companyId, alongside the existing "home" Firebase. Each registered location now also records its owning `companyId` (auto-detected by `register_location`).
+- **`switch_location` routes Firebase automatically.** It resolves the target location's company and swaps the workflow builder's Firebase auth to match — or restores your home auth when you switch back. If a company has no Firebase registered, it says so loudly instead of silently 401ing.
+- **Rotation is slot-aware.** When a refresh token rotates, it's persisted to the company that's currently active — a client's token never overwrites your home token, and vice versa.
+
+### New tools (2, both work without Firebase configured)
+
+- **`register_company_firebase`** — store a client company's Firebase creds (companyId, name, refresh token, user id; api key defaults to your home key). Optional `test_location_id` runs a real workflow-builder call to verify the credentials actually work for that company before you rely on them.
+- **`unregister_company_firebase`** — remove a company's Firebase creds.
+
+`list_registered_locations` now shows each location's company and which companies have Firebase wired up; `health_check` reports the active company. See the README "Working in Clients' Accounts" section for the full flow.
+
 ## 3.13.1 — Firebase token persistence fixes (reported by Don Harris)
 
 **Bug fixes. No tool changes — still 201 tools across 43 modules.**

package/README.md

@@ -1,6 +1,6 @@
 # GHL Command — GoHighLevel MCP Server
 
-**Full GoHighLevel API access for Claude.** 201 tools across 43 modules — manage contacts, conversations, pipelines, calendars, funnels, workflows, invoices, custom objects, webhooks, and more. **Includes full workflow builder, funnel/page editor, form builder, pipeline builder, bulk operations, account export, and workflow cloning** — capabilities no other GHL tool offers.
+**Full GoHighLevel API access for Claude.** 206 tools across 43 modules — manage contacts, conversations, pipelines, calendars, funnels, workflows, invoices, custom objects, webhooks, and more. **Includes full workflow builder, funnel/page editor, form builder, pipeline builder, bulk operations, account export, and workflow cloning** — capabilities no other GHL tool offers. **Multi-tenant:** one install can run the workflow builder across multiple clients' GHL accounts.
 
 **Distributed via npm as [`@elitedcs/ghl-mcp`](https://www.npmjs.com/package/@elitedcs/ghl-mcp).** Buyers install with one config block — no git, no Node.js setup, no terminal commands. Updates flow automatically (`npx @latest` re-resolves on every Claude restart).
 
@@ -138,7 +138,7 @@ https://app.gohighlevel.com/v2/location/YOUR_LOCATION_ID/dashboard
 
 ## Enable Workflow Builder (Optional)
 
-The 30 builder + cloner + validator tools (workflow builder, funnel builder, form builder, pipeline builder, workflow cloner, validate_workflow) use GHL'''s internal API and require Firebase credentials. Without them, the other 161 tools work fine — you just won'''t have workflow/funnel/form/pipeline editing.
+The builder + cloner + validator tools (workflow builder, funnel builder, form builder, pipeline builder, workflow cloner, validate_workflow) use GHL'''s internal API and require Firebase credentials. Without them, the other 163 tools work fine — you just won'''t have workflow/funnel/form/pipeline editing.
 
 Grab the three values from your GHL browser session, then re-run `setup_ghl_mcp` with them:
 
@@ -165,6 +165,37 @@ Re-run setup_ghl_mcp with workflow builder:
 
 > Firebase refresh tokens can rotate. If workflow tools stop working after a few weeks, repeat steps 1–7 and re-run setup_ghl_mcp with fresh values.
 
+## Working in Clients' Accounts (Multi-Tenant)
+
+The public-API tools work in any sub-account you have a Private Integration key for. The **workflow builder** (and every Firebase-gated tool) is different: GHL Firebase refresh tokens are **company-scoped**, so your own token can't build workflows inside a *client's* GHL — even if you're an admin user there. Without the client's own Firebase, those accounts are effectively read-only.
+
+To unlock full builder access across multiple clients from one install:
+
+1. **Register the client's sub-account key** so the public API works there:
+   ```
+   register_location
+     locationId: CLIENT_LOCATION_ID
+     name: "Client Name"
+     apiKey: pit-...   (a Private Integration created INSIDE the client's sub-account)
+   ```
+   This auto-detects and stores the owning **companyId**.
+
+2. **Capture the client's Firebase values** from a browser session logged into *their* account (same DevTools steps 1–7 above, but while viewing the client's GHL).
+
+3. **Register the client's company Firebase:**
+   ```
+   register_company_firebase
+     companyId: CLIENT_COMPANY_ID         (shown in register_location's output)
+     name: "Client Name"
+     ghl_firebase_refresh_token: FROM_STEP_7
+     ghl_user_id: FROM_STEP_6
+     test_location_id: CLIENT_LOCATION_ID  (optional — runs a live check that it works)
+   ```
+
+4. **Switch and build:** `switch_location CLIENT_LOCATION_ID` swaps both the API key *and* the Firebase auth automatically. The workflow builder now operates in the client's account. Switching back to your own location restores your home Firebase.
+
+`list_registered_locations` shows every location, its company, and which companies have Firebase wired up. `health_check` reports the active company. Rotated tokens are saved back to the correct client, never overwriting your own.
+
 ---
 
 ## Tools (190)