How do I use ghl-api-mcp?

1. Click on "Deploy 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., "@ghl-api-mcp search docs for contact API" 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.

ghl-api-mcp

by S5-labs

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

ghl-api-mcp

ghl-api-mcp is an MCP stdio server for GoHighLevel documentation. It lets agents search docs, list endpoints, and fetch focused API details without loading large markdown files into prompt context.

This repo does not include a runnable GoHighLevel OAuth/SSO sample app; it contains documentation and the MCP docs server that indexes that documentation.

What It Does

The server indexes markdown files under docs/ and exposes MCP tools for:

list_docs
search_docs
list_endpoints
get_endpoint_details
get_section
get_document
reload_docs

The current corpus includes API review docs, implementation guides, and operational notes such as OAuth/SSO integration details and rate-limit guidance. To see exactly what is loaded, run list_docs.

list_docs labels each file as either a reference or guide. Use get_document when an agent needs the full body of a longer procedural document instead of a single extracted section.

For search_docs, list_endpoints, get_endpoint_details, and get_section, you can pass an optional whitelabel_domain like api.example.com or https://api.example.com. Returned endpoint URLs and embedded example URLs will be rewritten to that domain.

Related MCP server: ghl-mcp

Requirements

Node.js >=20 for local usage
Docker, if you want to run the containerized version

Quick Start

Local

npm install
npm start

Or run the CLI entrypoint directly:

npm install
./bin/ghl-api-mcp.js

Important: this is a stdio MCP server. When you run it successfully, it stays attached and waits for client requests. It is not an HTTP server and does not open a port.

Docker

docker build -t ghl-api-mcp .
docker run --rm -i ghl-api-mcp

MCP Client Configuration

Local Repo Checkout

Use this when the repository already exists on disk:

{
  "mcpServers": {
    "ghl-docs": {
      "command": "node",
      "args": ["/absolute/path/to/ghl-api-mcp/src/server.js"]
    }
  }
}

Local Repo Checkout With External Docs Directory

{
  "mcpServers": {
    "ghl-docs": {
      "command": "node",
      "args": ["/absolute/path/to/ghl-api-mcp/src/server.js"],
      "env": {
        "GHL_DOCS_DIR": "/absolute/path/to/docs"
      }
    }
  }
}

Docker

{
  "mcpServers": {
    "ghl-docs": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "ghl-api-mcp"]
    }
  }
}

Docker With External Docs Directory

{
  "mcpServers": {
    "ghl-docs": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-v",
        "/absolute/path/to/docs:/docs:ro",
        "-e",
        "GHL_DOCS_DIR=/docs",
        "ghl-api-mcp"
      ]
    }
  }
}

Document Loading

Any .md file under docs/ is indexed automatically
If the server is already running, call reload_docs after changing docs on disk
If you add docs to the repo and run via Docker without a mounted docs directory, rebuild the image so the container includes the new files

Development

npm install
npm test

Scraping Workflow

Use the browser-backed scraper when a GHL doc links to richer ClickUp content:

npm run scrape:page -- \
  --url https://marketplace.gohighlevel.com/docs/ghl/contacts/search-contacts-advanced \
  --output docs/generated/search-contacts-advanced.md

Browser selection order:

Chrome
Chrome Canary
Zen

You can override the browser with --browser, --executablePath, or PUPPETEER_EXECUTABLE_PATH.

Available Tools

7 tools

get_documentA

Retrieve a full documentation file by id or title, useful for longer implementation guides and runbooks.

ParametersJSON Schema

Name	Required	Description
`max_chars`	No	Maximum number of document characters to return (default: 12000).
`id_or_title`	Yes	Document id or title, such as 'GHL_OAuth_SSO_Reproduction_Guide'.
`whitelabel_domain`	No	Optional whitelabel API domain or base URL to use when rendering endpoint URLs.

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description bears full transparency burden. It portrays a simple retrieval, but omits that max_chars can truncate the document, and does not describe read-only nature or any side effects. This is a gap.

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 a single sentence, concise and front-loaded with key information. It could be slightly more structured, but it is efficient.

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?

For a tool with 3 parameters, no output schema, and no annotations, the description lacks completeness. It does not explain truncation behavior, return format, or provide guidance relative to siblings like get_section. It adequately covers basic purpose but leaves gaps.

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 all parameters. The description adds little beyond schema, only noting usefulness for long docs. Baseline 3 is appropriate as the schema handles semantic load.

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 'Retrieve a full documentation file by id or title', specifying the verb (retrieve) and resource (documentation file). It differentiates from siblings like get_section (partial) and list_docs (listing), so purpose is clear.

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?

The description mentions it is 'useful for longer implementation guides and runbooks', providing context for when to use it. However, it does not explicitly state when not to use or name alternatives like get_section for shorter content, so it lacks exclusions.

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

get_endpoint_detailsA

Get details for a specific API endpoint, including scope, token type, and documentation excerpt.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Endpoint path, such as /objects/:schemaKey/records/search
`method`	No	Optional HTTP method to disambiguate endpoint matches.
`whitelabel_domain`	No	Optional whitelabel API domain or base URL to use when rendering endpoint URLs.

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description bears full responsibility. It discloses the kind of details returned (scope, token type, documentation excerpt), but does not mention whether the operation is read-only, requires authentication, or has any side effects. The behavior is basically implied as safe, but not explicitly stated.

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 a single, well-structured sentence that is front-loaded and concise. Every word adds value, and there is no redundant or extraneous information.

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 that there is no output schema, the description usefully indicates what the return value includes (scope, token type, documentation excerpt). However, it lacks mention of error conditions or prerequisites (e.g., a valid path). For a simple get tool, this is mostly adequate but slightly incomplete.

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 all three parameters having descriptions in the schema. The description adds no additional meaning beyond what the schema already provides, resulting in a baseline score of 3.

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 retrieves details for a specific API endpoint, including scope, token type, and documentation excerpt. It uses a specific verb ('Get') and resource ('details for a specific API endpoint'), distinguishing it from sibling tools like list_endpoints (listing) and get_document (document-level).

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 needing endpoint details, but provides no explicit when-to-use or when-not-to-use guidance compared to alternatives like list_endpoints or search_docs. There are no exclusions or context for choosing 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.

get_sectionA

Retrieve a documentation section by title or partial title.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Section title, such as 'Search Object Records'.
`max_chars`	No	Maximum number of section characters to return (default: 4000).
`whitelabel_domain`	No	Optional whitelabel API domain or base URL to use when rendering endpoint URLs.

TDQS

A3.7/5.0

Behavior3/5

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

No annotations provided; description discloses key parameters but omits search behavior (e.g., case sensitivity, exact vs. partial match). Adequate but not thorough.

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?

Single sentence, no fluff. Front-loaded with purpose. Efficient.

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?

Lacks output description, but given simple retrieval and no output schema, it is minimally complete. Could mention return type or format.

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%; description adds no meaning beyond schema descriptions. Baseline score 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?

Description uses specific verb 'Retrieve' and resource 'documentation section', clearly distinguishing from sibling tools like get_document (full document) and get_endpoint_details (endpoint-specific).

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?

No explicit when-to-use or alternatives, but the purpose is straightforward. Minimal guidance, acceptable for a simple retrieval tool.

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

list_docsA

List loaded GoHighLevel documentation files and their endpoint/section counts.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses the output (files with counts) but does not mention authentication, error states, or side effects. Adequate for a simple read-only list 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?

Single sentence, 12 words, front-loaded with the verb and resource. No unnecessary words; highly efficient.

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 zero parameters and no output schema, the description fully explains what the tool returns (files with endpoint/section counts). Complete for a simple listing tool.

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?

Zero parameters, so baseline is 4. Description adds no parameter info as none are 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?

Description clearly states 'List loaded GoHighLevel documentation files and their endpoint/section counts', specifying the verb 'list' and the resource with additional detail. It distinguishes from siblings like get_document and list_endpoints which have different purposes.

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?

Usage is implied by the simple action and zero parameters; used to get an overview of loaded files. No explicit when-not or alternatives, but sibling tools are sufficiently different that confusion is unlikely.

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

list_endpointsB

List available API endpoints with optional method/path/section filters.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum rows to return (default: 25).
`method`	No	HTTP method filter (GET, POST, PUT, DELETE).
`path_contains`	No	Filter endpoint path by substring.
`section_contains`	No	Filter by section or operation title.
`whitelabel_domain`	No	Optional whitelabel API domain or base URL to use when rendering endpoint URLs.

TDQS

B3.4/5.0

Behavior2/5

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

No annotations exist, so the description bears full responsibility. It does not disclose any behavioral traits such as whether it is read-only, pagination behavior, or any side effects. The description is too terse to inform about safety or limitations.

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 a single, concise sentence with no unnecessary words. It is front-loaded with the main action and resource, and every word 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?

With 5 parameters, no output schema, and no annotations, the description does not explain return values, default behaviors, or any limitations. It is insufficient for an agent to fully understand the tool's behavior.

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 description coverage is 100%, so baseline is 3. The description adds no new parameter meaning beyond what the schema already provides, as it merely restates 'method/path/section filters'.

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 uses a specific verb 'List' and clearly identifies the resource 'available API endpoints'. It distinguishes from siblings like get_endpoint_details (which is for specific endpoints) and list_docs (which lists documents).

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 only mentions optional filters, but does not provide explicit guidance on when to use this tool versus alternatives. No exclusion criteria or when-not-to-use context is given.

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

reload_docsA

Reload markdown files from disk (useful after docs updates).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It indicates a mutation (reload from disk) but does not disclose side effects such as overwriting cached data, required permissions, or idempotency.

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 a single sentence with front-loaded verb and no wasted words. It is appropriately concise for the tool's simplicity.

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?

For a simple 0-param tool with no output schema or annotations, the description is largely complete in its purpose and usage context. It could be improved by mentioning what the return value is (if any).

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?

The tool has zero parameters, so the schema coverage is 100%. The description adds purpose and context beyond the empty schema, meeting the baseline for 0-param tools.

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 'reload' and resource 'markdown files from disk' with a specific use case 'useful after docs updates'. It distinguishes itself from sibling tools that are for reading or searching docs.

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?

The description implies when to use it ('after docs updates') but does not explicitly exclude alternatives or mention prerequisites. However, the context is clear and distinct from siblings.

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

search_docsA

Search GoHighLevel API docs with keyword matching across endpoints and section content.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of results to return (default: 8).
`query`	Yes	Keywords, endpoint name, scope, or concept to find.
`whitelabel_domain`	No	Optional whitelabel API domain or base URL to use when rendering endpoint URLs.

TDQS

A3.5/5.0

Behavior3/5

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

The description mentions 'keyword matching across endpoints and section content' hinting at the scope but lacks details on search behavior (e.g., case sensitivity, full-text vs partial match). No annotations are present to fill this gap.

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 a single efficient sentence that states the core functionality. It is front-loaded and to the point, though slightly more detail could be included without becoming verbose.

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?

The description does not mention what the tool returns (e.g., a list of matching documents, excerpts, or URLs). Given no output schema, this omission leaves the agent uncertain about the result format, reducing completeness.

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?

All three parameters (limit, query, whitelabel_domain) have descriptions in the schema (100% coverage). The tool description adds no additional parameter information, meeting the baseline of 3 for high schema coverage.

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's purpose: searching GoHighLevel API docs by keyword. It distinguishes from sibling tools like get_document, list_docs, etc., which do not perform keyword search.

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 for keyword-based search but does not explicitly state when to use this tool over alternatives like list_docs or get_endpoint_details. No exclusions or when-not-to-use guidance provided.

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.

7 tool updatesv0.1.0Jun 27, 2026
- First observedget_document
- First observedget_endpoint_details
- First observedget_section
- First observedlist_docs
- First observedlist_endpoints
- First observedreload_docs
- First observedsearch_docs

Deploy Server

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

TDQS

A4/5.0

Scored 2026-06-27 21:06 across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: listing docs, listing endpoints, searching, retrieving specific documents, sections, or endpoint details, and reloading. No overlapping functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_docs, get_document, search_docs). The naming is predictable and uniform.

Tool Count5/5

With 7 tools, the server covers all core operations for API documentation exploration: listing, searching, retrieving at different granularities, and reloading. The count is well-scoped for its domain.

Completeness4/5

The tool set covers key workflows except for listing individual sections within a document (only counts are provided). This minor gap prevents a perfect score, but overall the surface is largely complete.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Context Awesome A
io.github.bh-rat
MCP server for accessing curated awesome list documentation
Documentation Access Research & Data
2259
agentverse
io.github.doc2mcp
MCP server for agentverse documentation, generated by doc2mcp.
Agent Orchestration Documentation Access
24
vonage-documentation-mcp A
io.github.Vonage
MCP server for Vonage API documentation, code snippets, tutorials, and troubleshooting.
Documentation Access Communication Developer Tools
72
Bitrix MCP A
io.github.bitrix24
MCP server that delivers up-to-date Bitrix24 REST API documentation.
Documentation Access API Testing Developer Tools
53

Related MCP Servers

grok-api-mcp
Documentation Access Search
tetsuo-ai
F
license
Not graded
quality
D
maintenance
An MCP server that provides comprehensive xAI/Grok API documentation, allowing AI assistants to search bundled guides, fetch live documentation, and browse API endpoints or model specifications.
Updated 7 months ago (2026-02-05 01:08 UTC)
13
-
ghl-mcp
CRM Marketing Payments & Billing
AustinMander
A
license
B
quality
D
maintenance
MCP server for GoHighLevel API v2 that provides 50+ tools for CRM, billing, marketing, and operations workflows, enabling natural language interaction with contacts, opportunities, conversations, and more.
Updated 6 months ago (2026-03-16 07:41 UTC)
50
1
MIT
CashClaw GHL MCP
CRM Communication
centrender
A
license
Not graded
quality
C
maintenance
An MCP server for GoHighLevel with 82 live-tested tools, enabling CRM operations like contact management, appointments, invoices, and workflows via natural language.
Updated 3 months ago (2026-06-23 02:58 UTC)
21
MIT
mcp-api-reference
Documentation Access Search Developer Tools
ei-nakamura
A
license
Not graded
quality
D
maintenance
An MCP server that automatically crawls, indexes, and serves API reference documentation for LLMs, enabling to search and retrieve endpoint details.
Updated 6 months ago (2026-03-05 04:35 UTC)
MIT