How do I use BackCrew GoHighLevel MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BackCrew GoHighLevel MCP Server show me the opportunities for John Smith" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

BackCrew GoHighLevel MCP Server

by jayson-svg

Overview Schema Related Servers Score Discussions

TypeScript

Remote

BackCrew GoHighLevel MCP Server

Think of this like a brand-new employee on their first day, not a business partner. A new hire only does the exact tasks you've shown them, nothing more, until you decide they're ready for more responsibility.

It lets you connect an AI assistant like Claude or ChatGPT to your GoHighLevel (HighLevel) account, so you can ask for things in plain English, like "find this lead," "what's in our pipeline," "text this customer back," instead of clicking through GoHighLevel yourself. On day one, it only knows how to look things up. You decide if and when to train it up to doing more.

GoHighLevel is a lead-gen and marketing CRM heavily used by agencies that run marketing for service businesses, including pest control companies whose marketing is managed through it. This repo is built to run alongside one of BackCrew's FSM servers in the same AI assistant, so a missed-call or new-lead workflow can span both lead capture and job scheduling.

Built by BackCrew, part of a series of free tools like this for pest control businesses.

Not a developer? That's fine. Everything up through "Testing it safely" is written for you, no coding background needed.

Related MCP server: GoHighLevel MCP Server

What this actually does

Let's be upfront about what this is, because it's easy to oversell: this is not an all-knowing marketing assistant that understands your leads and handles things for you. It's a specific, listed set of actions that an AI assistant is allowed to trigger when you ask for them in plain English. The AI doesn't have judgment about your business; it matches what you ask for to the closest action on its list and does exactly that, nothing more.

Why use an independent MCP server instead of the platform's own AI?

Software platforms are increasingly shipping their own built-in AI features. Worth knowing why you might still reach for this instead:

No plan-tier gates. Native AI features are often locked to a platform's most expensive plan. This project just needs API access, which is usually available on lower tiers too.
Cross-platform, not walled off. A platform's own AI only sees that platform's own data. It has no reason to work fluently with your FSM software, your accounting software, or your email, since those are somebody else's product. An MCP-connected assistant can have multiple servers attached at once (this one plus one of BackCrew's FSM servers), so it can work across your whole stack in one conversation.
Your choice of AI, not theirs. You keep using whichever assistant you already trust (Claude, ChatGPT, whatever) instead of learning a new vendor-specific AI interface.

Scope: this is intentionally narrow

GoHighLevel's platform is huge (funnels, websites, workflows, memberships, reputation management, and more). This repo covers exactly what's relevant to a pest control business handling leads:

Contacts: the people (leads, prospects, customers)
Opportunities: sales pipeline entries tied to a contact
Conversations: SMS/email/call threads with a contact, and sending new messages
Calendar: checking availability and booking/managing appointments

Not covered: funnels, websites, workflows (triggering them), memberships, reputation/review management, payments, and most of the rest of the platform. See ROADMAP.md.

Also from BackCrew

This is one of several MCP connectors BackCrew builds, same idea, different software. We've also got FSM connectors like Housecall Pro, plus QuickBooks for the accounting side. Full list and what's live right now: see ROADMAP.md.

Beyond this repo: once a business gets comfortable with an AI assistant reading its data, there's often more it wants to do with it, like catching missed calls faster, processing invoices and paperwork automatically, following up on quotes without someone having to remember, reactivating customers who've gone quiet, or pulling reports without digging through the software. That's a separate, scoped conversation, not part of this free, open-source repo. Same contact as in Built by BackCrew below if it's something you want to explore.

Some words you'll see, explained

API: a locked door into GoHighLevel's data that only software can open. This project is a key that opens that door.
MCP: the standard way an AI assistant like Claude or ChatGPT is told what it's allowed to do.
Server: a small program that sits between your AI assistant and GoHighLevel, translating requests back and forth.
Location: GoHighLevel's term for a specific sub-account (one business). This server is configured to operate on exactly one Location.
Private Integration Token: GoHighLevel's self-service equivalent of an API key, scoped to one Location. No separate developer account or OAuth flow needed for connecting to your own account.
Terminal: a plain-text window where you type commands.
Tool: one specific, individually named action the AI is allowed to take.

How this keeps you safe by default

Out of the box, this server can only look things up. It ships in read-only mode.
When you're ready for more, you choose a responsibility level:
- readonly-owner: same as the default. Look-ups only.
- office-ops: create/update contacts and opportunities, send messages, book/update appointments. No deletes.
- admin: everything, including deletes.
A typo can't accidentally hand out more trust than you intended. An invalid profile falls back to the safest option.

What it can look up (always safe)

What it covers	Examples
Contacts	Search and view contact records
Opportunities	View pipeline entries, pipelines and stages
Conversations	View message threads and individual messages
Calendar	View calendars, available booking slots, and existing appointments

12 look-up actions in total.

⚠️ What it can change (off by default)

office-ops level:

What it covers	Examples
Contacts	Create/update a contact, add a note
Opportunities	Create/update an opportunity, change its status
Conversations	Send a new SMS or email
Calendar	Book or reschedule an appointment

admin level only:

Deleting a contact, opportunity, or calendar event: GoHighLevel's API deletes are permanent, not a recoverable recycling bin

How to set it up

No context-switching here. Do these three steps in order, and you won't need to jump back and forth.

You'll need a computer with Node.js installed before you start.

Step 1: Make a folder for this on your computer

Open Finder (Mac) or File Explorer (Windows), go to your Desktop or Documents, and create a new folder. Give it a name you'll recognize later, like backcrew-mcp-gohighlevel.

That's it for now. Just know where this folder is. Everything else gets put inside it.

Step 2: Get your GoHighLevel credentials

Do this now, before touching the terminal:

Log into the specific GoHighLevel Location (sub-account) you want to connect
Go to Settings → Private Integrations → Create New Integration
Grant the scopes for the objects you want this server to touch (contacts, opportunities, conversations, calendars)
Copy the generated token, and note the Location ID (shown in your account settings)
Copy both values into a temporary note somewhere; you'll paste them in during Step 3

Step 3: Install it

With your folder made and your credentials in hand, this is one continuous run; don't skip ahead or double back.

Open a terminal. On a Mac, press Cmd+Space, type "Terminal," and hit enter. On Windows, click the Start menu, type "PowerShell," and hit enter. Use PowerShell rather than Command Prompt: a couple of the commands below, like pwd, only work in PowerShell.
Type cd (with a space after it), then drag your Step 1 folder from Finder/File Explorer straight into the terminal window; it'll paste the folder's path in automatically. Press enter.
Paste this exact command and press enter. It downloads the project directly into the folder you made (the trailing . matters, it means "put it here, not in a new folder"):
```
git clone https://github.com/jayson-svg/backcrew-mcp-gohighlevel.git .
```
Paste this and press enter. It installs the project's dependencies:
```
npm install
```
Paste this and press enter. It builds the project:
```
npm run build
```
Paste this and press enter. It prints the full folder path. Don't close this terminal window yet; you'll need this exact text in the next section.
```
pwd
```
Paste this and press enter. It creates your settings file from a template:
```
cp .env.example .env
```
Open that new .env file in a text editor. On a Mac, paste open -e .env into the terminal and press enter. On Windows, paste notepad .env and press enter.
Find the lines for GOHIGHLEVEL_PRIVATE_TOKEN= and GOHIGHLEVEL_LOCATION_ID=. Paste in the matching values you collected in Step 2, right after each =, with no extra spaces or quotes.
Leave GHL_MCP_MODE=read_only and GHL_MCP_PROFILE=readonly-owner exactly as they are for now; that's the safe default. Save the file and close the editor.

Connecting it to Claude

This step comes last on purpose; it needs the exact folder location from Step 3, and now you have it.

Open Claude's settings file (for Claude Desktop, claude_desktop_config.json) and add:

{
  "mcpServers": {
    "gohighlevel": {
      "command": "node",
      "args": ["PASTE_YOUR_PWD_OUTPUT_HERE/dist/index.js"],
      "env": {
        "GOHIGHLEVEL_PRIVATE_TOKEN": "your_token_here",
        "GOHIGHLEVEL_LOCATION_ID": "your_location_id",
        "GHL_MCP_MODE": "read_only",
        "GHL_MCP_PROFILE": "readonly-owner"
      }
    }
  }
}

Replace PASTE_YOUR_PWD_OUTPUT_HERE with the exact text the pwd command printed back in Step 3 (keep the /dist/index.js part after it). If you're on Windows, swap any backslashes in that path for forward slashes (for example C:/Users/yourname/Desktop/... instead of C:\Users\yourname\Desktop\...), since the config file needs regular slashes.

Restart Claude. Also works with other MCP-compatible AI tools, including ChatGPT. If you're also running one of BackCrew's FSM servers, add both to the same config.

Testing it safely

Start in read-only mode and stay there for a while.
When you turn on office-ops, test on a clearly fake contact first.
Be extra careful with send_message. Unlike most write actions in this series, sending an SMS or email reaches a real person immediately. Double-check the contact and content before sending, especially early on.
Never go straight to admin mode. GoHighLevel's API deletes are permanent.
Never share your Private Integration Token. Treat it like a password.
If something looks wrong, switch back to GHL_MCP_MODE=read_only immediately.

For developers

Everything below this point assumes a coding background.

Tool reference

Run the server and call tools/list to see exact schemas; every tool's description includes the GoHighLevel API path it maps to and its access tier.

Project layout

src/
  index.ts          Server entrypoint
  client.ts          Minimal fetch-based GoHighLevel API client (Bearer auth, required Version header, error handling)
  toolkit.ts          Tier/profile-aware helper that wires a Zod input schema + handler into an MCP tool
  tools/
    contacts.ts
    opportunities.ts    (+ list_pipelines)
    conversations.ts
    calendar.ts

The tier/profile system

Same pattern as the rest of this series: GHL_MCP_MODE/GHL_MCP_PROFILE gate what's registered at startup; read_only always wins; invalid profile falls back to the safest tier.

Notes on the GoHighLevel API

Base URL: https://services.leadconnectorhq.com. GoHighLevel's API runs under their white-label backend domain ("LeadConnector"), not gohighlevel.com
Auth header: Authorization: Bearer <token> (works identically for both OAuth access tokens and Private Integration Tokens)
Every request also needs a Version: v3 header; confirmed directly and identically across every live endpoint page checked during this build (Create Contact, Create Opportunity, Send Message, Create Appointment)
Most endpoints require a locationId (query param or body field, depending on the endpoint); this server reads it once from GOHIGHLEVEL_LOCATION_ID and includes it automatically, so individual tools don't ask for it
Full reference: marketplace.gohighlevel.com/docs and the official public docs source repo, GoHighLevel/highlevel-api-docs

This server was built by reading GoHighLevel's public API documentation directly, endpoint by endpoint, with real field names and required-parameter rules confirmed against live documentation pages for Contacts, Opportunities, Conversations/Messages, and Calendar Events.

This repo intentionally stops at honest API access. It does not include business-logic features; those live in BackCrew's managed offering, not in this public repo. See ROADMAP.md.

What's next

See ROADMAP.md for the rest of the planned series and the pattern this repo follows.

Built by BackCrew

This project is free and open for anyone to use, copy, or build on.

It's also a sample of the kind of work BackCrew does. If you want this expanded (workflow triggers, funnels, reputation management) or connected alongside a specific FSM server for your business, that's exactly the kind of project we take on.

Want this done for you? Reach out: jayson@backcrew.co

No pressure either way. Everything above works on its own, for free.

License

MIT

Available Tools

12 tools

get_appointmentB

Get a single appointment by ID. Maps to GET /calendars/events/appointments/{id}. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so description must fully disclose behavior. While it notes the REST endpoint and tier 'readonly-owner', it fails to describe error handling, null responses, rate limits, or authorization details beyond the tier hint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: a single sentence and supplemental context. All information is front-loaded and relevant. No wordiness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should explain return values or fields. It does not. The tool is simple but missing error behavior and complete authorization context beyond the tier. Adequate but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, placing burden on description. The description only adds that 'id' is the appointment ID, but does not specify format (e.g., UUID), constraints, or any additional meaning beyond the schema's basic requirement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Get a single appointment by ID', specifying the verb and resource. Distinguishes from siblings like get_contact and get_opportunity by naming the appointment resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as search_contacts or list_calendar_events. Lacks context for preferred scenarios or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_contactA

Get a single contact by ID. Maps to GET /contacts/{id}. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds tier info 'readonly-owner' indicating safety, but with no annotations, it lacks details on auth, rate limits, or error handling beyond what the name suggests.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with essential info, no filler, front-loaded with action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 param, no output schema), the description covers purpose, endpoint, and tier; missing return value details but not required per scoring rules.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only mentions 'by ID' which is already obvious from the schema; with 0% schema description coverage, the description fails to clarify format, source, or constraints of the 'id' parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'Get' and resource 'single contact by ID', distinguishing it from sibling 'search_contacts' which searches instead of retrieves by ID.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage when a specific contact ID is known, and the sibling list shows search_contacts as alternative for queries without an ID.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_conversationB

Get a single conversation thread by ID. Maps to GET /conversations/{id}. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Includes tier hint '[tier: readonly-owner]' indicating read-only scope. But does not describe what is returned (e.g., metadata only, full thread with messages). Lacks behavioral details beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no superfluous information. Efficiently communicates core purpose and endpoint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple tool with one required parameter, but lacking description of return value. With no output schema, agent needs more context on what is fetched.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%; description only says 'by ID' without clarifying ID format or source. Adds minimal value over the parameter name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'Get' and resource 'single conversation thread by ID'. Mention of API endpoint adds clarity. However, does not explicitly distinguish from sibling tools like search_conversations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. No mention of prerequisites, edge cases, or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_free_slotsA

Get available booking slots for a calendar within a date range. Maps to GET /calendars/{calendarId}/free-slots. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`userId`	No	Restrict to a specific team member's availability
`endDate`	Yes	Unix timestamp in milliseconds
`timezone`	No
`startDate`	Yes	Unix timestamp in milliseconds
`calendarId`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the full burden. It identifies the operation as read-only via '[tier: readonly-owner]' and provides the endpoint, but does not disclose what happens in edge cases (e.g., no slots, invalid calendar) or any rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences with the most important information first. Every sentence adds value: purpose, endpoint, permissions. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 5 parameters (3 required), no output schema, and no annotations. The description provides the endpoint and permission tier, but lacks details on return format, pagination, error handling, or timezone behavior. Adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 60% schema description coverage, the schema already documents most parameters. The description adds no further detail about parameters (e.g., date format, timezone usage). It fails to compensate for the schema's gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get available booking slots for a calendar within a date range', which is a specific verb-resource combination. It distinguishes from sibling tools like list_calendar_events or get_appointment by specifying it's about free slots.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an endpoint mapping and a permission tier hint, but does not explicitly state when to use this tool vs alternatives like list_calendar_events. Usage context is implied but not clarified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_opportunityA

Get a single opportunity by ID. Maps to GET /opportunities/{id}. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It reveals the HTTP method (GET), indicates readonly behavior via '[tier: readonly-owner]', and implies safety. However, it does not discuss error conditions or null returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the purpose and provide endpoint and tier information. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (1 param, no output schema), the description is fairly complete in purpose and safety. But it omits expected return value details, which would be useful since no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It only says 'by ID' without specifying format, source, or constraints of the 'id' parameter. Minimal added meaning over the schema's raw type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'opportunity by ID', and maps to a specific REST endpoint. It distinguishes from sibling tools like search_opportunities (which lists) and get_contact (different resource).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you have a specific ID and need a single opportunity, but does not explicitly state when not to use or compare to alternatives like search_opportunities. It provides minimal guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_calendar_eventsB

List calendar events (appointments and blocked slots) within a date range. Maps to GET /calendars/events. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`userId`	No
`endTime`	No	ISO 8601 timestamp
`startTime`	No	ISO 8601 timestamp
`calendarId`	No

TDQS

B3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description indicates a read-only operation via 'Maps to GET /calendars/events' and '[tier: readonly-owner]', but since no annotations are provided, the description carries the full burden. It does not disclose other behavioral traits such as rate limits, authentication needs, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, using two sentences and a tag with no redundant information. Every part serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there is no output schema and the tool has 4 parameters, the description is sparse. It does not describe the return format, pagination behavior, or what happens when no date range is provided, which is important for a list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds minimal parameter understanding beyond the schema. While it mentions 'within a date range', it does not elaborate on the meaning of 'userId' or 'calendarId', and the schema coverage is only 50% (descriptions for startTime and endTime only).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists calendar events (appointments and blocked slots) within a date range, specifying the verb and resource. However, it does not explicitly differentiate from sibling tools like get_free_slots or get_appointment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or context that would help the agent choose this tool over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_calendarsA

List the calendars configured for this account. Maps to GET /calendars/. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so description carries burden. Discloses readonly nature via tier, maps to HTTP endpoint. Lacks details on authorization scope but sufficient for a read-only list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences, front-loaded with purpose, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with no parameters and no output schema. Description is complete enough; could mention return format but not essential.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, baseline 4. Description correctly confirms no additional meaning needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'List the calendars configured for this account' with a specific verb and resource. Distinguishes from sibling tools like list_calendar_events and get_appointment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage for viewing available calendars, but no explicit when-to-use or alternatives provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_messagesC

List the individual messages in a conversation thread. Maps to GET /conversations/{id}/messages. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`conversationId`	Yes

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It includes 'tier: readonly-owner' indicating read-only behavior, but lacks details on authorization, rate limits, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences, the first being the core purpose and the second adding mapping and tier information. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with two parameters and no output schema, the description is incomplete. It lacks parameter documentation, usage guidance, and behavioral details, given the 0% schema coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain any of the two parameters (limit, conversationId) beyond what the schema provides. With 0% schema description coverage, this is a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List the individual messages') and the resource ('in a conversation thread'). It maps to a specific API endpoint, but it does not explicitly differentiate from sibling tools like search_conversations or get_conversation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. It implies usage for listing messages in a thread but does not mention exclusions or conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_pipelinesA

List the sales pipelines and their stages configured for this account. Maps to GET /opportunities/pipelines. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description discloses that the tool is read-only ('readonly-owner') and maps to a GET endpoint. This adds value beyond a simple 'list' statement, though it does not describe the return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences and a tag. Every element is informative and necessary, with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and no output schema, the description is complete. It explains the purpose, the API mapping, and permission requirements, which is sufficient for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the schema coverage is 100%. The description does not need to add parameter information, and the baseline for 0 parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists sales pipelines and stages, with a specific verb and resource. It includes the API endpoint and permission tier, and there are no sibling pipeline tools to distinguish from.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lacks explicit when-to-use or when-not-to-use guidance. However, the read-only tag and endpoint mapping imply its use case, and no alternative sibling tools exist, so the gap is minor.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_contactsB

Search contacts in this account. Maps to POST /contacts/search. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`query`	No	Free-text search across name/email/phone
`filters`	No	Advanced filter objects — see GoHighLevel's Search Contacts docs for the full filter/operator syntax
`pageLimit`	No	Default 20
`startAfterId`	No	Pagination cursor from a previous call

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It only includes a tier tag '[tier: readonly-owner]', hinting at read-only access but without confirming. No details on authorization, rate limits, or side effects. For a read-only search, it should explicitly state that it does not modify data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences plus a tag, no wasted words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters and no output schema, the description could mention return values or response structure. While schema covers params, the description lacks information about pagination behavior or what the response contains (e.g., list of contact objects).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions for each parameter (query, filters, pageLimit, startAfterId). The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Search contacts in this account', which is a specific verb-resource pair. It distinguishes from siblings like 'get_contact' (single contact retrieval) and 'search_opportunities' (different resource).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. It does not mention when not to use it or provide context about when search is appropriate compared to get_contact.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_conversationsC

Search/list conversations (SMS, email, call, chat threads), with filtering. Maps to GET /conversations/search. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`limit`	No	Default 20
`query`	No
`status`	No	e.g. all, read, unread, starred
`contactId`	No

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses it is readonly (tier: readonly-owner) and maps to GET, indicating a read operation. However, it lacks details on pagination, rate limits, or what is returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: one sentence plus API and tier info. It is front-loaded with the main action. Could be slightly expanded on filtering but effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should clarify what the tool returns (e.g., list of conversation objects). It does not. Also lacks context on pagination, sorting, or how filtering works. Overall incomplete for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% with minimal descriptions for limit and status. The description does not add any parameter-specific details beyond 'filtering'. It does not explain query or contactId parameters, leaving ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches/lists conversations with examples of types (SMS, email, call, chat threads) and mentions filtering. It is distinct from siblings like get_conversation and search_contacts, but does not explicitly differentiate from them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description only states what it does, not when it's appropriate or not. Sibling tools exist but are not referenced.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_opportunitiesB

Search/list opportunities (sales pipeline entries), with filtering and pagination. Maps to GET /opportunities/search. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`q`	No	Search query, max 75 characters
`page`	No	Default 1
`limit`	No	Default 20
`status`	No
`contactId`	No
`assignedTo`	No
`pipelineId`	No
`pipelineStageId`	No

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description carries full burden. Mentions readonly-owner tier but doesn't disclose return format, pagination details, or ordering. Not sufficient for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences: first defines purpose and scope, second maps to API and tier. Front-loaded, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 parameters, low schema coverage, and no output schema, the description is too minimal. Doesn't clarify optionality, filter behavior, or response format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 38% (only q, page, limit have descriptions). Description adds no new parameter info beyond 'filtering and pagination'. Does not explain status enum, contactId, etc.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches/lists opportunities (sales pipeline entries) with filtering and pagination, and gives the API endpoint. It distinguishes from siblings like get_opportunity (single) and list_pipelines (different resource).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage: use when you need to search/list opportunities. No explicit when-not-to-use or alternatives mentioned. Sibling names provide context, but description lacks guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

12 tool updatesv0.1.0Jul 28, 2026
- First observedget_appointment
- First observedget_contact
- First observedget_conversation
- First observedget_free_slots
- First observedget_opportunity
- First observedlist_calendar_events
- First observedlist_calendars
- First observedlist_messages
- First observedlist_pipelines
- First observedsearch_contacts
- First observedsearch_conversations
- First observedsearch_opportunities

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool targets a distinct resource and action (search/list/get). Contacts, opportunities, conversations, and calendars are clearly separated, with no overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern: search_, get_, list_. The naming is uniform and predictable across all resources.

Tool Count5/5

12 tools is a well-scoped count for a read-only CRM data server. Each tool serves a distinct purpose without being overwhelming or too sparse.

Completeness4/5

The set covers the main retrieval needs for contacts, opportunities, conversations, and calendars. Minor gaps exist (e.g., no direct search for a contact's opportunities), but agents can work around using filters.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Leadconnector A
io.github.pipeworx-io
LeadConnector / GoHighLevel MCP Pack — wraps the GoHighLevel CRM for AI agents.
CRM Marketing
362
PlixanaOAuth
com.plixana
Operate the Plixana CRM from any AI: contacts, deals, quotes, WhatsApp and metrics.
CRM Communication
2
HAVNOAuth
app.havnre
Read-only AI access to HAVN properties, leads, tasks, files, media, and analytics.
Real Estate CRM
2
RevOrbit CRM
com.revorbit
Search, summarize, and update your RevOrbit CRM (leads, deals, contacts, tasks) in plain language.
CRM Search
2

Related MCP Servers

GoHighLevel (GHL) MCP Server
Customer Data Platforms Marketing App Automation
BusyBee3333
A
license
Not graded
quality
C
maintenance
Provides access to over 460 tools within the GoHighLevel CRM, allowing AI assistants to manage contacts, opportunities, messaging, and business workflows through natural language.
Updated 5 days ago (2026-09-01 04:38 UTC)
26
102
ISC
GoHighLevel MCP Server
CRM Calendar Management
basicmachines-co
A
license
Not graded
quality
C
maintenance
Enables AI assistants to manage GoHighLevel CRM data including contacts, conversations, opportunities, calendars, and forms through MCP tools and resources.
Updated 2 months ago (2026-07-08 16:49 UTC)
50
AGPL 3.0
ghl-mcp-server
CRM Communication Calendar Management
RichMarin19
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with GoHighLevel's CRM, marketing automation, and business management tools via the API v2, with support for contacts, conversations, calendars, opportunities, payments, and workflows.
Updated a year ago (2025-07-15 05:09 UTC)
37
MIT
GoHighLevel MCP Server
CRM Communication Calendar Management
geopopos
F
license
Not graded
quality
D
maintenance
Enables LLMs to read conversations, send messages, create tasks, and manage calendar appointments within GoHighLevel CRM locations.
Updated 7 months ago (2026-02-04 18:11 UTC)
1
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jayson-svg/backcrew-mcp-gohighlevel'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

BackCrew GoHighLevel MCP Server

Contents

What this actually does

Why use an independent MCP server instead of the platform's own AI?

Scope: this is intentionally narrow

Also from BackCrew

Some words you'll see, explained

How this keeps you safe by default

What it can look up (always safe)

⚠️ What it can change (off by default)

How to set it up

Step 1: Make a folder for this on your computer

Step 2: Get your GoHighLevel credentials

Step 3: Install it

Connecting it to Claude

Testing it safely

For developers

Tool reference

Project layout

The tier/profile system

Notes on the GoHighLevel API

What's next

Built by BackCrew

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API