GoHighLevel MCP

Server Quality Checklist

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

Latest release: v1.2.4
Disambiguation3/5
With 127 tools spanning many GHL modules, most tools are clearly separated by resource (contacts, conversations, calendars, opportunities, payments, etc.). However, there is direct overlap between ghl_get_contacts and ghl_search_contacts, and similar list/get pairs (e.g., ghl_get_invoices vs ghl_get_invoice) may confuse agents. Descriptions are detailed and generally disambiguate, but the sheer volume introduces some boundary ambiguity.
Naming Consistency4/5
All tool names follow a consistent snake_case verb_noun pattern with the ghl_ prefix, using verbs like get, create, update, delete, and upsert. The main inconsistency is the mixed use of 'get' and 'list' for retrieval operations (e.g., ghl_get_contacts vs ghl_list_faqs), and some domain-specific verbs like 'purchase' and 'discover'. Overall, naming is predictable and readable.
Tool Count1/5
127 tools is an extreme mismatch for an MCP server, far exceeding the 50+ threshold. Even for a comprehensive platform like GoHighLevel, this volume overwhelms agents and makes tool selection difficult. A more curated set of 15-30 high-level tools would be far more usable.
Completeness3/5
The server covers a wide range of GHL features with full CRUD for contacts, opportunities, users, knowledge bases, FAQs, and templates. However, several exposed modules are incomplete: funnels are read-only (get only), forms/surveys have no create/update/delete, media library lacks upload, and social posts have no update. These notable gaps mean agents will hit dead ends for common operations.
Average 3.4/5 across 127 of 127 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 148 commits in the last 12 weeks
- Last stable release on August 4, 2026
- 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.
This repository includes a glama.json configuration file.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core action and fails to mention any side effects, permissions, reversibility, or error conditions. The description adds no context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. While it wastes no words, it is not appropriately sized for a tool with 10 parameters and 4 required fields. It fails to convey essential usage context that a few additional sentences could provide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 params, 4 required, 50% schema coverage), no output schema, and no annotations, this description is completely inadequate. It does not explain return values, error handling, or any operational context, making it nearly impossible for an agent to invoke the tool confidently.
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 does not address any parameters, leaving the agent to rely solely on the schema. With only 50% schema coverage (5 of 10 params documented), the description should compensate for gaps like cc, bcc, subject, fromName, and conversationId, but it does not.
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 ('Send an email') and the resource ('within an existing conversation'). It distinguishes from siblings like ghl_send_message by specifying email rather than a generic message, though it does not explicitly name alternatives.
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 such as ghl_send_message or ghl_add_inbound_message. There is no mention of prerequisites like the conversation needing to exist.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. Saying 'Update' implies mutation, but it does not explain whether missing fields are left unchanged, whether options are replaced entirely, or what the response contains. This is minimal behavioral transparency for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence of five words. It is not verbose, but it is under-specified rather than effectively structured. There is no front-loaded detail beyond the basic action, so it earns a middle score.
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 mutation tool with 5 parameters, no annotations, and no output schema, the description is far from complete. It does not explain what a custom field is, what update semantics apply (e.g., partial vs. full replacement), or what the caller should expect in return. Sibling tools like ghl_get_custom_fields and ghl_create_custom_field hint at context, but the description itself leaves major gaps.
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?
Schema description coverage is only 20%, with only fieldId documented. The description does not compensate by explaining the meaning of name, options, position, or placeholder, nor how they interact. The tool's five parameters are left almost entirely unexplained, and the description adds no parameter-level meaning.
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 a specific action ('Update') and resource ('an existing custom field'), which distinguishes it from sibling tools like ghl_create_custom_field and ghl_delete_custom_field. However, it lacks detail about what fields can be updated or how it differs from ghl_update_custom_value, so it doesn't fully earn a 5.
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 guidance on when to use this tool versus alternatives. It does not mention that create_custom_field is for new fields, delete_custom_field for removal, or update_custom_value for values. There is no exclusion or context about prerequisites such as fieldId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral transparency burden. It only says 'Update an existing custom value' without disclosing effects, reversibility, permissions, or response behavior. This is essentially a tautology of the tool name and offers no additional insight into the mutation's implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is appropriately front-loaded and free of fluff. However, it is under-specified and merely restates the tool's name with minimal additional information, so it does not fully earn its place as a useful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description is too terse to convey necessary context such as what a custom value is, which fields are updatable, expected inputs, or any side effects. This is inadequate for an agent to use the tool correctly without external knowledge.
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 schema has 3 parameters (name, value, valueId), but only valueId has a description. Schema description coverage is only 33%. The main description does not explain what 'name' or 'value' mean or how they relate to a custom value, leaving the agent with ambiguous fields and no semantic guidance.
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 action ('Update') and the resource ('existing custom value'), which distinguishes it from sibling tools like ghl_create_custom_value and ghl_delete_custom_value. The verb and resource are specific enough for an agent to understand the tool's core function.
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 guidance on when to use this tool instead of alternatives such as ghl_create_custom_value or ghl_delete_custom_value. There is no mention of prerequisites, context, or exclusions, leaving the agent without a decision framework.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. The description merely restates the tool's name, offering no additional context about irreversibility, permissions, side effects, or return behavior. It adds no value beyond what the name already implies.
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 concise sentence with no unnecessary words. It is front-loaded and easy to parse. However, it is under-specified, which limits its overall value, though that is more a matter of content than conciseness.
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 the tool's simplicity (one parameter, no output schema), the description is minimal but still incomplete. It does not explain what a trigger link is, how to find the linkId, or the consequences of deletion (e.g., whether it is a hard delete). More context is needed for an agent to confidently use this tool without additional assumptions.
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 schema has one parameter (linkId) with 0% description coverage. The description does not mention or explain linkId, leaving the agent to infer its meaning from the parameter name alone. Since schema coverage is low, the description was expected to compensate, but it fails to do so.
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 action ('Delete') and the resource ('trigger link'), which distinguishes it from sibling tools like get_trigger_links and create_trigger_link. The verb+resource combination is specific and unambiguous.
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 guidance on when to use this tool, any prerequisites, or alternatives. It simply states the operation without explaining the context (e.g., when a trigger link should be deleted) or any conditions under which it should not be used.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states a read operation without revealing response format, pagination behavior, authentication needs, or scope limitations. No additional context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it is under-specified. It is a complete sentence but lacks the contextual structure that would make it valuable, though it does not waste 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 tool with 7 parameters, no annotations, and no output schema, this description is critically incomplete. It fails to explain the response format, filter behavior, pagination, or how the location context is determined.
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 14% (only contactId has a description), so the description must compensate. It mentions none of the 7 parameters, leaving endAt, limit, offset, search, status, and startAt semantically unexplained beyond their types and enum.
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 uses a specific verb 'Get' and clearly identifies the resource as 'invoices' (plural), distinguishing it from the singular 'ghl_get_invoice' tool. However, 'in the location' is vague and does not specify what constitutes a location or what the response includes.
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 like ghl_get_invoice (singular) or invoice mutation tools. The description does not mention filtering, pagination, or any specific use cases.
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?
With no annotations, the description bears full responsibility for behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not mention pagination behavior, date filtering, return format, or any side effects. It offers minimal transparency beyond the implied read-only nature.
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, clear sentence with no wasted words. It is concise and front-loaded, though it may be too brief to convey necessary details. However, as a short statement it is well structured.
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 the tool has 5 parameters, no output schema, and no annotations, the description is too sparse. It lacks critical context such as pagination handling, date range format, filtering by contact, and expected response structure. The one-sentence description is insufficient for a tool with this complexity.
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 schema provides no descriptions for any of the 5 parameters (0% coverage), and the description does not explain them. Parameter names like 'page', 'limit', 'startAt', 'endAt', and 'contactId' are self-explanatory to some extent, but the description does not clarify their format, constraints, or usage, leaving the agent without essential semantic information.
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 retrieves payment transactions, with a specific verb ('Get') and resource ('payment transactions'). It is distinct from siblings like ghl_get_orders or ghl_get_invoices, but does not explicitly differentiate itself from them, so it lacks strong sibling differentiation.
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 preferred scenarios, exclusions, or comparison to sibling tools like ghl_get_orders or ghl_get_invoices. The description gives no context for decision-making.
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 side effects. It states the primary action but does not mention test mode, resend behavior, or consequences like marking the invoice as sent.
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?
One efficient sentence with no filler, but it is under-specified for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, no annotations, and no output schema, this minimal description leaves critical gaps such as the meaning of action, liveMode, and the required invoiceId.
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 does not explain any parameter meaning. Schema documents userId and liveMode, but invoiceId and action are left unspecified; action's send/resend semantics are not clarified.
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 sends an invoice via email, using a specific verb and resource. It distinguishes from invoice creation/retrieval, though sibling ghl_send_email could overlap.
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 other sending tools like ghl_send_email, or when to use send vs resend.
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?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states that the tool retrieves scheduled or published posts, omitting that the status parameter also supports 'failed' and 'all', and does not mention default behavior, pagination via skip/limit, or output format. This lack of detail is a significant gap for a read tool without 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key verb and resource. It wastes no words, though it could be slightly more informative without losing conciseness. It is not overly verbose but lacks some critical details that would fit naturally in a longer description.
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 there is no output schema and no annotations, the description must provide sufficient context for the agent to invoke the tool correctly. It fails to cover default parameter values, the full status range, pagination behavior, or return structure, making it incomplete for a tool with three parameters and zero schema description coverage.
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 schema has 0% description coverage and the description does not explain the parameters. It partially hints at the 'status' parameter by mentioning scheduled or published posts, but omits the 'failed' and 'all' enum values and provides no explanation of 'skip' or 'limit'. This does little to compensate for the undocumented schema.
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 identifies the tool as fetching social media posts, using the verb 'Get' and resource 'social media posts'. It distinguishes from sibling tools like ghl_create_social_post and ghl_delete_social_post by indicating a read operation, though it does not explicitly differentiate from ghl_get_social_accounts (accounts vs posts is implicit). The qualifier 'scheduled or published' is slightly limiting given the status enum includes 'failed' and 'all', but the core purpose is unambiguous.
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 such as ghl_get_social_accounts or ghl_create_social_post. There is no mention of scenarios, exclusions, or related tools, leaving the agent to infer usage solely from the name and basic description.
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 provided, so the description carries full burden. It does not disclose return format, pagination, rate limits, or whether results include full conversation objects or summaries. It only lists filters, which is minimal and does not go beyond the obvious search behavior.
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?
One short sentence with no fluff, front-loaded with the action. However, the sentence includes an inaccurate 'date' filter, which is a content issue, but structural conciseness is achieved.
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 search tool with 5 parameters, no output schema, and no annotations, the description is too thin. It doesn't explain what gets returned, how limit works, or what status values mean beyond the enum. The false 'date' filter makes the description less complete and potentially misleading.
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 maps 'contact' to contactId, 'status' to status, and 'type' to lastMessageType, but also mentions 'date' which has no corresponding parameter. The undocumented parameters limit and status receive no explanation. With 60% schema coverage, it partially compensates but introduces a false parameter.
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 uses a specific verb 'Search' with resource 'conversations' and lists filter dimensions (contact, status, type, date). It clearly distinguishes from siblings like get_conversation (fetch single) and get_messages. However, the 'date' filter is not in the schema, slightly reducing clarity.
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 like ghl_get_conversation or ghl_get_messages. The description simply states the search action and filters, leaving the agent to infer use cases. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely states 'Update an existing contact note' without conveying side effects, error handling, return values, or any other behavioral context.
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 that directly states the action. It contains no wasted words and is appropriately front-loaded.
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 the absence of annotations and output schema, the description is insufficient. It only states the action and does not mention required fields, update semantics (full vs. partial), or what the response contains, making the tool incomplete contextually.
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?
Schema description coverage is only 33% (only 'body' has a description), and the tool description adds no parameter information. The IDs (contactId and noteId) remain undocumented, forcing the agent to infer their meaning from the name alone.
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 ('Update') and resource ('contact note'), clearly indicating it modifies an existing note. This distinguishes it from sibling tools like ghl_create_contact_note and ghl_delete_contact_note.
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, when a note needs updating, or how it differs from other note operations.
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?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only says 'Update' without mentioning that this is a mutation, whether updates are partial or full, required permissions, or effects on linked data. The behavioral profile is essentially the same as what the tool name already conveys.
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, lean sentence with no filler, and it front-loads the action. It is appropriately minimal, though it could arguably be richer without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and no annotations, a one-line description is insufficient. It omits any information about required vs optional fields, intended usage patterns, response values, or edge cases, making it incomplete for correct invocation.
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 adds no meaning beyond the input schema. Schema description coverage is only 14% (just 'completed'), and the description does not explain any of the other six parameters (body, title, dueDate, taskId, contactId, assignedTo), nor their relationships or formats. It fails to compensate for the low schema coverage.
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 ('Update') and the resource ('a task for a contact'), which is specific and distinguishes it from contact-level updates like ghl_update_contact. However, it does not explicitly differentiate from task create/delete operations, leaving some ambiguity at the sibling 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 phrase 'for a contact' implies the tool is used when a task associated with a specific contact needs modification. There is no explicit guidance on when to use this instead of ghl_create_contact_task or ghl_delete_contact_task, nor any exclusion criteria, so the usage context is only implied.
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?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states that an update occurs, without explaining whether it is a partial or full replacement, whether omitted fields are preserved, or the permission requirements. There is no mention of side effects, errors, or return values, which is a significant gap for a mutation tool.
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, front-loaded sentence that is easy to scan and contains no redundant wording. It efficiently gives the core verb and examples, though the brevity limits the depth of information conveyed. It earns its place without being 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?
Given the tool has 9 parameters, no output schema, no annotations, and multiple related sibling tools, this description is incomplete. It does not address required vs optional fields, how customFields should be structured, or what the response contains. The agent lacks essential context for safe and effective invocation, especially compared to the richer descriptions expected for such a parameter-heavy 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 11% (only pipelineStageId has a description). The description maps 'move to a new stage' to pipelineStageId, 'update value' to monetaryValue, and 'reassign' to assignedTo, but it does not explain name, source, status, pipelineId, or customFields. The 'etc.' hints at more but fails to clarify the semantics of the remaining six parameters.
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 uses a clear verb+resource structure: 'Update an opportunity' followed by examples of common actions (move to a new stage, update value, reassign). This distinguishes it from create/get/delete tools, though the presence of a sibling 'ghl_update_opportunity_status' creates some ambiguity about whether status updates are included here. The 'etc.' covers the missing status field, so the purpose is reasonably clear.
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?
There is no explicit guidance on when to use this tool versus alternatives. It does not mention that for status-only updates one might use 'ghl_update_opportunity_status', nor does it provide any context about prerequisites or when a partial vs full update is appropriate. The usage context is only implied by the verb and examples.
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?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It only states 'Update' without explaining whether it performs a partial or full replacement, how unspecified fields are handled, or any side effects. No mention of return values, error conditions, or required permissions. This is a significant gap for a mutation operation.
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 concise sentence that directly states the purpose. It is front-loaded and free of waste. However, it is perhaps too terse, lacking any structured detail about usage or parameters, so it does not fully earn its place in context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, this description is severely incomplete. It does not explain update semantics, optional vs required fields, or any behavioral nuances. It is not minimally viable for an agent to invoke correctly without additional information.
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?
Schema description coverage is only 20% (only templateId has a description), and the description itself does not explain any parameters. It mentions SMS/email/WhatsApp but does not clarify how body, subject, name, or attachments relate to the update. The description adds no value beyond the schema's minimal information.
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 action ('Update') and the resource ('an existing SMS/email/WhatsApp template'), which distinguishes it from sibling tools like ghl_create_template, ghl_delete_template, and ghl_update_email_builder_template. The verb-resource combination is specific and unambiguous.
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 context on when to use this tool versus alternatives, such as ghl_update_email_builder_template or ghl_create_template. It does not mention any prerequisites, exclusions, or scenarios where another tool would be more appropriate. There is no usage guidance beyond the literal statement of purpose.
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?
With no annotations, the description carries the full burden. It only mentions 'Returns the created contact object' as behavioral context. It does not disclose validation requirements, duplicate handling, idempotency, auth needs, or the fact that all parameters are optional, leaving significant uncertainty for a mutation 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 short sentences, front-loaded with the verb and resource. Every word earns its place; no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 parameters, no output schema, no annotations, and only 25% schema description coverage, this description is severely under-specified. It fails to explain required vs optional fields, return structure beyond 'object', relationship to upsert, or any behavioral caveats. The agent is left without critical context needed for correct invocation.
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?
Schema description coverage is only 25%, and the description adds no meaning for the 16 parameters. It does not even mention that all fields are optional or explain key fields like email or customFields. The description provides zero parameter-level clarity beyond the schema itself.
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 action ('Create'), the resource ('a new contact'), and the scope ('in the GHL location'). This distinguishes it from sibling tools like ghl_update_contact, ghl_upsert_contact, ghl_get_contact, and ghl_delete_contact.
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 given on when to use this tool versus the closely related ghl_upsert_contact or ghl_update_contact. The phrase 'new contact' weakly implies use for new records, but there is no explicit when-not-to-use or alternative naming, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 disclosing behavior. It does not mention read-only semantics, pagination, ordering, permissions, or whether completed tasks are included. The description is essentially a restatement of the tool name, offering no additional behavioral insight.
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, concise sentence with no fluff. It is front-loaded and directly states the core function, though it could be expanded to include necessary behavioral context without becoming overly 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?
Given the absence of annotations, output schema, and any parameter details, the description is insufficient for an agent to fully understand the tool's behavior. It does not address filtering, pagination, return fields, or error scenarios, making it incomplete for a production context.
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 schema has 0% description coverage and the description does not explain the contactId parameter beyond implying it is the contact identifier. The phrase 'for a contact' adds minimal context but no details about format, requirements, or behavior.
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 specifies the action ('Get all tasks') and the target resource ('for a contact'), which distinguishes it from sibling tools like ghl_get_contact_notes or ghl_get_contact_appointments. It is specific, action-oriented, and unambiguous.
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?
There is no guidance on when to use this tool versus alternatives, such as when to use ghl_create_contact_task or how it differs from ghl_get_contact_notes. The description simply states what it does without context or exclusions.
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?
With no annotations provided, the description carries the full burden. It only states 'List', implying read-only, but does not disclose pagination behavior, default status filtering, rate limits, or what the 'schedule endpoint' entails. The agent lacks insight into the tool's operational behavior.
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, concise sentence that front-loads the primary purpose. It is appropriately sized for a simple list operation, though it omits useful detail. It earns its place by stating the verb, resource, and endpoint.
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 tool is simple with three optional parameters and no output schema or annotations, but the description is incomplete. It does not explain the parameters or the implications of 'via the schedule endpoint', leaving gaps in how the agent should invoke the tool effectively.
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?
Schema description coverage is 0%, and the description adds no meaning for limit, offset, or status. The parameter names and enum values are self-explanatory, but the description does not compensate for the lack of schema documentation, leaving the agent without context on how these parameters affect results.
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 action (list) and resource (email marketing campaigns) with a specific scope ('in the location') and an endpoint detail ('via the schedule endpoint'). This distinguishes it from siblings like ghl_get_email_campaign (singular get) and ghl_get_campaigns (generic campaigns).
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. The description only states what it does, with no mention of when to choose it over ghl_get_email_campaign, ghl_get_campaigns, or other campaign-related tools.
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?
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
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 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits itself. It only mentions that subscriptions are 'active' but does not explain return format, pagination, authorization requirements, or what happens with invalid parameters, offering minimal transparency.
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 concise sentence that immediately states the action and target. It is front-loaded and free of fluff, though it sacrifices detail for brevity.
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 the tool has no annotations, no output schema, and three undocumented parameters, the description is too sparse. It does not cover pagination behavior, filtering semantics, or expected response structure, making it inadequately complete for an agent to use reliably.
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?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. However, it does not mention page, limit, or contactId at all, providing no additional meaning beyond the parameter names and types in 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 uses the specific verb 'Get' and resource 'subscriptions', clearly indicating it retrieves subscription data scoped to the current location. It is distinct from sibling tools like ghl_get_orders or ghl_get_transactions, which handle different resource types.
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 guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or situations where another tool would be more appropriate, leaving usage context entirely to inference.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. Though 'List' implies a read-only operation, it does not mention pagination behavior, default ordering, response format, or any side effects, adding minimal context beyond the tool name.
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 concise sentence with no redundant words, and the main action is front-loaded. It is not bloated, though it may be under-specified for the tool's complexity, which is acceptable under the conciseness dimension.
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 tool with three parameters and no output schema or annotations, the description is insufficiently complete. It doesn't explain how skip and limit work, what 'type' filters, or what the returned data looks like, leaving an agent with significant ambiguity.
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 refer to any of the three parameters (skip, type, limit). Only the schema's 'type' parameter has a description, leaving skip and limit completely undocumented. With schema coverage at 33%, the description fails to compensate and adds no meaning to the parameters.
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 all surveys created in the location, using the verb 'List' and specific resource 'surveys', which distinguishes it from sibling tools like ghl_get_survey_submissions that deal with survey submissions rather than surveys themselves.
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 gives no guidance on when to use this tool versus alternatives such as ghl_get_survey_submissions or ghl_get_forms, nor does it mention pagination or filtering context. It simply states the basic function without any contextual use cases or exclusions.
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?
With no annotations provided, the description must convey behavioral traits on its own. It only states the basic action, without disclosing potential side effects, permission requirements, or what happens if the contact does not exist. The mutation nature is implied but not elaborated.
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, front-loaded sentence with no redundancy or fluff. However, it is quite under-specified, lacking any structural breakdown of important details, making it not fully appropriately sized for the tool's complexity.
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?
Despite the tool's apparent simplicity (3 simple parameters, no output schema), the description is incomplete. It does not explain return behavior, required permissions, or error conditions, and with no annotations to fill gaps, it leaves the agent without sufficient context for reliable invocation.
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 schema already describes 'body' and 'userId', but 'contactId' lacks a description and the tool description adds no additional parameter meaning. With only 67% schema coverage and no compensation from the description, the missing 'contactId' semantics remain unclear beyond its name.
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 'Add a note to a contact' uses a specific verb and resource, clearly indicating the action of creating a note for a contact. It distinguishes from sibling tools like ghl_get_contact_notes, ghl_update_contact_note, and ghl_delete_contact_note by using 'add' as the operation.
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 guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It lacks any contextual information about choosing this over other note-related or contact-related tools.
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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states that it creates a conversation thread, but does not mention side effects, permissions, idempotency, or whether a conversation thread is distinct from a message. This leaves the agent without key information about the operation's implications.
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 redundant words. Every word contributes to the meaning, making it highly concise and easy to parse.
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 single-parameter create operation, the description covers the essential action and target. However, without annotations or an output schema, it lacks details about return values (e.g., conversation ID), potential errors, or how the conversation thread fits into the broader messaging workflow. It is minimally adequate but leaves obvious 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?
The schema has a single parameter (contactId) with no description, and schema coverage is 0%. The description adds only 'for a contact,' which clarifies that contactId is a contact identifier but does not explain its format, where to obtain it, or whether it is the initiator or participant. This is insufficient compensation for the lack of schema documentation.
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 identifies the action (create), the resource (conversation thread), and the target (a contact). This distinguishes it from sibling tools like search_conversations or send_message, which focus on retrieving or messaging within existing threads. However, it does not explicitly mention how it differs from creating a message, so it's specific but not fully elaborated.
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 guidance on when to use this tool versus alternatives. There is no mention of prerequisites, such as whether the contact must already exist, or how this differs from adding a message to an existing conversation. Sibling tools like send_message or add_inbound_message are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It fails to mention side effects, required permissions, idempotency, validation, or return behavior. The description merely restates the action from the tool name.
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, well-formed sentence with no redundancy. It is front-loaded and efficient. However, given the tool's 8 parameters, it is arguably too sparse, but as a concise statement it is 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 8 parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain return values, error behavior, usage context, or any nuances of creating a coupon, leaving significant gaps for an agent.
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 75%, so the baseline is 3. The description adds no parameter-level meaning beyond the schema, and the two undocumented parameters (name, discountType) remain unexplained. The schema does most of the heavy lifting.
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 the specific verb 'create' and identifies the resource as a 'discount coupon', which clearly distinguishes this tool from siblings like ghl_get_coupons or other create tools. It is unambiguous and acts as a precise verb+resource statement.
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?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description only states the action without any contextual usage instructions.
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, and the description adds no behavioral context. It does not mention whether duplicate names are rejected, whether fieldKey is auto-generated, or what the response includes. This is a significant gap for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded, but it is too sparse to be useful. It omits necessary context, trading completeness for brevity.
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 8 parameters, no output schema, and no annotations, the description is severely under-specified. It only states the basic action, leaving the agent without information about how to construct valid requests or what to expect in return.
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 schema description covers 63% of parameters, but the tool description adds no parameter-level information. Undocumented parameters like position and placeholder remain unexplained, and the description does not compensate for this gap.
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 action (create) and resource (custom field) within a location. It distinguishes from sibling tools like update_custom_field and delete_custom_field, though 'location' could be more explicit.
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 like update_custom_field or create_custom_value. It does not mention prerequisites or cases such as needing a folder (parentId) or whether options are required for certain dataTypes.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and does not reveal if the operation is idempotent, what it returns, any naming restrictions, or potential side effects. For a creation tool, this is a notable 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 concise sentence with no unnecessary words. It is structurally clear and front-loaded with the action, but it is so brief that it borders on under-specification, so it does not earn a 5.
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 tool is simple (1 parameter, no output schema), but the description lacks any contextual information such as return value, error conditions, or relationship to sibling tag tools. The absence of annotations and output schema makes this description 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?
The schema covers 100% of the parameters with 'name' described as 'Tag name', so the baseline is 3. The description adds no additional semantic detail beyond what the schema already provides, but it does not need to since the schema is sufficient.
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 verb 'Create' and the resource 'a new tag in the location', making the primary purpose obvious. However, it does not distinguish this from sibling tools like ghl_add_contact_tags or ghl_delete_location_tag, so it falls short of a 5.
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, such as ghl_add_contact_tags (for contact tags) or ghl_delete_location_tag. The description does not mention any prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of disclosing behavioral traits. It only says 'Delete a tag' without mentioning irreversibility, effects on contacts, permissions required, or error behavior. This is a significant gap for a destructive 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, focused sentence with no redundant words. It is front-loaded with the action and resource, making it appropriately concise for a simple tool.
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 simple one-parameter delete operation, the description gives the basic action, but it omits contextual details such as where the tag ID comes from, consequences of deletion, or any prerequisites. Given the low complexity and no output schema, it is partially complete but leaves important behavioral 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?
The input schema has 100% coverage for the single tagId parameter, with a clear description already provided. The tool description adds no additional meaning beyond what the schema states, so the baseline of 3 applies.
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 (delete) and resource (tag from the location), making it distinguishable from other delete tools like delete_contact_note. However, it does not explicitly reference sibling tools or provide additional differentiation beyond the resource name, though the name already encodes this.
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 such as ghl_remove_contact_tags or ghl_create_location_tag. There are no prerequisites, context, or exclusion criteria mentioned, leaving the agent to infer usage solely from the tool name.
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?
Annotations are absent, so the description must carry the full burden. It states only 'List all funnels' and does not disclose pagination via limit/offset, default response size, filtering behavior, or any side effects. The return structure is also unspecified.
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, front-loaded with the key information, and no wasted words. It is highly concise and immediately understandable.
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 annotations, no output schema, and a sparse parameter explanation, the description is too thin to fully equip an agent. It lacks pagination details, response format, and how it relates to other funnel tools, making it incomplete for a list operation.
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?
Schema coverage is only 33% (only 'name' has a description). The description does not explain limit or offset, and 'List all funnels' does not clarify default behavior or how the name filter interacts. It fails to compensate for the low 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 uses a specific verb (List) and resource (funnels), scoping it to 'the location'. This clearly distinguishes it from sibling tools like ghl_get_funnel_pages or ghl_get_pipelines.
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 such as ghl_get_funnel_pages, nor are there any exclusions or prerequisites. The description simply states the function without contextual usage hints.
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 carries the full burden for behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not mention any critical details such as required permissions, response format, error behavior, or whether the resource might be modified.
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 sentence with no superfluous information. It is appropriately brief for a straightforward get-by-ID operation.
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 tool is simple, but with no annotations and no output schema, the description is the only source of context. It does not mention what the response contains, any potential pitfalls, or usage context, leaving the agent with only a minimal understanding.
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?
Schema description coverage is 0%, and the description adds no meaning beyond what the parameter name 'opportunityId' already conveys. Saying 'by ID' is redundant with the schema, providing no additional semantic value.
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 the verb (Get), the resource (specific opportunity), and the scope (by ID). This distinguishes it from sibling tools like ghl_search_opportunities, which involves querying for multiple opportunities.
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. While the name and description imply using it when you have an opportunity ID, there is no explicit mention of when not to use it or when to prefer ghl_search_opportunities instead.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without revealing pagination behavior, return format, or whether filters are mandatory. The schema hints at filters, but the description adds no context beyond the 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?
The description is a single sentence with no redundancy, effectively stating the core function. It is appropriately concise and front-loaded.
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, and the description doesn't explain what the response contains or how pagination works. With 6 optional filter parameters and many sibling commerce tools, a single sentence is insufficient for an agent to correctly understand the tool's full 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?
The schema describes endAt, startAt, and contactId, but page, limit, and status lack descriptions. The description itself adds no parameter semantics. However, page and limit are standard pagination parameters, and status has an enum that is self-explanatory, so the gaps are acceptable.
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 uses the verb 'Get' plus resource 'payment orders', clearly indicating it retrieves payment order data. However, it doesn't explicitly differentiate from the sibling 'ghl_get_order' (singular) or clarify the meaning of 'the location'.
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 about when to use this tool versus alternatives like ghl_get_order, ghl_get_transactions, or ghl_get_invoices. There are no mentions of use cases, prerequisites, or exclusions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state that purchasing may incur costs, is likely irreversible, or what the outcome/return value is. This is a significant gap for a financial transaction 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 a single, short sentence with no unnecessary words. It is appropriately sized and immediately communicates the core function.
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 purchase action, the description is incomplete. It lacks information about the expected response, possible errors, financial implications, or how the purchased number is associated with the location. This is insufficient for an agent to invoke the tool with confidence.
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 input schema already describes the phoneNumber parameter and its E.164 format at 100% coverage. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
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 verb 'purchase' and the resource 'phone number', distinguishing it from sibling tools like search, release, and update. However, 'for the location' is vague and doesn't specify which location or how it is determined, slightly detracting from clarity.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that one might need to search for available phone numbers first (e.g., via ghl_search_available_phone_numbers) or any prerequisites for purchasing.
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 present, so the description must carry the burden of behavioral disclosure. It correctly states the destructive action but does not mention whether the deletion is permanent, idempotent, or what happens if the note does not exist. This leaves behavioral traits undisclosed.
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 that directly communicates the tool's purpose with no extraneous words. It is appropriately front-loaded and easy to parse.
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 simple two-parameter delete operation, the description is minimally complete: it states the action and identifies the resource. However, it lacks any detail about return values, error handling, or whether the operation is reversible, which would be more complete given the absence of annotations and output schema.
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?
Schema description coverage is 0%, and the description does not explain the two parameters (contactId and noteId) beyond what their names imply. The description adds no additional meaning regarding format, constraints, or usage, failing to compensate for the lack of schema descriptions.
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 action (delete) and the target (a note within a contact), which is specific enough to distinguish from sibling tools like ghl_create_contact_note or ghl_delete_contact. The verb 'Delete' and object 'note' are unambiguous.
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, such as when deleting the entire contact or removing a tag. The description only states the action without any context about prerequisites, side effects, or situations where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 disclosing behavioral traits. It only says 'Remove a team member' without stating that this is a permanent deletion, that it may have irreversible consequences, or that specific permissions are required. For a destructive operation, this lack of disclosure is a significant gap.
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 that is front-loaded with the action and resource. It contains no filler or redundant information, making it easy for an agent to parse quickly.
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?
This is a one-parameter destructive tool with no output schema and no annotations. The description is minimal and does not elaborate on the outcome, error handling, or whether the deletion is permanent. For a deletion operation, this level of completeness is insufficient for an agent to understand the full impact.
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 input schema has 100% coverage for the single parameter 'userId', with its description 'User ID to delete' being self-explanatory. The tool description adds no extra meaning beyond the schema, which is acceptable given the high schema coverage, but it does not compensate for any potential ambiguity in parameter format or source.
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 action ('Remove') and the resource ('a team member') with the context 'from the location'. This specific wording distinguishes it from sibling user tools like ghl_create_user or ghl_update_user, leaving no ambiguity about what the tool does.
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 guidance on when to use this tool versus alternatives, such as ghl_update_user for updating roles or ghl_get_user for viewing. It also does not mention any prerequisites, side effects, or alternatives for revoking access versus deleting a user.
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?
With no annotations provided, the description carries the full burden. It simply says 'Get a specific calendar by ID' without disclosing behavioral traits such as read-only nature, authentication requirements, rate limits, or return structure. The description adds no information beyond the obvious action.
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 short sentence with no extraneous content. For a tool with one parameter and a straightforward operation, this length is efficient, though it is also minimal in substantive detail.
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 simple get-by-ID operation, the description is minimally viable but lacks helpful context. It does not cross-reference sibling tools like 'ghl_get_calendars' for listing, nor does it explain what a calendar resource contains or any expected output. The absence of an output schema increases the burden on the description, which it does not fully meet.
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 0%, so the description must compensate. The only parameter 'calendarId' is minimally explained as 'by ID', which tells the agent it is an identifier, but does not specify format, source, or how to obtain valid values. The schema already defines the type as string, so the description provides little additional meaning.
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 retrieves a single calendar by ID, using the verb 'Get' and the resource 'specific calendar'. It hints at differentiation from the sibling 'ghl_get_calendars' (plural) through the word 'specific', but does not explicitly name or contrast with that alternative.
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 phrase 'by ID' implies the tool should be used when one has a calendar identifier, but there is no explicit guidance on when to choose this over sibling tools like 'ghl_get_calendars' (list all) or 'ghl_get_calendar_groups' (list groups). Usage context is only implied, not stated.
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 carry the behavioral burden. It fails to disclose side effects (e.g., whether notifications are triggered, what happens to existing appointments, idempotency, or if it validates slot availability despite the 'check free slots' warning). The phrase 'Always check free slots first' hints at a possible lack of validation but doesn't specify failure behavior or error conditions.
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 extremely concise at one sentence and is front-loaded with the core action. The second sentence adds a crucial usage constraint without redundancy. However, the title is null, so the description bears the full naming burden.
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 tool has 11 parameters, no output schema, and no annotations, yet the description only provides a high-level action and a prerequisite. It lacks critical context such as return value behavior, required permission scopes, or interaction with free-slot checking. While the sibling list indicates a rich domain, this description is insufficient for an agent to confidently invoke the tool in complex scenarios.
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 low (45%), and the description adds minimal parameter meaning beyond listing 'calendar', 'contact', and time fields. It does not clarify the purpose of optional parameters like 'ignoreDateRange', 'toNotify', 'meetingLocationType', or 'appointmentStatus', leaving the agent to infer their semantics from enums or names alone.
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 (book an appointment) and the resource (GHL calendar for a contact). It distinguishes the tool from siblings by specifying 'create' on an appointment context, though it does not explicitly contrast with other appointment-related tools like 'update_appointment'.
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 instruction 'Always check free slots first' provides explicit usage guidance by referencing the prerequisite of checking availability. It implies this tool should be used after ghl_get_free_slots, but does not explicitly name the alternative tool or describe when not to use this tool.
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?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only mentions that blocking prevents bookings, but does not discuss side effects, permissions, reversibility, or what the response will be; this is insufficient for a mutation 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 a single sentence with no filler, directly stating the action and its purpose. It is well-structured and front-loaded.
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 tool has 5 parameters, 3 required, no annotations, and no output schema. The description is too sparse to fully explain the tool's behavior and parameters, especially given the weak schema coverage. It leaves the agent with insufficient context to invoke it correctly.
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 does not mention any parameters or add meaning beyond the input schema. Schema coverage is only 40% (only startTime and endTime have descriptions), leaving calendarId, title, and assignedUserId unexplained in both the schema and the description.
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 'block' and clearly identifies the resource as 'a time slot on a calendar.' It also explains the effect ('prevents bookings during that period'), which distinguishes it from appointment creation or event deletion tools in the sibling list.
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 guidance on when to use this tool versus alternatives like ghl_create_appointment or ghl_get_free_slots. There is no mention of appropriate scenarios, prerequisites, or exclusions.
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 present, so the description carries the full burden of behavioral disclosure. It only states the action ('create') without revealing side effects, required permissions, return values, idempotency, or validation behavior. This is comparable to under-specified mutation tools.
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 that immediately states the action and object. It contains zero wasted words and is as concise as possible.
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 tool has 8 parameters, nested objects, and no output schema, but the description is just one sentence. It does not explain required fields, item structure, currency denominations, or what the response will contain. This is significantly under-specified for a create operation with this complexity.
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 38%. The description does not mention any parameters or compensate for the low coverage. Several properties (contactId, currency, discount, invoiceNumber, title) lack schema descriptions, and the description adds no additional meaning.
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 ('create') and resource ('invoice') and identifies the target ('for a contact'). It clearly distinguishes from sibling tools like ghl_void_invoice, ghl_send_invoice, and ghl_record_invoice_payment.
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 such as ghl_get_invoices, ghl_send_invoice, or ghl_record_invoice_payment. There are no mentions of prerequisites (e.g., contact must exist) or cases where another tool would be more appropriate.
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?
With no annotations, the description carries the full burden for disclosing side effects. It only says 'Create' without noting required parameters, whether an opportunity ID is returned, or any error conditions. This is insufficient for a mutation 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 a single, clear sentence front-loaded with the action and object. It contains no filler or repetition, earning high marks for conciseness.
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 the tool has 9 parameters, 4 required, no output schema, and no annotations, the one-sentence description is inadequate. It fails to mention required fields, expected return value, or any pipeline/contact context that would help an agent invoke the tool correctly.
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 schema already documents 6 of 9 parameters with descriptions. The tool description adds no additional meaning about parameters, leaving undocumented params like source, status, and customFields unexplained. The moderate schema coverage (67%) is not compensated.
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 the verb 'Create' with the resource 'opportunity/deal' and specifies 'in a pipeline', clearly distinguishing this from sibling tools like ghl_update_opportunity, ghl_upsert_opportunity, and ghl_delete_opportunity. It unambiguously states the tool's function.
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 such as ghl_upsert_opportunity or ghl_update_opportunity. The description simply states the action without mentioning prerequisites, exclusions, or sibling-tool comparisons.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the core schedule/publish action, but omits important traits like immediate public posting, required permissions, reversibility, or what gets created. The schema's scheduledAt hint adds some behavior context, but the description itself is thin.
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. It conveys the core action and resource efficiently, earning its space.
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 simple 4-parameter tool with well-documented schema fields, the description is minimally viable. However, with no annotations and no output schema, it lacks return-value expectations, invocation prerequisites, and broader usage context, leaving notable gaps for an agent.
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 input schema covers all 4 parameters with 100% description coverage, so the baseline is 3. The description adds little parameter-level meaning beyond the 'schedule or publish' framing; the schema already explains scheduledAt and the meaning of each field.
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 uses a specific action ('Schedule or publish') and clearly identifies the resource ('a social media post'), making the tool's purpose immediately understandable. It semantically distinguishes itself from sibling tools like ghl_get_social_posts and ghl_delete_social_post, though it doesn't explicitly name alternatives.
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?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., retrieving account IDs via ghl_get_social_accounts), and no exclusions or limitations. The description simply states what it does without any contextual usage advice.
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 exist, so the description must disclose behavioral traits, but it only states the creation action. It does not mention whether an invitation is sent, how duplicates are handled, permissions required, or whether changes are reversible. This leaves significant side effects undisclosed.
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 that immediately states the action and scope. No filler or redundant information.
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 creation tool with a nested permissions object and no output schema, this description is too sparse. It does not explain what happens after creation, how permissions/role defaults work, or what the response will contain. Given the complexity of the input schema, the description is not minimally sufficient.
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%, with only 'phone' and 'permissions' having descriptions; the tool description adds no parameter details. The nested permissions object lacks per-field meaning, and required fields like firstName/lastName/email are only self-evident by name. The description does not compensate for this low 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 uses a specific verb ('Create') and resource ('new team member') with location scope, clearly distinguishing it from sibling tools like ghl_update_user and ghl_delete_user. It directly states the action without ambiguity.
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 about when to use this tool versus alternatives. There is no mention of prerequisites (e.g., existing location), related read tools, or exclusions such as 'to update a user, use ghl_update_user'.
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?
With no annotations provided, the description bears full responsibility for disclosing behavior. It only says 'Delete' without mentioning whether the operation is permanent, requires specific permissions, or has side effects like cancelling notifications. This leaves the agent unaware of the destructive implications.
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, front-loaded sentence with no wasted words. It is appropriately concise for a simple delete operation, though it could have included additional context without becoming verbose.
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 one parameter and no output schema, the description meets a minimum viable standard but has clear gaps. It lacks essential behavioral context such as irreversibility and response expectations, making it incomplete for an agent to fully understand the tool's impact.
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 schema has a single required eventId parameter with no description, and the tool description adds no detail about the parameter. The agent must infer its meaning solely from the name 'eventId', which is insufficient for clear invocation.
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 action (delete) and the resource (calendar event or appointment), distinguishing it from other delete tools for contacts, notes, tasks, etc. The verb+resource combination is specific and unambiguous.
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 guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply says 'Delete a calendar event or appointment' without contextualizing when this action is appropriate.
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?
With no annotations, the description fully bears the burden of behavioral disclosure. It states the action but doesn't mention side effects, permissions, error behavior, or what happens to associated 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?
A single, focused sentence that front-loads the action. 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?
For a mutation tool with no annotations, no output schema, and minimal description, essential context is missing. The agent knows what it does but not the implications or when to choose it.
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%, and the description doesn't elaborate on the parameters. The names contactId and taskId are self-explanatory, but the description adds no direct parameter semantics beyond what the schema already shows.
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 ('Delete') and identifies the resource ('a task') and its scope ('from a contact'), clearly distinguishing it from sibling tools like create/update/get tasks and other delete operations such as delete_contact_note.
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 lacks context about prerequisites, idempotency, or cases where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only states the deletion action but does not mention whether the deletion is permanent, if there are any side effects, permission requirements, or error conditions. This is a significant gap for a mutation 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 a single sentence of seven words, front-loaded with the action verb. Every word is necessary, and there is no redundancy or filler.
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 simplicity of the tool (one parameter, no output schema), the description is minimally viable. However, it lacks any context about the consequences of deletion, such as irreversibility or impact on related data, which would be expected given no annotations exist.
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 already provides full coverage for the single parameter (campaignId with description 'Campaign ID to delete'). The description's 'by ID' reinforces the schema but adds no new meaning beyond it, matching the baseline 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 action ('Delete'), the specific resource ('email marketing campaign'), and the method ('by ID'). It unambiguously distinguishes from sibling tools like ghl_get_email_campaign or ghl_delete_email_builder_template.
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, nor are there any exclusions or prerequisites mentioned. The description simply states the action without contextual usage advice.
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?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states the deletion is permanent, which is a key behavioral trait, but it does not mention any side effects (e.g., removal of related tasks/notes), permissions required, or response behavior.
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 with no wasted words. It is front-loaded with the key verb and resource, making it easy to scan.
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 destructive tool with no annotations and no output schema, the description is incomplete. It does not explain what 'permanently' entails (e.g., hard delete vs. soft delete, impact on related data) and lacks any guidance on finding the opportunityId.
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?
Schema description coverage is 0% and the description does not mention the 'opportunityId' parameter at all. The schema only provides the name and type (string), so the agent receives no additional context on where to find the ID or its format.
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 'delete' and the resource 'opportunity', distinguishing it from other sibling tools like ghl_get_opportunity and ghl_delete_contact. The word 'permanently' reinforces that this is a destructive operation, adding specificity beyond the tool name.
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, prerequisites, or alternatives. It does not warn about checking for associated data or mention that deletion is irreversible beyond the word 'permanently'.
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 fully disclose behavioral traits. It only indicates that the post is 'scheduled,' but does not mention consequences of deletion (irreversibility), permission requirements, what happens if the post doesn't exist, or whether only scheduled posts are eligible. This is minimal and leaves significant behavioral uncertainty for a destructive 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, direct sentence with no filler. It is front-loaded with the action and resource, and every word earns its place. For a simple tool, this is appropriately concise.
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?
Despite the tool's simplicity (one parameter, no output schema, no annotations), the description is insufficiently complete. It does not explain the parameter, provide usage context, or disclose any behavioral traits such as irreversibility or eligibility criteria. The 'scheduled' qualifier adds some context, but for a destructive tool, key information is missing, making the description barely adequate for an agent to use correctly without additional assumptions.
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 input schema has 0% description coverage; the parameter 'postId' is only defined as a required string. The description completely fails to explain what postId means, how to obtain it, or any format expectations. Since the schema does not provide semantics and the description adds nothing, the parameter meaning is entirely left to inference.
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 function: 'Delete a scheduled social media post.' It uses a specific verb ('delete') and resource ('social media post'), and the qualifier 'scheduled' distinguishes it from any other post-deletion tool. This is unambiguous and differentiates from sibling tools like ghl_create_social_post or ghl_get_social_posts.
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 (delete a scheduled post) but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions (e.g., cannot delete published posts, or use ghl_cancel_scheduled_message for text messages). The context is clear from the name, but there is no explicit guidance about prerequisites or when not to use it.
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 carries the full burden. It discloses only that the tool 'gets' data, but does not mention read-only behavior, pagination, authorization requirements, or what a 'calendar group' is. This is insufficient for a getter without annotations.
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 clause, front-loaded with the verb, and contains no filler words. Every word adds meaning.
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?
No output schema exists, and the description provides minimal context about the return value or the concept of 'calendar groups'. It is a simple tool, but the lack of any surrounding context (e.g., what location means, how this relates to calendars) leaves gaps for an agent selecting among many 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?
The tool accepts zero parameters, and the input schema is empty (100% coverage). Per baseline, with no parameters to explain, the description does not need to add parameter details.
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 uses a specific verb ('Get') and resource ('calendar groups') with scope ('in the location'), clearly conveying the tool's function. However, it does not explicitly distinguish from sibling tools like ghl_get_calendars, though the resource name itself provides some distinction.
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 guidance on when to use this tool versus closely related siblings such as ghl_get_calendars or ghl_get_calendar_events. It only states what it does, leaving the agent to infer usage context.
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 present, so the description carries the full burden. It states it gets 'all appointments' but does not disclose pagination, ordering, whether past/future appointments are included, or the response format. The read-only nature is implied by 'get' but not explicitly confirmed.
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 short, front-loaded sentence that directly states the tool's purpose with no filler or repetition. It is appropriately concise.
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 the lack of output schema and annotations, the description is too sparse to be fully self-contained. It does not explain what constitutes an 'appointment' or how results are returned, leaving the agent with incomplete information for handling the response.
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?
Schema coverage is 0% and the description adds no meaning beyond the schema. 'contactId' remains undefined; the phrase 'for a contact' simply restates the parameter's role without providing any additional guidance on its format, origin, or usage.
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 'get' with a clear resource 'appointments' and a scope 'for a contact'. It effectively distinguishes this tool from siblings like ghl_get_appointment (singular) and ghl_get_calendar_events.
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 alternative tools are mentioned, but the name and description imply this tool is for retrieving all appointments associated with a contact. The context is clear enough for basic usage, but no exclusions or alternatives are provided.
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 carries the full burden of behavioral disclosure. It only says 'Get all notes' and provides no additional context about pagination, ordering, authentication requirements, or potential side effects. While the read-only nature is implied by 'Get', nothing beyond that is disclosed.
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 that is front-loaded and directly states the tool's purpose. There is no unnecessary fluff or repetition; 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?
This is a simple tool with one parameter, but there is no output schema and no annotations. The description does not explain the return format, any limitations, or usage context. It is minimally sufficient for invocation but lacks completeness 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, contactId, with no description (0% schema coverage). The description says 'for a contact,' which adds only marginal clarity by implying that contactId identifies the contact, but this is already obvious from the parameter name. It does not explain the format, requiredness beyond the schema, or any other parameter details.
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 function: 'Get all notes for a contact.' It uses a specific verb ('Get') and resource ('notes for a contact'), and this distinguishes it from sibling tools such as create/update/delete note tools and other contact-related operations.
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?
There is no guidance on when to use this tool versus alternatives. The description simply states what it does without any context about prerequisites, comparison to similar tools, or scenarios where it is appropriate.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List all pages' but does not mention pagination behavior (despite limit/offset parameters), error handling, return format, or whether unpublished pages are included. The verb 'List' implies a read operation, but no additional context is given.
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 sentence with no waste. It is front-loaded with the core action and resource, making it immediately understandable.
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 is insufficient for a complete understanding. It does not mention the required funnelId parameter, lacks any return value details (since no output schema is provided), and does not address pagination or edge cases. Given the tool's moderate complexity (4 parameters, sibling tools), more context is needed.
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 50% (funnelId and name have descriptions; limit and offset do not). The description adds no parameter semantics beyond what the schema provides. It does not explain the limit/offset parameters or clarify how to use them, leaving the agent without crucial filtering/pagination information.
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 function with a specific verb ('List') and resource ('pages') in a specific scope ('in a specific funnel'). It distinguishes from siblings like ghl_get_funnels (which lists funnels) and ghl_get_funnel_page_count (which returns a count).
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 guidance on when to use this tool versus alternatives or any exclusions. It does not mention related tools like ghl_get_funnel_page_count or ghl_get_funnels. The prerequisite of obtaining a funnelId is only implied from the schema, not stated in the description.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action without revealing behavior such as pagination support (via lastMessageId), rate limits, authentication requirements, or error handling. The description does not add value beyond the raw action, leaving the agent without essential context about how the tool behaves.
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 that directly conveys the core purpose. It contains no filler, redundant information, or unnecessary qualifiers. It is well-structured for a simple getter tool, entirely earning 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?
Given the lack of annotations and output schema, the description must provide more context. It does not explain what the response contains (beyond 'messages'), how to handle pagination, or any constraints. The tool has three parameters and pagination implications, but the description is too sparse to fully guide an agent, especially compared to sibling tools that have more detailed descriptions.
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% (only lastMessageId has a description). The tool description fails to compensate by explaining the meaning or expected format of conversationId or limit. The mention of 'in a conversation' implies the need for a conversation ID, but it adds no detail about the limit parameter or how pagination works, leaving ambiguity for two of the three parameters.
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 'Get messages in a conversation' clearly states the action (get) and the resource (messages within a conversation), effectively distinguishing it from sibling tools like ghl_get_conversation (gets the conversation itself) and ghl_send_message (sends messages). It is specific and avoids vagueness.
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, such as ghl_get_conversation or other message-related tools. There is no mention of prerequisites, when pagination is needed, or scenarios where a different tool would be more appropriate. Usage is only implicitly suggested 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It does not disclose side effects such as marking the invoice as paid, whether the payment can be voided, or required permissions. The only hint is 'manual' which implies an override but adds little. This is a minimal, non-misleading but underinformative disclosure.
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 one concise sentence, front-loaded with the verb and resource. No word is wasted, and it is appropriately sized for the tool's apparent simplicity.
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 the lack of annotations, output schema, and low schema coverage, the description is incomplete. It does not explain the effect on the invoice, the expected response, or any validation rules (e.g., cannot exceed invoice balance). This is insufficient for a mutation tool that records financial transactions.
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 25% (only 'amount' is described as being in cents). The tool description adds no parameter meaning, leaving invoiceId, paymentMethod, and notes semantically unexplained. The enum for paymentMethod provides some structure but does not compensate for the low 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 specifies the action ('Record'), the resource ('a manual payment'), and the target ('against an invoice'). It distinguishes from sibling tools like ghl_void_invoice or ghl_send_invoice by the unique verb-resource pairing.
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 given on when to use this tool versus alternatives. There are no prerequisites, exclusions, or hints about typical scenarios (e.g., 'use when a payment is received outside of automated processing'). The description only states the basic action.
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?
With no annotations, the description carries the full burden of disclosing behavior, but it only states the creation action itself. It does not mention required parameters, side effects, validation, or return values, leaving significant behavioral ambiguity.
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 zero filler. It is efficient, though extremely sparse, but no words are wasted.
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 6 parameters, no output schema, and no annotations, the description is too minimal. It lacks context about return behavior, required fields, and relationship to other task tools, making it incomplete for an agent to invoke effectively.
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 83% (5 of 6 params have descriptions), and the description adds no parameter information. As per the rubric, baseline 3 applies because the schema already documents most parameters.
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 ('Create') and resource ('task for a contact'), clearly distinguishing it from sibling tools like ghl_update_contact_task and ghl_delete_contact_task. It is unambiguous and single-purpose.
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 guidance on when to use this tool versus alternatives, nor does it mention prerequisites like the contact needing to exist or relationships to other task operations. Users must infer usage from the tool name.
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 carries the full burden. It does not disclose any behavioral traits such as error handling (e.g., what happens if the event ID is invalid), authentication requirements, or the structure of the returned data. The description only states the basic 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 sentence, cleanly structured, with no redundant words. It achieves maximum conciseness while still conveying the core 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?
This is a simple one-parameter read tool with no output schema or annotations. The description is adequate for a basic get-by-ID operation, but it lacks details on the returned payload or edge cases. Given the low complexity, it does not need extensive elaboration, but a more complete description would mention what is returned or any limitations.
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 0%, so the description must compensate. It mentions 'event ID' but this merely restates the parameter name 'eventId' without adding meaning such as where to find it, its format, or how it relates to appointments. The description does not help the agent understand the parameter beyond the name.
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 action ('Get'), the resource ('appointment'), and the scope ('specific ... by event ID'). This distinguishes it from sibling tools that list appointments or events, such as ghl_get_calendar_events and ghl_get_contact_appointments.
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. There is no mention of prerequisites, nor any distinction from list or search tools. The only implied usage is that you need an event ID, but this is not stated as a decision criterion.
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 carries the full burden of behavioral disclosure. It only states the action 'List all campaigns' without mentioning read-only nature, pagination, authentication requirements, or response format. 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, concise sentence: 'List all campaigns in the GHL location.' It is front-loaded with the verb and resource, with no unnecessary words or 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 the low complexity (1 optional parameter, no output schema, no annotations), the description is minimal but incomplete. It does not clarify the difference between 'campaigns' and 'email campaigns' among siblings, nor does it provide any details about the returned data or behavioral constraints. An agent may struggle to select the correct tool without additional context.
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 input schema fully describes the only parameter 'status' with 'Filter by status (active, paused, etc.)'. Since schema description coverage is 100%, the description adds no additional parameter semantics. The baseline of 3 applies because the schema does the heavy lifting.
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 uses a specific verb ('List') and resource ('campaigns') with a clear scope ('in the GHL location'). It is clear in what the tool does, but it does not explicitly distinguish it from the sibling tool 'ghl_get_email_campaigns', which could cause confusion.
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 that this tool should be used when you need to list campaigns, but it provides no explicit guidance on when to use this tool versus alternatives like ghl_get_email_campaigns. There are no exclusions or alternative suggestions.
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 carries the full burden of behavioral disclosure. It only states the core action without mentioning side effects, reversibility, required permissions, idempotency, or response behavior. For a removal/mutation tool, this is a significant transparency 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, clear sentence with no wasted words. It is front-loaded with the action and resource. However, its brevity contributes to the lack of detail in other dimensions, so it is not maximally 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?
The tool operates without annotations or an output schema, and the description is minimal. Given the mutation nature, it should disclose prerequisites (e.g., valid contactId/workflowId), expected outcome, and error behavior. As it stands, the description is insufficient for an agent to fully understand the tool's context.
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 schema covers only 50% of parameters: workflowId has a description, contactId does not. The description adds no additional parameter meaning beyond what the schema already provides, and it fails to compensate for the undocumented contactId 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 the specific verb 'Remove' with a clear resource 'a contact from a GHL workflow/automation'. This unambiguously states the tool's function and distinguishes it from sibling tools like 'ghl_add_contact_to_workflow' and 'ghl_remove_contact_tags'.
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 the usage context: you need a contactId and workflowId to remove a contact from a workflow. However, it provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The implication is clear but not elaborated.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects, required permissions, return values, or constraints on status transitions. As a mutation tool, this lack of transparency is a significant 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, front-loaded sentence that efficiently conveys the core action. However, it sacrifices important usage and behavioral details for brevity, so it is concise but not optimally informative.
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 an 8-parameter mutation tool with no annotations and no output schema, the description is under-specified. It does not explain return values, parameter semantics beyond vague hints, or preconditions, leaving the agent to infer critical information from elsewhere.
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 25%, and the description only loosely groups some parameters (startTime/endTime for rescheduling, appointmentStatus for status, notes for notes). It does not clarify ambiguous fields like toNotify, calendarId, or title, leaving the agent with insufficient guidance for 8 parameters.
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 action 'Update an existing appointment' and lists the specific types of updates (reschedule, change status, update notes), making it easy to distinguish from create, get, and delete siblings.
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 phrase 'existing appointment' implies the tool is for updating already-created appointments, but there is no explicit comparison to alternatives like ghl_create_appointment or ghl_delete_calendar_event. Usage context is implied rather than clearly spelled out.
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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only restates the core action but fails to mention side effects, permissions, reversibility, or response behavior, which is a significant gap for a mutation 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 a single sentence with no redundant words, front-loading the key action. It is appropriately sized for the tool's simplicity, making every word earn its place.
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 simplicity of the tool (two required parameters, no output schema), the one-sentence description provides the minimum viable context. However, it lacks any mention of return values or edge cases, which prevents it from being fully complete.
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 50%, with only the status parameter having a description. The main description adds little beyond the schema, referencing 'read' and 'delivery status' which already appear in the enum values, and it does not explain messageId at all.
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 'Mark a message as read or update its delivery status' clearly states the tool's purpose with a specific verb and resource. It uniquely identifies this as a status-update operation, distinguishing it from siblings like send_message or get_messages.
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 offers no guidance on when to use this tool versus alternatives. It neither provides context nor excludes other tools, leaving the agent to infer usage solely from the operation name.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal the simulation aspect, which is key, but doesn't disclose side effects like whether it creates a conversation, triggers workflows, or requires existing contacts. This limited transparency is adequate but not rich.
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. It efficiently states the core purpose and key behavioral nuance in just a few 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?
Given four parameters, no output schema, and no annotations, the description is too minimal. It does not explain return values, side effects, required context (e.g., must contactId already exist?), or how this differs from sending a message. The tool is not fully specified for an agent to use confidently.
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?
Schema description coverage is 0% and the description makes no mention of any parameter. It does not explain the meaning of 'type', 'message', 'contactId', or 'conversationId', nor does it compensate for the schema's lack of descriptions. With no parameter documentation beyond the schema, this is a significant gap.
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 ('Inject') and identifies the resource ('inbound message into GHL'), clarifying it simulates receiving a message. This clearly distinguishes it from sibling tools like ghl_send_message, which send outbound messages.
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 parenthetical 'simulates receiving a message' implies its use for testing or simulating inbound messages. However, it provides no explicit guidance on when to prefer this over alternatives like ghl_send_message, nor any exclusions or prerequisites.
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?
With no annotations provided, the description carries the full burden. It states that a custom value is created but does not disclose any side effects, idempotency behavior, duplicate handling, or required permissions—beyond the simple act of creation.
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 that immediately states the purpose and scope. It is concise, front-loaded, and contains no filler.
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 simple create operation with a fully covered two-parameter schema, the description is minimally sufficient. However, it lacks usage context, any mention of return values, and behavioral caveats, making it adequate but not comprehensive.
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 input schema already describes both parameters ('Variable name' and 'Variable value') with 100% coverage. The description adds the context that the value is location-level but does not enrich parameter semantics 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 action ('Create') and resource ('new custom value'), with a parenthetical ('location-level variable') that distinguishes this from the sibling custom field tools. It is specific and understandable.
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 about when to use this tool versus alternatives like ghl_update_custom_value or ghl_delete_custom_value. The description implies creation but does not mention any context, exclusions, or prerequisites.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention potential side effects, permissions required, reversibility, or what the return value is. The only behavioral detail is that the link fires an action when clicked, which is minimal.
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, concise and front-loaded, with no redundant information. Every word contributes to the 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?
Given the simplicity of the tool (only 2 parameters, both described in schema), the description is minimally adequate. However, with no output schema, it fails to mention what is returned after creation, which is a gap for an agent expecting a result.
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 already covers both parameters (name and redirectTo) with descriptions, achieving 100% coverage. The tool description adds no additional meaning beyond the schema, so the baseline 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 identifies the action (Create) and the resource (trigger link), and specifies the behavior ('fires an action when clicked'). This distinguishes it from sibling tools like ghl_get_trigger_links and ghl_delete_trigger_link.
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 does not provide any guidance on when to use this tool vs alternatives, nor does it mention exclusions, prerequisites, or related tools. It simply states what the tool does, leaving the agent to infer usage context.
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?
With no annotations, the description must disclose behavioral traits, but it only states the action. It does not mention if deletion is permanent, irreversible, or requires special permissions, or what happens to references to the custom value.
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, focused sentence that frontloads the verb and resource. No redundant 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 is simple (one ID parameter, no output schema), and the description covers the core action. However, it lacks any mention of return values or error conditions, and for a destructive operation, additional context about permanence or side effects would make it more 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 single parameter valueId is fully described in the schema ('Custom value ID to delete') with 100% coverage, so the description adds little beyond reinforcing the need for an ID. The tool description clarifies the resource is a location-level variable, but this is not parameter-specific.
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 action ('Delete'), the object ('custom value'), and the identifier ('by ID'). It distinguishes from sibling tools like get_custom_values, create_custom_value, and update_custom_value by naming the delete operation.
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, such as prerequisites for obtaining the valueId or exclusions. While the verb implies deletion, there is no explicit context or alternative recommendations.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action, failing to mention pagination (limit/offset), filtering, or what the response contains. This is insufficient for a list 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, concise sentence that front-loads the core purpose. Every word adds value with no redundancy or irrelevant detail.
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 the tool has four parameters and no output schema, the description is too sparse. It does not explain the list behavior, return format, or the meaning of 'location,' leaving significant gaps for an agent to select and invoke the tool correctly.
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 50% (search and status have descriptions, but limit and offset do not). The description adds no parameter information, failing to compensate for the missing schema details. The unannotated parameters remain unclear.
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 action (get), the resource (discount coupons), and the scope (in the location). It is specific enough to distinguish from sibling tools like create_coupon or get_orders.
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 retrieving coupons but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria. The context is clear from the name, but no additional guidance is given.
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 carries full burden for behavioral transparency. It only states the action 'remove' with no disclosure of side effects, idempotency, error handling, or permission requirements. This is minimal for a mutation 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 a single concise sentence that is front-loaded and contains no unnecessary words. It efficiently conveys 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?
For a simple two-parameter removal operation with no annotations and no output schema, the description conveys the core action but lacks any behavioral details (e.g., idempotency, error conditions). It is adequate for basic invocation but not comprehensive.
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 documents 'tags' with a description ('Tags to remove'), while 'contactId' lacks description. The tool description adds little beyond the schema, though 'contactId' is inferable from the phrase 'from a contact'. With 50% schema coverage, the description does not significantly compensate but is sufficient for a simple two-parameter tool.
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 'Remove' and clearly identifies the resource 'tags from a contact'. This straightforwardly distinguishes it from the sibling tool ghl_add_contact_tags, which adds tags.
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 guidance on when to use this tool versus alternatives. It does not mention the sibling add_contact_tags or any exclusions, leaving the agent to infer usage from context.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It says 'update settings' but does not specify whether updates are partial or full, whether the number must already be purchased/owned, or any side effects or response behavior. This is a significant gap for a mutation 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?
A single, front-loaded sentence that efficiently conveys the tool's purpose with relevant examples. No filler or redundant content.
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 description is minimally viable for a simple update tool with well-documented parameters, but it lacks details on update semantics, return values, and prerequisites. The absence of annotations and output schema increases the burden, making this lean but not severely 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%, and the schema already provides descriptions for friendlyName and callForwardingNumber. The description merely echoes these examples without adding new meaning, so the baseline of 3 applies.
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 action ('Update settings') and the target resource ('phone number'), with concrete examples ('friendly name, call forwarding') that match the schema. It distinguishes this from sibling phone number tools like purchase, release, and get by focusing on modification.
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 such as ghl_get_phone_numbers or ghl_purchase_phone_number. The description only implies usage for updating an existing number, but lacks explicit context, prerequisites, or exclusions.
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. It states the action (void/cancel) but does not mention whether the operation is reversible, permanent, requires special permissions, or affects invoice status. For a destructive operation, this lacks critical transparency.
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, front-loaded sentence: 'Void (cancel) an invoice.' Every word is purposeful, with no redundancy or filler.
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 this is a destructive operation with no annotations and no output schema, the description is severely incomplete. It states the basic purpose but omits side effects, prerequisites, reversibility, and any usage context, leaving the agent undersupplied for safe invocation.
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 input schema has one parameter, invoiceId, with no descriptions (0% schema coverage). The tool description does not mention or explain this parameter, leaving the agent to infer meaning from the parameter name alone. It does not compensate for the lack of schema descriptions.
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 'Void (cancel) an invoice' uses a specific action verb ('void') and identifies the resource ('invoice'). It clarifies the meaning with 'cancel' and clearly distinguishes itself from sibling invoice tools like get, create, send, and record payment.
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 use when an invoice needs to be voided or canceled, but it provides no explicit context, prerequisites, or exclusions. It does not mention when not to use it or suggest alternative tools, so guidance is only implied.
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 carries the full burden. It discloses the operation is a read but adds no context about return behavior, error handling, auth requirements, or what 'metadata' includes. The phrase 'with metadata' is vague and does not clarify expected output 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?
One sentence, front-loaded with verb and resource. No wasted words; it is appropriately concise for the operation it describes.
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 simple get-by-ID operation with one parameter and no output schema, the description is minimally viable but lacks critical behavioral details like return format, error cases, or the nature of metadata. It does not fully compensate for missing annotations and no output schema, but the low complexity keeps it from being inadequate.
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 0%, and the description does not explain the conversationId parameter beyond its name. The name is self-explanatory, but 'with metadata' fails to clarify what is returned regarding the parameter. The description adds minimal value over 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 uses a specific verb ('Get'), names the resource ('conversation'), and adds scope ('by ID with metadata'). This clearly distinguishes it from sibling tools like ghl_search_conversations and ghl_create_conversation, 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 when you have a specific conversation ID, but it does not explicitly contrast with alternatives like searching or creating conversations. No when-not-to-use guidance is given, so usage context is only implied.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that this is a read-only operation, how pagination works, whether results are sorted by default, or any rate limits. The description only states the tool's purpose without revealing behavioral characteristics beyond the name 'search' implying read-only.
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, tightly written sentence. It is front-loaded with the essential purpose ('Advanced contact search') and provides relevant filter examples without padding. Every word earns its place, and the 'etc.' is acceptable shorthand for additional filter options.
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 the tool has 6 parameters, no output schema, and no annotations, the description is too sparse. It fails to mention what the response looks like, whether results are paginated, or how filters interact with the query parameter. The 'Advanced' label signals complexity, but the description does not provide enough context 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 only 33%, so the description should compensate. It adds value by giving concrete examples of filter fields (tags, pipeline stage, source) that clarify the 'filters' parameter. However, it does not explain pagination parameters like page/pageLimit or sorting parameters, leaving those semantics to the schema and parameter names.
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 identifies the tool as an advanced contact search with filters for specific fields like tags, pipeline stage, and source. This distinguishes it from the simpler ghl_get_contacts sibling, which likely lists contacts without advanced filtering. The verb 'search' plus resource 'contacts' and the filter qualifier make the purpose unmistakable.
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 advanced filtering scenarios but does not explicitly state when to use this tool over alternatives like ghl_get_contacts or ghl_get_contact. No exclusions or alternative tool names are provided, so the guidance is only implied rather than explicit.
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 carries the full burden. It states the update action but doesn't disclose whether the HTML content is fully replaced, how the optional previewText is handled, if the template must exist, or what the response looks like. This is insufficient for a mutation 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 a single, front-loaded sentence with no wasted words. It directly states the action and target.
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 3-parameter mutation tool with no annotations and no output schema, this description is too sparse. It lacks behavioral details, return value expectations, and explanation of the optional previewText parameter, leaving the agent without a full understanding of the 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 html and templateId with descriptions, and the description adds minimal context by mentioning 'existing' and 'HTML content'. However, it doesn't explain the optional previewText field or the relationship between parameters. With 67% schema coverage, the description doesn't significantly compensate for the gap.
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 'Update', the resource 'email builder template', and the specific scope 'HTML content'. This distinguishes it from the sibling tool ghl_update_template by specifying the email builder template context.
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 updating HTML content of an existing email builder template, but provides no explicit guidance on when to use this tool versus alternatives like creating a new template or using ghl_update_template. It also doesn't mention any exclusions or prerequisites.
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 carries the full burden. It states the action and allowed statuses but does not disclose potential side effects, whether other fields are preserved, or any validation rules. It simply restates the schema-defined enum, adding little beyond that.
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 earns its place, and the parenthetical status list is a useful, compact addition.
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 simple two-parameter tool, the description conveys the core action and status values. However, it lacks guidance on return behavior, success criteria, or how this differs from the sibling update tool. It is adequate but not rich.
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 0%, and the description does not explicitly explain the 'opportunityId' or 'status' parameters. It mentions statuses in parentheses but relies on the parameter names to convey meaning. The description adds minimal 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 uses a specific verb ('update') and resource ('status of an opportunity'), clearly limiting scope with 'only the status'. It also lists the valid statuses, distinguishing it from sibling tools like ghl_update_opportunity which likely update multiple fields.
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 phrase 'only the status' implies a focused use case, suggesting an alternative to a broader update tool. However, it does not explicitly name alternatives like ghl_update_opportunity or state when not to use it, leaving the guidance implied rather than explicit.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses permanence ('permanently delete') but omits other critical traits such as cascading effects on related data (notes, tasks), authentication requirements, or failure behavior. This is a significant gap for a destructive 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, front-loaded sentence ('Permanently delete a contact by ID.') with no wasted words. It efficiently conveys the core purpose and key behavior.
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 description is minimal but sufficient for a simple one-parameter delete tool. It does not explain return values (no output schema) or side effects, but the essential action is clear. Given the lack of annotations and the destructive nature, more context would improve 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?
The input schema already documents contactId with 100% coverage, so the baseline is 3. The description merely repeats 'by ID' and adds no additional meaning about the parameter's format, source, or constraints.
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 action (delete), the resource (contact), and the method (by ID). It distinguishes itself from sibling tools like ghl_get_contact, ghl_update_contact, and ghl_delete_contact_note by specifying a permanent contact deletion.
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 (use when you need to permanently delete a contact) but does not explicitly mention when not to use it or alternatives. There is no guidance on using this versus other contact-related editing tools, though the purpose is clear.
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?
With no annotations, the description carries the full burden for behavioral disclosure. It only states 'Delete', which inherently implies destruction, but does not disclose permanence, side effects, or any failure conditions. This is minimal information for a destructive 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, front-loaded sentence with no redundant words. It is appropriately sized for such a simple tool.
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's low complexity (one parameter, no output schema) and the clear purpose, the description is adequate for basic usage. However, the lack of behavioral details (e.g., permanence, error states) leaves room for improvement, especially without annotations.
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 single parameter is fully described in the schema ('Custom field ID to delete'), providing 100% coverage. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
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 the specific verb 'Delete' and clearly identifies the resource ('custom field') and scope ('from the location'). It is unambiguous and distinct from sibling tools by the action it performs.
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 usage is implied by the clear delete action, but there is no explicit guidance on when to use this tool versus alternatives like create/update/get custom fields, nor any mention of prerequisites or conditions.
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?
With no annotations, the description carries the full burden. It discloses that this is a list/search operation supporting query filtering and cursor-based pagination, which is helpful, but it does not describe return format, default or maximum page sizes, or any other behavioral traits beyond what is in the schema.
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 concise, with two short sentences that are front-loaded. Every clause contributes meaningful information about the tool's purpose and capabilities, with no redundancy or filler.
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?
Without an output schema, the description does not explain return values or pagination behavior details. It also does not differentiate from the sibling ghl_search_contacts. However, for a read-only listing tool with fully described parameters, it is minimally adequate.
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% for all 5 parameters, so the baseline is 3. The description mentions query and cursor-based pagination, which aligns with the schema parameters but adds no new semantic detail beyond what the schema already provides.
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 lists/searches contacts in the GHL location, with filtering and pagination. It uses a specific verb and resource, but does not explicitly distinguish it from the sibling ghl_search_contacts or ghl_get_contact, so it doesn't earn a 5.
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 provides clear context for listing/searching contacts and mentions filtering and pagination, but it does not offer guidance on when to use this tool instead of alternatives like ghl_search_contacts, nor any exclusions. Usage is implied rather than explicit.
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 burden. It discloses the return format (aggregate status counts and per-URL details), which is useful. However, it does not explicitly state that this is a read-only operation, nor does it mention authentication, rate limits, pagination, or error behavior.
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 main purpose, and every word adds value. There is no redundancy or filler.
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 simple status-check tool with no output schema, the description adequately covers the return values at a high level. However, it lacks lifecycle context such as when a crawl is complete, typical wait times, or how to interpret specific statuses, which would be useful for an agent.
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%, with both parameters fully described, including the fact that operationId comes from ghl_discover_website. The description adds no extra parameter context, so a baseline score of 3 is appropriate.
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's purpose: 'Check the status of a website crawling operation' with a specific verb and resource, and mentions the return values. However, it does not explicitly differentiate from sibling tools like ghl_list_crawler_urls, so it falls short of a 5.
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?
Usage context is implied rather than explicit. The description suggests the tool is used after starting a crawl, but it does not mention when to use it versus alternatives or provide any exclusions. No reference to ghl_discover_website or other lifecycle steps.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it lists custom fields but does not mention pagination, ordering, response shape, required scopes, or clarify what 'the location' refers to. 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 sentence of six words, efficiently conveying the core function. It is front-loaded with the action 'List' and the resource 'custom fields', with no unnecessary detail.
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 (no parameters, no output schema), so the description is minimally adequate. However, it does not clarify the return format, pagination, or the meaning of 'location', which could lead to ambiguity in a broader context with many 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?
The tool has zero parameters, so the input schema is trivially complete. Per the rubric, a baseline of 4 applies when there are no parameters to document, and the description adds no additional parameter meaning because none exist.
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 the specific verb 'List' with the resource 'custom fields' and scope 'for the location', making the tool's purpose immediately clear. It also distinguishes itself from sibling tools like create/update/delete custom field and get_custom_values by naming the exact entity being retrieved.
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, such as get_custom_values or the custom field mutation tools. The description is purely a statement of function without context or exclusions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the basic get action and provides no context about response format, error handling, permissions, or side effects. This is a very thin description for a tool with no 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 sentence, fully front-loaded with the action and resource, and contains zero wasted words. It is appropriately concise for a simple get-by-ID operation.
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 one-parameter simple retrieval, the description is minimally adequate. It does not explain what is returned, common failure modes, or any related endpoints, but given the low complexity, the absence of such detail is not severely penalized. It is still a complete enough description for basic invocation.
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 already defines templateId with a description, so schema coverage is 100%. The tool description adds no further meaning beyond what the schema provides, which is exactly the baseline 3 scenario where the schema does the heavy lifting.
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 'Get a single email builder template by ID' clearly states a specific action (get) on a specific resource (email builder template) with a clear scope (by ID). It distinguishes itself from the sibling ghl_get_email_builder_templates which presumably retrieves multiple templates.
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 'by ID' phrase implies this tool is intended when a specific template ID is known, which is a minimal usage hint. However, it does not explicitly mention when not to use it or suggest alternatives like the plural list endpoint, so guidance is only implied.
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 carries full burden. It only states 'Get the total count' without disclosing whether the count is affected by the optional 'name' filter, return format, or any behavioral constraints. This ambiguity reduces transparency.
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 sentence with no redundant wording; very concise and front-loaded.
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 simple 2-parameter tool, the description covers the primary purpose, but lacks clarification on the interaction between the optional name filter and the 'total count,' and no output schema or return information is specified. It is adequate but has clear 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 description coverage is 100%, with both 'name' and 'funnelId' already described. The description adds no parameter-level meaning beyond the schema, so baseline 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 the verb 'Get' and the resource 'total count of pages in a funnel,' which is specific and distinct from sibling tools like ghl_get_funnel_pages (which retrieves page list) and ghl_get_funnels (list of funnels).
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 usage guidance or alternatives are mentioned, but the name and description imply it is for counting pages. It does not state when to use this vs. ghl_get_funnel_pages, though the distinction is inferable.
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?
With no annotations, the description carries the full burden of behavioral disclosure. The wording implies a read-only operation, but it does not specify authentication requirements, rate limits, or what 'connected' means in practice. No contradictions with annotations exist.
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 that is front-loaded with the action and resource, containing no extraneous information. It is maximally concise for what it communicates.
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 zero-parameter read tool, the description is minimally adequate but lacks any indication of the response format or the specific social media platforms covered. Since there is no output schema, the agent might benefit from more detail about what is returned.
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 baseline for this dimension is 4. The description does not need to add parameter details beyond the empty schema, and it correctly implies no inputs are required.
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 action ('Get'), the resource ('connected social media accounts'), and the scope ('for the location'). It distinguishes itself from sibling tools like ghl_get_social_posts by focusing on accounts rather than posts.
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, nor are there any exclusions or prerequisites mentioned. 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.
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 full burden of behavioral disclosure. It only states that it lists all team members, without mentioning pagination behavior (despite skip/limit parameters), response format, potential size issues, or any access requirements. While it's a read operation, the description provides minimal transparency beyond the tool's 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the verb and resource immediately. There is no wasted text or redundancy. It is concise and to the point.
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 a simple list operation with two optional pagination parameters and no output schema. The description is minimal but adequate for the core purpose. However, it does not specify the return structure, pagination details, or clarify the relationship with sibling user tools. Given no annotations and no output schema, slightly more context would improve 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?
Schema description coverage is 100% for both parameters (skip and limit), so the schema already documents the parameters. The description adds no extra meaning about the parameters, such as how pagination works or defaults. Baseline 3 is appropriate because the schema does the heavy lifting.
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 'List all team members in the GHL location' uses a specific verb ('list') and resource ('team members'), and the scope ('all team members') distinguishes it from sibling tools like ghl_get_user (single user) and ghl_search_users (filtered search). It is clear and 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 this is for retrieving the full set of users in the location, but it does not explicitly mention when to use it over alternatives like ghl_search_users (for filtered queries) or ghl_get_user (for a single user). No exclusions or alternative guidance is provided, so usage context is implied rather than explicit.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that the tool releases/deletes a phone number, but does not mention irreversibility, required permissions, or any side effects such as whether the number becomes available for repurchase. The description adds little beyond the tool name.
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 sentence that immediately states the action and scope. No redundancy or filler. It is concise and well-structured.
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 simple one-parameter destructive operation, the description is adequate but not complete. It does not specify what the tool returns (no output schema) or any prerequisites, such as the number being currently owned. It gives the essential action but lacks additional context that would be helpful for an agent.
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 the parameter already described as 'The phone number ID to release.' The description does not add any extra meaning or clarify the format or source of the ID, so it remains at baseline.
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 action: 'Release (delete) a purchased phone number from the location.' It uses a specific verb and resource, and clarifies that 'release' means 'delete.' This distinguishes it from sibling tools like purchase, update, and get phone numbers.
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 purpose is clear, so when to use it is implied. However, there is no explicit guidance about alternatives or when not to use it. For instance, it doesn't mention whether updating the number to inactive is preferable in some cases. Usage is inferred from the action rather than stated.
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 carry the burden of behavioral disclosure. It does not mention that this is a read-only operation, does not describe pagination behavior, return format, or any side effects. It only states the action and filters.
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 that front-loads the tool's purpose and key filters. 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 description is adequate for a basic search tool but leaves gaps: no mention of pagination, return structure, or how filters interact. With no output schema or annotations, the agent has limited information about what to expect.
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 63%, so the baseline is 3. The description paraphrases the filter parameters already described in the schema (contact, stage, pipeline, status, assigned user) but does not add meaning for page, limit, or query, nor does it clarify status enum values or how filters combine.
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 opportunities in the pipeline, with a specific verb and resource. It lists the main filter dimensions, which distinguishes it from sibling tools that get, create, update, or delete opportunities.
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 searching opportunities with filters, but it does not explicitly mention alternatives like ghl_get_opportunity for retrieving a single record, nor does it state when not to use this tool. It provides clear context but no exclusions.
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 carry the burden of behavioral disclosure. It only states the action 'send a message' without discussing side effects, requirements, or behaviors such as scheduling, attachments, or error handling.
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 with no wasted words, front-loading the action and providing a positioning statement.
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 10 parameters and no output schema, the description is very minimal. The schema covers parameter details, but the description lacks guidance on important operational aspects like scheduling or channel-specific behavior, making it adequate but 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 description coverage is 90%, so the schema documents parameters. The description adds minimal parameter meaning beyond mentioning channels, not compensating for any gaps.
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 uses a specific verb 'send' with resource 'message to a contact' and lists channels. It positions itself as 'primary tool for outbound communication', which helps differentiate it from more specialized tools like ghl_send_email, though 'other channel' is vague.
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 is the primary tool for outbound communication', providing clear context for when to use it. However, it does not explicitly mention alternatives or when not to use it, lacking exclusion guidance.
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?
With no annotations provided, the description carries the burden of disclosure. It reveals the key behavioral trait that only provided fields are changed, implying a merge/patch behavior. However, it omits other important traits such as return values, error handling, or how array fields like tags are handled.
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 short sentences that front-load the purpose and immediately follow with the most important usage instruction. There is no redundant information.
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 mutation tool with 17 parameters, no annotations, and no output schema, the description is too sparse. It does not address how to handle arrays like tags or customFields, what the response contains, or prerequisites such as the contact needing to exist. The partial-update tip is useful but insufficient for complete guidance.
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 only 6% (only contactId is described). The description's 'only provide fields you want to change' adds general parameter usage context, but it does not explain the semantics of the 16 undocumented fields, nor does it compensate for the lack of descriptions in 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 states 'Update an existing contact' with a clear verb and resource, and 'Only provide fields you want to change' clarifies the partial-update scope. This distinguishes it from create/upsert/delete siblings through the word 'existing' and the update semantics.
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 a contact already exists and specific fields need modification, but it does not explicitly mention when not to use it or name alternatives like ghl_upsert_contact. The context is clear but lacks exclusions or direct sibling comparisons.
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 carries full responsibility for behavioral disclosure. It does not mention that deletion is permanent or irreversible, nor any permission requirements or side effects. For a destructive operation, this is a significant gap.
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 without redundant words. It efficiently conveys the action, resource, and method.
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 one-parameter delete tool with no output schema, the description is mostly complete: it specifies what is deleted and how. However, it could mention that deletion is irreversible or that the template is permanently removed, which would make it fully 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?
Schema coverage is 100% with templateId described as 'Template ID to delete'. The description's 'by ID' adds no additional semantic value beyond the schema, so baseline 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 the action (delete), the resource type (SMS/email/WhatsApp template), and the method (by ID). It distinguishes from sibling tools like ghl_get_templates, ghl_create_template, and ghl_update_template by specifying the exact resource variant.
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 (use this to delete a template by ID) but provides no explicit context, prerequisites, or alternatives. It does not mention when not to use this tool or that ghl_get_templates could be used to find the ID first.
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 carries the full burden of behavioral disclosure. It only restates the action without any context about return format, potential errors, authentication requirements, or side effects (which are likely none). For a simple getter, the description adds minimal behavioral insight beyond what the tool name already implies.
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 consists of a single, front-loaded sentence that conveys the essential information without redundancy. Every word earns its place, and it is appropriately sized for a simple getter tool. It is concise without being cryptic.
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 simple single-record getter with one required parameter and no output schema, the description provides the minimal necessary information. It adequately tells an agent what the tool does, but it lacks context about the response contents or any relationships to other invoice operations. Given the simplicity of the tool, this is borderline adequate.
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 schema has one required parameter, invoiceId, with 0% schema description coverage and no enum or format details. The description mentions 'by ID', which aligns with the parameter name but adds no extra semantic meaning. The description fails to compensate for the lack of schema parameter descriptions, even though the parameter is self-explanatory.
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 action ('Get') and the target resource ('a specific invoice by ID'). It explicitly narrows the scope to a single invoice, distinguishing it from the sibling tool ghl_get_invoices (which likely lists invoices). The verb and resource are specific and unambiguous.
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 clearly implies the use case: when you have an invoice ID and need that specific invoice. It distinguishes from listing (plural) tools by emphasizing 'specific' and 'by ID'. However, it does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent.
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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It states that the tool gets files and folders, which implies a read-only, non-mutating operation. However, it does not disclose additional behavioral details such as response format, pagination behavior, or authentication requirements. The basic behavior is clear, but deeper transparency is lacking.
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 that directly conveys the tool's function. It is front-loaded and contains no unnecessary words or filler. 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?
Given the tool has 7 parameters, no output schema, and no annotations, the description is too minimal. It does not explain what the returned data looks like (e.g., whether it's a list of objects, how files and folders are represented), nor does it describe pagination or default behavior. The complexity of the filtering/sorting options is not reflected in the description, leaving the agent with an incomplete picture.
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 description coverage is 57%, with descriptions for type, query, sortBy, and parentId, but not for limit, offset, or sortOrder. The tool description itself adds no parameter-specific information. While parameter names and enums provide some meaning, the description does not compensate for the missing parameter details. This is adequate but not helpful 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's action: getting files and folders from the GHL media library. It uses a specific verb ('Get') and a specific resource ('files and folders in the GHL media library'), which distinguishes it from sibling tools like ghl_delete_media_file. The purpose is immediately understandable.
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 the tool's use case (retrieving media library contents) but provides no explicit guidance on when to use it versus alternatives. No exclusions or alternative tools are mentioned. The context among siblings is clear enough that the intended usage is inferable, but the description itself lacks explicit direction.
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 carry the full burden of behavioral disclosure. It only states 'Get' which implies a read operation, but does not mention response format, error conditions, authorization needs, or any other behavioral traits. For a tool with no annotations, this is a significant gap.
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, highly concise, and front-loaded with the core purpose. No redundant information is present, earning a perfect score for conciseness.
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 low complexity (one parameter, no output schema), the description is largely sufficient for a basic get-by-id operation. It clearly states what the tool does and what input is required. However, without an output schema or annotation, it could benefit from mentioning what the response returns, but this is not critical for a simple read.
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 0%, but the description's phrase 'by ID' directly explains the purpose of the single orderId parameter. However, it merely restates the schema's field name and adds minimal semantic value beyond that. The description partially compensates for the lack of parameter details but could be more explicit.
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 ('Get') and resource ('a specific order') with a clear identifier ('by ID'), which distinguishes it from sibling tools like ghl_get_orders (plural) that likely list orders. It unambiguously states what the tool does.
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 fetching a single order by ID, but it does not explicitly differentiate from alternatives like ghl_get_orders or provide when-to-use/when-not-to-use guidance. The context is clear but no exclusions or alternative references are given.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it updates an existing team member, which implies mutation, and mentions partial-update semantics. However, it does not disclose potential side effects (e.g., email/password changes), required permissions, error behavior if the user doesn't exist, or whether nested permissions are merged or replaced. This is a significant gap for a mutation 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 extremely concise and front-loaded, consisting of two short sentences. Every word contributes meaning: 'Update an existing team member' states purpose, and 'Only provide fields you want to change' provides critical usage guidance. No filler or repetition.
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 the tool has 7 parameters including a nested permissions object, no output schema, and no annotations, the description is too brief to be complete. It does not address return values, error cases, or the crucial behavior of nested object updates (whether providing permissions merges or replaces existing permissions). This could lead to incorrect usage despite the schema and partial-update note.
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 only 29%, so the description needs to compensate. The 'Only provide fields you want to change' guidance adds general parameter semantics by clarifying that all fields except userId are optional and should be supplied only when changing. However, it doesn't explain the nested permissions object (merge vs. replace) or provide per-field details beyond what the schema already gives. The instruction adds value but does not fully compensate for the low 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: 'Update an existing team member.' The verb 'update' and resource 'existing team member' are specific and unambiguous. It distinguishes itself from sibling tools like ghl_create_user, ghl_delete_user, and ghl_get_user.
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 instruction 'Only provide fields you want to change' provides clear usage context for partial updates, implying that omitted fields remain unchanged. This is strong guidance for the primary use case. However, it does not explicitly exclude use for creating users or mention alternatives, though the tool name and 'existing' make that 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 carries the full burden of behavioral disclosure. It only states the action without revealing whether tags are appended to existing ones, how duplicates are handled, whether the contact must exist, or any other side effects. This leaves significant behavioral ambiguity.
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 that directly conveys the tool's action without unnecessary words. It is appropriately sized for the tool's simplicity.
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's simplicity, the description is minimal but incomplete. It omits essential context such as whether existing tags are preserved, how duplicate tags are treated, and the expected format of tag identifiers. With no annotations and no output schema, the description should provide more detail to fully guide an agent.
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 describes 'tags' as 'Tags to add' but gives no description for 'contactId'. The tool description mentions 'to a contact', which loosely maps to contactId, but does not clarify whether tags are names or IDs or any format expectations. With 50% schema coverage, the description only partially compensates for the missing contactId documentation.
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 'Add one or more tags to a contact' uses a specific verb and resource, clearly indicating the tool's function. It is distinct from the sibling 'ghl_remove_contact_tags', which performs the opposite operation.
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 clearly states the operation's context (adding tags to a contact) and implies when to use it. It does not explicitly mention alternatives or exclusions, but the purpose is straightforward and the sibling tool for removal is obvious.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Cancel') but does not mention whether cancellation is irreversible, any side effects, permission requirements, or what happens to the message after cancellation. This is a significant gap for a mutating 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, concise sentence with no redundant words: 'Cancel a scheduled (future) message before it is sent.' Every word contributes to the meaning.
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 simple one-parameter cancel operation, the description conveys the core purpose adequately. However, the absence of annotations and any explanation of outcomes, error conditions, or idempotency leaves some gaps, though these are less critical given the tool's simplicity. It is minimally viable but not rich.
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 100% coverage, with the messageId parameter described as 'ID of the scheduled message to cancel.' The description adds no new semantic meaning beyond what the schema already provides, so the baseline of 3 applies.
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 the specific verb 'Cancel' with a clear resource: 'a scheduled (future) message before it is sent.' This distinguishes it from sibling tools like send_message or update_message_status by explicitly scoping to future scheduled messages.
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 provides clear context that this is only for scheduled messages not yet sent ('before it is sent'), which effectively excludes already-sent messages. It does not explicitly name alternatives, but the context is clear enough for basic usage decisions.
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 carries the full burden. It only states 'Delete' without disclosing whether the deletion is permanent, requires special permissions, or has side effects like cascading deletions. This is insufficient for a destructive 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 concise sentence with no unnecessary words. It is front-loaded and directly states the action and target.
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 simple one-parameter delete tool, the description is minimally adequate but lacks detail about return values, error conditions, or confirmation. There is no output schema or annotations to compensate, so the description is the only source of context.
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 provides 100% coverage with one parameter 'templateId' and a description 'Template ID to delete'. The tool description adds no additional meaning beyond the schema, so baseline 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 uses a specific verb 'Delete' and clearly identifies the resource 'email builder template' with the method 'by ID'. This distinguishes it from sibling tools like get/create/update email builder templates.
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 clearly implies use when a specific email builder template needs to be removed. It does not explicitly mention alternatives or exclusions, but the context is clear for a delete operation.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It adds value by specifying the event types (appointments and blocked slots) but does not mention pagination, response format, or filtering behavior. Basic read behavior is clear, but deeper context is missing.
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 that is concise and front-loaded with the core action and resource. 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.
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, no output schema, and no annotations. The description provides the essential purpose but lacks details on response structure, optional filters behavior, or whether pagination exists. It is adequate but not rich enough for a fully autonomous agent.
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 80% (4 of 5 parameters have descriptions), so the schema carries most parameter semantics. The description only implies date range via 'startTime' and 'endTime' but does not add extra meaning beyond what the schema already provides.
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 'Get' with a clear resource 'calendar events' and clarifies the scope as 'appointments and blocked slots' for a 'date range'. This distinguishes it from siblings like ghl_get_calendars (list calendars) and ghl_get_appointment (single 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?
The usage is implied: use when you need calendar events (appointments and blocked slots) within a date range. However, there is no explicit guidance on when to prefer this over related tools like ghl_get_free_slots or ghl_get_contact_appointments, nor any exclusions or prerequisites.
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 carries the full burden. It only says 'Get details' with no mention of what data is returned, potential errors, auth implications, or read-only nature beyond the verb. The tool is likely a safe read, but this is not disclosed.
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 no wasted words. It front-loads the action and object, making it easily scannable.
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 with no parameters and no output schema, so the description could benefit from mentioning what details are returned (e.g., name, address, phone). Without that, it is minimally viable but leaves the agent uncertain about the return payload. The lack of annotations increases the burden on the description, which it only partially meets.
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 zero parameters, and the schema is an empty object, so no parameter documentation is needed. The baseline of 4 applies because there is nothing to compensate for; the description need not address parameters.
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 details about the current GHL location/sub-account, using a specific verb and resource. It distinguishes itself from sibling tools like ghl_get_location_tags and other getters by focusing on the location context.
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?
Usage is implied: use when you need details about the current location. However, there is no explicit guidance on when to use this over alternatives or any exclusions, which is acceptable for such a simple getter but still a gap.
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 context. It only states 'List all tags' without mentioning response format, pagination, ordering, or any constraints. This is minimal and leaves the agent with questions about what the return data contains.
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 no unnecessary words, front-loading the action and resource effectively.
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 and no annotations, the description is the only source of return-value insight. It confirms the tool returns tags but doesn't describe the tag structure or any pagination behavior. For a simple read operation this is borderline adequate, but incomplete for an agent that needs to parse the response.
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 is empty. The description adds the scope 'in the location', which clarifies that this is a location-scoped read, aligning with the tool name.
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 resource ('tags defined in the location'), clearly distinguishing it from sibling create/delete location tag tools. It unambiguously states what the tool does.
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 alternative guidance is provided. The description implies this is the tool for listing location-level tags, but doesn't contrast with contact-level tag operations like ghl_add_contact_tags or ghl_remove_contact_tags.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the tool gets submissions with filters but does not mention pagination behavior, response format, rate limits, or that it is read-only. This is minimal guidance.
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 one concise sentence with the main action front-loaded and no unnecessary words. Every part earns its place.
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 7 parameters, no output schema, and no annotations, this description is a bit thin. It covers the basic purpose and filter options but lacks details on pagination, the meaning of 'q' vs 'contactId', and what constitutes a submission. Adequate but with clear 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 description coverage is 86%, so the schema already documents most parameters. The description adds semantic grouping by mentioning 'survey, contact, or date range' filters, which helps, but this is not substantial beyond what the schema provides.
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 survey submissions' with a specific verb and resource. It distinguishes itself from sibling tools like ghl_get_form_submissions and ghl_get_surveys by focusing on survey submissions.
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 provides clear context: use this tool to retrieve survey submissions with optional filters. It implies usage but does not explicitly mention when not to use it or name alternatives, though no direct alternative exists among siblings.
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 clearly conveys that this is a read-only search operation with no destructive side effects, but it does not describe the return format, pagination, or any constraints. The phrase 'to purchase' helpfully clarifies that it does not actually purchase numbers.
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 of 13 words, front-loaded with the primary action and resource. Every phrase earns its place—action, object, filters—with zero redundancy or filler.
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?
Despite having 8 parameters and no output schema, the description gives a clear summary of intended use and main filter categories. However, it does not describe the structure of the return data or any pagination details, which leaves an agent uncertain about the response shape. The absence of an output schema places more responsibility on the description, which it only partially meets.
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 the baseline is 3. The description adds a high-level grouping of filters ('country, number type, or capabilities') but does not elaborate on number matching parameters like firstPart or lastPart. Thus, it provides minimal additional meaning 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 uses a specific verb ('Search') and a clear resource ('available phone numbers') with an explicit purpose ('to purchase'). It distinguishes from sibling tools like ghl_get_phone_numbers (which lists existing numbers) and ghl_purchase_phone_number (which executes the purchase) by clearly indicating this is a discovery step for available inventory.
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 context—searching for numbers before purchasing—but does not explicitly mention when not to use this tool or how it relates to alternatives. No exclusions are given, though the word 'available' and the purchase context provide some guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates a write operation and adds the matching behavior by contact and pipeline, which hints at an upsert flow. However, it does not disclose what happens on update (e.g., partial vs. full field overwrite), the return value, or error conditions. This is adequate but leaves significant behavior undocumented.
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 that front-loads the action and resource. Every word earns its place, and there is no verbose or redundant content. It is appropriately sized for a simple one-line purpose statement, though other dimensions highlight necessary additions.
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 the tool's complexity (7 parameters), lack of annotations, and absence of an output schema, this description is insufficient. It does not explain the upsert behavior in detail (e.g., what identifies an existing opportunity), what the tool returns, or prerequisites beyond the matching fields. The description is a minimal outline that leaves substantial gaps for an agent to infer.
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 0%, so the description must compensate. It only adds meaning for contact and pipeline parameters by stating they are the matching criteria. It provides no explanation for name, status, assignedTo, monetaryValue, or pipelineStageId, and doesn't clarify required vs. optional behavior for create vs. update. This is minimal compensation for a 7-parameter 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 uses a specific verb phrase "Create or update" for the opportunity resource and adds "matched by contact and pipeline" to specify the resource's identity criteria. This clearly distinguishes it from sibling tools like ghl_create_opportunity, ghl_update_opportunity, and ghl_update_opportunity_status, which have narrower or 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?
The description implies when to use the tool: whenever you need to create or update an opportunity based on a contact and pipeline match. This provides clear context but does not explicitly name alternatives or state exclusions (e.g., 'for status-only changes, use update_opportunity_status'). The presence of a match criterion offers practical guidance for when the tool applies.
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?
With no annotations, the description carries full burden. It discloses that it handles both skeleton creation and HTML upload in one call and returns the template ID. However, it omits prerequisites, permissions, validation behavior, or failure modes, leaving notable gaps.
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, each providing distinct value: purpose, operational behavior, and return value. No redundancy or 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?
For a simple 3-parameter create tool with no output schema or annotations, the description adequately communicates the dual-step operation and the critical return value (template ID) for use in workflows. Minor gaps like error handling or uniqueness constraints are not addressed, but overall it is sufficient for the complexity.
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 input schema already describes all parameters (100% coverage), so the description adds little beyond referencing HTML content and the returned template ID. It does not elaborate on parameter constraints or formatting 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 creates a new HTML email template in a specific location (GHL Marketing → Emails). It also highlights the combined operation (skeleton + content upload) and the return of a template ID, which distinguishes it from sibling tools like get/update/delete.
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?
Usage is implied by the verb 'create' and the resource, but there is no explicit guidance on when to use this vs alternatives (e.g., updating an existing template). No exclusions or alternative tool mentions are provided.
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?
With no annotations, the description carries the burden of disclosing behavior. It communicates the outcome (returns the created FAQ object with ID) and the mutation implied by 'Create', but does not mention potential failure modes, permissions, or the need for an existing knowledge base.
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 that immediately states the primary action and outcome, with no filler or redundant phrasing.
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 create tool with three well-described parameters, the description adequately covers the purpose and return value. However, it does not explicitly mention the prerequisite that the knowledge base must already exist, which is a minor gap given the sibling list includes KB creation tools.
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 input schema provides 100% description coverage for all three parameters, so the description adds little parameter-level meaning beyond repeating 'question and answer'. Baseline 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 uses the specific verb 'Create' with a clearly defined resource ('a new FAQ question and answer inside a knowledge base') and states the return value, making it easily distinguishable from sibling update/delete/list FAQ tools.
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 adding a new FAQ to an existing knowledge base but does not explicitly state when to use it versus alternatives like update_faq or list_faqs. No exclusions or prerequisites are mentioned.
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?
With no annotations provided, the description carries the burden of disclosure. It does disclose permanence ('Permanently delete') and the success return value ('Returns { success: true } on success'), which are useful. However, it does not describe error behavior (e.g., what if FAQ not found), permissions, or side effects beyond deletion. This is partial transparency.
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, front-loaded with the action and resource. It states what the tool does and what to expect on success, with no wasted words. This is exemplary conciseness.
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 single-parameter delete tool, the description is largely complete: it specifies the input, the permanence, and the success return value. It lacks error-handling details (e.g., not-found or failure responses), but given the simplicity and the rich sibling context, this is a minor gap. The description is sufficient for an agent to select and invoke the tool correctly.
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 input schema already provides 100% coverage: faqId is described as 'The FAQ ID to delete.' The description adds the phrase 'by FAQ ID,' which reinforces but does not add new semantic meaning beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.
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: 'Permanently delete an FAQ from a knowledge base by FAQ ID.' The verb 'delete' is specific, the resource is 'FAQ from a knowledge base,' and the scope is precise (by FAQ ID). It effectively distinguishes itself from sibling tools like ghl_update_faq and ghl_create_faq.
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: use this when you want to remove an FAQ, and the permanence warning suggests caution. However, it does not explicitly mention when not to use it or point to alternatives (e.g., 'use ghl_update_faq to modify instead'). For a simple delete tool, this is adequate but lacks explicit guidance.
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 carries the full burden. It states only the action 'Delete' without disclosing permanence, required permissions, side effects, or failure conditions. This is a significant gap for a destructive 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, concise sentence that front-loads the action and resource. It contains no unnecessary words 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?
For a simple one-parameter tool with no output schema, the description covers the essential information: what is deleted and what input is required. It could mention irreversibility, but the current description is sufficient for basic tool selection and invocation.
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 input schema has 100% coverage, with fileId described as 'File or folder ID to delete'. The description adds no extra parameter detail beyond the schema, so the baseline 3 applies.
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 identifies the action (delete) and the resource (file or folder from the GHL media library). It distinguishes itself from sibling tools like ghl_get_media_files and other delete operations targeting different resources.
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 provides clear context for when to use the tool (when deleting a media file/folder) but does not explicitly mention when not to use it or name alternatives. It lacks exclusionary guidance, so it fits the 'clear context, no exclusions' level.
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?
With no annotations provided, the description's verb 'List' conveys a read-only behavior, but it does not disclose additional behavioral traits such as pagination, response format, or permission requirements. It is minimally transparent 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?
The description is a single, front-loaded sentence with no redundant words. It efficiently states the tool's purpose without unnecessary detail.
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 list tool with one optional parameter documented in the schema, the description is mostly complete. It does not mention the optional filter or return shape, but these are minor gaps given the simplicity and schema coverage.
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% for the single parameter 'groupId', so the baseline is 3. The description does not mention the groupId parameter at all, adding no semantic value beyond what the schema already provides.
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 'List all calendars in the GHL location' uses a specific verb ('List') and resource ('calendars') with a clear scope ('all'), which distinguishes it from sibling tools like ghl_get_calendar (singular). It clearly states what the tool does.
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 retrieving all calendars, but does not explicitly state when to use this tool over alternatives like ghl_get_calendar or ghl_get_calendar_groups, nor does it mention any exclusions or prerequisites. Guidance is minimal and inferred.
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?
There are no annotations, so the description carries the full burden. 'Get' clearly implies a read-only operation with no destructive side effects, and there is no mention of anything unexpected. However, it does not disclose potential error behaviors, auth requirements, or rate limits. For a simple retrieval tool, this is minimal but adequate.
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, front-loaded with the action and resource. It contains no filler, every word earns its place. For a simple get-by-ID tool, this is perfectly concise.
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—one parameter, no output schema, no nested objects—the description is complete enough. It conveys what the tool does and what it returns (the campaign) implicitly. It does not explain the difference between 'email campaign' and other campaign types, but the sibling list provides context. Overall, adequate for the tool's complexity.
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 input schema has one parameter 'campaignId' with description 'Campaign ID to retrieve', providing 100% coverage. The tool description adds no additional semantic meaning beyond what the schema already states. Since schema coverage is high, the baseline 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 the tool's function: 'Get a single email marketing campaign by ID.' The verb 'Get' and resource 'email marketing campaign' are specific. It distinguishes from sibling tools like 'ghl_get_email_campaigns' by using 'single' and 'by ID', making it unambiguous which tool to use for retrieving one campaign.
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: use this tool when you have a specific campaign ID and need that one campaign. It does not explicitly mention alternatives like 'ghl_get_email_campaigns' for listing campaigns or 'ghl_get_campaigns' for non-email campaigns. This is acceptable for a simple get-by-ID tool, but not proactively guiding.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get a single team member' and offers no information about error handling, return format, required permissions, or any side effects. For a simple read operation this is minimal, but it lacks context such as what is returned if the user is not found.
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 that front-loads the purpose and key parameter. There is no unnecessary wording or redundancy, making it highly efficient.
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 tool is simple, with one parameter and a straightforward purpose. The description accurately conveys that it retrieves a single user by ID, which is sufficient for a get-by-id operation. Although there is no output schema or detailed return description, the context is adequately complete for a tool of this simplicity.
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 already provides full coverage for the single parameter (userId with description 'User ID'). The description reiterates this by saying 'by their user ID' but adds no extra semantic meaning (e.g., ID format, uniqueness constraints). Thus the baseline 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 the specific verb 'Get', the resource 'a single team member', and the key scoping parameter 'by their user ID'. This distinguishes it from sibling tools like ghl_get_users (plural) and ghl_search_users, as it explicitly retrieves one entity by a unique identifier.
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 phrase 'by their user ID' provides clear context that this tool is for fetching a specific user when the ID is known. However, it does not explicitly mention when to use ghl_get_users or ghl_search_users as alternatives, which would fully clarify usage boundaries.
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 must convey behavioral traits. It does state that both question and answer are required by the API and that the return value is { success: true }, which adds useful context. However, it does not disclose potential errors (e.g., FAQ not found), authorization requirements, or side effects beyond modifying the FAQ. The coverage is adequate but not comprehensive.
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 concise and front-loaded with the primary action. It consists of two sentences that convey the core purpose and key constraints without any fluff. Every sentence earns its place.
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 update tool with no output schema and no annotations, the description provides the essential information: the action, the required fields, and the return value. It is complete enough for an agent to invoke the tool correctly. The only missing aspect is error behavior, but for a straightforward update this is acceptable.
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 input schema already provides descriptions for all three parameters with 100% coverage. The description adds no additional parameter-level details beyond restating that question and answer are required (already in the schema's required list). The baseline of 3 applies because the schema fully documents the parameters.
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 function: 'Update the question and answer of an existing FAQ.' It specifies the verb (update), the resource (FAQ), and the fields involved. This distinguishes it from sibling tools like ghl_create_faq, ghl_delete_faq, and ghl_list_faqs.
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?
Usage context is implied by the phrase 'existing FAQ' and the update verb, indicating this tool is for modifying existing FAQs rather than creating or deleting them. However, there is no explicit when-to-use guidance, mention of alternatives, or exclusions. The context is clear but not explicitly stated.
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 carries the full burden. It only states the success return value but does not disclose error behavior, permission requirements, or consequences of updating non-existent IDs. For a mutation tool, this is a significant transparency gap.
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, with the action stated first and the return value second. Every word earns its place, and there is no redundancy or unnecessary detail.
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 tool is simple with three parameters and no output schema. The schema documents all parameters, and the description explains the return format. It misses potential error cases but given the simplicity and full schema coverage, it is adequately 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?
All parameters are fully described in the schema (100% coverage), with descriptions like 'New name for the knowledge base'. The tool description itself adds no additional semantic value beyond naming the fields, so the baseline 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 uses a specific verb 'Update' with the resource 'knowledge base' and explicitly names the fields ('name or description'), making the tool's purpose clear. It distinguishes from sibling tools like create/delete/get by focusing on modification of existing resources.
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 clearly implies use for updating an existing knowledge base's name or description. While it does not explicitly state alternatives or exclusions, the context is unambiguous given sibling tools, and it says 'existing' to signal that the resource must already exist.
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 carry the full burden of behavioral disclosure. It does not mention idempotency, side effects (e.g., duplicate enrollments), authorization requirements, or what happens on success/failure. For a mutation tool, this is a significant transparency gap.
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 short sentences with no filler. It front-loads the primary action, then adds a relevant usage hint. Every word earns its place, and the structure is easy to parse.
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 simple three-parameter mutation, the description provides the core action and a useful workflow-ID hint, and the schema covers two of three parameters. However, it lacks any mention of return values, idempotency, or preconditions, which would be helpful given there is no output schema and no annotations. It is minimally viable but leaves gaps.
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 schema covers 67% of parameters (workflowId and eventStartTime). The description adds meaningful nuance by explaining that workflow IDs can be 'configured' or 'custom', which is not in the schema. However, contactId is left undocumented in both schema and description, though its purpose is inferable from the tool name.
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 action ('Enroll a contact') and resource ('a GHL workflow/automation'), distinguishing it from the sibling tool 'ghl_remove_contact_from_workflow'. The mention of 'configured workflow IDs or supply a custom one' adds specificity, making the tool's purpose unmistakable.
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 the tool (to enroll a contact) and the schema adds a useful cross-reference to ghl_get_workflows for discovering valid workflow IDs. However, it does not explicitly exclude alternatives or state when not to use the tool, so it stops short of a 5.
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. It discloses that this is a create/mutation operation and that it uses a template, but it does not mention return values, what happens if scheduledAt is omitted, or any side effects. This is a moderate level of transparency, sufficient for a straightforward create 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 a single, concise sentence that front-loads the verb and key details. Every word adds value, and there is no redundancy or filler.
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 simple create tool with no output schema and no annotations, the description covers the core purpose and the prerequisite (existing template). However, it lacks information about return values or error conditions, and the scheduling behavior is only implied by 'scheduled send'. Sibling tools are not referenced for disambiguation, leaving some 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 description coverage is 100%, so the baseline is 3. The description adds minimal parameter context beyond the schema: it clarifies that templateId refers to an existing email builder template. It does not elaborate on scheduledAt behavior or name/subject semantics, but the schema already describes these sufficiently.
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 action (create), the resource (email marketing campaign), and a key differentiator (scheduled send using an existing template). This distinguishes it from siblings like ghl_send_email (immediate send) and ghl_create_email_builder_template (template creation).
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 usage context: it creates a scheduled campaign and requires an existing template. While it doesn't explicitly list alternatives or exclusions, the phrase 'scheduled send' and 'using an existing email builder template' gives clear contextual guidance. Sibling tools like ghl_send_email are implicitly contrasted.
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 burden of behavioral disclosure. The verb 'List' implies a read-only operation, but the description does not explicitly state safety, pagination behavior, or any caveats. It does add useful context about the template type, which is beyond the name, but lacks detail on what the response contains or edge cases.
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 main purpose, followed by relevant context. Every word earns its place; no fluff or repetition of the tool name.
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 low complexity (simple list with pagination), the description covers the core purpose and what type of templates are returned. However, there is no output schema and no mention of pagination behavior, default limits, or return structure, which would be helpful. It is adequate but not exhaustive.
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% (only sortByDate has a description). The tool description does not mention limit, offset, or sortByDate at all, so it adds no semantic value for the parameters. Since coverage is low, the description should compensate, but it doesn't, leaving the agent with only parameter names to infer meaning.
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 'List email marketing / builder templates for the location.' It uses a specific verb (List) + resource (email marketing/builder templates) + scope (for the location). It distinguishes from the singular sibling tool 'ghl_get_email_builder_template' and the generic 'ghl_get_templates' by specifying these are visual-editor templates used in Marketing → Emails and referenced by workflow Send Email actions.
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 provides clear context on what these templates are and where they are used, which helps an agent understand when to pick this tool over generic templates. However, it does not explicitly state when not to use it or mention alternatives (e.g., singular template fetch), so it stops short of full usage guidance.
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?
With no annotations, the description carries the full transparency burden. It discloses the query scope (specific or all forms) and implies a read-only operation via 'Get'. However, it does not describe pagination, response format, or other potential behavioral nuances.
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 sentence with no redundant information, making it highly concise and well-structured.
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 five parameters and no output schema or annotations, but the description gives enough context for a basic understanding. It lacks details on pagination, return structure, or any edge cases, which would improve completeness for a more complex tool.
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 description adds meaning to formId by explaining 'specific form or all forms', which complements the schema. However, the page and limit parameters are undocumented in both the schema and the description, and the coverage of 60% is only partially compensated.
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 retrieves form submissions, with an optional filter by form. It distinguishes from sibling tools like ghl_get_survey_submissions and ghl_get_forms by specifying 'submissions' and 'forms'.
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 provides clear context: use this tool to get submissions for a specific form (by formId) or all forms in the location. It does not explicitly mention alternatives, but the scope is well-defined and implies when it is appropriate.
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?
With no annotations provided, the description carries the full burden. It indicates a read-only list operation via 'List' and adds scoping to 'the location', but it does not mention pagination (skip/limit), return format, or any other behavioral traits such as whether the list is sorted. The description is honest but lacks deeper behavioral detail.
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 front-loads the action ('List') and adds necessary context without wasted words. It is concise and easy to parse.
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 list tool with three optional parameters and no output schema, the description is largely complete: it names the resource, scope (location), and clarifies the specific subtype. It omits pagination details but the tool's simplicity keeps this from being a critical gap.
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% (only 'type' has a description). The description adds no parameter information beyond naming the template channels, which somewhat reinforces the type enum. 'skip' and 'limit' remain undocumented in both schema and description, so the description fails to compensate for the low 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 states 'List SMS/email/WhatsApp templates in the location' with a specific verb and resource. It further clarifies these are 'quick-reply-style templates under Settings → Templates', which distinguishes it from confusingly similar siblings like ghl_get_email_builder_templates.
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 gives clear context ('quick-reply-style templates under Settings → Templates') that implies when to use this tool versus email builder templates, but it does not explicitly name alternatives or state exclusionary conditions. This is clear context without explicit when-not-to-use guidance.
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. It only states the basic action without mentioning return format, pagination, exact match behavior, or permissions. This is a thin description that adds little beyond the tool name.
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 that puts the action first and contains no filler. It is fully front-loaded and efficiently communicates 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?
Given the tool's simplicity (one optional parameter, no annotations, no output schema), the description covers the basic purpose but omits return-value details. For a search tool, it would be helpful to state that it returns a list of matching users, but the core intent is still understandable.
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 schema description for 'query' is generic ('Search query'). The tool description adds meaning by specifying that the query can be a name or email, which clarifies the expected input and compensates for the schema's vagueness.
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 action (search) and the resource (team members) with specific fields (name or email). It effectively distinguishes from sibling tools like ghl_search_contacts by focusing on users/team members rather than contacts.
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 provides clear context on what the tool searches (team members by name or email), which implies when to use it versus alternatives. It does not explicitly mention when-not-to-use or alternative tools, but the resource scope is unambiguous.
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?
With no annotations, the description carries the burden of disclosing behavior. It does state the core upsert behavior (create or update by email/phone), but omits important details such as matching precedence if both email and phone are provided, which fields get updated, and whether existing data can be overwritten.
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 that front-load the primary purpose and a secondary usage hint. Every word earns its place with no repetition or filler.
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 an 8-parameter tool with no annotations and no output schema, the description is quite sparse. It lacks information about return values, error behavior, or how the upsert handles conflicts, making it only minimally complete for real-world invocation.
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 description adds meaning to 'email' and 'phone' by identifying them as lookup keys, which is not in the schema. However, schema description coverage is 0% and the description ignores the other six parameters (tags, source, name fields, companyName, customFields), leaving their role ambiguous.
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 'Create or update a contact by email or phone,' which is a specific verb-resource pair with a precise matching mechanism. This distinguishes it from sibling tools like ghl_create_contact and ghl_update_contact by conveying the upsert semantics.
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 phrase 'Useful for ensuring no duplicates' provides a clear context for when to choose this tool over create or update. However, it does not explicitly state when not to use it or name alternatives, so it falls short of a 5.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It states the return value ('including its ID') and the email prerequisite, which adds value. However, it does not disclose other important behavioral traits like permission requirements, potential errors, or side effects beyond the obvious creation action. Moderate transparency.
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 with no fluff. The first sentence is front-loaded with the action and resource, and the second adds email-specific guidance and return behavior. Every word earns its place.
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 simple create operation with full schema coverage and a clear return statement, the description is largely complete. The only minor gap is not explicitly distinguishing from ghl_create_email_builder_template, but the explicit channel types reduce ambiguity. Overall adequate for an agent to invoke correctly.
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 input schema has 100% description coverage for all properties, including the subject requirement and body format. The description reinforces these points ('For email, provide a subject and HTML body') but does not add meaning beyond what the schema already provides. Baseline 3 applies since schema handles parameter documentation.
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 'Create a new SMS, email, or WhatsApp template', identifying the specific verb, resource, and channel types. It distinguishes from sibling tools like ghl_create_email_builder_template by explicitly naming messaging channel types. The added detail about returning the template with its ID further clarifies the scope.
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 provides clear context for when to use this tool: creating messaging templates across three channel types. It also includes a specific guideline ('For email, provide a subject and HTML body'). However, it does not explicitly mention alternatives or when not to use it, such as distinguishing from updating/deleting templates.
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 description bears full responsibility. It unambiguously states the destructive action and return value, but does not disclose whether deletion is permanent, requires permissions, or handles partial failures. Adds minimal behavioral context beyond the verb 'Remove'.
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, front-loading the action and resource, then giving a usage hint and return value. 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 2-param tool with explicit return value in description. Missing details like error behavior or irreversibility are notable but not critical for a straightforward delete operation within a knowledgeable domain.
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 descriptions already fully document both parameters (knowledgeBaseId and urlIds, including how to retrieve urlIds). Description adds no new semantics beyond what the schema provides. Baseline 3 applies with 100% 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?
Description uses specific verb 'Remove' and identifies resource 'trained page URLs from a knowledge base'. It clearly distinguishes from sibling tools like ghl_list_crawler_urls and ghl_train_crawler_urls by indicating a deletion operation.
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?
Provides clear context that urlIds should come from ghl_list_crawler_urls, which is a helpful usage hint. It does not explicitly mention alternatives or when-not-to-use, but the list reference implicitly guides correct usage.
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?
With no annotations, the description carries the burden of behavioral disclosure. It discloses that the response includes all fields, tags, and custom data, which is useful. However, it does not mention read-only safety, potential errors (e.g., 404), authentication requirements, or any other behavioral caveats beyond the return payload.
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 that front-loads the verb and resource, states the key constraint (by ID), and lists the included data. Every word earns its place with no waste or redundancy.
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 get-by-ID tool with one parameter and no output schema, the description sufficiently conveys the purpose and return contents. It lacks explicit error behavior or usage exclusions, but the tool's simplicity keeps the description close to complete. The mention of all fields, tags, and custom data fills the gap left by the missing output schema.
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 input schema has 100% coverage: contactId is described as 'The contact ID'. The description adds no additional semantic detail about the parameter beyond what is already in the schema. Baseline 3 applies because the schema fully documents the only 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 clearly states the tool retrieves a single contact by ID, with a specific verb ('Get'), a resource ('contact'), and a scope ('single', 'by ID'). It differentiates from siblings like ghl_get_contacts (plural list) and ghl_search_contacts (search-based) by emphasizing the single-ID lookup.
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 the tool should be used when you have a specific contactId, as opposed to listing or searching. It doesn't explicitly name alternatives or state when not to use it, but the 'single contact by ID' phrasing gives clear contextual guidance for use.
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?
With no annotations provided, the description carries the full burden. It implies a read-only lookup ('Get available...'), but it does not explicitly state that it has no side effects, nor does it mention any behavioral nuances such as timezone handling, buffer times, or whether blocked slots are excluded. It is accurate but lacks additional context that would be useful for a tool with no structured safety hints.
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, immediately front-loaded with the core action. No redundant words or filler. Every part adds value, making it easy for an agent 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?
For a simple read-only query tool with no output schema, the description adequately explains the purpose and usage context. It does not describe the return format or pagination, but the action is straightforward and an agent can reasonably infer that it returns a list of available slots. Slightly more detail would be beneficial, but it is sufficiently 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?
Schema coverage is 75% (three of four parameters have descriptions). The description adds context by mentioning 'date range' (matching startDate/endDate) and 'for a calendar' (matching calendarId), but these are already implicit in the schema. It does not provide new information about the parameters beyond what the schema already states.
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 the action: 'Get available appointment slots for a calendar within a date range.' It uses a specific verb and resource, and the phrase 'Use this before booking to find open times' further clarifies its role. This distinguishes it from sibling tools like ghl_get_calendar_events or ghl_create_appointment.
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 provides explicit usage context: 'Use this before booking to find open times.' This tells the agent when to invoke the tool relative to the booking workflow. However, it does not explicitly name alternatives or describe when not to use it, but the intended usage 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 provided, so the description carries the full burden. It accurately describes a read operation and highlights the return payload (full details with metadata counts), but it does not disclose potential error conditions (e.g., 404 on missing ID), authentication requirements, or other edge cases. Adequate for a simple GET, but not rich in behavioral disclosure.
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 primary action, and each sentence adds value. The first states the operation, the second details the return content. 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?
For a single-parameter GET tool with no output schema, the description gives the essential operation and high-level return information (full details, metadata counts). It is sufficient for selecting and invoking the tool, though it could list more specific return fields or usage caveats.
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 provides 100% coverage for the single parameter (knowledgeBaseId), including its description. The tool description mentions 'by ID' but adds no extra meaning beyond what the schema already states, so the 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 specifies the verb 'Get' and the resource 'knowledge base' by ID, distinguishing it from sibling tools like ghl_list_knowledge_bases, ghl_create_knowledge_base, etc. It also adds a specific detail about returning kbMetadata counts, making the purpose even clearer.
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 the tool is for retrieving a single knowledge base when the ID is known, but it does not explicitly differentiate from the list tool or mention when the list variant would be more appropriate. This is clear context without explicit exclusions or alternatives.
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?
With no annotations provided, the description must carry the burden of disclosing behavior. 'Get all' indicates a read-only operation, which is transparent. However, it does not mention whether results are paginated, ordered, or limited, which could be relevant for a list tool. Overall, it covers the basic behavior 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?
The description is a single, front-loaded sentence: 'Get all trigger links in the location.' Every word contributes to conveying the tool's purpose, with no redundancy or filler. It is an exemplar of conciseness.
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 tool with no parameters and a simple action, the description sufficiently conveys what the tool does and what it returns (trigger links). However, since there is no output schema, a bit more detail about the return structure or any limits could have made it even more complete. Still, it is adequate for the simplicity of the 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?
There are zero parameters, and the schema is empty (coverage 100%). The baseline for 0 parameters is 4, and the description correctly avoids adding unnecessary parameter details. No additional semantics 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?
The description 'Get all trigger links in the location' clearly states the verb (get), resource (trigger links), and scope (all in the location). It distinguishes itself from sibling tools like ghl_create_trigger_link and ghl_delete_trigger_link by explicitly indicating a read/list operation.
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 need to retrieve all trigger links—but does not explicitly state when not to use it or compare with alternatives. For a simple list operation, the intent is clear from the name and description, but there is no explicit guidance or exclusions.
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 burden. It discloses pagination and filtering behavior, and the 'List' verb implies a read-only operation. However, it does not specify return format, ordering, auth requirements, or error conditions, which are relevant for a list 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 three sentences: purpose, features, and use case. It is front-loaded and every sentence adds value with no redundancy.
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 and no output schema/annotations, the description covers the core aspects: what it lists, pagination/filtering, and intended use. It is slightly thin on return value details, but overall adequate for a list 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?
Schema description coverage is 100%, so the baseline is 3. The description adds minor context by mentioning 'pagination' and 'URL filtering' which map to the page/pageLength and query parameters, but it does not add syntax or format details 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 uses a specific verb ('List') with a clear resource ('trained page links for a knowledge base'). It clearly distinguishes from sibling tools like ghl_train_crawler_urls and ghl_delete_crawler_urls by focusing on listing, not training or deleting.
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 explicitly states when to use the tool: 'Use to get urlIds for training or deletion.' It also indicates supported operations (pagination, URL filtering). While it doesn't name alternative tools or exclusions, the use case 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?
With no annotations, the description carries the full burden. It discloses cursor-based pagination and the returned fields, which are useful behavioral details. However, it does not explicitly state that this is a read-only operation, mention authentication requirements, or describe how the pagination cursor is returned in the response.
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 one concise sentence that front-loads the core purpose. Every phrase adds value: scope ('for the location'), pagination ('cursor-based'), and return fields. No filler or redundancy.
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 list tool with three optional params and no output schema, the description provides the essential return fields and pagination behavior. It could be more complete by mentioning how the next cursor is exposed in the response, but it is sufficient for most listing scenarios.
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 input schema already provides 100% coverage for all three parameters, including descriptions for limit, query, and lastKnowledgeBaseId. The description adds no parameter-specific details beyond the schema, so the 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 uses a specific verb ('List') and resource ('knowledge bases'), clearly distinguishing it from sibling tools like get_knowledge_base or knowledge base mutation tools. It also specifies the return fields, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly signals when to use the tool—when listing knowledge bases for a location. It does not explicitly contrast with alternatives like ghl_get_knowledge_base or ghl_list_faqs, but the listing intent is clear enough for an agent to select it appropriately.
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 burden. It discloses the return value ('Returns { success: true } when training starts'), which indicates asynchronous initiation, but it does not mention potential side effects, rate limits, or whether the operation is destructive. Some behavioral context is added, but not comprehensive.
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 short sentences, each adding distinct value: purpose, data source, and return behavior. No redundancy, front-loaded main action.
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 low-complexity tool with full schema descriptions, the description covers purpose, source of IDs, and return value. It could mention error cases or asynchronous behavior more explicitly, but it is adequate for the tool's scope.
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%, and each parameter already has a description. The description repeats the urlIds source already present in the schema, adding no new parameter information. Baseline 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 uses a specific verb ('Ingest') with a clear resource ('page URLs into the knowledge base for AI training'). It distinguishes itself from siblings like ghl_list_crawler_urls (listing) and ghl_delete_crawler_urls (deletion) by focusing on the training action.
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 explicitly instructs to use urlIds from ghl_list_crawler_urls, providing a clear source and workflow context. It does not explicitly exclude alternatives, but the mention of the list tool implies a natural sequence after discovery.
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 disclosure. It adds valuable behavioral context: the mutation is implied by 'Create', the per-location limit of 15 is a critical constraint, and the return value (created KB object) is explicitly stated. This exceeds the bare minimum for a create 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 two sentences long and front-loaded with the action verb. It conveys purpose, constraint, and return value without wasted words. Every sentence adds value and the structure is clear.
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?
For a simple create tool with two documented parameters and no output schema, the description is sufficient. It states the operation, the location scope, the limit, and the return object. The content fully covers what an agent needs to invoke and interpret the result correctly.
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 input schema already provides 100% coverage, with descriptions for both 'name' (required) and 'description' (optional). The tool description does not add any parameter-specific details beyond what the schema already contains, so the 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 uses the specific verb 'Create' and identifies the resource 'knowledge base for the location', clearly stating the action and scope. It distinguishes from sibling tools like list/get/update/delete by naming the create operation explicitly.
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 via the verb 'Create' and mentions the location scope, but it does not explicitly compare to alternatives or state when not to use the tool. The constraint 'Max 15 knowledge bases per location' provides context but no direct guidance on selecting this over other KB operations.
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, the description carries the full burden. It reveals that the tool returns an operationId and implies an asynchronous operation by directing the user to track progress separately. This is a useful behavioral disclosure beyond the schema.
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 zero filler. The first sentence states purpose, the second gives the operational handoff, making it efficient and structured.
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 explains the tool's role, its async return, and the subsequent steps, which is adequate for a 3-param tool. It lacks a detailed output schema note, but the mention of operationId covers the key return value.
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 additional parameter-specific insights beyond the schema's definitions, so it neither elevates nor reduces the score.
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 clear action: 'Start crawling a website to discover pages for AI training.' It distinguishes itself by referencing ghl_get_crawler_status and ghl_train_crawler_urls, making the tool's role explicit.
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?
It provides workflow context by explaining the return of an operationId and instructing to use ghl_get_crawler_status to track progress and ghl_train_crawler_urls to ingest. This frames the tool's position in the pipeline, though it doesn't list alternative crawl-management tools.
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, the description conveys this is a read-only listing via the verb 'List' and scopes the result set to purchased/active numbers. It doesn't detail pagination behavior or output format, but the parameters and simple list nature provide adequate transparency.
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 unnecessary words. It earns its place by clarifying the resource scope.
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 list tool with no output schema, the description clearly states what it returns (all purchased/active phone numbers in the location). It doesn't explain return field details or default pagination, but these are likely consistent with sibling list tools and inferable from parameters.
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 each parameter having a description, so the description need not add parameter details. The tool description adds some context about the resource scope but doesn't enhance parameter semantics 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 uses the specific verb 'List' with the resource 'purchased/active phone numbers in the location', clearly distinguishing this from sibling tools that search available numbers, purchase, release, or update phone numbers.
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 phrase 'purchased/active' provides clear context that this tool is for existing numbers, implicitly contrasting with search_available_phone_numbers. However, it does not explicitly name alternatives or state when not to use it.
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?
The description discloses that the tool is a read operation ('Get'), returns all pipelines and their stages, and is scoped to the GHL location. This conveys the key behavioral traits, especially since no annotations are provided.
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?
A single, well-structured sentence that front-loads the action and resource. No unnecessary words or repetition.
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, zero-parameter read-only getter, the description adequately explains what the tool returns (all pipelines and stages) within the location context. It omits output format details, but no output schema exists, and the description at least names the returned data.
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 fully covers the input. The description adds no parameter-specific info, but with no parameters, the baseline score of 4 applies.
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 action (Get), the resource (all pipelines and their stages), and the scope (in the GHL location). This distinguishes it from sibling tools that operate on different resources like opportunities or workflows.
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 usage is implied by the description and tool name: use this tool when you need to retrieve pipeline definitions and their stages. However, there is no explicit mention of when not to use it or alternatives, so it relies on inference.
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?
The description discloses that deletion is permanent, cascades to all content, and returns a success object. With no annotations, this provides essential behavioral context, though it lacks auth prerequisites or error handling details.
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?
A single, information-dense sentence. It front-loads the purpose and includes key behavioral details without any fluff.
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?
For a simple destructive tool with one parameter and no output schema, the description covers the action, the scope of deletion, permanence, and the return value. This is complete and self-sufficient.
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 already fully describes the single parameter (knowledgeBaseId). The description adds no additional meaning beyond what is in the schema, so a baseline score of 3 is appropriate given 100% 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 verb 'delete' with the resource 'knowledge base' and specifies it deletes all content including FAQs and trained URLs. This differentiates it from sibling tools like delete_faq which deletes a single FAQ.
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 context is clear: this tool removes an entire knowledge base and its contents. While it doesn't explicitly say 'use this instead of delete_faq', the scope is unambiguous enough for an agent to select it correctly.
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 burden. 'List' clearly conveys a read-only, non-destructive operation. It adds the location scope and the fact that it returns all workflows. However, it doesn't disclose return format, pagination, or error behavior, which is a minor gap for a simple 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?
Two sentences, no wasted words. The first sentence states the action and scope; the second provides the practical use case. Information is front-loaded and easy to parse.
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, no output schema, and is a straightforward list operation, the description is complete. It covers what the tool does, the scope, and why you'd use it. No additional behavior needs explanation.
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, and the schema is empty. The description adds no parameter information, but none is needed. Per the rubric, a baseline of 4 is appropriate for zero-parameter tools, and the description doesn't introduce any ambiguity.
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 the specific verb 'List' with the resource 'workflows/automations' and scopes it to 'the GHL location'. It also explicitly states the purpose: 'Use this to discover workflow IDs before enrolling contacts.' This clearly distinguishes it from sibling tools like add/remove contact to workflow.
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 provides clear context for when to use the tool: 'before enrolling contacts' to discover workflow IDs. It implies this is a prerequisite step for enrollment operations, though it doesn't explicitly name alternative tools or state when not to use it.
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 explicitly indicates a read-only listing operation ('List all') and clarifies the scope ('in the location'), which is meaningful. It does not go into pagination or permissions, but for a simple list tool this is adequate and adds value beyond the bare name.
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 that is front-loaded with the verb and resource. Every word is meaningful, and there is no wasted text or repetition of the tool name.
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 parameterless list operation with no output schema, the description is sufficiently complete: it states the resource, the scope, and the action. It does not mention response format or limitations, but these are not critical given the simplicity. The clarification of 'location-level variables' adds useful context that helps distinguish from custom fields.
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 baseline is 4. The description adds context about what is being listed (custom values as location-level variables), which compensates for the absence of schema detail. No parameter explanations 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?
The description clearly states the action (List), the resource (custom values), and provides a clarifying parenthetical ('location-level variables') that distinguishes it from related concepts like custom fields. It is specific and differentiates from sibling tools like ghl_get_custom_fields and ghl_create_custom_value.
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 clearly implies when to use this tool (when you need to retrieve all custom values for the location), and the context 'in the location' sets expectations. However, it does not explicitly mention exclusions or alternative tools, though the sibling set makes the purpose unambiguous.
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 provided, the description carries full responsibility for behavioral disclosure. It explicitly mentions cursor-based pagination and the return fields (count, hasMore, lastFaqId), which is valuable beyond the schema and gives the agent a clear idea of the operation's behavior.
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 primary purpose and followed by pagination details. Every sentence contributes useful information without 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's simplicity (3 params, no output schema), the description covers the essential aspects: what is listed, pagination method, and return values. This is complete enough for an agent to invoke the tool correctly without additional context.
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 described in the input schema. The description adds high-level pagination context but does not add parameter-specific meaning beyond what the schema already provides, so the 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 the tool lists all FAQ question/answer pairs for a knowledge base, using a specific verb ('List') and resource ('FAQ question/answer pairs'). It distinguishes itself from sibling create/update/delete FAQ tools and includes pagination context.
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 usage when one needs to list FAQs for a knowledge base, with clear pagination behavior. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to select this tool.
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:

[![ghl-mcp-server MCP server](https://glama.ai/mcp/servers/NerdSnipe-Inc/ghl-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/NerdSnipe-Inc/ghl-mcp-server)

Score Badge

Copy to your README.md:

[![ghl-mcp-server MCP server](https://glama.ai/mcp/servers/NerdSnipe-Inc/ghl-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/NerdSnipe-Inc/ghl-mcp-server)

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/NerdSnipe-Inc/ghl-mcp-server'

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