Fetch all forms in a GoHighLevel location, filterable by type and paginated.
List all forms created in the location.
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "ghl_get_forms"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | ||
| type | No | Filter by form type | |
| limit | No |
Changes observed during successful MCP inspections.
v1.2.4Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description is responsible for disclosing behavioral traits. It only says 'List all forms...' without mentioning pagination (despite skip/limit parameters), filtering options, authentication needs, or return format. It adds minimal transparency beyond the tool name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'List', and contains no unnecessary words. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three optional parameters and no output schema, but the description does not explain pagination, filtering, or the scope of 'all forms'. It is incomplete for an agent to invoke correctly, especially with the 'type' filter and pagination parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'type' has a description). The tool description does not compensate for the missing 'skip' and 'limit' parameter explanations, nor does it clarify how 'type' filtering interacts with 'all forms'. It provides no additional meaning over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'List all forms created in the location' clearly states the action (list) and resource (forms) with a location scope. It is easy to understand, but it does not explicitly distinguish itself from sibling tools like ghl_get_form_submissions or ghl_get_surveys, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as ghl_get_form_submissions or ghl_get_surveys. The description simply states what it does without any context about filtering, pagination, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.