Key takeaways
- HighLevel operates an official first-party MCP server, now documented in its developer portal as the LeadConnector MCP server. There are two endpoints: the per-client pattern
https://services.leadconnectorhq.com/mcp/{client}/v2, live today for Claude at/mcp/anthropic/v2, and the originalhttps://services.leadconnectorhq.com/mcp/. - Both endpoints support OAuth and Private Integration Tokens. OAuth is HighLevel’s documented recommendation, because the consent flow exposes a wider scope set than a token does.
- The per-client endpoint does not publish one tool per operation. It exposes six unified tools that an assistant uses to discover and run everything else.
- HighLevel support articles dated 6 and 7 August 2026 put the catalog behind those tools at 625 operations across 40 domains. The developer portal describes it as hundreds of operations across 40 domains.
- On either endpoint, the operations an agent can see are filtered by the scopes you grant, so two clients pointed at the same server can have very different capability.
Short answer: yes, and it is a first-party server rather than a community project. If you are wiring an AI agent into a CRM in 2026, the useful question is no longer whether the vendor ships an MCP server. It is how much of the product that server can actually reach, and under what permissions.
If your team works in Claude, the Claude Desktop CRM connection lets the assistant read and update records through MCP.
Updated 2 September 2026. This page previously followed HighLevel’s support-portal setup guide, which was last modified on 9 July 2026 and still states that OAuth support is planned for a future release. The current source of record is the LeadConnector MCP server documentation in the HighLevel developer portal, and it contradicts that older guide on the two points that matter most: OAuth is supported today on both endpoints, and a newer per-client endpoint reaches a far larger operation catalog than the original one. Every HighLevel fact below is taken from HighLevel’s own current pages.
Does GoHighLevel have an MCP server?
Yes. HighLevel documents an official Model Context Protocol server in its developer portal, under the name LeadConnector MCP server. MCP itself is an open standard for letting an AI client discover a tool registry and then call those tools, so the practical effect is that a compatible assistant can look up a contact, search opportunities, read a conversation thread or send a message without anyone building a bespoke integration first.
What changed since mid-2026 is that there is no longer a single endpoint. The documentation now describes a per-client pattern, https://services.leadconnectorhq.com/mcp/{client}/v2, alongside the original https://services.leadconnectorhq.com/mcp/. The per-client version is the one HighLevel recommends, and the only client endpoint live at the time of writing is https://services.leadconnectorhq.com/mcp/anthropic/v2 for Claude. HighLevel states that the original endpoint remains fully supported and is not deprecated.
This matters for agencies evaluating a switch, because an MCP server is the difference between an AI layer that can only read what you paste into it and one that can act inside the system of record. If you are weighing platforms, our GoHighLevel alternatives comparison covers the wider feature and pricing picture.
How the HighLevel MCP server works
The first decision is which endpoint you are connecting to, because they differ in coverage even though they now share an authentication model.
/mcp/{client}/v2 (recommended) |
/mcp/ (original) |
|
|---|---|---|
| Endpoint | services.leadconnectorhq.com/mcp/anthropic/v2 is live; more clients planned |
services.leadconnectorhq.com/mcp/ |
| Auth | OAuth or Private Integration Token | OAuth or Private Integration Token |
| Clients | Per client. Claude live today, others on the roadmap | Any HTTP-based MCP client, including Cursor, Windsurf, n8n and custom agents |
| Coverage | Widest. The full operation catalog, described as hundreds of operations across 40 domains | Limited. A focused set of core tools with a narrower scope |
| Sub-accounts | Single sub-account, or agency-wide across several from one connection | One sub-account per connection |
Source: the HighLevel developer portal MCP documentation, read 2 September 2026.
Authentication
HighLevel documents two methods, and its current documentation says both work on both endpoints. OAuth is the recommended path. The client opens a browser to the LeadConnector sign-in page, you approve the scopes on a consent screen, choose the sub-account or sub-accounts to expose, and there is no credential to store or rotate afterwards. HighLevel states that OAuth makes the widest set of scopes available, and that this is a reason to prefer it.
A Private Integration Token still works. You create it inside the relevant sub-account under Settings and then Private Integrations, selecting the scopes you want, and pass it in the Authorization header as a bearer token. HighLevel is explicit that a token offers a more limited set of scopes than OAuth, which in turn limits how much of the operation catalog an assistant can reach. On the original endpoint the locationId header is documented as optional and can instead be supplied in the prompt.
The scoping model is the part worth reading twice. HighLevel states that available operations are filtered automatically by the grant, which means the server is not one fixed capability set. A grant covering only contact reads exposes a much smaller surface than one covering edits across conversations, opportunities and payments. That is good security design and it is also a support trap, because two people can follow the same guide and end up with different capability.
What tools it exposes
The most important architectural fact about the recommended endpoint is that it deliberately does not expose one tool per operation. HighLevel calls this a facade: rather than putting hundreds of tools in front of the model and letting them compete for attention, the server exposes a small, stable toolset and lets the assistant discover the rest at runtime. The developer portal lists six:
search: find customer or business records by name, email, phone, tag or similar criteria.fetch: retrieve the full details of one or more records returned bysearch.search_operations: discover the available operations by intent, such as list, create, update or delete.describe_operation: inspect the inputs an operation expects before running it.execute_operation: run one operation, subject to your scopes and built-in safety checks.list_locations: list the sub-accounts a connection can use, so an agent can pick one.
The documented working pattern is search_operations, then describe_operation, then execute_operation. Note that HighLevel’s own pages are not fully consistent here: the developer portal table lists six tools including list_locations, while one support article describes the same design as a five-tool facade and omits it. We are quoting the developer portal, which is the more recently maintained page.
How large is the catalog behind those tools
The developer portal describes the catalog as hundreds of operations across 40 domains without giving an exact figure. Two HighLevel support articles do publish one. The article on multi-account support for Claude, last modified 6 August 2026, and the article on increased scopes for the Anthropic endpoint, last modified 7 August 2026, both state 625 operations across 40 domains. The second publishes a breakdown:
| Metric | Value |
|---|---|
| Total operations in catalog | 625 |
| Active operations | 571 |
| Read operations | 243 |
| Write operations | 244 |
| Delete operations | 84 |
| Domains covered | 40 |
Source: HighLevel support portal, article last modified 7 August 2026. The read, write and delete figures sum to the active count, which is a small but useful sign the table is internally consistent rather than rounded marketing. Treat it as a snapshot with a date on it, not a permanent number.
What the coverage actually spans
HighLevel documents the per-client catalog as reaching contacts, conversations and messages, opportunities and pipelines, calendars and appointments, payments, products and store, invoices and estimates, social planner, blogs, emails, and forms and surveys. The original endpoint is documented as a narrower version of the same shape: contacts, conversations, opportunities, calendars, payments, social planner, blogs and emails.
For historical context, the older support-portal setup guide, last modified 9 July 2026, published a table of 36 example tools for the original endpoint and explicitly labelled it as examples rather than a full registry. That table is still live and it is still a reasonable picture of the original endpoint, but it is not a description of the per-client endpoint and it should not be read as the size of the HighLevel MCP surface today.
Limits worth knowing before you build on it
The old blocker is gone. OAuth is supported now, on both endpoints, so distributing an agent to clients no longer forces you to distribute token handling with it. Four operational constraints replace it, and all four come from HighLevel’s current pages.
The two endpoints are not equivalent. If you connect a client other than Claude today, you are on the original endpoint and its narrower toolset, not the full catalog. That is a coverage decision you make by choosing a client, which is an unusual thing to have to reason about.
Client coverage is still rolling out. HighLevel lists dedicated endpoints for OpenAI, Cursor, Windsurf and VS Code as planned rather than available. Building an agent that assumes full-catalog access is building against a roadmap for every client except Claude.
Scope drift is real. Because the surface is grant-dependent, an agent that works in your account can fail in a client account with a narrower grant, and the failure will look like a missing operation rather than a permissions error. A Private Integration Token narrows it further than OAuth does, by HighLevel’s own description.
Every request still targets one sub-account. Agencies can connect once and work across several sub-accounts on the per-client endpoint, but each individual request runs against a single location you selected at install. HighLevel describes the agency-wide multi-sub-account option as rolling out, and notes that if your install only offers a single sub-account, that option is not enabled for your app yet. One support article dated 7 August 2026 still describes connections as location-level only; the developer portal is the newer statement and we have followed it.
One more thing worth flagging for anyone researching this: HighLevel’s support portal and developer portal currently disagree. The support-portal setup guide has not been updated since 9 July 2026 and still says OAuth is planned for a future release. If you find that page first, as most people searching will, you will come away with a picture of the product that is roughly two months out of date.
None of these are reasons to avoid it. They are the operational cost of building on it, and they are the kind of thing worth pricing in alongside the plan cost covered in our GoHighLevel pricing breakdown.
How to evaluate any CRM MCP server
The market has moved quickly enough that “we have an MCP server” is now table stakes rather than a differentiator. Four questions separate a real one from a checkbox:
- Who operates it? A vendor-run server has a support path and a deprecation policy. A community server on GitHub has neither, however good the code is.
- How much of the API is reachable? Compare what the agent layer can reach against the vendor’s own published API surface. Do not compare raw tool counts, because a facade design like HighLevel’s deliberately shows a handful of tools in front of a much larger catalog. The number that matters is operations reachable, not tools listed.
- How does scoping work? Least-privilege scoping is the right answer, but you need to know how it fails and whether the failure is legible to the agent.
- Is the registry versioned? Tool names are an interface. If they change without notice, agents break in production and the symptom is a confused model rather than a clean error. A versioned endpoint path, like the
v2in the per-client pattern, is a good sign.
How Conduyt approaches MCP
Conduyt is built API-first, and the public catalog at conduyt.app/api/v1/schema/public reports 610+ API endpoints and 880+ API operations across 100+ API domains at the time of writing. The Conduyt MCP server exposes 170+ tools. The design goal is that the agent-facing surface tracks the product surface rather than lagging behind it, which is exactly the second question in the list above.
Underneath every feature is the CRM database, which is worth understanding before you migrate.
We are deliberately not turning that into a head-to-head score. The two numbers are not like-for-like: HighLevel counts operations sitting behind a six-tool facade, Conduyt counts tools exposed directly, and both are filtered by scope at runtime on either side. Counts also move between releases, and a number quoted out of a changelog is the kind of comparison that ages badly within a quarter. If you want the current picture, the Conduyt MCP server page documents what is exposed, and AI CRM vs GoHighLevel covers how the two platforms differ beyond the agent layer.
MCP is a layer over the same REST surface and the same scope model. If you are building directly against the endpoints instead, our breakdown of the GoHighLevel API covers the version header, the OAuth and Private Integration Token split, and the published rate limits.
FAQ
Does GoHighLevel have an MCP server?
Yes. HighLevel documents an official LeadConnector MCP server in its developer portal. The current documentation describes two endpoints: the per-client pattern at services.leadconnectorhq.com/mcp/{client}/v2, live today for Claude at /mcp/anthropic/v2, and the original endpoint at services.leadconnectorhq.com/mcp/. Both support OAuth and Private Integration Token authentication, and HighLevel states the original endpoint is not being deprecated.
What tools does the HighLevel MCP server expose?
The recommended per-client endpoint exposes six unified tools rather than one tool per operation: search, fetch, search_operations, describe_operation, execute_operation and list_locations. An assistant uses those six to discover and run the wider catalog, which HighLevel support articles last modified on 6 and 7 August 2026 put at 625 operations across 40 domains. The original endpoint exposes a narrower, focused set of core tools. On either endpoint, what a client actually sees is filtered by the scopes granted.
How do you authenticate with the GoHighLevel MCP server?
Both endpoints support two methods. OAuth is the documented recommendation, because the consent flow exposes a wider scope set and there is no credential to store or rotate. A Private Integration Token created under Settings and then Private Integrations also works, passed as a bearer token in the Authorization header, but HighLevel documents it as offering a more limited set of scopes than OAuth. Older HighLevel support documentation said OAuth was planned rather than available, and that statement is now out of date.
Which AI clients can connect to the HighLevel MCP server?
The per-client endpoint is live for Claude at services.leadconnectorhq.com/mcp/anthropic/v2, covering Claude.ai, Claude Code and Claude Cowork. HighLevel lists dedicated endpoints for OpenAI, Cursor, Windsurf and VS Code as planned rather than available. Until those ship, any HTTP-based MCP client can still connect through the original endpoint using either OAuth or a Private Integration Token.
What should you check before building on a CRM MCP server?
Check four things: whether the server is vendor-operated or a community project, how authentication and scoping work, how much of the underlying API is actually reachable through tools rather than only through REST, and whether the tool registry is versioned so an agent you ship today does not break silently next quarter.