GoHighLevel MCP Server

A Model Context Protocol server that gives an LLM agent operational control of a GoHighLevel CRM — 114 tools across 24 modules, covering contacts, pipelines, calendars, messaging, invoicing, and payments over the GoHighLevel API v2.

The problem

GoHighLevel is the system of record for a small agency: every client, every booking, every invoice. The work that actually eats the day is not any single CRM action but the stitching between them — a shoot gets confirmed, so someone has to create the opportunity, move it to the right pipeline stage, book the calendar slot against the right contact, draft the invoice, and log a note. Each step is thirty seconds of clicking, and the sequence runs several times a week.

That sequence is exactly what an agent can do, if it can reach the CRM. This server is that reach: it exposes GoHighLevel as typed, annotated tools so an agent can carry out the whole chain from a sentence of instruction, while the destructive and outward-facing steps stay visible for approval.

Related MCP server: GoHighLevel MCP Server

Architecture

24 tool modules register against one McpServer over stdio. Everything routes through a single ghlRequest() that owns auth, the mandatory Version header, query-string assembly, and error shaping. Modules are toggleable at startup via GHL_DISABLED_MODULES — which matters more than it sounds, because 114 tool definitions is a meaningful chunk of an agent's context window before it has read a single word of the user's request. A deployment that only does bookings can register six modules and skip the rest.

  MCP host (Claude Desktop / Claude Code)
          | stdio (JSON-RPC)
  +-------v--------------------------------------------+
  |  index.ts   MODULES registry, GHL_DISABLED_MODULES  |
  +-------+--------------------------------------------+
          |
  +-------v-----+ +---------------+ +-----------+ ......  24 modules
  |  contacts   | | opportunities | | invoices  |
  +-------+-----+ +-------+-------+ +-----+-----+
          |               |               |
          |               |         +-----v--------------+
          |               |         | billing-helpers.ts |
          |               |         |  businessDetails   |
          |               |         |  contactDetails    |
          |               |         |  sender resolution |
          |               |         +-----+--------------+
          +-------+-------+---------------+
                  |
        +---------v----------------------------+
        |  client.ts  ghlRequest()             |
        |   Bearer token + Version header      |
        |   status-specific error hints        |
        +---------+----------------------------+
                  |
          services.leadconnectorhq.com

Every write tool carries MCP annotations — 17 are marked destructiveHint, and ghl_send_message / ghl_send_invoice are flagged as outward-facing because they contact real customers. The host surfaces those before approving a call, which is the difference between an agent that drafts an invoice and an agent that mails one to a client by accident.

The genuinely hard part

Creating an invoice. The endpoint takes businessDetails and contactDetails blocks, and the documentation understates both: pass a contactId and a couple of line items, as the docs suggest, and you get a validation error that names no field. Both blocks are required in full, and businessDetails.phoneNo and contactDetails.phoneNo are mandatory — a contact with an email and no phone cannot be invoiced at all.

Worse, the values have to match what the UI produces, or invoices created via the API look different from invoices created by hand — different logo, missing terms, wrong numbering. Those defaults are not in the location profile where you would expect them; they live behind GET /invoices/settings, which is the same source the UI pre-fills from.

src/tools/billing-helpers.ts resolves both blocks so the tools only need a contactId. Business details fall through four levels — per-call argument, GHL_BUSINESS_* env, saved invoice settings, location profile — with each level filling only what the one above left blank. Contact details are fetched and assembled, with name falling back through full name, first+last, company name, email, then phone, because GoHighLevel rejects an empty name and real CRM records are frequently missing one. Both paths throw a message naming the missing field and how to supply it, rather than surfacing GHL's opaque 422. Each lookup is memoised per location so a batch of ten invoices costs one settings fetch, not ten.

What I'd do differently

1. No tests. 4,000 lines and none. The fallback chain in billing-helpers is pure logic over fixture data — the easiest thing in the repo to test and the most costly to get wrong, since the failure mode is a malformed invoice sent to a client.

2. No retry on 429. ghlRequest tells the caller "rate limited; retry after a short delay" and then does not retry. Backoff belongs in the client, not in the agent's judgement.

3. The caches are module-level mutable maps with no invalidation. Correct for a stdio server the host restarts freely; wrong the moment this runs as a long-lived process, where a business-profile edit would never be picked up.

4. Responses are Record<string, unknown> throughout. GoHighLevel publishes an OpenAPI spec; generating types from it would turn a class of runtime surprises into compile errors.

5. 114 tools in one server is too many. Module toggles are a workaround, not a fix. The better shape is a small set of tools plus a discovery mechanism, so the agent pays for what it uses.

Setup

Requires Node 20+ and a GoHighLevel account.

1. Create a Private Integration token

Settings → Private Integrations → Create new integration. Enable the scopes matching the tools you intend to use; at minimum:

contacts.readonly, contacts.write, opportunities.readonly, opportunities.write, calendars.readonly, calendars/events.write, conversations.readonly, conversations/message.write, invoices.readonly, invoices.write, products.readonly, products.write, locations/customFields.readonly, workflows.readonly

Copy the token — it starts with pit-.

2. Find your Location ID

Settings → Business Profile, or read it out of the dashboard URL: .../location/<LOCATION_ID>/...

3. Build

git clone <this-repo>
cd ghl-mcp
npm install
npm run build

4. Register with an MCP host

{
  "mcpServers": {
    "gohighlevel": {
      "command": "node",
      "args": ["/absolute/path/to/ghl-mcp/dist/index.js"],
      "env": {
        "GHL_API_KEY": "pit-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "GHL_LOCATION_ID": "your-location-id"
      }
    }
  }
}

Restart the host. See .env.example for every supported variable, including the invoice business block and the module toggles.

To exercise the server without a host:

GHL_API_KEY=pit-... GHL_LOCATION_ID=... npm run inspect

A note on "building automations"

GoHighLevel's API cannot create workflow logic — the visual builder is UI-only. The supported pattern is to build the workflow once in the UI, find its id with ghl_list_workflows, and enrol contacts with ghl_add_contact_to_workflow.

Tool reference

Licence

MIT — see LICENSE. Not affiliated with or endorsed by GoHighLevel.