GoHighLevel MCP Starter

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action: calendar slot retrieval, contact search/by-id/creation, calendar listing, and appointment booking. There is no ambiguity between tools; even related tools like list_calendars and get_free_slots serve clearly different purposes.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern: get_free_slots, search_contacts, get_contact, create_contact, list_calendars, book_appointment. This makes the toolset predictable and easy to navigate.
Tool Count5/5
With 6 tools, the server is well-scoped for a GoHighLevel starter integration, covering contact management and calendar/appointment workflows without unnecessary bloat. Each tool serves a clear purpose within this domain.
Completeness3/5
The toolset covers contact creation, retrieval, search, and appointment booking, but lacks contact update/delete operations and appointment cancellation/listing. These are notable gaps, especially for a CRM-related server, though the core workflow of finding/creating contacts and booking appointments is intact.
Average 3.8/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning whether it is read-only, what it returns, pagination behavior, or any side effects. This leaves the agent without important context for a search operation.
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, clear, and front-loaded sentence with no filler. Every word adds meaning, and it avoids restating information already present in the schema.
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 is simple, but with no output schema and no mention of return format or pagination behavior, the description is only minimally complete. It provides enough to understand the search action but leaves gaps about what the agent will receive.
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%, so the baseline is 3. The description adds no new meaning beyond repeating the schema's parameter descriptions (query as name/email/phone, limit default). It does not clarify format or edge cases, so no extra credit is warranted.
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 states a specific verb ('Search') and resource ('contacts in the connected GoHighLevel location'), with searchable fields (name, email, phone). This clearly distinguishes it from siblings like get_contact (single contact retrieval) and create_contact (creation).
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 searching for contacts by name, email, or phone, but provides no explicit guidance on when to use this tool versus alternatives such as get_contact. Sibling tools exist but are not referenced, and there are no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly reveals the critical dry-run-by-default mechanism and the need for confirm:true to actually write, which is valuable context. It does not describe post-confirmation effects or return format, preventing a higher score.
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 two concise sentences, front-loaded with the core purpose followed by the key dry-run behavior. Every word earns its place with no redundancy.
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 no annotations, no output schema, and 6 parameters, the description is incomplete. It omits what happens after confirmation, whether fields are validated, and any guidance on returning a created object. This is insufficient for a potentially mutating 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 description coverage is only 33%, and the description fails to compensate. It only references confirm:true and 'payload' without explaining tags, email, phone, or name fields, leaving most parameters semantically undocumented.
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 phrase 'Create a contact' uses a specific verb and resource, clearly identifying the tool's action. It distinguishes from sibling tools which handle searches, slots, and appointments, making the purpose unambiguous.
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 creating contacts and emphasizes the dry-run-then-confirm pattern. However, it does not explicitly contrast with sibling tools or state when not to use this tool, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The description only says 'Fetch', which implies a read operation but gives no details about error handling, return format, authentication requirements, or behavior when the contact is not found. This is a significant gap for a tool with zero annotation support.
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, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose.
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 is simple: one parameter, no output schema, no annotations. The description covers the core purpose and the parameter's type, but omits any detail about the return value or failure behavior. For such a simple tool, this might be acceptable, but it still leaves basic expectations (e.g., what happens if the contact doesn't exist) unstated, making it minimally complete.
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?
The schema has no description for contactId (0% coverage), so the description must compensate. The description explains that the ID is a 'GoHighLevel contact id', which adds meaning beyond just 'contactId'. However, it doesn't specify format or any other nuances, so it is minimally sufficient for a single 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?
The description uses a specific verb ('Fetch') and resource ('one contact') and clearly identifies the lookup by 'GoHighLevel contact id'. This distinguishes it from sibling tools like search_contacts (which searches) and create_contact (which creates). Purpose is immediately 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 states this tool is for fetching a single contact by its ID, implying it should be used when the ID is known. It does not explicitly mention alternatives (e.g., 'use search_contacts if you don't have the ID'), but the context of having a specific ID is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It adds a useful detail: 'Handles the epoch-milliseconds requirement for you,' but it does not mention whether the operation is read-only, what side effects exist, error behavior, or return format. Some context is provided, but significant gaps remain.
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 two sentences, front-loaded with the core purpose, and contains no redundant or extraneous information. Every word earns its place.
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?
There is no output schema, so the description must explain what the returned slots look like—especially since book_appointment likely needs a slot identifier. It does not describe the return structure, nor does it address how timezone affects slot availability. This makes it insufficient for an agent to fully chain with the sibling tools.
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?
Schema coverage is 75% (three of four parameters have descriptions). The description adds value by revealing that date parameters are automatically converted from ISO 8601 to epoch milliseconds, which is not stated in the schema. It does not clarify calendarId or timezone semantics further, but the added detail improves parameter understanding.
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 gets 'real bookable slots' for a specified calendar and date range, using a specific verb and resource. This distinguishes it from siblings like book_appointment and list_calendars.
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 finding available slots before booking, but it does not explicitly say when to use this versus alternatives, nor does it mention any exclusions or prerequisites. The guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It reveals the output contents (ids and slot durations) and implies a read-only operation, but does not mention any limitations, authentication requirements, or side effects. Adequate for a simple listing, but lacks depth.
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?
One concise sentence that is front-loaded with the action and resource. Every word contributes meaning without redundancy or filler.
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 zero parameters and no output schema, the description adequately supports invocation by stating what the tool returns. It could mention ordering or filtering, but for a simple 'list all' operation, the provided information is sufficient for an agent to select and call it.
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 input schema has zero parameters, so the description need not explain parameter syntax. Baseline of 4 for tools with no parameters is appropriate; the description adds no parameter information but none is 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 the tool lists all calendars in the connected location, specifying the output includes ids and slot durations. The verb 'list' is specific and the resource is well-defined, distinguishing it from sibling tools like get_free_slots which focuses on availability slots.
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 explicit guidance on when to use this tool versus alternatives. There is no mention of exclusions, complementary tools, or scenarios where another tool would be more appropriate. The usage context is only implied by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses critical behavioral traits: it verifies the slot first (read-before-write) and is dry-run by default, requiring confirm:true for the actual booking. This is excellent transparency for a mutating 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?
The description is two sentences, front-loaded with the core purpose, and every word adds value. It avoids fluff and is easy to parse quickly.
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?
The description covers the most important behavioral context (dry-run, verification) but does not mention return values or error handling, and there is no output schema. It also does not relate to sibling tools, leaving the agent to infer the workflow. Still, it is fairly complete for a booking operation.
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?
The schema covers 57% of parameters with descriptions. The description emphasizes the confirm parameter's dry-run behavior, but this is largely already in the schema. It does not explain the undocumented parameters (title, contactId, calendarId), so it adds limited value beyond the schema.
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 books an appointment, using a specific verb and resource. It also distinguishes from siblings like get_free_slots by noting it verifies the time is a real free slot before writing.
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?
It provides the key usage instruction to pass confirm:true to actually book, and explains the dry-run default. However, it does not explicitly mention when to use this tool versus alternatives like get_free_slots, nor does it state any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![gohighlevel-mcp-starter MCP server](https://glama.ai/mcp/servers/rockurbusinesscs-ship-it/gohighlevel-mcp-starter/badges/card.svg)](https://glama.ai/mcp/servers/rockurbusinesscs-ship-it/gohighlevel-mcp-starter)

Score Badge

Copy to your README.md:

[![gohighlevel-mcp-starter MCP server](https://glama.ai/mcp/servers/rockurbusinesscs-ship-it/gohighlevel-mcp-starter/badges/score.svg)](https://glama.ai/mcp/servers/rockurbusinesscs-ship-it/gohighlevel-mcp-starter)

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/rockurbusinesscs-ship-it/gohighlevel-mcp-starter'

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