Server Quality Checklist

Tool Scores

• ghl_store_get_shipping_carrierD
  1.8/5.0
  Behavior2/5

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

  Annotations clearly indicate read-only, idempotent, non-destructive behavior. However, the description's claim of a 'list' operation contradicts the actual single-get behavior, undermining trust. No additional behavioral details (permissions, rate limits) 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.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short but contains redundant and misleading phrasing (e.g., 'List Shipping Carrier' for a get operation). It is not concise in a helpful way and wastes space with inaccurate 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?

  No output schema is present, and the description fails to describe the return format or fields. For a simple get tool, the description should state what data is returned but does not, leaving the agent uninformed.

  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 is adequately structured with examples, but the description adds no value beyond the schema. It fails to explain the purpose of 'altId' and 'altType' or how they relate to the carrier retrieval, leaving the agent to infer from examples only.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The name 'get_shipping_carrier' suggests retrieving a single carrier, but the description calls it 'List Shipping Carrier' and mentions a paginated list, creating confusion. The endpoint includes an ID path parameter, indicating a single resource retrieval, not a list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance provided on when to use this tool vs. alternatives. The sibling 'ghl_store_list_shipping_carriers' exists for listing, but the description incorrectly labels this as a list operation, further confusing usage.

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

• ghl_custom_field_delete_folderC
  2/5.0
  Behavior2/5

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

  Annotations already mark the tool as destructive and idempotent. The description adds OAuth scopes and the object support limitation. However, it fails to disclose what happens when a folder is deleted (e.g., impact on custom fields inside it). The contradictory 'Create' text also harms transparency.

  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 poorly structured. A div with incorrect 'Create' text appears, and the info callout is not clearly separated. The endpoint and scopes are technical details that could be omitted or presented more concisely.

  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 straightforward delete operation with two parameters, the description lacks key context about the folder resource, how to find the id, and expected response. The info callout adds some value but overall the description is incomplete.

  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 50% (only locationId has a description). The description does not explain the 'id' parameter (folder ID) or how to obtain it. No examples or additional context are provided to clarify parameter usage beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The title and tool name indicate 'delete', but the description includes a div with 'Create Custom Field Folder' which directly contradicts the purpose. This inconsistency severely undermines clarity. The tool deletes a custom field folder, but the misleading text confuses the agent.

  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 a constraint (only supports Custom Objects and Company) and endpoint details, but no explicit guidance on when to use this tool versus related tools like ghl_custom_field_create_folder or ghl_custom_field_update_folder. The agent is left to infer usage from the name alone.

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

• ghl_invoice_template_deleteC
  2.2/5.0
  Behavior2/5

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

  The description provides the HTTP method and OAuth scopes, which are partially helpful, but the misleading 'update' statement overshadows these. Annotations already indicate destructiveHint=true, so the delete nature is clear from annotations, but the description's internal inconsistency 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.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very short but includes a contradictory and irrelevant line ('API to update...') that wastes space. A tool description should be concise and accurate; here the inaccuracy harms 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 destructive nature and the presence of sibling tools, the description should clarify what deletion entails (e.g., irreversibility, cascading effects). It fails to provide complete context and includes an error, making it insufficiently informative.

  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% parameter description coverage, and the description adds no additional meaning for the parameters. Baseline score of 3 applies as the schema adequately explains the parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with 'Delete template' which matches the name, but then says 'API to update an template by template id,' introducing confusion about whether the tool deletes or updates. The HTTP method DELETE in the endpoint contradicts the 'update' phrase. This muddles the 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?

  No explicit guidance on when to use this tool versus alternatives like ghl_invoice_template_update or other invoice template tools. The description does not mention prerequisites, use cases, or exclusion criteria.

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

• ghl_invoice_template_update_payment_methods_configurationC
  2.2/5.0
  Behavior2/5

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

  Annotations indicate a write operation (readOnlyHint=false) and description states 'updates', but there is a contradiction: the annotations title says 'update template late fees configuration' while the description's first sentence says payment methods. No disclosure of side effects, authorization needs, or rate limits.

  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 contains four sentences: one clear, two redundant/conflating late fees, and one endpoint detail. It is not concise and includes contradictory 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?

  The tool has nested objects and moderate complexity, but the description lacks explanation of altId/altType purpose, paymentMethods structure, and any output description. It fails to provide a complete 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?

  Schema coverage is 100%, with descriptions for all properties. The description adds no extra semantic context beyond the schema, so it meets the baseline without adding value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The first sentence clearly states the tool updates payment methods on invoice templates, but the following two sentences inconsistently mention 'update template late fees configuration', conflating two different functionalities. The name also indicates payment methods, creating confusion about the actual 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?

  No guidance is provided on when to use this tool versus alternatives like ghl_invoice_template_update. There is no mention of prerequisites, when-not to use, or exclusions.

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

• ghl_social_attach_tiktok_profileC
  2.2/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false and openWorldHint=true, but the description adds no behavioral context beyond the endpoint. No mention of side effects, authentication requirements, or what happens upon execution. Does not contradict annotations.

  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 extremely brief but provides minimal useful information. It is under-specified rather than concise. A single line restating the name and an endpoint is not sufficiently structured for an agent.

  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 three parameters, a nested body object, and no output schema, the description is too sparse. It omits usage context, behavior, and parameter semantics, making it incomplete for effective 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?

  Schema description coverage is 100% (all parameters have descriptions), so baseline is 3. The description does not add any additional meaning about the parameters (e.g., body properties) beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description restates the tool name as 'Attach Tiktok profile' without adding specificity. It does not distinguish from sibling social attach tools like facebook_page_group or twitter_profile. The endpoint URL is provided but does not clarify what 'attach' means or what the tool accomplishes.

  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?

  Description offers no guidance on when to use this tool versus alternatives. No prerequisites, context, or exclusions are mentioned. The agent has no basis to decide between this and similar tools.

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

• ghl_social_edit_postC
  2.2/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false (modifies data) and idempotentHint=true (potentially idempotent). The description does not elaborate on behavioral traits such as side effects, permissions, or rate limits. It mentions a PUT endpoint but does not clarify idempotency or consequences of editing.

  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 contains contradictory information (edit vs create). It front-loads the title but disrupts clarity with irrelevant create instructions. The link and endpoint info are useful but could be more 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 tool's complexity (nested objects, many parameters) and lack of output schema, the description is incomplete. It fails to state the core editing functionality and leaves confusion with creation details. The schema is thorough, but the description does not provide adequate higher-level 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 description coverage is 100%, so the baseline is 3. The description adds minimal value beyond what the schema already provides (e.g., a link to platform limitations). No parameter semantics are enhanced, but no contradiction either.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with 'Edit post' but immediately describes creating posts ('Create posts for all supported platforms...'). This is contradictory and confuses the tool's purpose. The endpoint (PUT) confirms an edit operation, but the description does not consistently state that it modifies an existing post.

  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_social_post_create' (a sibling tool for creating posts). The description does not specify that this tool is for editing existing posts, nor does it exclude its use for creation (which is incorrect).

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

• ghl_store_get_shipping_zoneC
  2.3/5.0
  Behavior2/5

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

  While annotations declare readOnlyHint, the description adds little beyond the endpoint URL and source. It incorrectly describes the operation as a 'list' with pagination, which contradicts the actual single-resource retrieval, and fails to disclose behavior such as what happens when the zone is not found or authentication requirements.

  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 short but contains redundancy (title repeated) and confusing terminology ('List' instead of 'Get'). It could be clearer and more 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 no output schema, the description should explain what is returned. It does not mention the purpose of altId and altType (location/agency context) or the return format. The pagination mention is irrelevant and misleading. The description is incomplete for a get-by-ID 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 coverage is high (75%), so the schema already describes parameters. The description does not add any parameter-specific meaning beyond what is in 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.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is confusing: it states 'Get Shipping Zone' but then says 'List Shipping Zone' API and mentions 'paginated list', while the input schema requires a single shippingZoneId, indicating a get-by-ID operation. This contradiction makes the purpose unclear and potentially misleading.

  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 like ghl_store_list_shipping_zones or other CRUD operations. No context is provided about prerequisites or typical scenarios.

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

• ghl_workflow_listC
  2.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds endpoint details, version header, and OAuth scopes, which are useful for understanding API requirements, but does not disclose return format or pagination.

  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 very short and includes relevant technical details (endpoint, version, scopes) without extraneous information. However, it could be slightly improved by clarifying the purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that there is no output schema, the description should explain what the tool returns (e.g., list of workflows). It does not provide this information, and the lone parameter is not described, making the tool incomplete for an agent to use correctly.

  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 one required parameter (locationId) with 0% description coverage. The description does not explain the meaning or purpose of locationId, leaving the agent to infer its role from the name only.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The title says 'Get Workflow' but the tool name is 'ghl_workflow_list' and the endpoint is GET /workflows/ (plural), suggesting it lists workflows. The description does not clearly state that it retrieves a list of workflows, causing ambiguity about the exact 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. The sibling tools include many others, but there is no indication of other workflow-related tools or criteria for selection.

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

• ghl_agent_studio_promote_and_publishC
  2.4/5.0
  Behavior2/5

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

  The description adds minimal behavioral context beyond annotations: it confirms the action is a mutation (consistent with readOnlyHint=false) and provides endpoint details and OAuth scopes. However, it does not disclose crucial behaviors like whether promotion is irreversible, if it overwrites an existing production version, or any side effects. Annotations already indicate destructiveHint=false, but this is 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and the key action is front-loaded. However, including endpoint details and OAuth scopes adds technical verbosity that may not be essential for an agent. It could be more compact by focusing only on the behavioral purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (nested schema, no output schema), the description is insufficient. It does not explain prerequisites (e.g., how to obtain a draft versionId), the outcome of promotion, or any return value. An agent would struggle to use this tool correctly without additional context.

  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 mention any parameters at all. With only 33% schema description coverage (just a generic comment on body), the agent is left without guidance on what versionId represents or how to construct the body fields meaningfully. This is a critical gap for a tool with nested objects.

  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 it promotes a draft version to production, specifying the verb 'promote' and resource 'draft version to production'. It distinguishes from sibling agent_studio tools like create, delete, or execute by its unique action, though it does not explicitly contrast with these 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. It does not mention prerequisites (e.g., must have a draft version) or when not to use it. The large sibling list includes many other agent_studio operations, but no comparisons are made.

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

• ghl_association_delete_relationC
  2.4/5.0
  Behavior2/5

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

  Annotations already indicate destructive behavior and idempotency, but the description adds only the endpoint and OAuth scopes, which are technical details rather than behavioral context. It does not disclose consequences like cascading deletions or required permissions beyond scopes.

  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 short and includes necessary technical details (endpoint, scopes) without excessive fluff. It is front-loaded with the title, though some technical content may be unnecessary for an agent. Still, it is reasonably 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?

  For a destructive tool with no output schema and partial parameter descriptions, the description lacks completeness. It does not specify what happens after deletion, any error conditions, or how relationId should be obtained. Annotations help but leave gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 50%: locationId has a description ('Your Sub Account's ID'), but relationId has no description and is not explained in the tool description. The description does not add meaning beyond the schema, which already partially covers locationId but leaves relationId ambiguous.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description merely restates the tool's name as 'Delete Relation' and provides endpoint details, but fails to clarify what a 'relation' is in the context of associations. It does not distinguish this tool from siblings like ghl_association_delete or ghl_association_create_relation.

  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 alternative tools such as ghl_association_delete. The description lacks any context about prerequisites, typical use cases, or scenarios where this operation is appropriate.

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

• ghl_calendar_appointment_note_updateC
  2.4/5.0
  Behavior3/5

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

  Annotations already indicate idempotent and non-destructive mutation. The description adds OAuth scope 'calendars/events.write', which is useful but minimal. No contradiction with annotations.

  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?

  Very concise but includes raw endpoint and version header that may be irrelevant for an AI agent. The structure is acceptable but could be more focused.

  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?

  Lacks business context about what a note is or how updating it works. No output schema, so agent cannot infer response structure. Incomplete for a mutation 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?

  Schema coverage is 100% and parameter descriptions exist. The tool description adds no additional meaning to parameters, but baseline is 3 due to high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Update Note' essentially restates the tool name without clarifying what a note is in the context of calendar appointments. It does not differentiate from sibling tools like note_create or note_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?

  No guidance on when to use this tool versus alternatives. The description lacks any context about prerequisites, when not to use, or how it relates to other note operations.

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

• ghl_store_get_shipping_rateC
  2.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. However, the description inaccurately suggests pagination, which could confuse agents. Additional context like authentication needs or response format is missing but not critical given annotations.

  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 short and starts with the tool name, but it includes extraneous technical details (endpoint, source) and an incorrect reference to a 'list' API, reducing clarity.

  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, yet the description fails to specify what is returned (expected to be a single shipping rate object). It also does not explain required parameters like altId/altType, leaving 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 coverage is 75% (3 of 4 parameters have descriptions). The description adds no semantic value beyond the schema; it does not explain the role of altId/altType or the overall request structure.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Get Shipping Rate' but contradicts itself by mentioning 'retrieve a paginated list of shipping rate', which is inaccurate for a single-resource GET. It does not clearly distinguish from sibling tools like ghl_store_list_shipping_rates.

  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 such as listing or creating shipping rates. The description lacks context for selection.

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

• ghl_link_updateC
  2.5/5.0
  Behavior2/5

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

  Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds the OAuth scopes and endpoint, but does not explain update semantics (e.g., whether it's a full replace or partial update). No contradiction with annotations.

  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 very short (two lines), which is concise, but it omits important details like usage context and parameter explanations, making it less effective despite its 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 a required nested body parameter and sibling tools for link operations, the description fails to provide sufficient context. It does not explain the effect of the update or how it relates to other link tools. Output schema is absent.

  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?

  Input schema has 100% coverage with descriptions for both parameters (linkId, body). The 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.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Update Link', which is a clear verb+resource combination. However, it lacks specifics on what fields are updated, relying entirely on the input schema. It distinguishes from sibling tools like ghl_link_create by using 'Update', but does not elaborate.

  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 does not mention that ghl_link_create is for creating links or that ghl_link_delete is for deletion, leaving the agent without context for tool selection.

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

• ghl_location_task_searchC
  2.5/5.0
  Behavior2/5

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

  The description includes OAuth scope 'locations/tasks.readonly' suggesting read-only behavior, but the annotation readOnlyHint is false, creating a contradiction. No additional behavioral traits like rate limits or state changes are disclosed.

  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 concise but front-loads technical endpoint details rather than a clear purpose statement. It is adequate but could be more structured for an AI agent.

  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 lacks information about return values, pagination, or typical usage patterns. For a search tool with no output schema, this is insufficient for an agent to use it 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 coverage is 100% with parameter descriptions already in the schema. The description adds no extra semantic value beyond what the schema provides, resulting in a baseline score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Task Search Filter' and 'Task Search', indicating it searches for tasks, but does not clearly articulate the scope or differentiate from other search tools. The purpose is implied rather than explicitly stated.

  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 contact or opportunity search. There is no mention of prerequisites, limitations, 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.

• ghl_location_update_custom_fieldC
  2.5/5.0
  Behavior2/5

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

  Annotations provide idempotentHint=true and destructiveHint=false, but the description adds no behavioral context beyond that. It does not mention side effects, permissions, or other traits.

  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 very short (two lines) and front-loaded with the title, but it lacks substantive information. It is concise but at the expense of completeness.

  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 3 parameters including a nested body and no output schema, the description fails to provide an overview of behavior, required context, or return format. Incomplete for an agent to use 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 coverage is 100% with descriptions for all parameters. The description adds no extra meaning beyond what's in the schema, so baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Update Custom Field' which is clear about the action and resource, but it does not differentiate from the sibling tool 'ghl_custom_field_update'. This lack of sibling distinction reduces 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_custom_field_update' or other custom field tools. The description only provides the endpoint, no usage context.

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

• ghl_social_attach_facebook_page_groupC
  2.5/5.0
  Behavior2/5

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

  Annotations already indicate this is a non-read-only, non-destructive mutation. The description adds only the endpoint URL and version, which do not disclose behavioral traits like auth requirements, rate limits, side effects (e.g., does it replace existing attached pages?), or error conditions. No contradiction with annotations.

  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 very short but includes technical endpoint details that are likely not useful for an agent selecting the tool. It is concise but under-specified, lacking necessary context to be actionable.

  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 complexity of attaching a Facebook page/group and the existence of many similar sibling attach tools, the description is incomplete. It does not explain the process, prerequisites (e.g., OAuth integration), or what the body fields represent. No output schema, and the description fails to compensate.

  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?

  Despite 100% schema coverage, the description does not explain the parameters beyond what the schema provides. The body fields are undocumented in the description, and their purpose is unclear. The description adds no additional meaning to aid the agent in constructing valid inputs.

  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 states the verb-resource combination 'Attach facebook pages' clearly, and the endpoint confirms it attaches a Facebook account. However, it does not differentiate from sibling attach tools like ghl_social_attach_instagram_page_group, and the tool name includes 'page_group' but description only mentions 'pages', potentially causing slight 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 on when to use this tool versus alternatives (e.g., when to attach a page vs a group or other social accounts). There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.

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

• ghl_social_attach_instagram_page_groupC
  2.5/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description does not add any behavioral context beyond the endpoint, such as side effects, authorization requirements, or that it performs a creation operation. With minimal annotations, the description should compensate but fails to do so.

  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 very short, which is efficient, but it includes technical endpoint details (POST path and version header) that may be unnecessary for an AI agent. It is not well-structured or prioritized for agent comprehension.

  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 complexity of the social media attachment domain and the large list of sibling tools, the description is incomplete. It does not explain what the tool does beyond 'attach,' what the outcome is, or how it integrates with other steps. No output schema exists to compensate.

  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 input schema already describes each parameter (e.g., 'Account Id', 'Account Location Id', and the body with its properties). The description adds no additional meaning or context to the parameters, so it meets the baseline score but provides no extra value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Attach Instagram Professional Accounts,' which is a verb+resource that indicates the tool attaches Instagram accounts. However, it is essentially identical to the title and does not provide additional clarity or differentiation from sibling tools like ghl_social_attach_facebook_page_group, making it adequate but not distinctive.

  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 attaching Instagram accounts is appropriate or what prerequisites are needed. The description lacks any context for informed selection.

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

• ghl_store_update_shipping_carrierC
  2.5/5.0
  Behavior2/5

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

  Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds no behavioral details beyond stating 'update', missing edge cases like the effect of an invalid ID.

  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 very short but not excessively so. However, it lacks structure (e.g., sections) and could be more concise while still conveying necessary 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?

  With siblings for CRUD operations and a required body parameter, the description fails to explain the operational context (e.g., that it modifies an existing carrier). No output schema mentioned.

  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?

  Input schema has 100% coverage with descriptions and examples for each parameter. The description adds no additional parameter info, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'update a shipping carrier' which is clear but merely restates the tool name. It does not distinguish from sibling tools like create or delete, lacking specific scope or 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 on when to use this tool versus alternatives (e.g., create for new carriers, delete for removal). The description offers no context or prerequisites.

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

• ghl_conversation_ai_update_followup_settingsC
  2.6/5.0
  Behavior2/5

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

  Annotations already indicate the tool is not read-only, destructive, or idempotent. The description adds no behavioral context beyond stating it's an update, missing details like side effects, rate limits, 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded with the title and action, but it wastes space on endpoint details and OAuth scopes that could be implicit. It is concise but lacks substance.

  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 complex nested schema and no output schema, the description fails to explain what the tool returns or any side effects. Important context like response format or error conditions is missing.

  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 50% parameter coverage (body has a description, agentId lacks one), but the description adds no parameter explanations or usage tips, leaving the agent to infer from the schema 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 title and description clearly state the tool updates followup settings for an action, with a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like ghl_conversation_ai_update_action, 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 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, lacks context on prerequisites, and does not mention exclusions or appropriate scenarios.

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

• ghl_custom_field_update_folderC
  2.6/5.0
  Behavior3/5

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

  Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true, indicating a safe update operation. The description adds the endpoint URL and OAuth scopes, which are helpful. However, the misleading create statement detracts from transparency.

  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?

  Description is short but contains messy HTML and a redundant/contradictory div ('Create Custom Field Folder'). The structure is not clean; the info block and endpoint details are useful but poorly formatted.

  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, so the description should ideally explain what the response contains or how the folder is updated. It only provides the endpoint and scopes. Missing details on return value, error handling, or side effects beyond 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?

  Input schema already provides descriptions for 'name' and 'locationId' (e.g., 'Field name', 'Location Id'). The description does not add further semantic meaning beyond what the schema provides. Schema coverage is moderate, so baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Update Custom Field Folder Name' which clearly indicates updating a folder name. However, a div inside the description says 'Create Custom Field Folder', causing confusion. The purpose is mostly clear but undermined by the contradictory create 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?

  No explicit guidance on when to use this tool versus alternatives like ghl_custom_field_create_folder. The info note mentions scope limitation to Custom Objects and Company, which implicitly suggests usage context, but no clear when-to-use or alternatives.

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

• ghl_link_createC
  2.6/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false and openWorldHint=true. The description adds nothing beyond the endpoint and OAuth scopes. It does not disclose side effects, duplicate handling, or rate limits, which are important for a mutation tool with openWorldHint.

  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 very short (three lines) with no unnecessary content. However, it could be better structured by including a brief usage example or behavioral note. The conciseness is acceptable but at the cost of missing important details.

  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 presence of multiple sibling link tools and nested parameters, the description is incomplete. It does not explain what a link is used for, what the response contains (no output schema), or any constraints. For a creation tool, this is insufficient.

  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 descriptions for each required field. The description does not add any extra meaning about parameters. A baseline score of 3 is appropriate since the schema already documents them adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Create Link' and provides the endpoint, but does not explain what a link is (e.g., a trigger link that redirects). It does not differentiate from sibling link tools like update or delete. The schema hints at a trigger link, but the description itself is too vague.

  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 like ghl_link_update or ghl_link_search_trigger. The description lacks context about prerequisites or when creation is appropriate. Only the OAuth scope is mentioned, but no usage direction.

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

• ghl_location_create_recurring_taskC
  2.6/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds no additional behavioral context such as side effects, authentication needs, rate limits, or idempotency behavior (idempotentHint=false).

  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 short (two lines) but lacks structure. It provides the endpoint but no front-loaded summary of when to use it. It is adequate but not notably efficient or well-organized.

  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 complexity of the input (nested object with recurrence rules), the description is too minimal. It does not explain what a recurring task is, how recurrence options work, or what the response contains. Output schema is absent, so more description 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?

  The description does not mention any parameters, and with 50% schema coverage, it fails to compensate for the missing parameter details. Key parameters like rruleOptions (a complex nested object) are left unexplained in the tool description.

  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 'Create Recurring Task' and provides the endpoint, indicating the tool creates a recurring task. However, it does not differentiate from sibling tools like ghl_contact_create_task or ghl_location_update_recurring_task.

  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 (e.g., one-time task creation). No prerequisites or context about recurrence rules are mentioned, leaving the agent without decision support.

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

• ghl_product_bulk_updateC
  2.6/5.0
  Behavior1/5

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

  The annotation destructiveHint is false, yet the description lists 'delete' as a possible operation, creating a direct contradiction. The description does disclose the destructive capability, but the rubric specifies a score of 1 when description contradicts annotations.

  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 moderately concise but contains redundant phrasing ('Bulk Update Products' repeated) and mixes endpoint details with the functional description. It could be tightened without losing essential 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?

  The description omits important context such as the required body structure, how to use filters, and the meaning of different 'type' values. For a complex mutation tool with no output schema, this leaves gaps in understanding how to correctly invoke it.

  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 schema itself provides full descriptions for all parameters. The description adds no extra semantic meaning beyond listing operation types, resulting in a baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with 'Bulk-mutates multiple products in one call', clearly stating the verb and resource. It enumerates specific operations (price, availability, collections, delete) and distinguishes from single-product tools like ghl_product_update, but does not explicitly differentiate from the similarly named ghl_product_bulk_edit sibling.

  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_product_bulk_edit or individual product updates. It only warns to review productIds and mentions OAuth scopes, but does not clarify prerequisites or situations where a different 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.

• ghl_store_list_shipping_carriersC
  2.6/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds only endpoint details, which are redundant. No additional behavioral traits (e.g., pagination, rate limits, error conditions) are disclosed.

  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 short but includes a repetitive phrase ('List Shipping Carrier' vs title) and unnecessary endpoint technical details. Could be more concise and focused.

  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 lacks information about the return value structure, scoping to location, and any limitations. For a simple list tool, it should at least state what fields are returned or that it requires valid altId/altType.

  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 50% coverage (altId described, altType only enum). The description does not explain any parameters, missing an opportunity to clarify altType's purpose or the role of the two 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 clearly states 'retrieve a list of shipping carrier', which aligns with the tool name and distinguishes it from sibling tools like get/create/delete/update. However, it could be more precise by specifying that it lists carriers for a given 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 on when to use this tool versus alternatives such as ghl_store_get_shipping_carrier or ghl_store_list_shipping_rates. The description does not mention prerequisites or context.

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

• ghl_association_get_by_object_keyC
  2.7/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, making the safety profile clear. The description adds that the tool retrieves associations for specific object types (contacts, custom objects, opportunities) but does not disclose additional behavioral traits like return structure or rate limits. It complements annotations without contradicting them.

  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?

  Description is moderately concise but includes extraneous details (e.g., renaming history, exact endpoint, OAuth scopes) that may not be necessary for selection or invocation. The key information is front-loaded but could be trimmed for clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema and 0% parameter description coverage, the description fails to explain what the tool returns, the meaning of an association, or how to properly use the objectKey parameter. Essential invocation context is missing, making it incomplete for an AI agent.

  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?

  Input schema has 0% description coverage for its two parameters (objectKey, locationId). The description does not explain these parameters, their formats, or how to construct valid values. The schema provides examples but no semantic meaning, leaving a significant gap for correct invocation.

  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 clearly states 'Get association by object keys' and lists example object types (contacts, custom objects, opportunities). It is specific about the verb and resource. However, it does not explicitly differentiate this from other association retrieval tools like get_by_id or get_by_key_name, relying on the name to imply 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?

  No guidance on when to use this tool versus alternatives such as ghl_association_get_by_id or ghl_association_get_by_key_name. The description includes endpoint and OAuth scope info but lacks context for appropriate invocation or exclusions.

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

• ghl_calendar_notification_deleteC
  2.7/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=false, destructiveHint=true, idempotentHint=true. The description adds OAuth scopes (calendars/events.write) which affirm write access but does not disclose behavioral nuances like irreversibility or impact on related entities. It adds some value beyond annotations but not substantial.

  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 short but includes technical details (endpoint, OAuth scopes) that are not essential for an AI agent. The repetition of 'Delete Notification' wastes space. More focused structuring would improve it.

  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 does not explain what happens upon successful deletion (e.g., confirmation, removed notification). For a destructive operation, this lack of completeness leaves the agent uncertain about the outcome.

  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?

  Both parameters (calendarId, notificationId) are required but have no descriptions in the schema (0% coverage). The description fails to add any meaning or context for these parameters, leaving the agent without guidance on what values to provide.

  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 explicitly states 'Delete Notification', which clearly indicates the action and resource. Among sibling tools like ghl_calendar_notification_create, get, list, update, this delete tool is distinctly identified. No ambiguity, but it lacks additional context like what type of notification.

  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, prerequisites, or when not to delete. The description only states the action, leaving the agent with no context for appropriate usage.

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

• ghl_campaign_listC
  2.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description adds modest value by specifying the HTTP method (GET) and OAuth scopes. It does not disclose pagination, error handling, or other behavioral details, but the annotations cover the safety profile adequately.

  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 brief (3 lines) and front-loads the purpose. However, it redundantly repeats 'Get Campaigns' from the title and includes technical details (endpoint, version, OAuth) that may not be essential. Still, it is efficient with no wasted sentences.

  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 lacks an output schema, but the description does not mention what the response contains (e.g., list of campaigns, pagination). It also fails to address filtering (beyond the status parameter) or how results are ordered. For a list tool in a domain with many campaign variants, this incompleteness impairs effective 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 schema has zero description coverage (0%) for both parameters (status, locationId). The description does not explain the purpose or allowed values of status, nor the format or source of locationId. This is a significant gap that prevents the agent from understanding how to set parameters correctly.

  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 states 'Get Campaigns' which clearly indicates the verb (get) and resource (campaigns). However, it does not differentiate from other campaign-related tools (e.g., ghl_email_list_campaigns, ghl_ad_fb_campaign_get), leaving ambiguity about which campaign type is being listed.

  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 lists the endpoint and OAuth scopes but does not mention any use cases, prerequisites, or exclusions. Given the many sibling campaign tools, this omission hinders correct selection.

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

• ghl_contact_search_advancedC
  2.7/5.0
  Behavior1/5

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

  The description states 'Search' implying a read-only operation, yet annotations set readOnlyHint: false, contradicting the described behavior. Additionally, the OAuth scope 'contacts.readonly' further suggests read-only, conflicting with readOnlyHint. This contradiction undermines transparency.

  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 verbose and front-loads a technical note about the spec gap, burying the actual purpose and usage details. Essential information like 'Search Contacts' only appears mid-text, reducing clarity and readability.

  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 provides an external documentation link, endpoint details, and OAuth scopes, which are helpful. However, it lacks practical guidance on how to construct queries, expected output (no output schema), and explicit usage prerequisites, leaving gaps for complex advanced search functionality.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema for 'body' is empty, but the description compensates by explaining the schema gap, linking to external documentation for real field names, and noting that the body accepts arbitrary JSON for advanced filters. This adds significant meaning beyond the schema's minimal description.

  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 'Search contacts based on combinations of advanced filters,' indicating a specific verb (search) and resource (contacts) with advanced filtering capability. However, it does not explicitly differentiate from sibling tools like ghl_contact_list or potential basic search tools, missing an opportunity to clarify its unique value.

  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_contact_list or other search tools. It mentions 'advanced filters' but does not elaborate on scenarios where this tool is preferred, leaving the agent without clear usage context.

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

• ghl_contact_update_noteC
  2.7/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds OAuth scopes and endpoint info, which are not in annotations. However, it does not explain the update behavior (e.g., partial vs full replacement) or side effects. Minimal added value beyond annotations.

  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 very short (two lines), which is concise, but it sacrifices completeness. It lacks structured information and reads more like a raw API reference than a user-friendly guide.

  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 3 parameters including a nested body object and no output schema, the description provides insufficient context. It does not explain the response format, how to construct the body, or any constraints. Schema alone is not enough for effective tool 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?

  Schema description coverage is 100% with detailed field descriptions. The tool description does not add any extra meaning beyond the schema. Baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Update Note' which clearly indicates the action on a note resource. However, it is minimal and does not differentiate from sibling tools like ghl_contact_create_note or ghl_contact_delete_note. The endpoint details add context but the purpose is somewhat vague.

  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 vs alternatives. There is no mention of prerequisites, scenarios, or exclusions. The description lacks any usage recommendations.

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

• ghl_location_create_tagC
  2.7/5.0
  Behavior3/5

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

  Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive. The description adds OAuth scopes (locations/tags.write) which provides auth context beyond annotations, but no other behavioral traits are disclosed.

  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 short but contains redundancy ('Create Tag' repeated) and is not structured to clearly highlight key information. It is adequately concise but could be more efficient.

  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 nested parameters and no output schema, the description lacks information about expected response, prerequisites, or examples. It is too minimal to fully guide an agent, especially given the complexity of the nested body object.

  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 input schema already describes both parameters (locationId and body with nested name). The description adds no additional meaning or usage tips for the parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Create Tag' which matches the tool's name and title but does not differentiate from sibling tools like ghl_location_update_tag or explain what a tag is. It is clear but lacks distinguishing context.

  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_location_update_tag or ghl_location_delete_tag. The description does not specify context 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.

• ghl_saas_get_locationsC
  2.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds the agency token requirement, which is valuable, but does not elaborate on other behavioral aspects like rate limits 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.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single paragraph with inconsistent capitalization (REQUIRES, `page`), redundant 'Get SaaS Locations', and an endpoint line that is more technical than helpful. It is not well-organized and could be more 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?

  With 2 required params, no output schema, and annotations covering safety, the description is incomplete. It does not explain the return format, pagination details (e.g., page size, max pages), or how to iterate through results. The endpoint info is extra but not essential for an agent.

  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%. The description mentions `page` as a required query param and vaguely mentions pagination, but does not explain `companyId` or provide details like default values, formats, or how to handle pagination. The phrase 'pass them to page through full result sets' is unclear.

  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 clearly states it fetches SaaS-activated locations for a company with pagination. However, it does not distinguish itself from sibling tools like the deprecated version or the stripe ID variant, leaving some 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?

  The description mentions the requirement for an agency-level token but provides no guidance on when to use this tool versus alternatives (e.g., deprecated versions, stripe ID version). No when-not-to or alternative references.

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

• ghl_social_attach_linkedin_page_profileC
  2.7/5.0
  Behavior2/5

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

  Annotations indicate a non-read-only, non-destructive write operation, which aligns with 'Attach'. However, the description provides no additional behavioral context beyond the endpoint URL, such as whether the action is idempotent, what the response contains, or any 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.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very short but omits essential details. While it has no fluff, it is under-specified for a tool with required nested parameters and no output schema. Front-loading is minimal.

  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 complexity (nested body, 3 required params, no output schema), the description is incomplete. It does not explain the concept of 'attaching', expected outcomes, or any preconditions. The endpoint detail is useful but not 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?

  Schema coverage is 100%, so the schema itself documents parameters. The description includes the endpoint URL which reinforces the path parameters (locationId, accountId) but adds no semantic context for the nested body fields. The body description merely restates the schema source.

  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 states 'Attach linkedin pages and profile', which is a specific verb and resource. The tool name includes the platform, distinguishing it from sibling tools for Facebook, Instagram, etc. However, it does not elaborate on what 'attach' entails (e.g., linking an account).

  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. The description does not mention prerequisites, when not to use, or alternative tools. The sibling list includes other social attach tools, but no explicit comparison is made.

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

• ghl_social_get_postC
  2.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and idempotentHint. The description adds endpoint and version info, which provides technical detail but limited behavioral context beyond what annotations offer.

  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 very short (two lines), front-loading "Get post." It is compact but lacks essential context, making it under-specified.

  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, the description fails to state that it retrieves a single post by ID, and does not clarify its return or differentiate it from similar tools like ghl_social_get_posts. Missing completion for effective use.

  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% (both parameters have descriptions). The description does not add extra meaning about parameters, so baseline score applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states "Get post" (verb+resource) but is very brief. It does not differentiate from sibling tools like ghl_social_get_posts or others, leaving ambiguity about whether it retrieves a single post or a 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?

  No guidance on when to use this tool vs alternatives (e.g., ghl_social_get_posts for listing posts, or other social retrieval tools). Missing context for selection.

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

• ghl_store_delete_shipping_carrierC
  2.7/5.0
  Behavior2/5

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

  Annotations provide destructiveHint: true and idempotentHint: true. The description adds only endpoint detail, not behavioral context such as side effects (e.g., cascading deletions) or required permissions. With annotations present, the description's additional value 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is concise with three lines, each adding value: action, parameter, and endpoint. The endpoint detail is somewhat redundant but not excessive. Efficiently communicates the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Lacks context about prerequisites (e.g., carrier must exist) and consequences (e.g., impact on shipping rates). The required altId and altType parameters are not explained in the description, leaving ambiguity about their purpose. A complete description would address these 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?

  Schema coverage is 67% (2 of 3 parameters have descriptions). The description mentions shippingCarrierId but does not add meaning for altId or altType beyond what the schema provides. It fails to compensate for the missing parameter description.

  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 clearly states the action 'Delete shipping carrier' and identifies the key parameter (shippingCarrierId). However, it does not distinguish from sibling tools like ghl_store_get_shipping_carrier or ghl_store_update_shipping_carrier, which have similar descriptions but different actions.

  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. The description only states what it does, without mentioning when deletion is appropriate or any prerequisites.

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

• ghl_association_create_relationC
  2.8/5.0
  Behavior2/5

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

  Annotations indicate it is not read-only and not destructive, but the description adds no further behavioral traits such as side effects, idempotency, or error states beyond the OAuth scopes. The technical endpoint detail is present but does not convey 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short but includes a documentation link and endpoint details that are not essential for an AI agent's tool selection. The core statement is concise, but the extra information adds noise without significant value.

  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 complexity of nested objects and no output schema, the description lacks explanations of what a relation is, what happens on creation, or how it interacts with other association tools. It is insufficient for complete understanding.

  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 parameters within the body. The tool description does not add any 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool creates a relation between associated entities, which provides a clear verb and resource. It is distinguishable from siblings like delete_relation and get_relations, though it could be more specific about what a relation is. Overall, adequate 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 is given on when to use this tool vs alternatives like ghl_association_create or ghl_association_get_relations_by_record_id. There are no prerequisites, context, or exclusions mentioned.

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

• ghl_association_updateC
  2.8/5.0
  Behavior3/5

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

  Annotations already indicate idempotent and not read-only. The description adds OAuth scopes and endpoint, which is useful but does not elaborate on side effects or error scenarios. No contradiction with annotations.

  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 not overly long but has redundancy ('Update Association' repeated) and includes extraneous details (documentation link, endpoint info). Could be more concise and better 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?

  Lacks information about return values, error handling, or prerequisites. For a mutation tool, the description should provide more context about what happens after the update and potential failure modes.

  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 superficially indicates that the body contains labels, but does not clarify the structure or allowed values for firstObjectLabel and secondObjectLabel. Schema coverage is incomplete, and 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it updates labels of an association, and the verb 'Update' combined with resource 'Association' is specific. It distinguishes from siblings like create and delete. However, it could be more precise about what an association is.

  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, no prerequisites or context provided. The description only states what it does but not 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.

• ghl_calendar_appointment_updateC
  2.8/5.0
  Behavior3/5

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

  Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds endpoint details and OAuth scopes, but does not disclose behavioral traits beyond what annotations provide, such as side effects, permissions required, or behavior for recurring appointments.

  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 very short, with only two substantive lines beyond the title. It front-loads the purpose and includes technical details (endpoint, scopes) in a compact form, though the title repetition wastes a line.

  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 2 parameters with a complex nested body, the description fails to explain return values, how to handle recurring appointments, or provide high-level usage guidance. Given the tool's complexity and lack of output schema, this minimal description is insufficient for an AI agent to use it 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?

  The input schema provides 100% coverage with descriptions for both parameters (eventId and body) and all nested fields. The description adds no additional meaning or context about parameters; it relies entirely on the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Update Appointment' which identifies the action and resource, but it merely repeats the tool name. It does not differentiate this tool from sibling tools like ghl_calendar_appointment_create or ghl_calendar_appointment_get, making it ambiguous what specific aspects of an appointment are updatable.

  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 lacks any discussion of prerequisites, context, or scenarios where other calendar tools (e.g., create, delete) 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.

• ghl_calendar_block_slot_createC
  2.8/5.0
  Behavior2/5

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

  Annotations already indicate this is a mutation (readOnlyHint=false). The description adds OAuth scopes and endpoint info, which provide some auth-related insight. However, it does not explain side effects (e.g., does this create a time block that prevents appointments?), so behavioral understanding remains limited.

  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 very short but contains redundancy (title repeated twice). It efficiently conveys the endpoint and scopes, but the repetition wastes space. It is acceptable but not 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 7 parameters (nested) and no output schema, the description lacks essential context. It does not explain the purpose of block slots versus regular events, nor what the response contains. The description is insufficient for an agent to fully understand the tool's role.

  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, so all parameters are documented. The tool description itself does not add any parameter-level meaning beyond what the schema provides, but the schema is sufficient. Baseline 3.

  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 'Block Slot', so the tool's action is identifiable. However, it does not explain what a block slot is, which could help distinguish it from other calendar tools like event creation. It is a specific verb+resource pair, meriting a 4.

  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 like ghl_calendar_block_slot_update or other calendar event tools. The description provides no context for selection, only the endpoint and OAuth scopes.

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

• ghl_calendar_group_deleteC
  2.8/5.0
  Behavior2/5

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

  The annotations already indicate destructiveHint=true, so the description adds no behavioral insight beyond repeating the endpoint and OAuth scopes. It does not disclose what happens to associated resources (e.g., appointments, slots) or recovery options. The OAuth scopes are useful but not behavioral.

  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 very short (three lines) but includes technical details (endpoint, version, OAuth scopes). While concise, these details are somewhat redundant with structured data and do not aid an AI agent in understanding usage. The structure is flat but acceptable.

  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 operation with no output schema, the description lacks critical context: what the response looks like (e.g., success code), error conditions (e.g., group not found, group in use), and side effects. The agent is left with minimal information to handle 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 covers 100% of parameters with a description 'Group Id' and an example. The tool description does not add additional meaning beyond the schema. Baseline score of 3 is appropriate as the schema does the work.

  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 explicitly states 'Delete Group', which clearly indicates the action (delete) and the resource (calendar group). Among siblings like ghl_calendar_group_create and ghl_calendar_group_update, it is distinct as the delete operation. However, it lacks additional context such as the scope of deletion (e.g., whether it deletes associated 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?

  No guidance is provided on when to use this tool versus alternatives like ghl_calendar_group_update_status or ghl_calendar_group_validate_slug. There is no mention of prerequisites (e.g., group must exist) or consequences (e.g., cannot be undone). The agent receives no decision support.

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

• ghl_contact_add_tagsC
  2.8/5.0
  Behavior2/5

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

  The description does not disclose behavioral traits beyond annotations (destructiveHint=false, readOnlyHint=false). It fails to mention whether tags are appended or overwritten, or any side effects. Adding tags is a mutation, but the description offers no caveats.

  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 concise but includes unnecessary technical details (endpoint path, version header) that are not helpful for the AI agent. The title 'Add Tags' is redundant. Every line is functional but not optimally 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?

  Missing important context: no mention of output/response, no error handling, no specification that tags are added (not replaced). For a mutation tool with no output schema, more detail is needed for 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%, so baseline is 3. The description does not add any extra meaning to the parameters (e.g., format of tags, constraints on contactId). No value added beyond 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 states 'Add Tags' which clearly indicates the action of adding tags to a contact. Among sibling tools like ghl_contact_remove_tags and ghl_contact_bulk_update_tags, it is distinct. However, it lacks explicit differentiation, e.g., 'Add tags to a single 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 on when to use this tool versus alternatives like ghl_contact_bulk_update_tags or ghl_contact_remove_tags. Missing context about prerequisites (e.g., contact must exist) or whether tags are appended or replaced.

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

• ghl_contact_createC
  2.8/5.0
  Behavior2/5

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

  Annotations indicate it's a write operation (readOnlyHint false) and openWorldHint true, but the description adds only OAuth scopes and endpoint. It does not disclose idempotency, behavior on duplicates, or any side effects beyond creation.

  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 very short and includes only the bare essentials. While concise, it lacks important context, making it merely adequate.

  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 complex schema with many nested fields and no output schema, the description is incomplete. It does not explain return values, error handling, or behavioral details necessary for correct usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed parameter descriptions, so the description does not need to add extra semantics. The description itself adds no parameter info beyond what the schema provides, meeting the baseline.

  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 states 'Create a new contact' clearly indicating the action and resource. However, it does not distinguish from sibling tools like ghl_contact_upsert which also creates contacts, so there is a slight lack of 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 on when to use this tool versus alternatives (e.g., upsert, update). No context about prerequisites or when to avoid using it.

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

• ghl_contact_update_task_completedC
  2.8/5.0
  Behavior2/5

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

  The description repeats the action title and includes endpoint and OAuth scopes, but adds no behavioral context beyond what annotations already provide (idempotentHint, destructiveHint). It does not explain effects like whether it overwrites or toggles completion status.

  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 very concise but lacks substantive information. It is front-loaded with the title and includes endpoint details, but could be better structured to provide more value without increasing length.

  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 3 required parameters, no output schema, and annotations, the description is incomplete. It does not explain how the tool relates to contact tasks, what the response looks like, or differentiate from similar 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 has 100% description coverage and clearly documents all three parameters (contactId, taskId, body with completed field). The description adds no additional parameter semantics, so baseline 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 'Update Task Completed' which indicates the action of updating a task's completion status. However, it does not distinguish from the sibling tool 'ghl_contact_update_task', which likely updates other fields, missing an opportunity to specify scope.

  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_contact_update_task' or 'ghl_contact_create_task'. The description lacks context for appropriate usage.

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

• ghl_conversation_ai_list_actionsC
  2.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the HTTP endpoint and OAuth scopes, which are useful for understanding access requirements, but does not disclose pagination, rate limits, or other behavioral details.

  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 short but contains redundancy ('List Actions for an Agent' followed by 'List for actions for an agent'). It could be more concise by removing duplication, but overall length is acceptable.

  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 simple list tool with a single parameter and no output schema, the description lacks key details such as the structure of the response (e.g., what fields are returned), any default sorting or pagination behavior, and how to interpret the results. The endpoint and OAuth scopes are helpful but insufficient for full understanding.

  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 only parameter, agentId, is not described in the description or input schema (0% schema description coverage). The description implies its existence but does not explain its format, source, or any constraints, leaving the agent without sufficient information to correctly provide the value.

  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 it lists actions for an agent, using the verb 'List' and specifying the resource 'Actions for an Agent'. This distinguishes it from sibling tools like get_action_by_id and create_action, though it doesn't explicitly call out 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 on when to use this tool versus alternatives such as ghl_conversation_ai_get_action_by_id or ghl_conversation_ai_search_agent. It does not specify prerequisites or context for use.

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

• ghl_email_verifyC
  2.8/5.0
  Behavior2/5

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

  Annotations are sparse (readOnlyHint false, destructiveHint false). The description does not explain the side effects (e.g., potential charges, which are hinted in the schema but not repeated). It mentions 'lc-email.readonly' OAuth scope, which contradicts the readOnlyHint false annotation, creating confusion. No disclosure of rate limits or idempotency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short but includes unnecessary internal details like 'Version header: v3; source: v3/email-isv-v3.json' that are irrelevant to an agent. It could be more concise by omitting these and focusing on the core action. The structure is acceptable but lacks front-loading of the most critical 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?

  Given the tool's simplicity (2 params, no output schema) and the presence of annotations, the description is incomplete. It does not explain the expected output, what happens on success/failure, or the meaning of the 'type' parameter (email vs contact). The charge implication from the schema is not reinforced.

  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 provides descriptions for all parameters. The main description adds no parameter information. Per guidelines, baseline is 3 when schema coverage is high and description adds nothing. However, the body's schema description is generic, and the main description could have clarified the 'type' enum options.

  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 states 'Email Verification' and 'Verify Email', clearly indicating a verb and resource. It distinguishes itself from sibling tools as no other tool focuses on email verification. However, the description lacks details about the scope of verification (single email vs batch) and includes non-helpful internal details like version headers.

  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 conditions under which it should or should not be used. Sibling tools are numerous but unrelated, so no differentiation is offered.

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

• ghl_invoice_schedule_update_and_activateC
  2.8/5.0
  Behavior2/5

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

  Annotations indicate it is non-readOnly (mutation) and non-destructive. The description adds the OAuth scope for permissions but does not explain side effects such as whether it overrides existing settings or activates the schedule. No additional behavioral context beyond what annotations imply.

  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 short but contains redundant phrasing ('Update scheduled recurring invoice API to update scheduled recurring invoice'). It could be more concise by removing the repetition and front-loading the core action.

  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 does not specify what the tool returns (e.g., updated schedule object or success confirmation). The nuance between this tool and ghl_invoice_schedule_update is not clarified, leaving the agent with incomplete information.

  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?

  With 100% schema coverage and only one parameter (scheduleId), the description adds no extra meaning. The schema itself is sufficient. Baseline 3 is appropriate as no added value.

  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 states 'Update scheduled recurring invoice' and repeats it, clearly indicating the verb and resource. It distinguishes from sibling tools like ghl_invoice_schedule_activate and ghl_invoice_schedule_update by mentioning both update and schedule. However, it is slightly redundant and could explicitly state the dual action of updating and activating.

  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 vs alternatives like ghl_invoice_schedule_update or ghl_invoice_schedule_activate. It does not mention prerequisites, exclusions, 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.

• ghl_location_update_recurring_taskC
  2.8/5.0
  Behavior2/5

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

  Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds no behavioral context (e.g., whether updates overwrite fields, effects on past tasks, or permissions required). It merely restates the endpoint.

  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 minimal (title + endpoint) and concise but lacks informative content. While it is not verbose, it sacrifices value for brevity. A few more sentences would improve structure.

  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, and the nested body parameter (rruleOptions) is complex. The description does not explain update behavior, return values, or important side effects. This leaves 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 coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the title and endpoint; it does not explain parameter relationships or nuances. Agents must rely solely on 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?

  The title 'Update Recurring Task' clearly indicates the action and resource. The endpoint path also confirms it. However, there is no differentiation from sibling tools like create or delete recurring tasks, which weakens 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 vs alternatives (e.g., create or delete). No prerequisites, constraints, or scenarios provided, leaving the agent without context for selection.

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

• ghl_opportunity_add_followersC
  2.8/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false (mutation) and destructiveHint=false (non-destructive). The description adds no behavioral details beyond 'Add Followers', such as success responses, error conditions, or side effects. It does not contradict annotations.

  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 (single line with endpoint and scopes). While efficient, it lacks structure or front-loading of key decision-making information for an AI agent.

  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 is provided, and the description omits typical outcomes (e.g., success, duplicate follower handling, errors). For a mutation tool with nested parameters, the description feels incomplete for reliable agent selection.

  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 parameters (id, body.followers) are well-described in the schema. The description adds no additional meaning, meeting the baseline for high 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 'Add Followers' and includes the endpoint and OAuth scopes, making it obvious it adds followers to an opportunity. The sibling tool ghl_opportunity_remove_followers provides clear differentiation. However, the description is terse and relies on the name itself.

  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 (e.g., remove followers) or prerequisites like needing the opportunity ID. The description does not provide context about typical scenarios or limitations.

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

• ghl_opportunity_createC
  2.8/5.0
  Behavior2/5

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

  Annotations indicate it is not read-only, not destructive, but the description adds no behavioral context such as side effects, required permissions beyond OAuth scopes, or error conditions. The description does not add value beyond the annotations.

  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 brief but omits useful structural elements like a summary of when to use or return value. It is not verbose but is under-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?

  Despite the tool's complexity (many parameters, nested objects, custom fields), the description does not explain how creating an opportunity fits into the broader pipeline workflow, the return value (no output schema), or the effect on related entities like contacts.

  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 detailed descriptions for all parameters (100% coverage), so the description's lack of parameter info is acceptable. No additional meaning or usage tips are provided.

  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 states 'Create Opportunity' which clearly indicates the action and resource. However, it does not differentiate from sibling tools like update or upsert, relying on the tool name for 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?

  No guidance on when to use this tool versus alternatives (e.g., update, upsert). No prerequisites or context provided beyond the endpoint and OAuth scopes.

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

• ghl_opportunity_upsertC
  2.8/5.0
  Behavior2/5

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

  Beyond annotations (readOnlyHint=false, etc.), the description only restates the tool's purpose. It does not disclose behavioral traits like what happens when an ID is provided (update) vs. omitted (create), required fields, or potential side effects. The openWorldHint suggests side effects, but description adds no clarification.

  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 very concise (two lines plus endpoint/scopes), but it omits important context such as usage guidelines and behavioral details. While brevity is positive, the lack of essential information prevents it from being well-structured or fully 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?

  Given the tool's complexity (multiple parameters, nested objects, no output schema), the description is too minimal. It does not explain return values, error conditions, or behavior for missing required fields. Annotations partially compensate but are insufficient for full contextual 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 has 100% parameter description coverage, so the baseline is 3. The description adds no further parameter meaning beyond what the schema provides, thus it meets the baseline without enhancement.

  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 states 'Upsert Opportunity' and the endpoint, clearly indicating it creates or updates an opportunity. However, it does not distinguish itself from sibling tools like ghl_opportunity_create or ghl_opportunity_update, leaving ambiguity about when to use upsert versus separate create/update actions.

  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 prerequisites, such as requiring an existing opportunity ID for updates, or scenarios where upsert is preferred over separate create/update calls.

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

• ghl_product_review_countC
  2.8/5.0
  Behavior3/5

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

  The description adds value beyond annotations by specifying the HTTP endpoint, version header, and OAuth scopes (products.readonly). However, it does not describe the response format (e.g., returns an integer count) despite no output schema, leaving a gap in behavioral understanding.

  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 short and includes endpoint/auth scopes, but it repeats 'Fetch Review Count as per status' twice, which is unnecessary. Otherwise, minimal waste.

  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 (2 required), no output schema, and siblings like ghl_product_review_list, the description lacks contextual completeness. It does not differentiate from sibling tools, explain the response, or cover all parameter purposes implicitly.

  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?

  With 86% schema description coverage, the baseline is 3, but the description does not add meaning to parameters. Instead, it mentions filtering 'as per status' which is not present as a parameter, potentially misleading. No parameter-specific details beyond 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 states that the tool fetches a review count, specifying the resource and verb. However, the phrase 'as per status' is not directly reflected in the input schema parameters (which include rating, dates, IDs but no status field), causing slight 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?

  The description provides no guidance on when to use this tool versus alternatives like ghl_product_review_list or ghl_product_review_get. No usage context or exclusions are given.

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

• ghl_social_delete_accountC
  2.8/5.0
  Behavior2/5

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

  Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds minimal behavioral context ('Delete account and account from group') but does not explain permanence, side effects, or required permissions. Beyond annotations, the description adds little value regarding behavior.

  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 very short (two sentences plus endpoint) but includes redundant content: 'Delete Account' repeats the title. The endpoint detail is useful for developers but not semantically helpful for an AI agent. It is not concise in a targeted way.

  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 does not explain the return value or clarify if the deletion is permanent or if there are dependencies. For a destructive action, the description lacks sufficient context for full agent understanding.

  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 schema already documents all parameters adequately. The description does not add any additional meaning or usage tips beyond what is in the schema, meeting baseline expectations.

  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 states it deletes an account and an account from a group, which combined with the tool name 'ghl_social_delete_account' and endpoint '/social-media-posting/{locationId}/accounts/{id}' clearly indicates it deletes a social media posting account. This distinguishes it from ad platform account deletes (e.g., ghl_ad_fb_account_delete) that appear in sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives, no prerequisites or conditions mentioned. The agent receives no help in deciding between this and other account deletion tools.

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

• ghl_social_delete_postC
  2.8/5.0
  Behavior2/5

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

  Annotations already provide destructiveHint=true and idempotentHint=true, but the description adds no behavioral context (e.g., permanence, consequences). It merely repeats the function.

  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 very brief, consisting of two lines. While concise, it includes endpoint details that may not be standard or helpful for selection, and it lacks structure.

  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 delete operation with no output schema, the description should clarify expected behavior (e.g., permanent deletion, response). It does not, leaving the tool's effects ambiguous.

  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 minimal descriptions for both parameters. The 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Delete Post' and provides the endpoint, indicating the verb and resource. It distinguishes from siblings like bulk delete by specifying a single post deletion via IDs.

  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 such as bulk delete or queue-related operations. The description lacks any context or prerequisites.

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

• ghl_social_get_postsC
  2.8/5.0
  Behavior2/5

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

  The description implies a read operation ('Get posts') and includes a read-only OAuth scope, but annotations set readOnlyHint=false. This contradiction is not resolved. No additional behavioral context (e.g., side effects, pagination behavior) is provided beyond annotations.

  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 short but contains redundancy ('Get posts' repeated). It front-loads the purpose and adds endpoint details, but could be more 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?

  No output schema is provided, yet the description does not describe the response format (e.g., list of post objects). The use of POST method for retrieval is not explained, leaving the agent without full 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%, so the schema already documents all parameters. The description adds no parameter-level information beyond the schema, hitting the baseline.

  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 states 'Get posts' clearly, but it is repetitive and does not explicitly distinguish from the sibling tool 'ghl_social_get_post' which likely retrieves a single post. The endpoint indicates a list operation, but this is not highlighted.

  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_social_get_post or ghl_social_get_statistics. The description provides no context about appropriate scenarios or exclusions.

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

• ghl_social_get_tiktok_profileC
  2.8/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description merely adds the endpoint URL, which does not contribute behavioral context. No mention of side effects, permissions, or response structure.

  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 short but lacks structure. It contains only the purpose and an endpoint line. No front-loading of key information or logical organization.

  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 output schema, the description should hint at the return value or structure. It does not. Also missing error conditions, authentication requirements, or expected behavior. Only the bare minimum exists.

  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 both parameters having descriptions. The 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Get Tiktok profile' which clearly indicates the action and resource. However, it does not distinguish from the sibling 'ghl_social_get_tiktok_business_profile', which likely fetches a different type of profile. The name and description are clear but lack 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 like 'ghl_social_get_tiktok_business_profile'. There are no prerequisites, context, or when-not-to-use instructions.

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

• ghl_social_set_google_locationsC
  2.8/5.0
  Behavior2/5

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

  Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds no behavioral traits beyond the endpoint. It does not disclose side effects (e.g., whether existing locations are overwritten) or authorization requirements.

  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 very concise but poorly structured for an agent. The endpoint detail is secondary and not front-loaded. It lacks a clear separation of purpose from technical details, and every sentence is not equally valuable for tool selection.

  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 a complex nested body (account, location, companyId) with no output schema. The description fails to explain the effect of setting locations, the structure of the body fields, or the expected response. Relies entirely on schema, which is insufficient.

  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 basic descriptions for parameters (e.g., 'Account Id', 'Company ID'). The description adds no extra meaning to the parameters, repeating only the endpoint. Baseline 3 is appropriate as the schema already documents the 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 states 'Set google business locations' with an endpoint hint, clearly indicating the resource (Google business locations) and action (set). However, 'set' is ambiguous (create/update/overwrite) and does not explicitly distinguish from the sibling 'ghl_social_get_google_locations' tool.

  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 lacks context for when 'set' is appropriate compared to other social media tools, nor does it mention prerequisites or exclusions.

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

• ghl_store_update_shipping_rateC
  2.8/5.0
  Behavior2/5

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

  Annotations indicate idempotent and not destructive, but the description adds no behavioral context beyond 'update'. It does not describe what happens to fields not included, error cases, or that the operation returns the updated rate or success confirmation. For a mutation tool with no output schema, more detail is expected.

  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 brief (2 sentences) but contains a grammatical error ('allows update a shipping rate'). Including the full endpoint path is unnecessary clutter for an AI agent. It could be more polished and front-loaded with essential info.

  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?

  Without an output schema, the description should at least mention what the tool returns after a successful update. It also lacks explanation of the nested body properties' purpose as a group. The description is too minimal to give a complete understanding of tool behavior and usage.

  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 schema already documents all parameters. The description repeats the endpoint but does not add meaning to the parameters themselves (e.g., explaining which fields are commonly updated together or constraints). Thus, it provides no additional value beyond 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?

  The description clearly states that the tool updates a shipping rate, using the verb 'update' and the resource 'shipping rate'. The endpoint path in the description explicitly includes the required IDs, confirming the resource. While it doesn't explicitly contrast with create/get/delete siblings, the name and endpoint pattern make the differentiation obvious.

  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 list prerequisites, mention that shipping zone and rate must exist, or explain that this is for modifying an existing rate rather than creating a new one. No exclusions or conditions are given.

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

• ghl_association_get_by_key_nameC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the HTTP method (GET) and OAuth scopes, but doesn't reveal additional behavioral traits like response structure or pagination. Does not contradict annotations.

  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 includes a note about renaming and endpoint details, which adds context but could be more concise. It's not excessively long, but the renaming note is extraneous for usage. Front-loaded with the primary 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 (2 params, no output schema) and the read-only nature, the description is minimally adequate. However, it lacks guidance on return format and does not explain the locationId parameter. With many sibling tools, more context on when to use this over others would improve completeness.

  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 2 required parameters (key_name, locationId) with 0% description coverage. The description only implies the purpose of key_name but does not explain locationId or provide any additional meaning beyond the schema. With only 2 params and no enums, the description should at least clarify the role of each 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 clearly states the tool retrieves an association key by its key name, distinguishing it from sibling tools like ghl_association_get_by_id and ghl_association_get_by_object_key. The verb 'Get' and resource 'association key' are specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives. The description lacks context for selecting this tool over other association retrieval methods, such as by ID or object key. The OAuth scopes are mentioned but not as a usage discriminator.

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

• ghl_blog_site_listC
  2.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, destructiveHint, etc. The description adds value by specifying the endpoint, required OAuth scopes, and pagination parameters (skip, limit) for full result retrieval. This provides behavioral context beyond the annotations.

  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 relatively short but includes extraneous technical details like the exact endpoint path with version header and source file path. This adds clutter without aiding an AI agent. It is front-loaded with the title, which is helpful, but could be more concise.

  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 covers purpose, pagination, and OAuth scopes but omits the response structure, error handling, or the effect of the optional searchTerm parameter. Given the tool has 4 parameters and no output schema, the description provides adequate but not comprehensive 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?

  Schema description coverage is only 25% (only searchTerm described). The description adds minimal parameter insight: it mentions 'Pagination params: skip, limit — pass them to page through full result sets' and implicitly references locationId in the title. The description does not explain locationId or searchTerm beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Get Blogs by Location ID' and the tool name includes 'site_list', but it doesn't explicitly differentiate from the sibling tool 'ghl_blog_post_list'. The endpoint '/blogs/site/all' suggests it lists blog sites, but the description uses 'blogs' ambiguously. An agent might confuse it with listing blog 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 like 'ghl_blog_post_list'. The description focuses on API details rather than use case differentiation. An agent receives no help in choosing between listing blog sites vs. blog posts.

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

• ghl_brand_board_create_voiceC
  2.9/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false, consistent with a create operation. The description does not add behavioral details beyond what annotations already provide (e.g., it doesn't mention authentication, rate limits, or side effects like overwriting existing voice). No contradiction with annotations. The endpoint info is present but not behavioral.

  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 short (two lines) but includes unnecessary endpoint detail that may not be helpful for an AI agent. It could be more concise by omitting the endpoint and version info, which are already implied by the schema and annotations. Front-loads the purpose, which is good.

  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 complex nested body object and three creation types (manual, url, description), the description lacks guidance on how to choose between them or what the response contains. No output schema is provided, so the agent is left uninformed about return values. The description is insufficient for a complete understanding.

  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% via the input schema, where each parameter (locationId, body and its inner properties) has clear descriptions and examples. The tool description adds no further semantic value; it only restates the endpoint. Baseline 3 is appropriate since 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 clearly states 'Create a brand voice for a location,' specifying the verb (create) and resource (brand voice). It distinguishes from siblings like ghl_brand_board_create (which likely creates a brand board) by mentioning 'voice' explicitly. However, the title is null and the description redundantly repeats 'Create Brand Voice.'

  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_brand_board_update_voice or ghl_brand_board_delete_voice. The description does not mention prerequisites, when not to use it, or alternative approaches. The context signals and sibling list show many related brand board tools, but no differentiation is provided.

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

• ghl_brand_board_update_voiceC
  2.9/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false, destructiveHint=false, etc. The description adds 'Update' but does not disclose whether updates are partial or full replacement, what side effects occur, or any specific behavioral traits beyond the annotations. Minimal extra value.

  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 very short (two lines) and front-loaded with the action. No wasted words, but it could benefit from more structure (e.g., sentence about usage).

  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 defined, and description does not mention return value or error handling. Given the relatively simple operation, some context on what is returned (e.g., updated brand voice object) 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 coverage is 100% with descriptions for all parameters. The description adds no additional semantics beyond what the schema provides (e.g., for 'body' it just repeats the schema verbatim). Baseline 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 'Update Brand Voice' and 'Update a brand voice by ID', which specifies the action and resource. It also provides the endpoint. It is distinct from sibling tools like create_voice and delete_voice, but could be more explicit about what exact fields are updated.

  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 vs alternatives (e.g., create_voice for new voices, delete_voice for removal). No prerequisites or context provided. The agent must infer usage from the tool name alone.

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

• ghl_business_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering basic behavioral traits. The description adds endpoint details and OAuth scopes. However, it does not disclose whether the update is partial or full replacement, which is expected for a PUT endpoint. No contradiction with annotations.

  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?

  Three lines conveying purpose, endpoint, source, and scopes. It is efficient and front-loaded. Could include brief usage context without becoming verbose, but as is, it is 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?

  Given the existence of sibling create/delete/get tools and no output schema, the description lacks completeness. It does not clarify whether the PUT operation replaces the entire business or allows partial updates. No guidance on required body fields (the schema says body is required but no subfield required). This is a significant gap for a mutation 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 50%—only the body parameter has a generic description ('Request body carried verbatim from the official OpenAPI spec'). businessId has no description. The tool description does not add any parameter semantics. Property names and examples in schema provide some meaning, but the lack of descriptions for key parameters (especially businessId) leaves the agent guessing.

  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 'Update Business', which is a specific verb+resource combination. It also includes the endpoint and OAuth scopes, adding clarity. However, it does not differentiate from sibling tools like ghl_business_create or ghl_business_delete, but the action verb is sufficiently distinct.

  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. The description does not mention prerequisites, when not to use it, or how it compares to create/delete/get. The agent must infer from the name alone, which is insufficient for proper tool selection.

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

• ghl_calendar_createC
  2.9/5.0
  Behavior2/5

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

  The description adds only the endpoint and OAuth scopes beyond the annotations. Annotations already indicate it is a write operation (readOnlyHint false) and not destructive (destructiveHint false). No information is provided about side effects, error conditions, or whether the creation is immediate or async.

  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 very concise (three lines) with clear line breaks. However, it includes technical details (endpoint, version header, source) that could be deemphasized or moved to a separate section. It is efficient but could be slightly more structured for readability.

  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 (many parameters, nested objects, deprecated fields) and lack of output schema, the description is incomplete. It does not mention important caveats (e.g., deprecated fields like openHours and availabilities that recommend using Availability APIs) or provide guidance on how to effectively use the 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 input schema has 100% description coverage, so the schema itself documents all parameters. The description adds no parameter-specific information. Baseline 3 is appropriate since the schema carries the burden.

  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 'Create calendar in a location', which is a specific verb and resource. It distinguishes the tool from sibling tools (e.g., ghl_calendar_group_create) as it is the only direct calendar creation tool. However, it does not elaborate on the type of calendar or its specific use case, so it is not a perfect 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 (e.g., ghl_calendar_group_create for groups, or ghl_calendar_update for modifications). The description lacks any context about prerequisites, post-conditions, or exclusions.

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

• ghl_calendar_event_listC
  2.9/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, idempotentHint, openWorldHint. The description adds the endpoint and OAuth scopes, but does not elaborate on behavioral aspects like pagination, ordering, or error handling. With annotations covering the core safety profile, a score of 3 is appropriate.

  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 concise (three lines) and front-loaded with the purpose. However, it lacks important usage details that could be included concisely, making it under-informative. It earns its space but could be improved.

  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 and no output schema, the description is incomplete. It does not explain the response format, pagination, or what fields are returned. Annotations exist but the description should compensate for the missing output schema. It fails to provide sufficient context 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%, so the schema already describes all parameters. The tool description adds no additional meaning beyond the schema. Baseline 3 is correct.

  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 'Get Calendar Events', which combined with the title in annotations, indicates listing calendar events. It is distinct from sibling tools like calendar_list or event_schedule_create, but does not explicitly differentiate. The endpoint and OAuth scopes reinforce the 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?

  No usage guidelines are provided. The description does not mention when to use this tool over alternatives, prerequisites (e.g., need a locationId), or any context for selecting this tool among calendar-related siblings.

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

• ghl_calendar_notification_listC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context like OAuth scopes, endpoint, and pagination, but does not discuss rate limits or other traits. It is consistent with annotations.

  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 concise with no unnecessary words. It front-loads the purpose and includes essential details (endpoint, scope, pagination). Could be slightly better structured (e.g., grouping param info), but overall efficient.

  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 lacks details about the response format, what constitutes a 'notification', and how the boolean filters (`deleted`, `isActive`) work. With no output schema, more context on return values is needed. The tool has 5 parameters and no output schema, so the description should provide more 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 description coverage is only 40% (2 of 5 params documented). The description adds pagination guidance for `limit` and `skip` but leaves `deleted`, `isActive`, and `calendarId` unexplained. Description partially compensates but not sufficiently for the low 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 it returns calendar notifications based on a query, with the endpoint and pagination details. The purpose is clear, though it doesn't explicitly distinguish from the sibling `ghl_calendar_notification_get` which would retrieve a single notification.

  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 mentions pagination for full result sets but does not provide guidance on when to use this tool versus alternatives like `ghl_calendar_notification_get`. No when-not-to-use or prerequisite information is given.

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

• ghl_calendar_resource_createC
  2.9/5.0
  Behavior3/5

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

  The description adds value beyond annotations by specifying OAuth scopes (calendars/resources.write) and the API version (2021-04-15). However, it does not disclose other behavioral traits such as idempotency (already false in annotations), side effects, error handling, or what happens on duplicate resource creation. The deprecation note adds behavioral context but lacks specificity about the replacement.

  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 longer than necessary, containing redundant statements (e.g., 'Create Calendar Resource' repeated), excessive version details, and a deprecation warning that could be more succinct. The information is not front-loaded efficiently; the core purpose and endpoint come after background notes.

  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 no output schema and sparse annotations, the description lacks completeness. It does not explain the return value, error conditions, prerequisites (e.g., valid locationId), or how to handle failures. The schema covers field requirements, but the description fails to provide operational 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 has 100% description coverage, with descriptions for both parameters (resourceType and body). The tool description does not add any additional parameter-level information beyond what is already in the schema. Per guidelines, baseline is 3 when coverage is high, so no deduction.

  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 explicitly states 'Create Calendar Resource' and 'Create calendar resource by resource type (Services V1)', clearly identifying the verb (create) and resource (calendar resource). The endpoint is provided, adding context. However, the description is cluttered with version and deprecation warnings that can distract from the primary 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 warns against using the v3 version and states the tool is deprecated, but does not specify when to use this tool vs alternatives. No alternative tool name is given, and there is no guidance on the context or prerequisites for using this tool. The deprecation note itself is vague and does not direct the user to a replacement.

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

• ghl_calendar_service_booking_createC
  2.9/5.0
  Behavior2/5

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

  The description adds minimal behavioral context beyond annotations. It does not explain idempotency, side effects, or the meaning of the openWorldHint. Annotations already indicate non-read-only and non-destructive, but the description repeats little.

  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 concise with four lines covering purpose, endpoint, and OAuth scopes. It is well-structured but could be slightly improved by front-loading the most critical usage 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?

  Given the tool's complexity (nested objects, no output schema), the description is insufficient. It lacks information about return values, error conditions, and behavior of optional flags like overrideAvailability.

  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 comprehensive descriptions for all parameters (100% coverage). The description adds no additional parameter insight, 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 'Create Service Booking' and 'Create a new service booking', along with the endpoint and OAuth scopes. It identifies the resource and action, distinguishing it from other calendar tools like appointment creation, though not explicitly.

  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 (e.g., ghl_calendar_appointment_create). There are no prerequisites, exclusions, or context for when it is appropriate to create a service booking.

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

• ghl_calendar_service_location_listC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds endpoint and OAuth scopes but does not disclose expected response format or pagination behavior. Given robust annotations, this is adequate but not enhanced.

  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 short but includes repetitive text ('Get Service Locations' and 'Get all service locations') and technical endpoint details that may not be needed for decision-making. It is concise but not optimally 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?

  With no output schema, the description fails to mention that the tool returns a list of service location objects. It does not explain the role of `locationId` or any pagination. For a simple list tool, it provides minimal 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 the `locationId` parameter described as 'Location ID'. The description adds no additional meaning, such as clarifying it is the parent location ID. Baseline 3 is appropriate per rubric when schema coverage is high, but a small missed opportunity.

  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 states 'Get Service Locations' and 'Get all service locations', clearly indicating a list operation. It implicitly distinguishes from sibling `ghl_calendar_service_location_get` which retrieves a single item. However, the phrase 'all service locations' is ambiguous because the required `locationId` parameter suggests scoping to a parent 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?

  The description provides no guidance on when to use this tool versus alternatives (e.g., get, create, update, delete). It does not explain that this tool lists service locations for a given parent location ID, nor when not to use it. The endpoint and OAuth scopes are technical details but not usage guidance.

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

• ghl_chat_widget_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations already convey non-destructive, non-read-only, and idempotent behavior. The description adds OAuth scopes and endpoint details, but the phrase 'Full update' is ambiguous—it does not clarify whether all fields must be provided or if missing fields will be reset. No contradictions with annotations.

  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 short (3 lines) but includes technical details (endpoint, version header, source file) that are likely irrelevant for an AI agent. Could be more focused on usage intent, though the OAuth scope is useful.

  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 complex nested input schema, the description is insufficient. It does not explain what a chat widget is, how the full update behaves (e.g., partial vs complete replacement), or any constraints. Annotations partially compensate but the overall context is lacking.

  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 adds no additional meaning beyond the schema; baseline 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?

  Clearly states 'Update Chat Widget' and 'Full update of a chat widget resource', establishing the verb and resource. However, it does not differentiate from the sibling tool `ghl_chat_widget_patch`, which could cause confusion about which to use for partial updates.

  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_chat_widget_create` or `ghl_chat_widget_patch`. No exclusions, prerequisites, or context for selection are given.

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

• ghl_contact_add_followersC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the OAuth scopes (contacts.write) and endpoint, but does not explain behavioral specifics such as whether followers are appended or replaced, handling of duplicates, or what the response returns. Given annotations cover safety, the description provides marginal added value.

  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 brief and to the point, containing only the operation name and endpoint technical details. It is not overly verbose, but the brevity sacrifices conceptual completeness. Conciseness is acceptable but could be improved by adding key usage context in a structured way.

  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 the tool is simple (2 parameters, no output schema) but has a direct sibling (ghl_contact_remove_followers) and annotations are present, the description lacks critical context: when to use over sibling, the effect on existing followers, return structure, and prerequisites. This makes it incomplete for an agent to confidently invoke.

  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 100% of parameters with descriptions: contactId described as 'Contact Id' and followers as 'List of user Ids to follow or unfollow the contact'. The description does not add further semantic meaning beyond what is already in 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Add Followers') and specifies the resource (contacts) via the endpoint. The name distinguishes from siblings like ghl_contact_remove_followers and ghl_opportunity_add_followers, though the description does not explicitly differentiate them. Still, the 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 (e.g., when to add vs. remove followers, or prerequisites like contact existence). The description includes only the endpoint and OAuth scopes, which are technical details, not usage context.

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

• ghl_contact_add_to_workflowC
  2.9/5.0
  Behavior2/5

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

  Annotations indicate it's a mutation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds no extra behavioral details, such as side effects (e.g., triggering automations) or error conditions (e.g., if contact already in workflow).

  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 concise (two sentences) and includes essential technical details like the endpoint and OAuth scopes. It is front-loaded and easy to scan, though it could be slightly more 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?

  There is no output schema, but the description does not explain return values or expected outcomes. It also does not clarify the optional eventStartTime parameter or any post-conditions of the operation. For a mutation tool, more context is needed.

  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 parameter descriptions and examples. The description adds no additional meaning beyond the schema, but since the schema already fully documents parameters, 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 action 'Add Contact to Workflow' and provides the endpoint. The purpose is specific enough to distinguish it from similar tools like ghl_contact_add_to_campaign or ghl_contact_add_tags, as the resource is different. However, it doesn't elaborate on what a workflow is or the exact operation performed.

  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 (e.g., when to add vs. remove from workflow, or prerequisites like contact/workflow existence). The description only provides the endpoint and OAuth scopes, not usage context.

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

• ghl_contact_delete_taskC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds endpoint details and OAuth scopes, which are useful but do not significantly expand behavioral transparency. No contradictions with annotations.

  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 very concise, using a single line for the purpose and one additional line for technical details. It is front-loaded but may be too brief.

  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 simple nature of a delete operation, the description is adequate but lacks information about the permanence of the deletion or the response format. Annotations cover destructive and idempotent aspects, so no major gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the description does not add any meaning beyond what the schema already provides (e.g., 'Task Id', 'Contact Id'). Baseline score for high coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states "Delete Task," which specifies the verb and resource, but it is vague. It does not clarify that the task belongs to a contact, though the tool name and endpoint imply it. It distinguishes from sibling tools like ghl_contact_delete but lacks explicit 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 on when to use this tool vs. alternatives such as ghl_contact_update_task or ghl_contact_get_task. The description provides no when-to-use or when-not-to-use context.

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

• ghl_contact_remove_tagsC
  2.9/5.0
  Behavior2/5

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

  Description only provides technical details (endpoint, OAuth scopes) and does not explain the behavioral effect of removing tags, such as whether tags are permanently deleted or if validation occurs. Annotations indicate destructive behavior, but the description adds no additional transparency.

  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 very short but includes some technical details that are not essential for understanding the tool's purpose. It could be more concise by removing endpoint/OAuth information, which may be better in annotations.

  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 (remove tags from a contact) and high schema coverage, the description is minimally adequate. However, more context about the operation's effect and error conditions 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 coverage is 100%, so the schema already describes parameters adequately. The description does not add extra meaning beyond what is in 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?

  The description states 'Remove Tags' which clearly indicates the action and resource. The tool name further clarifies it removes tags from a contact. However, the description could explicitly mention 'from a contact' for even clearer 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?

  No guidance on when to use this tool versus alternatives like ghl_contact_add_tags or ghl_contact_bulk_update_tags. No prerequisites or context provided.

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

• ghl_conversation_add_inbound_messageC
  2.9/5.0
  Behavior2/5

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

  The description indicates a mutation operation (adding a message) but does not disclose any behavioral traits beyond that. Annotations are minimal (non-destructive, non-idempotent), and no additional context is provided about side effects, prerequisites, or data handling. The direction field default in the schema may cause confusion.

  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 concise with two key sentences plus endpoint and scopes. It is front-loaded with the primary purpose. Minor HTML formatting (<br />) is unnecessary but does not detract significantly.

  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 complex nested schema and no output schema, the description does not explain the return value, required conditions (e.g., existing conversation/contact), or how nested objects interact. It leaves the agent with insufficient context to use the tool 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?

  Input schema has 100% description coverage, so each property is documented. The description adds no additional parameter meaning beyond what the schema provides, meeting the baseline expectation.

  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 'Add an inbound message' and provides the endpoint and OAuth scopes. It identifies the specific resource (inbound message) and action (add), but does not explicitly distinguish from the sibling tool ghl_conversation_add_outbound_message, though the name implies the difference.

  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 lacks guidance on when to use this tool versus alternatives like ghl_conversation_add_outbound_message or ghl_conversation_send_message. It only provides technical details (endpoint, scopes) without usage context.

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

• ghl_conversation_ai_create_agentC
  2.9/5.0
  Behavior3/5

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

  Annotations provide basic non-readOnly, non-idempotent, non-destructive hints. The description adds endpoint and OAuth scopes but lacks details on potential side effects, rate limits, or what happens on conflict (openWorldHint=true is ambiguous). 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise but includes redundant title line and technical details (endpoint, OAuth) that could be placed elsewhere. It is front-loaded but lacks structure for quick comprehension.

  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 complex nested body with 20+ properties, the description provides no high-level guidance on constructing the request or typical configurations. No output schema is provided, leaving the agent unsure of the response format.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions and examples, so the description adds minimal value beyond listing 'name, role, actions, behavior settings'. There is a mismatch: 'role' is not in the schema. The description does not compensate for schema 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 clearly states that the tool creates a new AI agent for a location, distinguishing it from update/delete siblings. The title 'Create an Agent' matches the action. However, the description mentions 'role, actions' which are not in the schema, causing slight confusion.

  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 (e.g., updating an existing agent). No prerequisites or context about when creation is appropriate. The agent must be for a specific location, but this is not emphasized.

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

• ghl_conversation_createC
  2.9/5.0
  Behavior2/5

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

  The description adds the endpoint and OAuth scopes but fails to disclose behavioral details beyond what annotations imply (readOnlyHint=false indicates mutation). It does not mention side effects, error handling, or required preconditions like whether the contactId must already exist. The annotations provide no additional transparency, so the description carries the burden but does not fulfill it.

  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 brief and front-loaded with the action 'Creates a new conversation', followed by relevant endpoint and scopes. It contains no unnecessary information, making it efficient. However, it could be more structured by separating the purpose from technical details.

  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 parameter and no output schema, the description lacks completeness. It does not explain the response format, error conditions, or necessary preconditions. Compared to the calibration mid example, this description is insufficient for an agent to reliably invoke the 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 has 100% coverage with descriptions for contactId and locationId (both as strings). The description only notes the body is from the OpenAPI spec, adding no extra meaning. Since schema coverage is high, the baseline is 3; the description does not improve parameter understanding.

  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 creates a new conversation, with the verb 'creates' and resource 'conversation' explicitly mentioned. It also provides the endpoint and required OAuth scopes, which adds specificity. However, it does not explain what constitutes a conversation in this context, leaving some ambiguity compared to sibling tools like ghl_conversation_add_inbound_message.

  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 such as ghl_conversation_add_inbound_message or ghl_conversation_send_message. There is no mention of prerequisites, context, or scenarios where creating a conversation is appropriate versus adding to an existing one, leaving the agent to infer usage from the name alone.

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

• ghl_course_importC
  2.9/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false (mutates), openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds no behavioral context beyond stating the tool imports courses, failing to disclose what happens on import (e.g., duplicate handling, validation, side effects). Since annotations already provide some info, the bar is lower, but the description contributes little.

  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 short and includes the endpoint, which is helpful for debugging. However, it redundantly repeats 'Import Courses' and is somewhat unstructured. Overall, it is mostly 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 complex nested schema and lack of output schema, the description is insufficient. It does not explain what happens after import, error handling, or response format, leaving the agent without enough context to use the tool 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 coverage is 100%, so the schema fully describes the required 'body' parameter with nested objects. The description adds no additional meaning to parameters, repeating only the tool's purpose. Baseline is 3 due to high 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 'Import Courses through public channels' and provides the endpoint. It specifies the verb (Import) and resource (Courses), making the purpose clear. However, the phrase 'public channels' is vague and the description is slightly redundant by repeating 'Import Courses'.

  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 how it differs from alternatives. The description gives no context for usage beyond the basic action, leaving the agent without direction on when to invoke it.

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

• ghl_estimate_sendC
  2.9/5.0
  Behavior2/5

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

  Annotations (readOnlyHint=false) indicate mutation, but the description adds no behavioral context beyond the endpoint. It does not disclose potential side effects (e.g., triggering notifications) or state changes, which are critical for a sending 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 very short and includes technical details (endpoint, scopes) but is efficient. However, it could better structure information for agent consumption without losing 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 complexity (nested body, enums, no output schema), the description is incomplete. It does not explain the purpose of the body fields, required action, or output, leaving significant gaps for correct 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?

  Schema coverage is 100%, so the schema already documents parameters. The description adds no additional meaning beyond the schema, meeting the baseline requirement but offering no extra value.

  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 states 'Send Estimate' and 'API to send estimate by estimate id', clearly indicating the action and resource. This distinguishes it from sibling tools like ghl_estimate_create or ghl_estimate_update, though it lacks specifics on what 'send' entails.

  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 (e.g., ghl_estimate_create, ghl_estimate_update). The description does not mention prerequisites or context, leaving the agent uninformed about appropriate usage scenarios.

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

• ghl_form_upload_custom_filesC
  2.9/5.0
  Behavior4/5

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

  The description explicitly discloses a critical behavioral trait: the tool currently cannot accept file bytes due to a missing request body schema. This goes beyond annotations, which only indicate readOnlyHint=false and openWorldHint=true. The limitation is honestly stated, giving the agent a clear understanding of the tool's current capability.

  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 poorly structured, starting with a lengthy technical note about a registry limitation that dominates the space. The actual upload instructions are brief but buried. While the technical note may be contextually important, it harms conciseness and discoverability. The description could be trimmed to focus on usage.

  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 (multipart upload, custom fields, no output schema), the description omits important context: what the API returns on success/failure, how to handle errors, and whether the tool works at all (contradictory exception note). The coverage is incomplete for an agent to use this tool effectively, especially missing response format.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with descriptions for all three parameters. The description adds significant value by explaining the required key format for file fields ('<custom_field_id>_<file_id>'), allowed MIME types, size limit, and support for multiple files. While the body parameter's description in the schema already hints at multipart uploads, the description provides concrete, actionable details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Upload files to custom fields' and explains the key format, which clarifies the intended operation. However, the prominent technical note declaring the tool non-functional ('no way to attach file bytes') directly contradicts the purpose and may confuse an agent evaluating whether to use it. The purpose is clear in principle but undermined by the exception 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?

  The description provides formatting details (key format, allowed types, size) but offers no guidance on when to use this tool versus alternatives. No comparison with sibling tools like ghl_location_upload_file_custom_fields is made. The agent is left to infer usage context from the tool name alone.

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

• ghl_funnel_get_pages_by_idC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds the endpoint URI and pagination behavior (limit, offset for full result sets), which provides some behavioral context beyond annotations. However, it does not mention any other behaviors such as rate limits, authentication, or potential errors.

  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 concise with three sentences, front-loading the main purpose. It efficiently communicates the action, endpoint, and pagination note without wasted words. However, it could be slightly improved by integrating the parameter explanation more seamlessly.

  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 an output schema and only 0% parameter coverage, the description is incomplete. It does not describe the return values (e.g., structure of a funnel page) or provide enough detail for an agent to use the tool effectively, especially for the 4 required parameters. Annotations only cover safety, not functional completeness.

  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 coverage is 0%, placing the burden on the description to explain parameters. The description only mentions pagination params (limit, offset) in passing, but fails to explain the purpose of funnelId, locationId, and name. The agent cannot infer what these parameters represent without additional context.

  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 'Fetch list of funnel pages' and 'Retrieves a list of all funnel pages based on the given query parameters.' It also names the HTTP endpoint and indicates pagination. However, it does not explicitly differentiate from the sibling 'ghl_funnel_get_pages_count_by_id' which retrieves a count, so it leaves some ambiguity about when to use each.

  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 versus alternatives like the count tool or other funnel tools. It mentions pagination usage but fails to give explicit context on selection or exclusion of sibling tools, making it harder for an agent to decide.

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

• ghl_invoice_schedule_set_auto_paymentC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint false, so the mutation nature is clear. The description adds the OAuth scope requirement (invoices/schedule.write) and endpoint information, which are behavioral constraints. However, it does not disclose side effects (e.g., whether settings are overwritten or merged) or confirm the behavior of the 'enable' field.

  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 short (4 lines) but contains redundancy: the first two lines essentially repeat 'Manage Auto payment for an schedule invoice'. The endpoint and scope info are useful though. It is front-loaded with the purpose, but conciseness could be improved by removing the duplicate sentence.

  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 complex nested body parameter and no output schema, the description does not explain what the tool returns (e.g., success indicator, updated configuration). It also omits any example usage or clarification on how to enable vs disable auto payment. For a tool with no output schema and nested objects, this is 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 100%—every parameter in the input schema has a description. The tool description adds no additional parameter meaning beyond what the schema provides. According to guidelines, baseline is 3 for high coverage, so this score 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 it manages auto payment for a schedule invoice, which aligns with the tool name 'set_auto_payment'. It specifies the resource (auto payment) and action (manage), but 'manage' is slightly vague; an explicit verb like 'enable/disable' would be stronger. It is distinct from sibling invoice schedule tools (e.g., create, update) due to the focus on auto 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 like ghl_invoice_schedule_update or ghl_invoice_schedule_create. There is no mention of prerequisites (e.g., the schedule must exist) or exclusions. The description merely describes the tool 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.

• ghl_invoice_template_createC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds no additional behavioral traits such as side effects, state changes, or response behavior. It does not contradict annotations but offers no value beyond them.

  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 with only three lines: name, endpoint, and scopes. It is not verbose and front-loads key information. However, it could be more informative without adding much length, but it earns points 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 complexity of the tool (nested parameters, no output schema), the description is insufficient. It lacks context about the purpose of an invoice template, required fields like altId/altType, and what the response looks like. The detailed schema partially compensates, but overall context is missing.

  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 parameters with detailed descriptions and examples. The single 'body' parameter is documented thoroughly within the schema. The description adds no further meaning, meeting the baseline for high 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 'Create template' alongside the tool name 'ghl_invoice_template_create' makes it clear the tool creates an invoice template. The verb 'Create' and resource 'template' are directly stated, and the sibling tools like 'ghl_invoice_template_update' further differentiate it. However, the description is minimal and does not elaborate beyond the name itself.

  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 (e.g., update, list). It only includes endpoint and OAuth scopes, but no context about prerequisites, limitations, or scenarios where creation is appropriate. Agents lack help in deciding if this is the right tool.

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

• ghl_invoice_text2payC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds that the tool can 'create or update', which aligns with annotations but adds little new context. No contradiction, but the description fails to disclose behavioral traits like side effects or authorization details beyond scopes.

  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 very concise (two lines) and to the point, including endpoint info and OAuth scopes. Every sentence serves a purpose, though it could be expanded slightly with usage guidance without becoming verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (many nested parameters, no output schema), the description is too brief. It omits return values, error handling, and important context about when to use this specific text2pay variant over other invoice 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?

  Schema description coverage is 100%, so the input schema fully documents all parameters. The description does not add any additional meaning beyond what the schema provides, earning a baseline of 3.

  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 'API to create or update a text2pay invoice', specifying the action (create/update) and resource (text2pay invoice). It also provides the endpoint. However, it does not distinguish this tool from sibling invoice creation tools like ghl_invoice_create, which reduces clarity for selection.

  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 (e.g., ghl_invoice_create, ghl_invoice_schedule_create). The description only mentions OAuth scopes but does not explain context or prerequisites.

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

• ghl_invoice_update_late_fees_configurationC
  2.9/5.0
  Behavior2/5

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

  Annotations indicate non-read-only and non-destructive, but the description adds no behavioral details (e.g., authorization requirements, side effects, rate limits). Only the endpoint and version header are mentioned.

  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?

  Two sentences plus endpoint info; concise and no fluff. Could be slightly improved by structuring usage before endpoint details.

  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 complex nested schema and missing output schema, the description lacks explanation of return values or potential side effects. It is minimally complete for an experienced user but insufficient for full 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 detailed descriptions in the input schema, so the description does not need to add parameter meaning. It provides no additional param context beyond 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?

  The description clearly states the tool updates invoice late fees configuration and specifies the endpoint. It distinguishes from sibling tools like ghl_invoice_update (updates invoice fields) and ghl_invoice_template_update_late_fees_configuration (updates template config).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool vs alternatives such as invoice update or template configuration update. No prerequisites or context provided.

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

• ghl_kb_crawler_discoverC
  2.9/5.0
  Behavior2/5

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

  The description adds the endpoint URL but does not disclose behavioral traits such as whether crawling is asynchronous, how long it takes, or any side effects. Annotations (readOnlyHint=false, destructiveHint=false) are not contradicted, but the description adds minimal 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise with two sentences, but the first sentence is slightly redundant ('Start crawling and discover pages for training'). It is front-loaded and to the point, with minimal waste.

  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 does not explain what the tool returns (e.g., a crawl job ID, status). It also lacks information about error handling, rate limits, or post-call behavior. For an action that initiates a process, this is 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?

  The input schema has 100% coverage with descriptions for all parameters (locationId, url, option, knowledgeBaseId). The description does not add any additional meaning beyond what the schema already provides, so 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 starts crawling and discovers pages for training, aligning with its name. It is distinct from siblings like ghl_kb_crawler_list_urls or ghl_kb_crawler_train, but does not explicitly differentiate the scope or purpose from them.

  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 (e.g., ghl_kb_crawler_train or ghl_kb_crawler_status). It lacks when-not-to-use or prerequisite information.

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

• ghl_kb_crawler_trainC
  2.9/5.0
  Behavior2/5

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

  Annotations cover safety aspects (not read-only, not destructive), but the description adds no behavioral context beyond the basic action. It does not disclose whether the operation is asynchronous, how long it might take, or what happens to existing data. For a training/ingestion tool, 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with minimal waste. The purpose is front-loaded. The endpoint detail is useful but could be placed in a separate field. Still efficient and easy to parse.

  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 lacks information about return values, error handling, or post-conditions. Given it is a training tool with nested parameters and no output schema, more context is needed to understand what happens after ingestion. The openWorldHint annotation does not compensate for this gap.

  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 schema already documents all parameters with descriptions and examples. The description adds no additional meaning to the parameters. Baseline of 3 is appropriate as the schema carries the load.

  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 (train and ingest) and the resource (discovered website pages into knowledge base). It distinguishes from sibling tools like ghl_kb_crawler_discover by specifying 'train discovered pages' rather than discover. However, it does not explain what 'train' entails, slightly limiting 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 is provided on when to use this tool versus alternatives. The description implies it should be used after discovery (by mentioning 'discovered website pages'), but there is no explicit when/when-not or reference to sibling tools like ghl_kb_crawler_discover or ghl_kb_crawler_list_urls.

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

• ghl_kb_update_knowledge_baseC
  2.9/5.0
  Behavior2/5

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

  Annotations already convey idempotency and non-destructiveness. The description adds no behavioral insights beyond the endpoint details, which are technical rather than behavioral. No mention of side effects, permissions, or constraints.

  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 very short (one sentence plus endpoint line). It is concise but the endpoint information may be unnecessary for an AI agent. 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?

  Given the tool has nested parameters and no output schema, the description omits important context like that the knowledge base must exist, or that updates are partial. It is incomplete for an agent to use correctly without additional knowledge.

  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 50%; the description does not explain the 'id' parameter or add meaning beyond the schema. The body field has a generic description, but the tool description adds no value for parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action 'Update' and the resource 'knowledge base', distinguishing it from sibling tools like create, delete, and get. The title also reinforces 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 on when to use this tool versus alternatives such as creating or listing. No prerequisites or when-not-to-use information is provided.

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

• ghl_location_delete_custom_fieldC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds only the endpoint details, not additional behavioral context such as irreversibility or required permissions. It does not contradict annotations, but adds minimal value.

  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 short but includes technical endpoint information that may not be essential for tool selection. It is concise but could be improved by focusing on purpose and 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?

  For a simple delete operation with full schema coverage and clear annotations, the description is adequate but fails to distinguish from a similarly named sibling tool, leaving a gap in 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 coverage is 100%, and both parameters have descriptions in the schema. The description does not add new meaning beyond what the schema provides, meeting baseline expectations.

  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 states 'Delete Custom Field' with the endpoint, clearly indicating the action and resource. However, it does not differentiate from sibling 'ghl_custom_field_delete', which appears to have similar functionality.

  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_custom_field_delete. There is no context for usage or exclusion criteria.

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

• ghl_location_delete_custom_valueC
  2.9/5.0
  Behavior2/5

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

  Annotations already mark the tool as destructive. The description redundantly states 'Delete' but adds no behavioral context beyond the endpoint. No mention of recovery options, permissions, 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very short and front-loaded with the purpose. It could be improved with clearer structure, but it earns a high score 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?

  For a destructive operation, the description omits important context like the irreversibility of deletion, potential impacts on other resources, and required permissions. The endpoint version info is technical but not contextually 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 adequate descriptions for both parameters. The description adds no further meaning, so baseline 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 tool name and title clearly indicate deletion of a custom value, and the description repeats this. However, it lacks any explanation of what a custom value represents, relying solely on the 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 vs. creating, updating, or getting custom values. Prerequisites or effects (e.g., dependent data) are not mentioned.

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

• ghl_media_update_fileC
  2.9/5.0
  Behavior2/5

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

  The description only says 'Updates', which implies mutation but does not disclose behavioral details such as whether the update is partial or full replacement, what happens on error, or required permissions. Annotations are minimal (readOnlyHint: false, etc.) and provide no additional context.

  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 very short (3 lines) and front-loaded with the core action. The endpoint line may be unnecessary for an AI agent, but overall it is efficient with 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?

  Given that there is no output schema and the tool is an update operation, the description is incomplete. It does not mention the response format, whether the update is idempotent, or how the body requirements affect usage (e.g., all fields required suggests full update).

  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 extra meaning beyond the parameter names and schema; it does not explain the purpose of altType or altId, or provide examples of usage.

  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 'Updates a single file or folder by ID', specifying the verb (update), resource (file or folder), and scope (single, by ID). It distinguishes from sibling tools like ghl_media_bulk_update_files which updates multiple files, but does not explicitly mention this 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. The description lacks context about prerequisites, such as whether the file/folder must exist, or scenarios where this tool is preferred over other media tools like ghl_media_upload_file or ghl_media_delete_file.

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

• ghl_object_get_record_by_idC
  2.9/5.0
  Behavior2/5

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

  Annotations already provide readOnlyHint, idempotence, non-destructive. Description only adds endpoint URL and version, no further behavioral context (e.g., auth, rate limits, data returned). Minimal value beyond annotations.

  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?

  Short, front-loaded with title and purpose. Endpoint info is useful but could be trimmed. Efficient 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?

  Minimal but sufficient for a straightforward read operation. Lacks output description (no output schema) and error scenarios. Could mention it returns the full record object. Adequate with 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?

  Schema coverage is 100%, so baseline is 3. Description does not add meaning beyond schema; it repeats endpoint structure but no additional semantics. No contradiction but no added value.

  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?

  Clearly states 'get' verb and 'record by Id' resource. Mentions both standard and custom objects. Distinguishes from create/delete/update siblings. However, could differentiate from other get tools (e.g., schema, association) more explicitly.

  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 vs alternatives (e.g., search_records, get_schema). Missing when-not-to-use or context for selection among many sibling tools.

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

• ghl_phone_purchase_numberC
  2.9/5.0
  Behavior3/5

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

  Description adds endpoint, OAuth scopes, and response structure beyond annotations. However, it omits important behavioral traits such as cost implications, irreversibility, or prerequisites for payment parameters.

  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?

  Description has redundancy ('Purchase number for location' repeated) and includes both high-level purpose and low-level response details. Could be more 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?

  Given the complexity (12 required body parameters including payment and Twilio IDs), the description lacks context on prerequisites, like having a Stripe account or valid payment methods. No output schema is provided.

  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 baseline is 3. Description does not add any additional meaning to the parameters beyond what the input 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 'Purchase number for location' and provides details about the response structure. It implicitly distinguishes from sibling phone tools (list, search) by focusing on purchase, but does not explicitly contrast.

  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 listing available numbers first. No prerequisites or context for selection are provided.

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

• ghl_product_deleteC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds the endpoint '/products/{productId}' and OAuth scopes 'products.write,' which provide additional behavioral context. However, it does not disclose cascade effects, error handling, or what happens if the product does not exist, so it adds moderate value beyond annotations.

  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 relatively short but redundant: the first sentence repeats the title. It includes endpoint and scopes, which are useful, but the repetition wastes words. Overall concise but could be tighter.

  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 simple delete operation, the description lacks completeness. It does not explain the effect of the optional sendWishlistStatus parameter, error scenarios, or whether deletion cascades to related records. The schema description for productId is inconsistent with deletion. No output schema exists, so the description should cover return behavior, but it does not.

  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, so the schema itself documents all three parameters. The tool description does not add any parameter-level details beyond implying productId is the identifier. It fails to address the misleading schema description for productId ('ID or the slug of the product that needs to be returned' suggests a read operation, not delete). Thus, the description adds no meaningful parameter semantics.

  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 tool name 'ghl_product_delete' and title 'Delete Product by ID' clearly indicate the action. The description explicitly states 'Delete Product by ID' and 'deleting a specific product using its unique identifier,' making the purpose unambiguous. It distinguishes from sibling product tools like ghl_product_create or ghl_product_get by focusing on deletion, but does not explicitly differentiate from other delete tools.

  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 only states 'Use this endpoint to remove a product from the system,' providing basic guidance. It offers no when-to-use vs alternatives, prerequisites, or when not to use. Given siblings include other product operations and many delete tools, this minimal guidance is insufficient.

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

• ghl_proposal_list_documentsC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description adds value by mentioning pagination behavior (limit, skip). However, it does not disclose other behavioral traits like rate limits or authentication requirements.

  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 relatively short but contains repetition ('List documents'). It briefly covers endpoint and pagination, but lacks a clear structure or prioritization of key 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?

  Given the tool's complexity (8 parameters, many optional filters) and no output schema, the description is minimal. It does not describe return values or explain how filters work together, leaving significant gaps for the 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 has 100% coverage, so the description does not need to explain each parameter. It adds marginal value by clarifying pagination parameters, but does not elaborate on filters like query, date range, or status beyond what the schema 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 'List documents' and 'List documents for a location', which conveys the primary purpose. However, it does not differentiate from similar sibling tools like ghl_proposal_list_templates, leaving ambiguity about when to use which.

  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 explicit when-not or alternative tool names are mentioned, 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.

• ghl_proposal_send_templateC
  2.9/5.0
  Behavior2/5

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

  Annotations indicate it's not read-only, but description adds no behavioral details beyond the endpoint. No disclosure of side effects (e.g., email sending, record creation).

  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?

  Short and to the point, but repeats 'Send template'. Efficient for a simple action.

  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?

  Lacks information on return values, prerequisites, or effects. For a mutation tool with nested parameters, the description is incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with minimal field descriptions (e.g., 'User Id'). Description does not add additional meaning to parameters beyond 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 clearly states it sends a template to a client, matching the tool name. Distinguishes from siblings like ghl_proposal_list_templates and ghl_proposal_send_document, though not explicitly.

  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 vs. alternatives like ghl_proposal_send_document. No context about prerequisites or exclusions.

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

• ghl_saas_enable_locationC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false (mutation) and destructiveHint=false. The description adds no behavioral details beyond 'enable', such as side effects, idempotency, or what enabling entails. It does not contradict annotations but fails to provide meaningful transparency beyond structured data.

  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 includes unnecessary HTML tags and repeated title, making it verbose and messy. The core information (token requirement, plan restriction) is there, but the formatting is distracting. Every sentence should earn its place; the HTML and repetition do not.

  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 a complex nested parameter (body) and no output schema. The description covers token and plan restrictions but omits details about request body structure, locationId semantics, and response format. Given the complexity, this is incomplete for an agent to use 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 coverage is 50%, yet the description provides no parameter descriptions. It mentions locationId only via the endpoint path but does not explain its meaning. The nested body object has many fields, but the description offers no guidance on when to use them (e.g., V1 vs V2).

  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 ('Enable SaaS') and the resource ('Sub-Account (Formerly Location)'), and the endpoint is provided. It distinguishes from sibling tools like bulk enable. However, the title is repeated and HTML formatting adds noise, 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly warns that it requires an agency-level token and is only available on the Agency Pro plan. This provides strong usage context, but it does not explicitly mention when not to use it or compare with alternatives like bulk enable.

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

• ghl_saas_update_rebillingC
  2.9/5.0
  Behavior2/5

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

  Annotations show readOnlyHint=false and destructiveHint=false, and description says 'Bulk update', implying mutation. No additional behavioral context is provided, such as whether the update is atomic, affects existing subscriptions, or triggers side effects. The description adds the authentication requirement but does not disclose response format or potential failures.

  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 short and front-loaded with the critical security requirement. It provides the tool name, a summary, and the endpoint details in three compact lines. However, it could be more structured by separating the security note from the functional 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 the tool has nested input parameters and no output schema, the description should explain expected response, scope of changes, or caveats. It only gives the endpoint and that it's a bulk update. Important behavioral details (e.g., whether rebilling is enabled/disabled per location, errors handling) are missing.

  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 50%; the companyId parameter lacks a description, and the body parameter has a generic note. The nested properties (config, product, locationIds) have individual descriptions. The description hints at locationIds usage but does not explain syntax or constraints beyond the schema. It adds the endpoint info which identifies companyId as a path 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 clearly states the tool updates rebilling settings in bulk for given location IDs. The verb 'Update Rebilling' and noun 'Bulk update rebilling for given locationIds' provide specific action and resource. However, it does not explicitly differentiate from sibling tools like ghl_saas_bulk_enable or the deprecated ghl_saas_update_rebilling_deprecated.

  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 includes an explicit prerequisite: 'REQUIRES AN AGENCY-LEVEL (Company) TOKEN'. However, it offers no guidance on when to use this tool versus other SaaS tools (e.g., ghl_saas_bulk_enable, ghl_saas_update_rebilling_deprecated) or conditions when 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.

• ghl_social_fetch_queue_itemsC
  2.9/5.0
  Behavior2/5

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

  The description implies a read operation ('fetch'), but the annotation readOnlyHint=false contradicts that. No disclosure of side effects or other behavioral traits beyond basic description.

  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 two sentences plus endpoint and OAuth scopes, which are not essential for an AI agent. It is reasonably concise but includes some technical details that could be omitted.

  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 covers pagination and draft session, but lacks info on error handling, response format, or additional constraints. Adequate for basic use 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 provides detailed descriptions and examples for all parameters within the body object. The tool description adds no extra parameter semantics.

  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 it fetches items from a queue, returns paginated results, and mentions the sessionId for draft items. It differentiates from siblings like ghl_social_fetch_queues or ghl_social_fetch_queue_by_id, though not explicitly.

  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 vs alternatives. The description only states what it does, not when to choose it over other queue-related tools.

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

• ghl_social_get_linkedin_page_profileC
  2.9/5.0
  Behavior2/5

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

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds the endpoint URL and version header, but does not disclose additional behavioral aspects like response structure, pagination, or authentication beyond what annotations imply.

  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 brief and front-loaded with the purpose, followed by endpoint details. No superfluous content, though it could be slightly more 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 no output schema and two required params, the description lacks completeness. It does not explain the response format, scope (single vs multiple accounts), or that it retrieves a specific LinkedIn account's data, leaving ambiguity.

  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?

  Input schema covers both parameters with descriptions ('Account Id', 'Account Location Id'). The description does not add parameter 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get Linkedin pages and profile', specifying a verb and resource. It differentiates from sibling tools like ghl_social_attach_linkedin_page_profile by indicating a read operation, though it uses plural 'pages' while the endpoint is singular.

  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, such as getting other social accounts. The description provides no context about prerequisites, output, or when to choose this over similar read operations.

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

• ghl_store_create_shipping_carrierC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, but the description adds minimal behavioral context. It does not disclose authentication requirements, idempotency, or what happens if a duplicate is attempted. No contradiction with annotations.

  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?

  Short and to the point, but includes endpoint info that may be unnecessary for an AI agent. The purpose is clearly stated upfront, though the title is repeated.

  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, yet the description does not mention the return value (e.g., created carrier object). For a create tool with nested parameters, the description is 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%, so baseline is 3. The description does not add any parameter semantics beyond the schema; it only repeats the tool's function.

  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 'Create Shipping Carrier' and 'adding a new shipping carrier,' indicating the action and resource. It distinguishes from sibling tools like update or delete, but could be more specific about what creating entails.

  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 (e.g., update, delete). The description lacks context about prerequisites or scenarios for creation, leaving the agent to infer.

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

• ghl_store_update_shipping_zoneC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate it's a write operation (readOnlyHint=false) and idempotent. The description adds no behavioral details beyond that, such as partial update behavior 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short but contains redundancy ('Update Shipping Zone' repeated). The endpoint info is useful, but the sentence about the API is nearly tautological.

  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, no mention of success response, error cases, or required permissions. For a simple update tool, this leaves gaps in understanding the outcome.

  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 includes descriptions for each parameter. The description adds no additional meaning; it merely references the schema. Baseline 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 tool updates a shipping zone, with the title reinforcing this. It distinguishes from sibling create/delete/get/list operations, though it doesn't explicitly contrast with other update tools.

  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 over alternatives (e.g., create vs. update). No mention of prerequisites or context like existing zone ID requirement.

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

• ghl_user_updateC
  2.9/5.0
  Behavior3/5

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

  Annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) already convey key traits. The description adds OAuth scopes and the known issue that the tool is currently broken due to a missing userId field, which is useful but does not elaborate on other behaviors like partial updates 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with a detailed known issue, which is important but verbose. The rest is concise with endpoint and scopes. It could be more structured (e.g., separate sections for usage and caveats).

  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 complexity of the tool (many nested parameters, no output schema), the description lacks overall context. It does not summarize what can be updated, update semantics (e.g., partial vs full replacement), or expected response, leaving the agent to infer from the schema alone.

  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 parameters with descriptions, achieving 100% schema description coverage. The description itself does not add any parameter-level information beyond what the schema already provides, so it meets the baseline expectation.

  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 'Update User' and provides the PUT endpoint, making the tool's purpose clear. However, it does not explicitly differentiate from sibling tools like ghl_user_create or ghl_user_delete, though the verb 'Update' implies it is for modifying existing users.

  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 (e.g., ghl_user_create for new users, ghl_user_delete for removal). There is no mention of prerequisites or context such as the user must exist.

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

• ghl_ad_fb_campaign_upsertB
  3/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds endpoint and OAuth scopes but does not disclose behaviors beyond what annotations imply, such as partial vs full update, or what happens when a campaign already exists.

  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 mostly concise but includes technical details (endpoint path, version, source) that may not be essential for an agent. While front-loaded with purpose, the extra details slightly reduce clarity.

  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 (nested body, enums) and lack of output schema, the description does not cover return values, error handling, or how to differentiate create vs update. It relies heavily on the schema but fails to tie concepts together.

  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 all parameters have descriptions in the input schema. The description adds no additional parameter-level information beyond the schema, meeting the 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 verb 'upsert' and resource 'campaign', with the explanation 'Create or update a Facebook campaign'. This distinguishes it from sibling tools like delete, get, pause, etc., which have different verbs.

  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 vs alternatives (e.g., create vs update scenarios, or when to use other campaign tools like duplicate or publish). The description only provides endpoint and OAuth scopes, leaving usage context entirely to the agent.

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

• ghl_blog_check_url_slug_existsB
  3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to reiterate safety. It adds the HTTP method (GET) and OAuth scopes, which is helpful but does not describe the return value or behavior when a slug exists or not. The lack of output schema makes the description incomplete for full transparency.

  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 somewhat verbose, including endpoint path, version header, and OAuth scopes which could be considered clutter for an agent. The first line 'Check url slug' is redundant with the title. It could be more 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?

  Given the lack of output schema and zero schema descriptions, the description should fully explain the tool's usage and return value. It fails to describe what response the agent should expect (e.g., boolean, status code). The context of being a pre-publish validation is helpful, but the tool is not complete enough for confident 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?

  Schema description coverage is 0%, placing full burden on the description to explain parameters. The description only hints at where to find postId but does not explain urlSlug or locationId at all. With three parameters (one optional), this is insufficient for an agent to understand required inputs.

  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 it checks blog slug validation needed before publishing. It identifies the verb 'check' and resource 'url slug existence', distinguishing it from other blog tools like creating or listing posts. The intended 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description indicates the tool should be used before publishing a blog post, which provides a use context. However, it does not compare with alternative blog tools (e.g., the listing or creation endpoints) nor explicitly state when not to use it. Guidance is present but not robust.

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

• ghl_business_createB
  3/5.0
  Behavior2/5

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

  The description adds minimal behavioral context beyond annotations. It indicates a POST request with businesses.write scope, implying write permission, but does not describe side effects, response structure, or creation behavior. Annotations already indicate non-read-only and non-destructive.

  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 concise but mixes purpose with technical endpoint details. It is adequately short but lacks a structured format that separates purpose from usage notes.

  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 creation nature of the tool and absence of output schema, the description is incomplete. It omits response expectations, idempotency (annotations say not idempotent), and any duplicate handling. The tool is minimally viable 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 coverage is 100%, so the schema fully documents the body parameter and its properties. The description adds no additional meaning beyond repeating the schema's existence. 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 'Create Business' with a specific verb and resource. It effectively distinguishes from sibling tools like update, delete, get, and list by implying creation.

  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. Lacks information on prerequisites, scenarios, or exclusions. The endpoint and OAuth scopes are technical, not usage-oriented.

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

• ghl_business_deleteB
  3/5.0
  Behavior3/5

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

  Annotations include destructiveHint: true, already signaling destructive behavior. The description confirms deletion via 'Delete Business' and the DELETE endpoint. However, it does not elaborate on side effects, such as whether the deletion is permanent or cascading effects on related data. The description adds minimal value beyond annotations.

  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 short, covering title, endpoint, and OAuth scopes in three lines. While concise, the structure could be improved by separating the title and endpoint details, but it is still efficient with no unnecessary 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 that there is no output schema and one required parameter, the description is incomplete. It does not explain response format, error cases, or prerequisites like needing the businessId from another call. The lack of contextual details may hinder effective tool usage.

  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 one required parameter (businessId) with no description (0% coverage). The tool description does not explain what businessId is or how to obtain it. In the absence of schema descriptions, the description fails to compensate, leaving the agent without guidance on this critical 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 title 'Delete Business' and description starting with 'Delete Business' clearly state the tool's purpose. The endpoint and OAuth scopes provide additional context. Among sibling tools like ghl_business_create and ghl_business_get, this tool is uniquely identified as the deletion tool.

  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 guidance on when to use this tool versus alternatives. It mentions OAuth scopes (businesses.write) but does not explain prerequisites, such as obtaining the businessId from a list/get operation. No when-not-to-use or alternative suggestions are given.

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

• ghl_contact_get_appointmentsB
  3/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds minimal additional behavioral context: the endpoint, OAuth scopes, and a renaming note. It does not disclose what the response contains (e.g., list of appointments), pagination, or ordering. The description fails to add meaningful behavioral insights beyond annotations.

  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 relatively short but includes an irrelevant note about renaming ('Renamed from the auto-generated...'), which does not aid the agent. The structure is acceptable: purpose statement followed by technical details. Could be more concise by removing the renaming note.

  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 simple tool with one parameter and no output schema, the description should at least mention that it returns a list of appointments. It does not specify the response format, any filtering options, or what types of appointments are included (e.g., future, past). Without output schema, this leaves the agent uninformed about the tool's output.

  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 the single parameter (contactId) with a description ('Contact Id'), achieving 100% schema description coverage. The description does not add further parameter information, so a 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 'Get Appointments for Contact', using a specific verb ('Get') and resource ('Appointments for Contact'). It distinguishes from sibling tools like ghl_calendar_appointment_get (which gets a single appointment by ID) and other contact tools. The endpoint and OAuth scopes further clarify the 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?

  No guidance is provided on when to use this tool versus alternatives, such as ghl_calendar_appointment_get or other contact-related tools. There is no mention of prerequisites, limitations (e.g., date range), 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.

• ghl_email_update_campaignB
  3/5.0
  Behavior2/5

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

  Annotations indicate a non-read-only, non-destructive, non-idempotent write operation, but the description adds minimal behavioral details beyond the basic update action. It does not disclose whether updates are partial or full replacements, if the campaign must be in draft status, or what side effects (e.g., notifications) occur. The OAuth scopes are mentioned but that's standard authentication info.

  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 relatively concise but includes a redundant first line ('Update Email Campaign') that mirrors the title. The structure mixes a title-like statement with the actual purpose and endpoint info, making it less efficient than it could be.

  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 an output schema, the description should at least mention the response format (e.g., returns updated campaign or success status). It lacks preconditions (e.g., campaign must be draft) and error conditions, leaving the agent underinformed about 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?

  Schema coverage is 100%, so the schema already documents all parameters with descriptions. The tool description does not add any additional meaning beyond what's in the schema, earning the baseline score.

  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 updates an email campaign draft, using the verb 'update' and specifying the resource as 'email campaign draft'. This distinguishes it from creating or deleting campaigns, though it doesn't explicitly contrast with sibling tools like ghl_email_create_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 for updating drafts but provides no explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it (e.g., for sent campaigns). 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.

• ghl_funnel_create_redirectB
  3/5.0
  Behavior2/5

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

  Annotations already provide readOnlyHint=false and destructiveHint=false, so the description's confirmation of creation adds no new behavioral insight. It does not disclose idempotency, error behavior, or side effects beyond what the annotations and schema imply.

  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 short but redundant, repeating 'Create Redirect' and including technical details (OAuth scopes, endpoint) that are not essential for an AI agent. It could be more concise by removing duplication and focusing on core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema is provided, and the description does not explain what the response contains (e.g., created redirect ID). For a creation tool, this missing information leaves the agent uncertain about the operation's outcome. The description also lacks details on rate limits or permissions beyond the mentioned OAuth 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% with detailed descriptions of all required subfields (locationId, domain, path, target, action). The description adds no additional semantics beyond 'provide required info,' 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 explicitly states 'Create Redirect' and 'adding a new url redirect to the system,' clearly indicating the action (create) and resource (funnel redirect). Among siblings with related operations like delete and list, this tool is uniquely identified as the creation endpoint.

  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 (e.g., ghl_funnel_delete_redirect_by_id, ghl_funnel_fetch_redirects_list). It merely states to ensure required info is provided, without contextualizing when creation is appropriate or what prerequisites exist.

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

• ghl_invoice_voidB
  3/5.0
  Behavior2/5

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

  The description adds important behavioral context (irreversible, cannot be paid/reactivated) and OAuth scopes. However, it contradicts the destructiveHint annotation (false) by describing an irreversible state change. Additionally, the phrase 'delete invoice' is inaccurate for voiding, creating confusion.

  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 has redundancy: 'Void invoice' is repeated from the title. The endpoint and OAuth info could be more concisely integrated. It is not overly long but could be streamlined.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema and 2 parameters, the description lacks error handling, prerequisites (e.g., invoice status before voiding), and outcome details. The confusing 'delete' wording also harms 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 coverage is 100%, so the input schema documents both parameters thoroughly. The description adds no extra meaning to the parameters (altId, altType, invoiceId) beyond what is already in 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?

  The description clearly states 'marks the invoice as void' and explains irreversibility, which defines the tool's purpose. However, it also misleadingly says 'API to delete invoice by invoice id' which could cause confusion with the sibling tool ghl_invoice_delete. The purpose is mostly clear but has a slight ambiguity.

  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 does not explicitly guide when to use this tool over alternatives like ghl_invoice_delete or ghl_invoice_schedule_cancel. The irreversibility hint implies finality, but no comparative guidance is provided.

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

• ghl_kb_delete_knowledge_baseB
  3/5.0
  Behavior3/5

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

  Annotations already provide destructiveHint=true and readOnlyHint=false. The description adds the specific endpoint version but no additional behavioral context beyond what annotations convey.

  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?

  Single sentence with endpoint info is concise, but could add parameter guidance without bloating.

  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 mention of side effects, return values, error scenarios, or idempotency behavior despite idempotentHint=true in annotations.

  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?

  Required parameter 'knowledgeBaseId' has no description in schema and is not explained in the tool description, leaving the agent without guidance on value format or semantics.

  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 explicitly states 'Delete a knowledge base' with specific verb and resource, and the sibling tools clearly differentiate operations like create, get, update, etc.

  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, no prerequisites, no cautionary notes about deletion consequences.

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

• ghl_location_get_all_or_email_sms_templatesB
  3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds the endpoint, OAuth scopes, and pagination behavior (skip/limit), providing some context beyond annotations. No contradictions are present.

  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 very concise: three sentences that front-load purpose, then provide endpoint, scopes, and pagination. Every sentence contributes meaningful technical detail with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool lacks an output schema, so the description should explain what is returned. It does not mention the structure of the response, nor does it clarify that the required parameters (originId, locationId) are necessary. The safety hints from annotations are present but insufficient for complete usage.

  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 33% description coverage (only originId and locationId). The description explains only the pagination parameters (skip, limit), leaving 'type' and 'deleted' undocumented. This fails to add meaning for the majority of 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 states 'GET all or email/sms templates' and provides the endpoint, making it clear that the tool retrieves templates for a location. However, the phrase 'all or email/sms' is slightly ambiguous given the schema includes 'whatsapp' as a type, and it does not explicitly differentiate from sibling tools like the deletion tool.

  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 (e.g., for filtering vs. retrieving all templates). The description only mentions technical details like OAuth scopes and pagination, but does not explain 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.

• ghl_media_delete_fileB
  3/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds no further behavioral details such as whether deletion is permanent, effects on dependent resources, or required permissions beyond the OAuth scopes. With annotations present, the description does not contradict them but adds minimal value.

  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 brief and front-loaded with the purpose. The endpoint and OAuth scopes are useful technical details. However, the description lacks structure (e.g., no section for parameters or behavior) and could be slightly more organized 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?

  Given the three required parameters, annotations, and lack of output schema, the description covers the primary action and technical details. However, it omits important context such as what happens after deletion (no return value description), error conditions, or prerequisites (e.g., location ownership). It is adequate but not comprehensive.

  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 67%, but the description does not explain any parameters. The endpoint line hints that 'id' is the media ID, but altType and altId are not described. The schema already provides minimal descriptions (e.g., 'location Id' for altId), so the description fails to add meaning beyond 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?

  The description clearly states 'Delete File or Folder' and specifies 'Deletes specific file or folder from the media storage'. It distinguishes the action from siblings through the name and context, but does not explicitly differentiate from ghl_media_bulk_delete_files or ghl_media_create_folder.

  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 the endpoint and OAuth scopes but gives no guidance on when to use this tool versus alternatives like ghl_media_bulk_delete_files for bulk deletions or ghl_media_update_file for non-destructive updates. No when-to-use or when-not-to-use context.

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

• ghl_social_attach_oauth_accountsB
  3/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=false. The description does not add meaningful behavioral context beyond the OAuth flow step; it lacks details about side effects, permissions, rate limits, or error cases. The endpoint and version are mentioned but provide limited agent guidance.

  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 front-loaded with the step number and includes a clear OAuth flow summary. However, it is somewhat verbose with truncated JSON examples and a raw endpoint string. The structure is organized but could be more 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?

  There is no output schema, and the description does not explain return values, success/error conditions, or prerequisites (e.g., OAuth token from Step 1). For a mutation tool with four required parameters and platform-variant body, the description lacks completeness in guiding the agent on 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 100%, so baseline is 3. The description adds platform-specific JSON examples (though truncated) and explains the 'body' parameter structure varies by platform. This adds some value, but the examples are incomplete and the schema itself is already descriptive.

  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 is the final step (Step 3 of 3) to connect an OAuth account after retrieving available accounts. It uses a specific verb ('Connect Account') and resource ('account'), though it does not explicitly distinguish from sibling attach tools (e.g., ghl_social_attach_facebook_page_group).

  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 an OAuth flow summary and indicates this tool is used after Step 2 ('Get Accounts'), but it does not give explicit when-to-use or when-not-to-use guidance. Alternatives (platform-specific attach tools) are not mentioned, leaving the agent to infer usage context from the flow summary.

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

• ghl_social_bulk_delete_planner_postsB
  3/5.0
  Behavior1/5

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

  There is a clear contradiction: the description says the tool deletes posts (destructive action), but the annotations set destructiveHint=false. Additionally, the description states 'It will only get deleted in CRM database' which hints at scope but is vague. The contradiction undermines transparency.

  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 relatively concise but includes an awkwardly phrased note and an endpoint line that may be extraneous. It could be streamlined while retaining key 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?

  The description lacks details on success/error responses, output format (no output schema), and precise behavioral scope (only CRM deletion). The contradiction with annotations further reduces completeness. For a bulk delete operation, more context is needed.

  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 one useful detail beyond the schema: the maximum of 50 post IDs per request. However, the schema descriptions for locationId and postIds are poor ('Requested Results'), and the tool description does not elaborate on the structure of the body or the locationId. With 100% schema coverage but weak schema descriptions, the added value is moderate.

  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 bulk deletes social planner posts by providing a list of post IDs. It specifies the action (bulk delete) and the resource (social planner posts), and the mention of 'clearing up large numbers of posts efficiently' distinguishes it from single-delete alternatives like ghl_social_delete_post.

  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 indicates the tool is useful for efficient bulk deletion and notes a maximum of 50 posts per request. However, it does not explicitly state when to use this tool over alternatives (e.g., single delete) or provide exclusion criteria. The guidance is minimal.

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

• ghl_store_create_shipping_zoneB
  3/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds only the endpoint and source, with no additional behavioral context such as auth needs, rate limits, side effects, or success/failure outcomes.

  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 short but contains repetition (title repeated). It is adequately concise but could be more structured and avoid 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 complexity of the nested body parameter and no output schema, the description lacks an overview of constraints (e.g., altType must be 'location'), response behavior, or the openWorldHint property. Key context is missing.

  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 descriptions for the body parameter and its nested properties. The tool description does not add extra meaning beyond what the schema already provides, 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.

  Purpose5/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 'Shipping Zone', and among siblings (delete, get, list, update), it uniquely identifies itself as the creation tool. It also provides the endpoint for additional 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 is given on when to use this tool versus alternatives, no prerequisites, exclusions, or when-not-to-use indications. The description only states what the tool does.

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

• ghl_ad_fb_audience_listB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which clarify it's a safe read operation. The description adds the specific endpoint and required OAuth scopes (adPublishing.readonly), providing concrete behavioral context beyond the annotations.

  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 concise, containing two lines plus essential technical details (endpoint, OAuth). It is front-loaded with the main purpose and avoids unnecessary fluff, though it repeats the title verbatim.

  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 output schema provided, the description should at least hint at the return format (e.g., list of audience objects, fields returned). It does not, leaving a gap for agents to infer or default. For a simple list operation, this lack of return value clarity reduces 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?

  Input schema coverage is 100% with descriptions, examples, and enums for all 4 parameters. The description does not add additional semantic details beyond what the schema already provides, so 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 title and description clearly state 'Get custom audiences' and 'Retrieve Facebook custom audiences for a location', indicating a list operation. The verb 'Get' combined with 'audience_list' in the name distinguishes it from related tools like ghl_ad_fb_audience_get (singular fetch), though not explicitly contrasted.

  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 (e.g., ghl_ad_fb_audience_get for a single audience, ghl_ad_fb_audience_delete for deletion). There is no mention of prerequisites, limitations, or exclusions.

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

• ghl_ad_fb_entity_getB
  3.1/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, idempotentHint, etc. Description adds endpoint and OAuth scopes but no additional behavioral context (e.g., rate limits, response structure). Does not contradict annotations.

  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?

  Description is brief and includes necessary technical details (endpoint, version, source, scopes). Could be more front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite annotations and full schema coverage, the description omits information about pagination (next parameter), fetchAll behavior, and output format for a 9-parameter 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?

  Schema coverage is 100% with descriptions for all parameters. The description does not add further 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Get'/'Retrieve') and resource (Facebook campaigns, adsets, or ads) based on entityType. However, it does not differentiate this generic entity getter from sibling tools like ghl_ad_fb_campaign_get, which serve similar purposes for specific entity 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?

  No guidance on when to use this tool versus alternatives (e.g., specific campaign/get tools). Lacks context for filtering, pagination, or prerequisites.

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

• ghl_ad_fb_page_set_defaultB
  3.1/5.0
  Behavior2/5

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

  The description adds little beyond annotations: it mentions the endpoint and OAuth scopes but does not explain side effects (e.g., replaces any existing default? only one default per location?). Annotations cover idempotency and non-destructiveness, but the description misses behavioral details.

  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 concise and front-loaded with the purpose. The endpoint and scopes are supplementary but not verbose. It could be slightly tighter by omitting the endpoint line, but it remains efficient.

  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 3 parameters including a nested object and no output schema, the description should clarify behavior like whether setting a default overwrites an existing one. It lacks this operational context, leaving gaps for the 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%, so the schema already describes all parameters thoroughly. The description adds no additional meaning beyond what is in the schema (e.g., it does not clarify the relationship between locationId and pageId).

  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 explicitly states 'Set default page' and 'Set the default Facebook page for a location', clearly indicating the verb (set) and resource (default Facebook page) with a specific scope (for a location). This distinguishes it from sibling page operations like listing 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 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_ad_fb_page_list or ghl_ad_fb_page_delete. It does not mention prerequisites, conditions, 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.

• ghl_ad_fb_reporting_getB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat these. It adds the endpoint and OAuth scopes, which provide useful context. However, it does not disclose any further behavioral traits such as rate limits, pagination, or data freshness.

  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 concise with two main sentences and technical details appended. It is front-loaded with the core purpose. However, the first line is slightly redundant with the second.

  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 no output schema, so the agent relies on the description for understanding return values. The description does not explain the response format, fields returned, or any aggregation details. Important context like location-specific scope is mentioned but not emphasized.

  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 descriptions and examples for all 6 parameters. The description adds no additional parameter meaning beyond what the schema provides, 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 retrieves aggregated Facebook ad reporting metrics for a location. It specifies the verb 'Get' and the resource 'reporting data'. However, it does not differentiate from sibling tools like ghl_ad_fb_campaign_reporting_get, which might be more campaign-specific.

  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 lacks explicit context for suitable scenarios or exclusions, leaving the agent without decision-making support.

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

• ghl_ad_google_audience_listB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which inform safety. The description adds the endpoint method (GET) and required OAuth scope, but does not disclose additional behavioral traits like pagination, rate limits, or response structure. Since annotations cover the safety profile, a score of 3 is appropriate.

  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 concise with three sentences covering purpose, endpoint, and scopes. The first sentence ('Get audiences') is slightly redundant but not harmful. 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?

  The description lacks mention of the return format (list of audiences), the filtering role of the 'isDraft' parameter, and any pagination or response limits. Given no output schema, these omissions leave the agent underinformed about what to expect and how to use the parameters 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?

  Input schema coverage is 100%, and both parameters (locationId, isDraft) have descriptions and examples in the schema. The description does not add any semantics beyond what the schema already provides, so the baseline score 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 tool retrieves 'Google Ads combined audiences for a location,' specifying the verb 'Retrieve' and the resource. The endpoint and OAuth scope provide additional context. However, it does not explicitly differentiate from the sibling 'ghl_ad_google_audience_get' tool.

  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_ad_google_audience_get' or Facebook audience tools. The description only states the OAuth scope, missing explicit when-to-use or when-not-to-use advice.

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

• ghl_ad_google_entity_getB
  3.1/5.0
  Behavior3/5

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

  Annotations already cover readOnly, idempotent, and non-destructive hints. The description adds endpoint details and OAuth scopes, which are useful for understanding access requirements. However, it does not disclose whether the response returns a list or single object, or how filtering works 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short (two sentences plus endpoint/scope lines). It is front-loaded with purpose. While the endpoint info may be unnecessary for AI agents, it does not significantly detract. Efficient and to the point.

  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 9 parameters and no output schema, the description lacks important context about the response format (list vs. single), required relationships (e.g., locationId), and pagination. This gap could lead to misuse or extra trial-and-error queries.

  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 mentions 'based on entity type' which aligns with the schema's entityType parameter, but adds no additional meaning or context 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 it retrieves Google campaigns, ad groups, or ads based on entity type. The title is null but the first two sentences specify the resource and action. However, the initial 'Get entities' is generic, and it does not differentiate from sibling tools like ghl_ad_google_campaign_get that target specific entities.

  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 OAuth scopes as a prerequisite but offers no guidance on when to use this tool versus alternatives (e.g., ghl_ad_google_campaign_get for a single campaign). No when-not-to-use or comparison with sibling tools.

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

• ghl_ad_google_keyword_ideas_getB
  3.1/5.0
  Behavior1/5

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

  The annotation readOnlyHint is false, but the description states OAuth scopes 'adPublishing.readonly', implying read-only behavior. This is a direct contradiction. The description also does not disclose important traits like pagination or rate limits beyond what annotations fail to indicate.

  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 relatively concise, with the main purpose in the first sentence. Extra endpoint and scope details are useful but could be trimmed. Still 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?

  Missing important context: no output schema so return format is unspecified, no usage context (e.g., when to use vs other Google Ads tools), and the contradiction undermines trust. Incomplete for an agent rely solely on this definition.

  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 schema already describes all parameters. The description adds no additional meaning beyond the schema, warranting a baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it retrieves keyword ideas for Google Ads campaigns, with a specific verb ('Get') and resource ('keyword ideas'). It differentiates from sibling tools like campaign or account 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 explains it retrieves keyword suggestions, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., targeting search tools). No exclusions or context are given.

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

• ghl_ad_google_reporting_listB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, establishing the tool as a safe read operation. The description adds the HTTP method (GET), API version, and OAuth scopes, but does not disclose behavioral traits like pagination, rate limits, or data freshness beyond what annotations imply.

  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 two sentences long, with technical details appended. It is concise and free of fluff, though the first sentence 'Get reporting list' is redundant with the tool name. The structure could be improved by front-loading the most important purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description lacks critical context: it does not mention that listType can be other values (e.g., ads, keywords) or that campaignId is required for certain listTypes. With no output schema, the agent has no information about the return structure, making the description incomplete for effective use.

  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?

  With 100% schema description coverage, the input schema already documents all parameters with examples and descriptions. The description adds no new meaning beyond stating the tool retrieves a list of campaigns or ad groups, which aligns with schema but does not elaborate on parameter constraints or dependencies.

  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 it retrieves a list of Google campaigns or ad groups with reporting data, providing a specific verb and resource. It distinguishes from sibling tools like 'ghl_ad_google_reporting_get' (singular) and 'ghl_ad_google_campaign_get' (specific campaign), though it does not fully enumerate all listType options (e.g., ads, keywords).

  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, such as when to use 'ghl_ad_google_reporting_get' or 'ghl_ad_google_campaign_get'. It only includes technical details like endpoint and OAuth scopes, but no contextual advice.

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

• ghl_ad_li_reporting_listB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, signaling a safe read operation. Description adds endpoint and OAuth scopes, which provide some behavioral context but no additional details about rate limits, pagination, or response structure.

  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?

  Description is concise with front-loaded purpose. Includes technical details (endpoint, version, OAuth) that may be helpful but are not essential. No redundant sentences.

  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 required parameters and no output schema, the description lacks important context: how parameters interact (e.g., campaignId and campaignGroupId both required? Can they be used together?), pagination behavior, default sorting, or what fields are returned in the response.

  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 baseline is 3. Description does not add any extra meaning beyond what the schema provides (e.g., explaining relationships between campaignId and campaignGroupId, or clarifying that both are required).

  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 clearly states it retrieves a list of LinkedIn campaigns/campaign groups with reporting data. The verb 'Retrieve' and resource 'list' are specific. However, it doesn't explicitly distinguish between listing campaigns vs. campaign groups, or clarify that it returns multiple items vs. a single report.

  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 vs. alternatives like ghl_ad_li_reporting_get (for a single report) or Facebook/Google reporting lists. No mention 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.

• ghl_blog_get_all_categories_by_locationB
  3.1/5.0
  Behavior3/5

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

  Annotations already indicate the tool is read-only and idempotent. The description adds pagination details (limit, offset) which is helpful for understanding behavior during large result sets. However, it does not disclose error conditions or required permissions beyond the scope.

  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 includes redundant phrases (repeating the title) and a typo ('categoies'). It is short but not maximally concise; every sentence earns its place except the first line which repeats the title.

  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 read operation, the description provides endpoint, scope, and pagination. However, it omits response format, error handling, and contextual usage compared to sibling blog tools. The missing schema description for locationId reduces 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 67% (2 of 3 params described). The description reiterates that limit and offset are for pagination, which is already in the schema. The locationId parameter lacks a schema description, but the description mentions it is needed for a given location ID, adding minimal value.

  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 that the tool retrieves all blog categories for a given location ID. The purpose is explicit and the resource (blog categories) is well-defined. However, it doesn't differentiate itself from sibling blog tools like get_all_authors, but the name is sufficiently specific.

  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 mentions the OAuth scope 'blogs/category.readonly', but does not explain when to prefer this tool over other blog-listing tools or provide any exclusions.

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

• ghl_blog_post_createB
  3.1/5.0
  Behavior2/5

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

  Annotations indicate non-read-only, non-destructive, non-idempotent, but the description adds no behavioral context beyond the obvious. No mention of side effects, authorization needs, or rate limits.

  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 concise and includes relevant endpoint and OAuth scope. It could be more structured (e.g., bullet points) but is not 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 complexity (nested object, many required fields) and no output schema, the description is insufficient. It does not explain return values, error handling, or how to obtain required IDs (though some hints are in the schema). The tool's purpose is clear, but deeper context is missing.

  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 many fields have descriptions (e.g., author, blogId, categories). The description adds no additional meaning beyond the schema, so it meets the baseline but does not exceed.

  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 blog post and provides the endpoint and OAuth scopes. It is distinct from sibling tools like ghl_blog_update_post and ghl_blog_post_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?

  No guidance on when to use this tool versus alternatives, no prerequisites (e.g., need a blog site), and no exclusions. The description does not help the agent decide if this is the right tool.

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

• ghl_calendar_appointment_createB
  3.1/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, so the tool is a write operation. The description adds endpoint and OAuth scopes (write access). It does not describe side effects like free slot validation or whether automations run, though the schema covers flags for these.

  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 concise: three lines covering purpose, endpoint, and scopes. It is front-loaded with 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?

  Despite a complex input schema with many parameters, the description is extremely minimal (single line + technical details). It does not explain the overall workflow or what the tool does beyond 'Create appointment'. The schema descriptions are thorough, but the tool description lacks 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 description coverage is 100%, with each parameter having a description. The tool description itself adds no parameter information, so it meets the baseline of 3.

  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 states 'Create appointment' with the verb 'create' and resource 'appointment', clearly indicating the action. It distinguishes from update/delete tools but not from other creation tools like calendar_service_booking_create; however, the name itself is specific.

  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 (e.g., calendar_service_booking_create). No prerequisites or conditions mentioned. The description is purely functional.

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

• ghl_calendar_appointment_note_createB
  3.1/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, destructiveHint, etc. The description adds OAuth scopes, which is useful, but does not elaborate on side effects, idempotency, or other behavioral traits beyond the annotations.

  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 very short and includes endpoint and OAuth scopes, which are relevant. It is concise and front-loaded, though slightly terse.

  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 lacks information about return values or output (no output schema). It does not mention constraints like maxLength (though present in schema). For a tool with siblings, more context would help the AI understand the full 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?

  Schema coverage is 100% with descriptions and examples for both parameters. The description itself adds no extra parameter semantics beyond the schema, so baseline 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 creates a note (verb 'Create Note') and provides the endpoint path. It implicitly distinguishes from sibling note tools (delete, list, update) via the verb, but does not explicitly differentiate.

  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 note update or delete. No prerequisites or typical use cases are mentioned.

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

• ghl_calendar_appointment_note_deleteB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true and idempotentHint=true, which the description does not contradict. The description adds OAuth scopes, providing some transparency about authorization needs, but doesn't explain the deletion effect (e.g., irreversibility, cascading effects).

  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 brief and front-loaded with the purpose ('Delete Note'), followed by technical details. It is concise but could be more informative 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?

  For a destructive operation with no output schema, the description lacks contextual information about what happens when a note is deleted (e.g., permanent removal, impact on the appointment). Given the low complexity, the minimal description is borderline 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?

  Both parameters (appointmentId, noteId) have descriptions in the input schema (100% coverage). The tool description adds no additional semantics 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 title and description clearly state 'Delete Note', indicating a delete operation on a note resource. The sibling tools include create, list, and update variants, so this tool is easily distinguished as the delete action. However, the description adds no additional context beyond the title and endpoint details.

  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 a note should be deleted or prerequisites (e.g., note must exist). The absence of usage direction forces the agent to infer from context alone.

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

• ghl_calendar_group_createB
  3.1/5.0
  Behavior2/5

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

  Annotations already indicate write, non-destructive, non-idempotent. Description adds only endpoint and OAuth scopes, not behavioral details like side effects or return value. No contradiction with annotations.

  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?

  Description is very short and front-loaded with purpose. However, including version header and source file may be unnecessary for an AI agent. Still efficient.

  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, yet description fails to explain what the tool returns or how the created group is used. Minimal context for a creation operation with nested 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 examples and descriptions for all body fields. Description adds no additional parameter information, 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?

  Description starts with 'Create Calendar Group', providing a clear verb and resource. The name and listing among sibling tools (e.g., delete, list, update) make 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 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_calendar_group_validate_slug or ghl_calendar_create. Prerequisites like location ID existence are not mentioned.

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

• ghl_calendar_group_updateB
  3.1/5.0
  Behavior3/5

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

  Annotations provide idempotentHint=true and destructiveHint=false. The description adds endpoint and OAuth scopes but does not elaborate on side effects, idempotency implications, or return 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 brief but includes some redundancy ('Update Group' twice). Could be more concise by removing the first line.

  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 is provided, and the description does not explain what the response contains or how the update affects the resource. Missing details on error scenarios or typical usage 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%, so parameters are fully defined in the schema. The description adds no additional meaning beyond what is already in the input 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 states the tool updates a calendar group via group ID. However, it does not differentiate from sibling tools like ghl_calendar_group_update_status or ghl_calendar_group_validate_slug, which also operate on groups.

  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 creating, listing, or updating status of a group. No prerequisites or alternatives mentioned.

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

• ghl_calendar_list_blocked_slotsB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, signaling a safe read operation. The description adds that startTime/endTime are epoch milliseconds as strings and lists OAuth scopes, but does not disclose potential limits, pagination, or empty result 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 concise, with only a few lines covering the critical format note, endpoint, and scopes. It is front-loaded with the parameter format note, which aids understanding. Every sentence is useful.

  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 is provided, and the description does not explain the return format, pagination, or what fields are included in the blocked slots list. For a list tool, this is a significant gap, making the description incomplete for the 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%. The description adds value by clarifying that startTime and endTime are passed as strings, which supplements the schema's 'in millis' description. However, only two of six parameters are mentioned, and the schema already describes all parameters adequately.

  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 'Get Blocked Slots' and provides the endpoint, making it obvious that the tool retrieves blocked calendar slots. However, it does not differentiate from sibling tools like ghl_calendar_list_free_slots, missing explicit 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?

  No guidance is given on when to use this tool versus alternatives such as ghl_calendar_list_free_slots or ghl_calendar_block_slot_create. The description lacks any when-to-use or when-not-to-use context.

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

• ghl_calendar_notification_getB
  3.1/5.0
  Behavior3/5

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

  Annotations already indicate read-only and idempotent behavior. The description adds endpoint details and OAuth scopes, which are useful but do not disclose additional behavioral traits (e.g., error handling, rate limits). It meets the baseline by not contradicting annotations.

  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 short and front-loaded with the action, but it contains a slight redundancy ('Get notification' followed by 'Find Event notification'). It is acceptable but not exemplary in 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?

  For a simple get-by-ID tool, the description lacks information about return values, error scenarios, or the role of notifications in the calendar system. No output schema exists, so the description should provide more context to compensate. It is incomplete.

  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?

  With 0% schema description coverage, the description must compensate. It mentions 'notificationId' in context but does not explain 'calendarId' or provide detailed semantics for either parameter. The endpoint path gives some hint, but it is insufficient for an agent to understand parameter origins 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 ('Get notification') and the resource ('notification by notificationId'). It distinguishes from sibling operations like list, create, delete, update by specifying it's a read operation. The inclusion of the full endpoint path further reinforces the 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?

  No guidance is provided on when to use this tool versus alternatives such as listing notifications or creating them. The description does not mention context or prerequisites beyond OAuth scopes, leaving the agent to infer usage without clear direction.

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

• ghl_calendar_service_location_createB
  3.1/5.0
  Behavior3/5

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

  Annotations indicate this is a write operation (readOnlyHint false) but not destructive (destructiveHint false). The description adds the endpoint URL and OAuth scopes, which are useful. However, it does not disclose whether the operation is idempotent (idempotentHint false) or what happens if a location with the same slug already exists. The behavioral information is adequate but not thorough.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and includes essential information: title, action, endpoint, and scopes. It is well-structured and easy to scan. A slightly more structured format (e.g., bullet points) could improve readability, but it is already 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?

  The tool has no output schema, and the description does not explain what the response will contain (e.g., the created service location object). For a create operation, this is a significant gap. The description also omits any error conditions or success indicators. Overall, it is not complete enough 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 input schema provides detailed descriptions, examples, and structure for all parameters, achieving 100% coverage. The description adds no extra meaning beyond what the schema already offers, so it does not compensate further. 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 creates a service location. The verb 'Create' and noun 'Service Location' are specific. However, it does not differentiate from sibling tools like ghl_calendar_service_location_update or ghl_calendar_service_location_delete, leaving ambiguity about when to use this tool over 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?

  The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, success criteria, or scenarios where this tool should be preferred over ghl_calendar_service_location_update or other calendar service location tools.

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

• ghl_calendar_service_location_getB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds OAuth scopes and endpoint method (GET), which aligns with the annotations. No contradictions, but no additional behavioral insights beyond what annotations provide.

  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 very concise, front-loading the purpose and then providing endpoint and auth details. Every sentence adds value, though the title repetition is minor 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?

  The tool has no output schema, and the description does not mention what is returned (e.g., full service location object). For a simple retrieval, it is barely adequate, lacking completion for effective use.

  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 parameter description 'Unique Service Location ID' and example. The description does not add new semantics 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get Service Location by ID', which is a specific verb+resource pair. It distinguishes from siblings like ghl_calendar_service_location_list by implying retrieval of a single item via ID, but does not explicitly differentiate.

  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 endpoint and OAuth scopes but gives no guidance on when to use this tool versus alternatives (e.g., list, create, update). Without context like 'Use after listing to get details', the agent lacks direction.

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

• ghl_calendar_service_updateB
  3.1/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds OAuth scopes (calendars.write), which is useful auth context. However, it does not disclose update semantics (partial vs full replacement), rate limits, 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise (3 lines) and front-loads the purpose. It includes endpoint and OAuth scopes. While very short, it avoids unnecessary verbosity. Could add more context without being wordy, but overall efficient.

  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 lacks crucial details for a complex update operation: no mention of what the response contains (no output schema), no explanation of whether it's a full replacement or partial update (PUT), and no notes on validation or required fields beyond the required parameters. This incompleteness hinders effective use.

  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 description adds no parameter-level information. The body parameter is complex, but the schema documents each field with examples. The description does not provide additional meaning, so baseline 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 states 'Update service by ID,' clearly indicating the verb and resource. It distinguishes from sibling tools like create, delete, get, list. However, it is very terse and does not elaborate on what properties can be updated, though the schema covers that.

  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, nor any when-not-to-use advice. Given the many sibling tools, this omission makes it harder for an agent to decide.

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

• ghl_contact_add_remove_from_businessB
  3.1/5.0
  Behavior3/5

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

  Annotations indicate non-readOnly and non-destructive. The description adds that passing null removes the businessId, providing behavioral insight. However, it doesn't detail idempotency or side effects beyond the null 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 concise with two sentences plus endpoint info. It front-loads the purpose. The endpoint line could be considered redundant but not harmful.

  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 bulk operation with nested objects and no output schema, the description lacks outcome details (success/failure, partial updates, response structure). Annotations provide some context but insufficient for a 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 input schema covers 100% of parameters with descriptions. The description adds value by noting that null businessId removes the association. Baseline 3 achieved with slight extra context.

  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 'Add/Remove Contacts From Business' and explains that passing null businessId removes the association. The resource (contacts) and action (assign/remove business) are clear, but it does not explicitly differentiate from sibling contact tools.

  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. No prerequisites, context, or when-not scenarios are provided.

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

• ghl_contact_create_noteB
  3.1/5.0
  Behavior3/5

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

  Annotations already indicate non-read-only (write) and non-destructive behavior. Description adds endpoint and OAuth scopes but does not disclose idempotency, error handling, or effects (e.g., whether note is appended or replaces existing notes).

  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?

  Description is very brief (3 lines) and front-loaded with the title. However, it is too sparse and could include more useful context without becoming verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Tool creates a note on a contact but does not describe the response format, error scenarios, or prerequisites (e.g., contact must exist). No output schema, so the description should compensate but fails to do so.

  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?

  Input schema has 100% description coverage for all properties, so the description adds no extra meaning to parameters beyond what the schema already provides. Baseline 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?

  Tool name and description clearly indicate 'Create Note' with endpoint details. Distinguishes from sibling tools by the verb 'create' but does not explicitly differentiate from related tools like ghl_contact_update_note or ghl_contact_get_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?

  Description provides no information about when to use this tool versus alternatives (e.g., ghl_contact_update_note). No prerequisites or context for use are given, leaving the agent to infer usage from the tool name alone.

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

• ghl_contact_create_taskB
  3.1/5.0
  Behavior2/5

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

  Annotations provide minimal behavioral hints (destructiveHint=false, etc.). The description adds some parameter constraints but does not disclose side effects, error behavior, or return value. Historical regression notes add context but do not improve transparency about the tool'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.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is overly verbose, beginning with regression notes that are not essential for an AI agent to use the tool. The core information (purpose, endpoint, requirements) is present but buried in 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?

  Given the nested body object and no output schema, the description provides the endpoint, OAuth scopes, and required fields. It lacks information on return values, error scenarios, and how the tool integrates with related actions like task retrieval or update.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and the description adds meaningful detail: it clarifies required fields, specifies ISO 8601 format for dueDate, and notes that completed:false is required even if counterintuitive. This provides value beyond 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?

  The description states 'Create Task' and provides the endpoint, making the action clear. However, the initial regression notes are verbose and could confuse an AI agent. The tool name itself is descriptive, and while it is one of several contact task tools, no explicit distinction from siblings is provided.

  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 gives specific requirements for the body fields (title, dueDate, completed must be present, dueDate must be ISO 8601) and mentions OAuth scopes. However, it does not guide when to use this tool versus update or delete, nor does it provide exclusions or alternatives.

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

• ghl_contact_deleteB
  3.1/5.0
  Behavior3/5

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

  Annotations already indicate this is a destructive and idempotent operation (destructiveHint: true, idempotentHint: true). The description adds the endpoint and OAuth scopes but no additional behavioral context beyond what the annotations provide.

  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 very brief, consisting of a single line and technical metadata. While it is concise, it lacks substantive guidance.

  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 delete tool with one parameter and existing annotations, the description is adequate but could be improved by specifying what happens on success or if the contact is permanently removed.

  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 sole parameter contactId is fully described in the input schema with type, example, and description (100% coverage). The tool description does not add any further 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 explicitly states 'Delete Contact', which clearly indicates the action and resource. This distinguishes it from sibling tools like ghl_contact_create or ghl_contact_update.

  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 removing a contact from a campaign. The description only includes technical endpoint details.

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

• ghl_contact_get_all_tasksB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, etc. The description adds the HTTP method and OAuth scopes. However, it does not disclose pagination, response format, or rate limits, which are relevant for a list endpoint.

  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 concise, including the purpose and key technical details (endpoint, version, scopes). It front-loads the purpose, though the first line is a repeat of the name.

  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, and the description does not explain the response structure, pagination, or filtering. For a 'get all' tool, this omission makes it incomplete and less actionable.

  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 parameter 'contactId' is described in the schema. The tool description adds no additional parameter semantics beyond 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?

  The description clearly states 'Get all Tasks', indicating a list retrieval. The endpoint confirms the resource. The name distinguishes it from sibling ghl_contact_get_task (single task). However, it doesn't explicitly differentiate from other list tools.

  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_contact_get_task or other contact tools. The description lacks any contextual usage cues.

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

• ghl_conversation_add_outbound_messageB
  3.1/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false; the description confirms it's a write operation for adding a call. No additional behavioral traits (e.g., whether the call is logged, if it triggers notifications) are disclosed, but it does mention required OAuth scopes.

  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 brief but includes redundant phrasing ('Post the necessary fields'). The endpoint and scopes information is useful but could be more focused. It does not waste words but could be better 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?

  Given the nested schema and no output schema, the description provides the endpoint and OAuth scopes, adding some context. However, it lacks information about return values, error handling, or side effects, making it minimally complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for all parameters; the description itself does not add semantic value beyond what the schema provides, meeting the baseline of 3.

  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 states 'Add an external outbound call' and provides the endpoint, clearly identifying the verb and resource. However, it does not differentiate from siblings like ghl_conversation_add_inbound_message, so it loses a point.

  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 (e.g., send_message or add_inbound_message). The technical details (endpoint, OAuth scopes) do not help an agent decide contextually.

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

• ghl_conversation_ai_create_actionB
  3.1/5.0
  Behavior3/5

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

  Annotations already indicate this is a write operation (readOnlyHint=false). The description adds OAuth scope information (conversation-ai.write) and endpoint details. However, it does not disclose potential side effects, idempotency, or behavior on duplicate requests. No contradiction with annotations.

  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 moderately lengthy, includes endpoint and OAuth details, but is front-loaded with purpose. Some redundancy (e.g., repeating 'Attach Action to Agent' in both title and description) could be trimmed. Acceptable for the 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 complexity (7 action types, nested body), the description provides only a high-level overview. It does not explain how to construct the body for each action type, nor does it describe the response (no output schema). The schema carries the burden, but the description lacks sufficient context for effective use.

  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 the two parameters (agentId and body) beyond referencing the schema. The schema itself has rich descriptions for nested fields, but the tool description adds no extra meaning for parameter usage or construction. Schema coverage is 50%, but the description does not 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?

  Clearly states it creates/attaches actions for AI agents, lists example action types, and distinguishes from sibling tools like ghl_conversation_ai_create_agent and ghl_conversation_ai_delete_action. The title 'Attach Action to Agent' aligns with the description.

  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 vs alternatives (e.g., other conversation AI tools). No conditions, prerequisites, or exclusions are provided. The description only explains what it does, not when to invoke it.

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

• ghl_conversation_get_messagesB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and not destructive. The description adds endpoint details, OAuth scopes, and pagination parameters, which provide some behavioral context beyond annotations but does not disclose return format or rate limits.

  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 moderately concise but redundantly repeats 'Get messages by conversation id' twice. The additional line with endpoint, scopes, and pagination is useful but could be integrated more efficiently.

  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 4 parameters, complete schema coverage, and no output schema, the description provides endpoint and OAuth scopes but lacks details on return format, error handling, or pagination behavior. It meets the minimum viable threshold but has gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description mentions pagination params but adds no new meaning beyond what schema descriptions already provide. No additional parameter semantics are offered.

  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 messages by conversation ID using a specific verb and resource. While it doesn't explicitly differentiate from siblings like ghl_conversation_get_message or ghl_conversation_get, the repeated emphasis on 'messages' (plural) and 'conversation id' makes the purpose 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?

  No guidance on when to use this tool versus alternatives (e.g., ghl_conversation_get_message for a single message). No mention of prerequisites or conditions where this tool should be chosen. The pagination note is present but insufficient for usage context.

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

• ghl_conversation_update_message_statusB
  3.1/5.0
  Behavior3/5

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

  Annotations already provide idempotentHint=true, destructiveHint=false, readOnlyHint=false. The description adds endpoint and scopes but no additional behavioral context. It does not contradict annotations.

  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?

  Concise at 3 lines, but the second line 'Post the necessary fields...' is somewhat redundant. Good structure with endpoint and scopes.

  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 and description does not explain return value or effects of status update. For a mutation tool, this is insufficient 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%, and the schema already describes parameters with examples. The description only says 'Post the necessary fields' which adds no new meaning beyond 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?

  The description clearly states the verb 'Update' and the resource 'message status', and provides the endpoint and OAuth scopes. It distinguishes the tool from siblings like 'ghl_conversation_update_email_message_status' by not mentioning email, but 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 on when to use this tool versus alternatives (e.g., ghl_conversation_update_email_message_status). No when-not-to-use or prerequisites mentioned.

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

• ghl_email_list_campaignsB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds the endpoint, OAuth scopes, and pagination parameters, which are useful. However, it does not disclose behaviors such as default sorting, rate limits, or what happens when no campaigns exist. No contradiction with annotations.

  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 concise and structured: title, action, endpoint, scopes, pagination. It avoids unnecessary details but could be slightly more streamlined by separating endpoint and scopes into a note. Overall, it is efficient.

  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 having no output schema, the description does not explain the response format or fields returned. It also omits default sorting, status meanings, and potential error conditions. For a listing tool, this leaves significant gaps in 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 description coverage is 100%, so the baseline is 3. The description adds minimal value by mentioning that limit and offset are pagination parameters. It does not elaborate on search or status parameters beyond what the schema 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's purpose: 'Get list of email campaigns for a location'. It specifies the resource (email campaigns) and the action (list). However, it does not differentiate itself from sibling listing tools like ghl_email_legacy_campaign_list or ghl_email_list_bulk_action_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 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 alternative listing tools. The description does not mention any conditions or exclusions. Users must infer usage from the tool name and endpoint alone.

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

• ghl_estimate_template_createB
  3.1/5.0
  Behavior2/5

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

  Annotations provide idempotentHint=false and destructiveHint=false, but description adds only endpoint and OAuth scopes. Does not disclose RbehaviorR such as what happens on success, error scenarios, or side effects beyond the mutation implied by 'Create'.

  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?

  Very concise at two lines but lacks structure. Every sentence is functional, though the technical details like endpoint and OAuth scopes could be integrated more cleanly.

  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 complexity of the input schema (nested objects) and no output schema, the description is incomplete. It does not explain return values, error handling, or how to properly construct the request body.

  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 schema already documents all parameters. The description adds no additional meaning or guidance on parameter usage, achieving baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Create Estimate Template' and 'Create a new estimate template', indicating the action of creating an estimate template. It distinguishes from sibling tools like ghl_estimate_template_delete, ghl_estimate_template_list, etc., which have different verbs.

  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 (e.g., ghl_estimate_template_update for updating). No prerequisites or context about when creation is appropriate provided.

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

• ghl_estimate_template_deleteB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true, so the destructive nature is acknowledged. The description adds the HTTP method, endpoint path, and OAuth scopes, which go beyond annotations but do not elaborate on irreversibility, side effects, or special 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 brief: a title, one-line summary, endpoint, and scopes. It avoids fluff and is front-loaded. Could be slightly more structured, but it's efficient for a delete 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?

  No output schema, but the description doesn't mention what happens on success or failure, or whether the deletion is permanent. The role of the body parameters (altId, altType) is not explained in context. More completeness would help, e.g., confirming that the template is permanently removed.

  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?

  Both parameters have descriptions in the schema (100% coverage). The description does not add further meaning beyond the schema; the body parameter's description is a meta-comment about the source. No extra clarity on how altId/altType are used.

  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 title 'Delete Estimate Template' and description 'Delete an existing estimate template' clearly state the verb (delete) and resource (estimate template). The endpoint is provided, but it does not explicitly differentiate from sibling tools like create or list; however, the 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 given on when to use this tool versus alternatives, prerequisites, or conditions. The description lacks any contextual advice such as 'use this when you need to remove a template' or 'do not use if template is in use.'

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

• ghl_estimate_template_updateB
  3.1/5.0
  Behavior3/5

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

  The description includes endpoint details and OAuth scopes, adding some behavioral context beyond annotations. However, it does not clarify whether updates are partial or full replacements, which is important given the openWorldHint annotation.

  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 concise with three short sentences. It front-loads the purpose but includes technical details (endpoint, version header) that, while informative, may be more than necessary for an AI agent.

  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?

  Without an output schema, the description should specify what is returned (e.g., the updated template object). It also lacks mention of the requirement that the template must exist. Given the complexity and sibling tools, the description is insufficiently 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%, so the input schema already documents both parameters thoroughly. The description does not add any additional parameter semantics beyond what is in the schema, meriting the baseline score of 3.

  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 it updates an existing estimate template, specifying the verb 'Update' and the resource 'estimate template'. However, it does not explicitly differentiate from the sibling tool ghl_estimate_template_create, which is for creating templates.

  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_estimate_template_create. It does not mention prerequisites such as the need for an existing template, nor does it give conditions or exclusions.

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

• ghl_estimate_update_last_visited_atB
  3.1/5.0
  Behavior2/5

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

  Annotations declare readOnlyHint=false and destructiveHint=false. The description adds no additional behavioral context (e.g., permissions, side effects). No contradiction, but no added value.

  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?

  Short but repetitive (first two sentences say same thing). Includes endpoint info which is extra but not harmful.

  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?

  Adequate for a simple timestamp update, but lacks usage guide. No output schema needed, but description does not mention return value or errors.

  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%; the description merely restates 'by estimate id' already in schema. No additional semantic insight beyond the structured input.

  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), resource (estimate last visited at), and identifier (by estimate id). It distinguishes from sibling tools like ghl_estimate_update or ghl_estimate_create by specifying the exact field being updated.

  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 vs alternatives. No prerequisites or context provided.

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

• ghl_form_get_submissionsB
  3.1/5.0
  Behavior3/5

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

  Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds pagination info but does not contradict annotations. The added value is limited beyond the structured data.

  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 short and includes key details like endpoint and OAuth scopes. However, the pagination note is somewhat vague ('pass them to page through full result sets'), slightly reducing clarity.

  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 is provided, and the description does not explain the structure of returned submissions. For a retrieval tool, this omission is significant, as the agent would need to know what fields are available.

  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 high (86%), and the sample schema provides detailed descriptions for most parameters. The description only mentions pagination params generally, adding little beyond the schema. Baseline 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 'Get Forms Submissions' and provides the endpoint, indicating retrieval of form submissions. However, it does not explicitly differentiate from sibling tools like 'ghl_form_list' or 'ghl_form_upload_custom_files', 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 Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description mentions OAuth scopes and pagination but provides no guidance on when to use this tool versus alternatives. There is no distinction between querying submissions vs. listing forms or other related operations.

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

• ghl_form_listB
  3.1/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint, idempotentHint, and nondestructive. The description adds endpoint details, OAuth scopes, and pagination info, which are useful beyond annotations. However, it fails to disclose what data is returned or any side effects (though none expected).

  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 brief and to the point, with no fluff. However, it could be better structured: the title is redundant with the first line, and the pagination info could be more clearly integrated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description should explain what the response contains (e.g., list of form objects, fields included). It only provides pagination hints but omits return structure, sorting, filtering, or pagination behavior details, making it incomplete for an AI agent.

  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 (25%: only limit has a description). The description lists pagination params (skip, limit) but does not explain 'type' or 'locationId' beyond being required. It adds minimal meaning beyond the schema for 3 out of 4 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 clearly states 'Get Forms' and provides the HTTP method and endpoint. The tool name and title align, making the purpose obvious. However, it does not differentiate from sibling form-related tools like ghl_form_get_submissions or ghl_ad_fb_conversation_form_list.

  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 mentions pagination parameters (skip, limit) and OAuth scopes, implying usage for listing forms. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., when to use ghl_form_get_submissions instead).

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

• ghl_funnel_delete_redirect_by_idB
  3.1/5.0
  Behavior3/5

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

  Annotations already provide destructiveHint=true and idempotentHint=true. The description confirms deletion and adds OAuth scopes but does not disclose side effects (e.g., cascading deletion) or recovery options. No contradiction with annotations.

  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?

  Relatively concise with a few sentences. Some redundancy (repeating title) and inclusion of endpoint/OAuth details which may not be essential for agent usage, but overall efficient.

  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 output schema and 2 undocumented required parameters, the description lacks information about return values, error conditions, and parameter meanings. Incomplete for a tool of 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 has 0% description coverage for parameters. The description only mentions 'using its unique identifier' for id but does not explain locationId. Required parameters are left unexplained, failing to add semantics beyond 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?

  Clearly states the verb (delete), resource (URL redirect), and method (by ID). However, it does not differentiate from sibling tools like ghl_funnel_update_redirect_by_id or ghl_funnel_create_redirect, leaving some ambiguity about when to use this versus alternatives.

  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?

  States 'Use this endpoint to delete a URL redirect' but does not provide explicit when-not-to-use scenarios, prerequisites (e.g., valid ID), or alternatives. The guidance 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.

• ghl_invoice_schedule_createB
  3.1/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false (write) and destructiveHint=false, so the description does not need to restate those. However, it adds the endpoint and OAuth scopes but does not disclose any behavioral traits such as creating a recurring invoice schedule, what happens upon creation, or any side effects. With annotations present, this is adequate but minimal.

  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 concise (4 lines) and front-loaded with the title and a clear verb-resource phrase. It includes endpoint and OAuth scopes without unnecessary words. However, it could be slightly more informative without being verbose, so 4.

  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 complexity of the input schema (many nested required fields), the description is too minimal. It does not explain what an invoice schedule is, how it relates to invoices, or what the return value looks like (no output schema). The sibling list hints at related tools but the description does not leverage that context. An agent would struggle to understand when to use this tool 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?

  The schema has 100% description coverage for its nested properties, so it already provides rich parameter semantics. The description adds no further parameter information. Baseline score of 3 is appropriate; no extra value from description.

  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 'Create Invoice Schedule' and 'API to create an invoice Schedule', which identifies the verb (create) and resource (invoice schedule). While it distinguishes from siblings by being the create operation among invoice schedule tools (activate, cancel, delete, etc.), it does not explicitly differentiate beyond the tool name, so a slight deduction.

  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 (e.g., when to create a schedule vs. update or activate). No prerequisites or exclusions mentioned. The description only states the endpoint and OAuth scopes, leaving the agent without usage context.

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

• ghl_invoice_schedule_updateB
  3.1/5.0
  Behavior3/5

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

  Annotations already indicate that the tool is not read-only (readOnlyHint=false), not destructive (destructiveHint=false), and idempotent (idempotentHint=true). The description adds OAuth scopes and endpoint details but does not disclose any additional behavioral traits beyond what annotations provide. It does not clarify whether the update overwrites all fields or merges, nor does it mention 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very concise, containing only two sentences and a few technical details. It is front-loaded with the purpose ('Update schedule') but lacks structure and focuses on endpoint details that may not be essential for an AI agent. Every sentence serves a purpose, but it could be more organized.

  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 complexity of the input schema (nested objects, many required fields) and the presence of multiple sibling schedule tools, the description is insufficient. It does not explain the effect of updates, constraints, or how this tool differs from similar ones. Without an output schema, an AI agent cannot understand what the tool returns.

  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, meaning all parameters have descriptions. However, the description of the 'body' parameter is generic ('Request body (schema carried verbatim from the official OpenAPI spec)') and adds no meaning beyond the schema. The schema itself is detailed, so the description does not need to compensate, but it also does not enhance understanding.

  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 that the tool updates a schedule by schedule ID. However, it does not distinguish this from sibling tools like ghl_invoice_schedule_update_and_activate, which also updates schedules. The verb 'update' and resource 'schedule' are specific, but the lack of differentiation from similar siblings prevents a perfect score.

  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_invoice_schedule_create, ghl_invoice_schedule_activate, or ghl_invoice_schedule_update_and_activate. An AI agent would have no context to choose this specific tool over others for update operations.

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

• ghl_kb_crawler_statusB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the endpoint and source details but no additional behavior (e.g., what 'latest operation' means, error handling, or response structure). With annotations present, a baseline of 3 is appropriate.

  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 two lines: a clear action statement and an endpoint reference. It is concise but the second line (Endpoint: ...) is somewhat technical and may not be essential for an agent. No wasted words, but could be slightly more streamlined.

  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 no output schema, and the description does not explain what information the status provides (e.g., progress, errors, completion percentage). For a read operation, this leaves the agent guessing about the return format. Sibling tools suggest multiple crawler operations, so more context would help.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All three parameters (locationId, operationId, knowledgeBaseId) are fully described in the input schema with types and examples. The description does not add any extra meaning or context beyond what the schema provides, so a baseline of 3 is given.

  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 'Get crawling status for the latest operation', which is a specific verb and resource. However, it does not distinguish this tool from sibling crawler tools like ghl_kb_crawler_train or ghl_kb_crawler_discover, which might also involve status tracking.

  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 alternative crawler tools. There is no mention of prerequisites, context for use, or exclusions.

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

• ghl_kb_create_knowledge_baseB
  3.1/5.0
  Behavior3/5

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

  Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds the behavioral constraint of a knowledge base limit (max 15 per location), but does not disclose other traits like creation side effects (e.g., default settings) or error scenarios. The limit is a positive addition but leaves gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence plus endpoint details, making it concise and front-loaded with the core action. It avoids fluff. However, it could be slightly more structured (e.g., listing constraints separately) to improve readability for agents.

  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 no output schema, the description should cover return value expectations (e.g., created resource ID) and common errors (e.g., limit exceeded). It does not. The sibling tools imply a broader CRUD context but the description remains isolated. The limit is useful but insufficient for full autonomous 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?

  Schema description coverage is 100% since the 'body' parameter has a description, albeit generic ('Request body...'). The tool description does not add meaning beyond the schema; it neither explains the purpose of 'name', 'locationId', nor 'description'. Baseline score of 3 is appropriate due to high schema coverage, but no enhancement from the description.

  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 'Create a new knowledge base' and includes a key constraint (max 15 per location). It is specific to the create operation, which distinguishes it from sibling tools like 'ghl_kb_update_knowledge_base' or 'ghl_kb_delete_knowledge_base'. However, it does not elaborate on what a knowledge base represents within the system.

  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 lacks explicit guidance on when to use this tool versus alternatives like 'ghl_kb_update_knowledge_base' for modifications. It only provides a constraint (max 15 per location) but no context on prerequisites (e.g., locationId must exist) or complex workflows. No when-not-to-use advice.

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

• ghl_link_listB
  3.1/5.0
  Behavior3/5

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

  Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds endpoint and OAuth scopes but omits pagination, response structure, or whether filtering is supported. With annotations bearing the safety burden, a 3 is appropriate.

  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 short (three lines) and front-loads the core action. However, it includes technical details (OAuth scopes) that may not be actionable for an AI agent, slightly reducing efficiency.

  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 lacks domain context: it does not explain what 'links' are in this system (e.g., shortened URLs, referral links). With no output schema, the description should clarify the return format or entity semantics to enable correct usage.

  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% for the single parameter with a description. The tool description adds no additional meaning beyond the schema, meeting the baseline expectation.

  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 states 'Get Links' and includes the endpoint, clearly indicating a list operation. However, it does not differentiate from sibling tools like ghl_link_get_by_id or ghl_link_search_trigger, leaving ambiguity about scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, filtering, or that it returns all links for a location, nor does it exclude other tools.

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

• ghl_location_create_custom_fieldB
  3.1/5.0
  Behavior3/5

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

  The description adds endpoint URL, version header, and OAuth scopes, which provide behavioral context beyond annotations (e.g., auth requirements). However, it omits any mention of the return format or response expectations, and annotations already cover safety traits.

  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 concise, with only three lines and no redundant information. It front-loads the core action and provides necessary technical details efficiently.

  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 schema being detailed, the description lacks information about the output or return value, which is missing due to no output schema. Given the tool's complexity (nested body, required params) and the presence of similar siblings, the description should at least hint at the response or why to use this location-specific variant.

  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?

  With 100% schema description coverage, the input schema already documents all parameters. The description does not add additional parameter-level meaning beyond what the schema provides, meeting the baseline but not exceeding it.

  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 and resource ('Create Custom Field') and the endpoint indicates location-specificity. However, it does not explicitly differentiate from the sibling tool ghl_custom_field_create, which may cause confusion; the distinction is only implied by 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?

  The description provides no guidance on when to use this tool versus alternatives like ghl_custom_field_create. There is no mention of prerequisites, when not to use, or comparisons with siblings.

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

• ghl_location_get_custom_fieldsB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which sufficiently convey safety and repeatability. The description adds the OAuth scopes and endpoint version, which provide minor context but no behavioral traits beyond annotations. No contradictions.

  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 very short but includes a title, endpoint, version, and scopes. It is concise but lacks substantive detail beyond technical metadata, making it minimally adequate.

  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 lack of an output schema, the description should mention what the tool returns (e.g., custom fields for the location, optionally filtered by model). It does not address return values or pagination, leaving some gaps for a read 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?

  Schema coverage is 100% with clear descriptions for both parameters. The description adds no additional meaning beyond the schema, meeting the baseline.

  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 states 'Get Custom Fields' which clearly identifies the action and resource. However, it does not differentiate this tool from related siblings like 'ghl_custom_field_get_by_id' or 'ghl_location_create_custom_field', so it is not fully distinctive.

  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 any prerequisites or exclusion criteria. The description only lists technical details (endpoint, scopes) without usage context.

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

• ghl_location_get_custom_valuesB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds OAuth scopes and endpoint method (GET), which are consistent. No contradiction, but minimal extra behavioral context beyond annotations.

  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?

  Description is short but includes verbose technical details (version header, source) that may not be useful for an AI agent. Could be more concise while still conveying 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 read operation with one parameter, the description is adequate but lacks explanation of return values (no output schema). Includes OAuth scopes for authorization 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 a clear description for locationId. The description does not add additional parameter meaning beyond the schema, so 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 tool retrieves custom values for a location using 'Get Custom Values' and provides the endpoint. It distinguishes from sibling tools that create, delete, or update custom values, but does not explicitly differentiate from other get tools like ghl_location_get_custom_field.

  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. The description only includes technical details (endpoint, OAuth scopes) without explaining usage context or distinguishing from siblings.

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

• ghl_location_searchB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and nondestructive nature. The description adds pagination behavior (skip/limit) and OAuth scopes. However, it does not explain search semantics (exact vs. partial match) or result structure. No contradiction with annotations.

  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 concise, containing endpoint, scopes, and pagination notes. The first line 'Search' is redundant but not harmful. All sentences are relevant, and the information is 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 no output schema, the description should explain return value structure or field details. It does not. The tool has 5 optional parameters, but the search behavior (e.g., how email filter works) is unclear. Completeness is lacking for a search 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?

  Schema description coverage is 80% (4 of 5 parameters have descriptions). The description mentions pagination params but does not add meaning beyond what the schema provides. The 'email' parameter lacks schema description and is not explained in the description either.

  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 it searches for sub-accounts (formerly locations) and provides the endpoint. The name 'ghl_location_search' combined with the description makes the purpose clear. However, it does not explicitly describe what is returned or contrast with sibling search tools.

  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 (e.g., ghl_contact_search_advanced, ghl_location_get). No when-to-use or when-not-to-use information is provided.

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

• ghl_object_create_recordB
  3.1/5.0
  Behavior3/5

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

  Annotations provide readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds useful context: body accepts arbitrary JSON (convention of 'properties' object) and OAuth scopes (objects/record.write). But the confusing spec gap note detracts, and no mention of idempotency 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.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description includes a verbose 'SPEC GAP' paragraph that is irrelevant for an AI agent. The useful part is relatively short, but the extraneous information harms conciseness and structure.

  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 creation tool with 2 params and no output schema, the description covers body flexibility and schemaKey prefix but lacks return format, error handling, or examples of when creation might fail. The spec gap note adds confusion rather than completeness.

  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?

  Both parameters have schema descriptions (100% coverage). The description adds value: for 'body', it explains arbitrary JSON and the expected 'properties' structure; for 'schemaKey', it details prefix requirements and examples beyond 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?

  The description states 'Create a Custom Object Record' and mentions supported objects (business and custom objects), clearly indicating the action and resource. However, the initial 'SPEC GAP' text and note about empty schema are distracting and reduce clarity slightly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives like ghl_object_update_record or ghl_object_get_record_by_id. The description does not differentiate based on use case or prerequisites.

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

• ghl_object_update_recordB
  3.1/5.0
  Behavior2/5

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

  Annotations provide readOnlyHint=false, idempotentHint=true, destructiveHint=false, but the description does not clarify if the update is partial or full replacement, nor does it explain idempotency or other behavioral implications.

  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 verbose with a technical 'SPEC GAP' note and a documentation link that are not immediately actionable. The core purpose is buried, making it less efficient.

  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 a complex nested parameter (body) and no output schema, the description does not adequately explain the body format, constraints, or response structure. The spec gap note is confusing rather than helpful.

  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%; the description adds value for the 'body' parameter via the spec gap note explaining the empty schema and expected properties format. However, other parameters like 'locationId' lack additional context.

  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 explicitly states 'Update a Custom Object Record by Id' and lists supported objects (business and custom objects). This clearly distinguishes it from sibling tools like create, delete, or get.

  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 mentions it updates records by ID and supports business/custom objects, but lacks explicit when-to-use, when-not-to-use, or prerequisites. No guidance on alternatives.

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

• ghl_object_update_schemaB
  3.1/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds OAuth scopes and endpoint version, but does not disclose other behavioral traits like field replacement behavior or side effects. With annotations present, the description adds some value but not significant depth.

  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 moderately concise but includes extraneous information (rename note, full documentation URL, endpoint details) that could be omitted or placed elsewhere. The core purpose is front-loaded, but overall structure is somewhat cluttered.

  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 complexity and well-documented schema, the description is adequate but lacks details on return values, error states, or usage examples. No output schema exists, so the description could provide more context about what happens after a successful update.

  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 input schema already documents both parameters ('key' and 'body') well. The description does not add new meaning beyond what the schema provides, achieving the baseline score.

  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 updates object schemas (custom or standard) by key, and pairs with ghl_object_get_schema_by_key. The purpose is specific, but the description includes unnecessary details like the rename note and full endpoint string, slightly diluting 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 explicit guidance on when to use this tool versus alternatives. While it mentions pairing with ghl_object_get_schema_by_key, there is no differentiation from other schema-related tools (e.g., ghl_object_create_custom_object, ghl_object_list) 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.

• ghl_payment_custom_provider_createB
  3.1/5.0
  Behavior2/5

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

  Annotations indicate non-readonly and non-destructive behavior, but the description adds no behavioral details such as side effects, expected response format, or authorization requirements beyond OAuth scopes. The agent lacks info on what happens after creation.

  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 short and front-loaded with the purpose (first sentence). Every sentence provides useful info (endpoint, scopes). No fluff, but could be slightly more informative 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?

  Despite high schema coverage, the description lacks crucial context: no response format, no prerequisites (e.g., location must exist), and no explanation of what 'association' means. The tool is moderately complex (nested body) but the description fails to provide a complete 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?

  Schema coverage is 100% with good parameter descriptions. The tool description adds no extra meaning beyond the schema, so baseline score 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 tool creates a new payment integration (custom provider) for a location, using specific verb ('create') and resource ('new integration'). It also provides the endpoint and distinguishes from sibling tools like delete and update by focusing on creation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives like create_config or update. The description lacks context for selecting this tool over other payment custom provider tools.

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

• ghl_product_review_listB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint, so the safety profile is clear. The description adds pagination and OAuth scopes but doesn't detail rate limits, data freshness, or response structure (no output schema).

  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 short and front-loaded with the purpose. It includes endpoint, OAuth scopes, and pagination without unnecessary fluff. Every sentence adds value.

  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 11 parameters and no output schema, the agent lacks information about the response format and filtering behavior. The description covers pagination but not how filters (rating, date, store, product) interact or what the returned data looks like.

  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 91%, so baseline is 3. The description mentions pagination params (limit, offset) explicitly, but other parameters are not described in the description. The schema already documents them sufficiently.

  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 'Fetch Product Reviews' and includes the endpoint and OAuth scopes. The tool name and description align, and it is distinct from sibling review tools like bulk_update, count, delete, update.

  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 vs alternatives (e.g., ghl_product_review_count). There is no mention of use cases or exclusion conditions.

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

• ghl_product_store_get_statsB
  3.1/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds the endpoint URL and OAuth scopes, which are useful but not deep behavioral insights (e.g., no mention of pagination, rate limits, or what 'other stats' includes). No contradiction with annotations.

  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?

  Three sentences covering purpose, details, and endpoint/scopes. The first sentence is slightly redundant with the title, but overall compact and front-loaded with the essential purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema is present, yet the description only vaguely mentions 'other stats' without detailing the response structure. It does not explain how parameters affect results (e.g., collectionId filtering). For a 5-parameter tool with no output schema, the description is insufficiently 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 description coverage is 80% (4 of 5 parameters have descriptions). The description does not add any extra semantic context for parameters like altId, altType, search, or collectionIds beyond the schema. Baseline 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 'Fetch Product Store Stats' and elaborates on what it retrieves (total products, included, excluded, other stats). It is specific to product store stats and implicitly distinguishes from sibling write tools (e.g., set_inclusion, set_priority) by being a read operation, though not explicitly differentiating from other stats tools.

  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_product_list or ghl_product_get. Does not mention prerequisites, exclusions, or scenarios where other tools would be more appropriate. The readOnlyHint is present but not leveraged in the description.

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

• ghl_product_store_set_priorityB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds the HTTP method and endpoint, providing some context, but does not elaborate on behavior like whether priorities are replaced or appended, or if there are rate limits or authorization requirements. It adds marginal transparency beyond annotations.

  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 short but contains slight redundancy between the first two sentences ('Update product display priorities in store' and 'API to set the display priority of products in a store'). The endpoint information is useful but could be integrated more concisely.

  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 a nested request body with required fields (altId, altType, products), but the description does not explain these or the expected format of the products array. The schema provides the details, partially filling the gap, but for a mutation tool with complex input, additional 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 provides 100% coverage of parameter descriptions, including examples and descriptions for all parameters. The tool description adds no additional parameter semantics, meeting the baseline but not exceeding it.

  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 clear action verbs ('update', 'set') and specifies the resource ('product display priorities in store'). It distinguishes from sibling tools like ghl_product_store_get_stats and ghl_product_store_set_inclusion, which have different purposes. However, it could be more specific about what 'display priorities' means (e.g., ordering in store listing).

  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_product_store_set_inclusion or other product update tools. It assumes the agent will infer based on the name and description, but lacks explicit context for selection.

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

• ghl_proposal_send_documentB
  3.1/5.0
  Behavior3/5

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

  Annotations mark readOnlyHint as false (write operation) and destructiveHint as false, which is consistent with 'send'. The description adds the endpoint but does not disclose any side effects (e.g., triggers notifications, changes document status). Minimal extra context beyond annotations.

  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 short (3 lines) but the first line repeats the title, and the second adds minimal clarification. The third line is technical endpoint info. Could be more structured or informative without being 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?

  Given no output schema and a moderately complex input, the description lacks details on return values, when to use different mediums (email vs link), and prerequisites. However, the schema provides good parameter documentation, so 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%, so the input schema already documents each parameter's meaning. The description adds no additional parameter semantics, only the endpoint. Baseline 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 'Send document' and 'Send document to a client', which conveys the primary action. The tool name includes 'proposal', so the type of document is implied. However, it does not explicitly distinguish from siblings like 'ghl_proposal_send_template', which also sends a proposal-related item.

  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, nor any comparison to sibling tools such as ghl_proposal_send_template or ghl_proposal_list_documents.

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

• ghl_saas_get_location_subscriptionB
  3.1/5.0
  Behavior4/5

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

  Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context: agency-level token requirement and the specific endpoint/version details. No contradictions with annotations.

  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 relatively concise but contains some redundancy (e.g., both a title phrase and a similar statement). It front-loads the security requirement, which is helpful, but could be more streamlined.

  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 and lack of output schema, the description covers purpose, security, and endpoint. However, it lacks context about return format, typical use cases, or relationship to other saas tools, leaving some 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 input schema has 0% description coverage for parameters. The description only hints at locationId's role via the endpoint and overall purpose, but does not explain companyId or provide any additional semantics beyond 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?

  The description clearly states the action ('Get Location Subscription Details' and 'Fetch subscription details for a specific location'), using specific verbs and identifying the resource. While it distinguishes itself from sibling tools by naming, it could be more explicit about what 'subscription details' 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?

  The description mentions an agency-level token requirement but offers no guidance on when to use this tool versus alternatives (e.g., deprecated version or other saas tools). No when-not-to-use or context for selection is provided.

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

• ghl_snapshot_create_share_linkB
  3.1/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds context beyond annotations by specifying the required token type (agency-level) and the POST endpoint. However, it does not disclose other behavioral traits like side effects 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, front-loaded with the critical security constraint. The repetition of 'Create Snapshot Share Link' adds minor redundancy. Overall efficient 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?

  No output schema and no description of the return value (e.g., what the share link contains or how to use it). For a creation tool that likely returns a link or object, this is a notable gap. Annotations partially compensate but the description is 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 50% (companyId lacks description), but nested parameters in 'body' have descriptions. The description text adds no new meaning to parameters beyond what the schema provides. Baseline is 3 due to adequate 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?

  Description explicitly states 'Create Snapshot Share Link' and 'Create a share link for snapshot', clearly identifying the action and resource. The tool name and sibling context (other snapshot ops like list, get pushes) further differentiate it. However, no explicit distinction from siblings is made in the description.

  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 emphasizes the required agency-level token but provides no guidance on when to use this tool versus alternatives (e.g., other snapshot operations). No exclusions or when-not-to-use scenarios are mentioned.

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

• ghl_social_delete_queue_itemB
  3.1/5.0
  Behavior3/5

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

  Annotations already mark destructiveHint=true, and the description confirms the deletion action. It adds OAuth scopes and endpoint details but does not disclose potential side effects or recovery options. No contradiction with annotations.

  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 concise but includes technical endpoint details (version header, source) that may not be essential for an AI agent. It could be more streamlined.

  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 is provided, and the description does not state what response to expect after deletion. For a destructive action, this omission reduces completeness.

  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 the parameters itemId, queueId, sessionId, or locationId beyond what the schema provides. Schema coverage is 50%, and the description adds no clarifying 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?

  The description clearly states the verb 'Delete' and the resource 'item from a queue'. It distinguishes itself from sibling tools like create, update, and clone queue items by specifying deletion as the action.

  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 guidance on when to use this tool versus other queue-related tools. No mention of prerequisites, scenarios, or alternatives.

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

• ghl_social_get_facebook_page_groupB
  3.1/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the endpoint URL but does not elaborate on behavioral traits like return data or side effects. It does not contradict annotations.

  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 concise with two lines (one sentence and endpoint). No unnecessary fluff. Could be more structured but it is efficient.

  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, yet the description does not explain what the tool returns. The name vs description mismatch (pages vs accounts) adds confusion. For a tool with good annotations, it lacks return value 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 descriptions for both parameters (accountId and locationId). The description adds no additional meaning beyond the schema, which is adequate per baseline.

  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 states 'Get facebook pages', which is a specific verb and resource. However, there is a slight mismatch with the tool name 'get_facebook_page_group' (singular vs plural, pages vs accounts from endpoint path). It does not differentiate from sibling tools like ghl_social_get_instagram_page_group.

  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 vs alternatives. No mention of prerequisites or when not to use it. Among many sibling social media tools, explicit usage context is absent.

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

• ghl_social_get_instagram_page_groupB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds endpoint technicalities but no additional behavioral traits. No contradiction with annotations.

  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 very short—two lines—and front-loaded with the purpose. However, it includes unnecessary technical endpoint details (URL, version header) that are not helpful for an AI agent.

  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?

  Without an output schema, the description fails to explain what data the tool returns, what a 'Professional Account' entails, or any prerequisites. This leaves significant gaps in understanding 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?

  Both parameters are described in the input schema (accountId and locationId). The description does not add any semantic meaning beyond what the schema provides, so baseline 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 'Get Instagram Professional Accounts', which identifies the action and resource. However, it does not differentiate from sibling tools like ghl_social_get_facebook_page_group or ghl_social_get_linkedin_page_profile, which serve similar purposes for different platforms.

  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 includes endpoint details, not usage context or exclusions.

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

• ghl_store_create_shipping_rateB
  3.1/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, aligning with a create operation. The description adds no extra behavioral context such as idempotency, rate limits, or permission requirements. With annotations present, the description provides minimal added value.

  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 concise at two sentences plus endpoint, but the endpoint details are more implementation-oriented. It front-loads the title effectively.

  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 complexity (many nested parameters, no output schema), the description is minimal. It lacks information on response structure, error handling, or non-obvious constraints, leaving the agent underinformed.

  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?

  Input schema coverage is 100%, with detailed descriptions for all properties. The description does not add meaning beyond the schema. 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 creates a new shipping rate and provides the endpoint. However, it does not differentiate from sibling tools like ghl_store_create_shipping_carrier or ghl_store_create_shipping_zone, leaving ambiguity for an AI agent.

  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, what prerequisites are needed (e.g., existing shipping zone), or any context for invocation. The agent has no decision support.

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

• ghl_survey_get_submissionsB
  3.1/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint, so the safety profile is clear. The description adds OAuth scopes and pagination behavior. However, it does not disclose that locationId is required or the filtering capabilities, which are important behavioral traits.

  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 concise with three sentences, front-loading the purpose. It includes technical details like version header and file path that may not be essential but do not detract significantly. Structure is adequate for the length.

  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 7 parameters, 1 required, and no output schema, the description should cover filtering options (q, date range, surveyId) and the required locationId. It also lacks mention of the returned data structure. Annotations help, but the description is insufficient for a complete understanding.

  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 high (86%), so the schema documents most parameters well. The description explains how page and limit are used for pagination, adding value beyond the schema. It does not describe other parameters like q, startAt, endAt, surveyId, or note that locationId is required.

  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 it retrieves survey submissions. The keyword 'Get Surveys Submissions' effectively conveys the action, and the endpoint details reinforce the purpose. However, it does not explicitly distinguish from similar tools like ghl_survey_list, which lists 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?

  No guidance on when to use this tool versus alternatives, such as ghl_form_get_submissions or ghl_survey_list. The description mentions pagination but does not indicate prerequisites or scenarios 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.

• ghl_voice_ai_create_agentB
  3.1/5.0
  Behavior2/5

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

  Annotations already indicate a write operation (readOnlyHint=false, destructiveHint=false). The description adds the endpoint and scopes but does not disclose what the tool returns upon success, whether it is idempotent, or side effects like creating a new agent in the system. With minimal annotation coverage, the description should provide more 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very short (three lines), but it front-loads the core purpose. It includes technical details like endpoint and scopes, which are useful but could be more structured. Some waste is acceptable given the schema's richness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description does not explain what the tool returns after creation (no output schema provided). It lacks mentions of prerequisites (e.g., location must exist) or constraints beyond the schema. For a complex creation tool, this is 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?

  The input schema has 100% coverage with detailed descriptions for all parameters. The tool description adds no additional parameter-level meaning beyond what the schema already provides. Baseline score of 3 is appropriate given the schema's thoroughness.

  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 voice AI agent configuration and settings', which identifies the specific verb and resource. The title 'Create Agent' reinforces this. It distinguishes from sibling tools like ghl_voice_ai_patch_agent or ghl_voice_ai_delete_agent by specifying creation.

  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 endpoint and OAuth scopes but offers no guidance on when to use this tool versus alternatives (e.g., ghl_voice_ai_patch_agent for updates). It does not mention prerequisites or contextual cues for selection.

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

• ghl_ad_fb_adset_duplicateB
  3.2/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, which is consistent. The description adds OAuth scopes and endpoint info, but does not disclose what happens to the original ad set, any limits, or that the operation creates a new ad set. Does not contradict annotations.

  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 short but contains redundancy ('Duplicate ad set' and 'Duplicate an existing Facebook ad set' say the same thing). Could be streamlined to one sentence and include essential details without 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?

  The tool performs duplication but does not describe the return value (e.g., the new ad set ID). With no output schema, the description should indicate what the response contains. Missing this information reduces 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 coverage is 100% with one parameter (adSetId) described. The description does not add additional meaning beyond what the schema provides (e.g., format, origin of the ID). Baseline score 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?

  Clearly states 'Duplicate ad set' and 'Duplicate an existing Facebook ad set', with a specific verb and resource. It is distinguishable from siblings like ghl_ad_fb_adset_delete, ghl_ad_fb_adset_upsert, and ghl_ad_fb_campaign_duplicate.

  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 vs alternatives (e.g., creating a new ad set from scratch). The description lacks context for when duplication is appropriate and does not mention excluded scenarios.

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

• ghl_ad_fb_page_lead_form_createB
  3.2/5.0
  Behavior3/5

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

  Annotations indicate non-readonly, non-idempotent, non-destructive. The description adds OAuth scopes, which is useful for authorization. However, it does not disclose side effects or state changes beyond the creation action itself. The description adds marginal value over annotations.

  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 brief (two lines plus endpoint/scopes) but lacks structured usage guidance. It is concise but not optimally front-loaded for quick decision-making. Every line serves a purpose, but more context would improve usability.

  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 complexity (nested objects, many properties, no output schema), the description does not explain the response format or mention that forms may need separate publishing steps. The agent lacks context about the full lifecycle.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with detailed descriptions for all parameters and nested objects. The description does not add meaning beyond what the schema already provides. Achieves the baseline of 3 for high-coverage schemas.

  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 creates a lead gen form on a Facebook page, using a specific verb and resource. It distinguishes from sibling tools like ghl_ad_fb_page_lead_form_list and ghl_ad_fb_lead_form_get, which handle listing and retrieval.

  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 such as ghl_ad_fb_conversation_form_create. It mentions OAuth scopes but lacks contextual prerequisites or exclusions. The agent is left to infer usage from the name alone.

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

• ghl_ad_google_asset_listB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the description adds the endpoint and OAuth scopes which are helpful but not about behavior. It does not mention pagination or response format, but is adequate for a read-only 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 very concise: two sentences plus endpoint and OAuth scopes. No wasted words, front-loaded with purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 4 parameters and no output schema. The description does not mention that it returns a list, nor does it explain how to interpret the parameters or what to expect as output. This is a significant gap 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 coverage is 100%, so baseline is 3. The description does not add any extra meaning to parameters 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 it retrieves Google Ads creative assets for a location, which matches the tool name 'asset_list'. However, 'Retrieve' could imply a single asset, but the name disambiguates. It distinguishes from siblings like the upsert tool.

  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 (e.g., create/update via asset_upsert). Missing context on required parameters and filtering. The OAuth scopes are mentioned but not usage context.

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

• ghl_ad_google_campaign_reporting_getB
  3.2/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description only adds endpoint details and OAuth scopes, which are already implied by annotations. It does not disclose additional behavioral traits such as rate limits or response format.

  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 concise with two sentences, plus endpoint and scopes. It front-loads the purpose and avoids unnecessary 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?

  No output schema exists, and the description does not specify what reporting metrics are returned (e.g., impressions, clicks). It adequately explains the purpose and required parameters but lacks detail on the 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 description coverage is 100% with all four parameters having descriptions. The description does not add extra meaning beyond what the schema provides. 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 retrieves reporting metrics for a specific Google campaign. It distinguishes from sibling tools like ghl_ad_google_campaign_get (which gets campaign details) and ghl_ad_google_reporting_get (likely for overall reporting) by specifying 'for a specific Google campaign'.

  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_ad_google_reporting_get or ghl_ad_google_reporting_list. It does not mention when-not or usage context.

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

• ghl_ad_google_reporting_getB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds endpoint details and OAuth scopes but no additional behavioral traits beyond what annotations provide. It does not contradict annotations, so score is moderate.

  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 very concise at three sentences, front-loading the core purpose. It includes necessary technical details (endpoint, OAuth scopes) without verbosity. However, the technical specifics may not always be essential for an AI agent, slightly reducing efficiency.

  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 read-only reporting tool with comprehensive schema and annotations, the description covers the basic purpose and authorization. However, it lacks guidance on when to use this specific tool versus other reporting tools (e.g., campaign-level, Facebook, LinkedIn), and does not explain the return value structure. Completeness is adequate but not thorough.

  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, meaning each parameter is already documented in the schema (e.g., type, fields, dates, locationId). The tool description does not add any extra meaning or clarify parameter relationships or dependencies, so it meets the baseline of 3 but does not improve it.

  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 it retrieves aggregated Google Ads reporting metrics for a location. It is specific about the resource (Google Ads reporting) and the action (get), but it does not explicitly differentiate from sibling tools like ghl_ad_google_reporting_list or ghl_ad_google_campaign_reporting_get, which could be confused for similar 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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention context like 'use for aggregate metrics across campaigns' or distinguish from campaign-level reporting. There are no explicit when-to-use or when-not-to-use indications, leaving the agent to infer from the name alone.

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

• ghl_ad_google_segment_deleteB
  3.2/5.0
  Behavior3/5

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

  Annotations already provide destructiveHint=true and idempotentHint=true. Description adds OAuth scopes and endpoint details but lacks information on permanence, cascading effects, or constraints.

  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?

  Short and front-loaded with purpose, but first line 'Delete segment' is redundant with the title. Endpoint details are useful but add some technical verbosity.

  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?

  Adequate for a simple delete action, but missing response expectations, error conditions, and prerequisites. No output schema exists, so description could compensate.

  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 parameters documented and examples. Description adds no extra meaning to the 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?

  Description clearly states it deletes a Google Ads audience segment by ID, and the resource is distinct from sibling tools like get, list, and upsert. However, it doesn't explicitly differentiate from other delete tools across platforms.

  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 update or get. Prerequisites, such as segment existence or permission requirements beyond OAuth scopes, are not mentioned.

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

• ghl_agent_studio_update_metadataB
  3.2/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false, but description adds that it's a PATCH endpoint and lists OAuth scopes. However, it doesn't elaborate on idempotency or side effects. Meets minimum but no extra depth.

  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 short and includes endpoint and scopes, but the technical details could be considered redundant. Still, it is efficient with 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?

  No output schema and no mention of return values. The description lacks details on response format, success indicators, or common errors. Given the tool's complexity and many siblings, it's insufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 33%, and the description does not explain the 'source' or 'agentId' parameters. It lists some body fields but adds no 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 clearly states the verb 'Update' and the resource 'Agent Metadata', listing specific fields (name, description, status). It distinguishes from sibling tools like create, delete, and 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?

  No guidance on when to use this tool versus alternatives, no prerequisites or exclusions mentioned. The description only states what it does without context.

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

• ghl_association_deleteB
  3.2/5.0
  Behavior4/5

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

  Annotations (destructiveHint=true, idempotentHint=true) are supplemented by the description noting that deleting an association also removes all its relations. OAuth scopes are specified, adding authorization context.

  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 brief and front-loaded with the action. Endpoint and scopes are appended efficiently. Minor grammar issue does not detract from conciseness.

  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, the description omits return value and error conditions. It covers deletion behavior and auth, but lacks explanation of what an association is and response details.

  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 sole parameter 'associationId' is only described as 'By Id' in the title; no additional meaning, format, or constraints are provided. Schema coverage is 0%.

  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 explicitly states 'Delete Association' and 'Delete USER_DEFINED Association By Id', clearly identifying the action and resource type. It distinguishes from sibling creation and update tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives like ghl_association_update or ghl_association_create. The phrase 'USER_DEFINED' implies a scope, but conditions or exclusions are absent.

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

• ghl_association_get_relations_by_record_idB
  3.2/5.0
  Behavior4/5

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

  Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds behavioral details beyond annotations: it mentions the HTTP endpoint, OAuth scopes (associations/relation.readonly), and explicitly states that pagination parameters (skip, limit) are needed to get full result sets. This provides useful context about how to use the tool effectively.

  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 mostly concise, with the pagination hint being the most valuable part. However, the first sentence is duplicated ('Get all relations By record Id' appears twice), which is unnecessary and slightly bloated. Otherwise, the structure is straightforward.

  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 5-parameter schema with 40% coverage and no output schema, the description provides endpoint, OAuth scopes, and pagination info, but lacks details on the return structure, what constitutes a 'relation', and the purpose of the required locationId. The description is not fully complete for an agent to understand the tool's output or handle edge cases.

  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 40%, with only locationId and associationIds having descriptions. The description does not explain the recordId parameter or clarify the meaning of associationIds beyond the schema. It mentions skip and limit but adds no semantic detail beyond what the schema provides. 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Get all relations By record Id', which clearly indicates the tool retrieves all relations for a given record ID. The name and description together distinguish it from other 'get' tools like ghl_association_get_by_id, though the description could be more explicit about what 'relations' are.

  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_association_get_by_id or ghl_association_get_by_key_name. The only usage hint is about pagination (skip/limit), which helps with invocation but not selection.

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

• ghl_brand_board_deleteB
  3.2/5.0
  Behavior2/5

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

  Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds endpoint and OAuth scopes but does not explain behavioral traits like permanence of deletion, what happens if board doesn't exist, or side effects. Little value beyond annotations.

  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?

  Description is short and includes essential technical details (endpoint, scopes). Minor repetition of 'Delete a Brand Board' but otherwise efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool, the description is adequate but could be improved. No output schema exists, so describing the return value (e.g., success status) would help. Missing error scenarios or authorization details beyond OAuth scopes.

  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 both parameters are described in schema. The tool description adds no additional information about parameters beyond what is already in input 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 it deletes a Brand Board, using specific verb 'Delete' and resource 'Brand Board'. It distinguishes from sibling tools like ghl_brand_board_create or ghl_brand_board_update by focusing on deletion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives. Does not mention prerequisites (e.g., board must exist), when not to use, or provide context for selecting this over other brand board operations.

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

• ghl_calendar_block_slot_updateB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the description does not need to repeat those. However, it adds OAuth scopes and endpoint info but does not disclose any additional behavioral traits like potential side effects, return value, or error conditions. For a mutation tool with annotations, this is adequate but not enriching.

  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?

  Description is very concise, consisting of a title, a single-sentence description, endpoint, and scopes. It avoids unnecessary detail and is easy to parse. However, the title is repeated verbatim, and the structure could be more front-loaded with the most critical information.

  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 2 parameters (one nested), full schema coverage, and no output schema, the description is minimal but functional. It does not explain the effect of updating a block slot, the significance of the eventId parameter (e.g., masterEventId for recurring), or any response details. Adequate for a straightforward update 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?

  Schema coverage is 100%, so baseline is 3. The description does not add any additional meaning or context for the parameters beyond what the schema already provides. For example, it does not explain the structure or constraints of the 'body' parameter. No enhancement over 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 clearly states verb 'Update' and resource 'block slot', and specifies it updates by ID. However, it does not clarify what a block slot is or distinguish it from other block slot operations (e.g., create, delete), though the verb inherently differentiates. Sibling tools with similar names like ghl_calendar_block_slot_create exist, but no explicit differentiation is provided.

  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 (e.g., create, delete, list). Does not mention prerequisites, constraints, or contexts where this tool is appropriate. The description lacks any usage direction beyond the basic update action.

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

• ghl_calendar_event_schedule_getB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the description merely reinforces the safe, read-only nature. It adds minimal behavioral context beyond what annotations provide.

  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 short and front-loaded with the action. However, it includes endpoint details and OAuth scopes which may be redundant with structured metadata, but it is not overly verbose.

  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 required param, read-only, no output schema), the description is mostly complete. It clarifies the returned resource is linked to the calendar ID, but does not explain return format or error conditions, which are acceptable given low 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 high description coverage (100% for calendarId). The description does not add any semantic value beyond what the schema already states ('Unique identifier of the event calendar'). Baseline 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 ('Get'/'Retrieve'), the resource ('availability schedule for event calendar'), and links it to a specific calendar ID. While it does not explicitly differentiate from siblings like create/update, the verb and resource 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?

  The description provides no guidance on when to use this tool vs. alternatives (e.g., create/update/schedule tools). No prerequisites, conditions, 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.

• ghl_calendar_schedule_assignB
  3.2/5.0
  Behavior4/5

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

  The description adds transparency beyond annotations by specifying the HTTP method (PUT), endpoint, and OAuth scopes. It is consistent with idempotentHint and non-destructiveHint.

  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 contains redundant phrases (e.g., 'Applies...' and 'Apply...' and 'Associates...') and technical details (endpoint, scopes) that could be condensed. It wastes space on repetition.

  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 tool with two parameters and no output schema, the description explains the core operation. However, it lacks prerequisites (e.g., schedule must exist) or behavior on duplicate association, leaving 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 coverage is 100% with descriptions and examples, so the description adds minimal value. It reinforces that 'calendarId' is added to a schedule, but does not explain parameter formats or relationships beyond 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?

  The description clearly states that it assigns an existing user availability schedule to a calendar by associating a calendarId with a schedule. The purpose is distinct from siblings like 'unassign', though not explicitly contrasted.

  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 (e.g., ghl_calendar_schedule_unassign). The description does not include any context about prerequisites or scenarios.

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

• ghl_calendar_service_booking_getB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the HTTP method (GET) and OAuth scopes (calendars/events.readonly), which reinforce the read-only nature but provide marginal 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 relatively concise but has minor redundancy: the first two sentences essentially repeat the same idea. Overall, it is front-loaded with the purpose and includes useful technical details.

  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 operation with one required parameter and comprehensive annotations, the description is fairly complete. It includes endpoint, version, and OAuth scopes. However, it does not hint at the return value, which could be helpful given the lack of an 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?

  Schema coverage is 100% with a single parameter (bookingId) that has both a description and example. The description does not add further parameter semantics beyond what is already in 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.

  Purpose4/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 'service booking by ID'. It distinguishes from sibling tools like ghl_calendar_service_booking_list and ghl_calendar_service_booking_update by implying retrieval of a single resource, but does not explicitly differentiate.

  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 endpoint and OAuth scopes but no guidance on when to use this tool versus alternatives like list or update. No explicit when-to-use or when-not-to-use advice is given.

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

• ghl_calendar_service_createB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds OAuth scope 'calendars.write' and endpoint details, which are useful but not essential. No behavior beyond annotations 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four lines and mostly concise. Redundancy exists: the first line 'Create Service' duplicates the annotation title. Front-loading is decent with the core purpose first.

  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 lacks context about what creating a service entails, e.g., that it adds to the catalog or how it relates to other calendar entities. Schema has full coverage, but no output schema. Minimal completeness for a mutation 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?

  Input schema has 100% documented parameter descriptions. The tool description does not add any additional meaning beyond what the schema already provides, so baseline score 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 title 'Create Service' and description 'Create new service in a location' clearly state the verb and resource. However, among sibling tools like ghl_calendar_service_list and ghl_calendar_service_booking_create, this tool is not distinguished from other service-related actions.

  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 OAuth scopes and endpoint but no guidance on when to use this tool versus alternatives like ghl_calendar_service_update or ghl_calendar_service_booking_create. No when-not-to-use or prerequisite information is given.

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

• ghl_calendar_service_deleteB
  3.2/5.0
  Behavior3/5

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

  Annotations already mark destructiveHint=true and readOnlyHint=false, so the description's main addition is OAuth scopes (calendars.write) and the endpoint URL. This adds moderate context beyond the annotations, but does not discuss irreversibility 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and includes relevant endpoint details without being verbose. The first line repeats the title, but overall it's concise.

  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 delete tool with one required parameter, the description covers the basic action and auth scope. However, it does not explain what the response looks like (e.g., success indicator) or whether the delete is permanent, which would be helpful given no 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?

  Schema coverage is 100% with an example and description for serviceId. The description only repeats 'by ID' without adding new meaning, so it meets the baseline but adds no extra value.

  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 'Delete service by ID', which is a specific verb-resource combination. However, it does not distinguish between sibling tools like ghl_calendar_service_create, ghl_calendar_service_get, etc., so it lacks 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 on when to use this tool versus alternatives, or when not to use it. There is no mention of prerequisites, cascading effects, or confirmation steps.

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

• ghl_chat_widget_patchB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate non-destructive, non-read-only behavior. The description adds OAuth scopes and endpoint version, but does not clarify partial update semantics (e.g., that missing fields are unchanged) or potential side effects. No contradiction with annotations.

  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 short and front-loaded with the core purpose. The endpoint and OAuth scopes are useful but could be integrated more naturally. Every sentence 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 mutation tool with a complex nested body, the description lacks information on return values, error handling, and the effect of partial updates on unspecified fields. No output schema is provided, so more context is needed.

  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?

  Input schema has 100% coverage with detailed descriptions for all parameters. The description adds no additional semantic meaning beyond what's in the schema, so 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 states 'Partial update of a chat widget resource,' which clearly identifies the action and resource. However, it does not differentiate from sibling tools like ghl_chat_widget_create or ghl_chat_widget_update, so it misses explicit 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 on when to use this tool versus alternatives (e.g., ghl_chat_widget_update for full updates). There is no mention of prerequisites, when not to use, or context that helps an agent decide.

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

• ghl_contact_get_all_notesB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the endpoint and OAuth scope 'contacts.readonly', which is consistent and provides minor additional behavioral context (authentication requirement). No mention of pagination or response structure.

  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 brief and front-loaded with the tool's title. It includes necessary technical details (endpoint, version, OAuth) without redundancy. However, the endpoint path may be unnecessary for an AI agent and could be omitted for brevity.

  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 parameter, no output schema), the description is adequate but incomplete. It does not specify the return format (e.g., list of note objects) or whether pagination is supported. An agent might need to infer behavior from the name and 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?

  Schema coverage is 100% and the description does not add parameter information beyond what the schema provides. The schema already includes an example and description for contactId, so the description offers no extra semantic value.

  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 'Get All Notes' and provides the endpoint details, making the purpose unambiguous. However, it does not differentiate from sibling note tools like ghl_contact_get_note or ghl_contact_create_note, which limits 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?

  No guidance is provided on when to use this tool versus alternative contact note tools. Sibling tools exist for creating, deleting, updating, and retrieving individual notes, but the description does not help an agent choose the correct one.

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

• ghl_contact_get_noteB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the behavior is well-defined. The description adds OAuth scopes and endpoint details, which are useful but not critical beyond annotations. No contradiction found.

  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 very concise, with only the title and technical details. It is front-loaded with 'Get Note'. However, including the full endpoint and version header may be extraneous for an AI agent's decision-making, slightly reducing efficiency.

  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 tool with rich annotations, the description is adequate but lacks mention of return value or behavior. The output schema is absent, so the agent does not know what the tool returns. Given the simplicity and annotations, a score of 3 is fair.

  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 both parameters (id, contactId) with examples and descriptions, achieving 100% coverage. The description does not add any further semantics 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 states 'Get Note' which clearly indicates retrieving a specific note. It includes the endpoint, making the action explicit. However, it does not differentiate from sibling tools like ghl_contact_get_all_notes or ghl_contact_get_by_id, which could confuse an agent about which tool to use for a single note vs 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?

  No guidance is provided on when to use this tool versus alternatives. The description lacks any context about prerequisites, use cases, or when not to use it. It only provides technical endpoint and OAuth scope information, not usage direction.

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

• ghl_conversation_get_email_messageB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the endpoint and OAuth scopes, which are useful but not critical. No contradictions with annotations. Missing details about error handling or rate limits, but annotations cover the main behavioral traits.

  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 somewhat verbose due to the technical note about the spec gap, which is important but could be integrated more concisely. It is well-structured with a clear summary line, but could be streamlined.

  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 no output schema, the description could elaborate on what the response contains (e.g., email details). Sibling tools like ghl_conversation_get_message exist, but the description does not clarify the distinction. The annotations cover safety, but completeness is adequate for a simple retrieval 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?

  Schema coverage is 100% for the single required 'id' parameter. The description adds context about why the parameter exists despite a spec gap, explaining it's a path parameter inferred from the URL template. This adds meaningful insight beyond the schema description.

  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 states 'Get email by Id' and includes the endpoint and OAuth scopes, making it clear it retrieves a specific email message. However, it does not specify what fields are returned, which would strengthen purpose clarity. It is distinguishable from sibling tools like ghl_conversation_get_message by specifying 'email'.

  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 guidance on when to use this tool versus alternatives such as ghl_conversation_get_message or ghl_conversation_get_messages. No when-to-use or when-not-to-use criteria are given. The only extra context is the spec gap explanation, which is not usage guidance.

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

• ghl_email_template_folder_createB
  3.2/5.0
  Behavior3/5

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

  The description adds OAuth scopes and endpoint details beyond the annotations, which are minimal. However, it does not disclose behaviors like idempotency, error conditions, or what happens if the folder already exists. Annotations already indicate non-destructive and non-idempotent, so the additional context is useful but not extensive.

  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 fairly concise with four lines, but the first two lines ('Create a template folder, Create a new template folder') are redundant. Endpoint and OAuth scopes are useful but could be more streamlined.

  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 is present, and the description does not explain what the response contains. It lacks information on error handling, prerequisites, or examples. For a creation tool, more context is needed to understand the expected 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 input schema has 100% coverage with descriptions for both parameters. The tool description adds no further explanation of parameters, but given full schema coverage, this is acceptable. No additional value is provided 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 'Create a template folder' and repeats 'Create a new template folder', making the action unambiguous. The tool name and description align, and it is distinct from siblings like ghl_email_template_create which creates templates 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?

  No guidance is provided on when to use this tool versus alternatives, such as other folder creation tools (e.g., custom_field_create_folder, media_create_folder). The description lacks context for tool selection.

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

• ghl_estimate_generate_numberB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, conveying safe, idempotent read behavior. Description adds endpoint URL and OAuth scopes but no further behavioral details (e.g., generation logic, concurrency).

  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?

  Description is relatively concise (4 lines) but includes technical details like version header and source file that may not be essential for an agent. Could be streamlined.

  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 simple nature (2 params, no output schema) and good annotations, the description covers the basic purpose and scopes. However, it lacks information about the generated number format, prerequisites (e.g., location existence), and any error conditions.

  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 50%: altId has a description in the schema, altType does not. The description adds no parameter information beyond the schema, failing to compensate for the missing altType 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?

  Clear verb 'Get' and specific resource 'next estimate number for the given location'. Unambiguously distinguishes from siblings like ghl_invoice_generate_number for invoices and other estimate 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?

  No explicit guidance on when to use versus alternatives such as ghl_estimate_create or ghl_invoice_generate_number. The context is implied by the name but not stated.

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

• ghl_invoice_schedule_deleteB
  3.2/5.0
  Behavior3/5

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

  Annotations already mark this as destructive and non-read-only. The description adds no additional behavioral context (e.g., irreversible deletion, cascading effects), but does not contradict annotations.

  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 concise with three clear lines including endpoint and OAuth scopes. It is front-loaded with 'Delete schedule' but may include technical details that some agents might find extraneous.

  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 omits return value or success/error behavior. Since there is no output schema, agents are left guessing what happens after deletion. Annotations mitigate some risk, but completeness is only 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?

  Input schema covers all parameters with descriptions (100% coverage). The tool description does not add extra meaning beyond what the schema provides, meeting the baseline expectation.

  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 'Delete schedule' and specifies it deletes by schedule ID. However, it does not differentiate from sibling tools like ghl_invoice_schedule_create, ghl_invoice_schedule_get, etc.

  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 any prerequisites or when-not-to-use context. The agent must infer usage from the tool name alone.

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

• ghl_invoice_schedule_listB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds technical details like endpoint, OAuth scopes, and pagination params (limit, offset). While these are useful, they don't disclose additional behavioral traits such as rate limits, data freshness, or response structure. The description does not contradict annotations.

  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 concise, with 5 lines covering purpose, endpoint, scopes, and pagination. It front-loads the purpose ('List schedules') and avoids redundancy. However, the line 'API to get list of schedules' repeats the purpose slightly. Overall, it is efficient and well-structured, earning a 4.

  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 9 parameters (4 required), no output schema, and moderate complexity. The description provides basic context (pagination, OAuth scopes) but fails to describe the response format or explain how optional filters (status, search, date range) affect results. Given the absence of an output schema, the description should offer more guidance on what the list returns. It is adequate but not fully 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?

  Schema coverage is 100%, so the schema already provides descriptions and examples for all 9 parameters. The description only mentions limit and offset as pagination params, which adds minimal context beyond the schema (e.g., 'pass them to page through full result sets'). Since the schema already conveys parameter semantics, the baseline of 3 is appropriate; the description does not significantly enhance understanding.

  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 'List schedules' and 'API to get list of schedules', which identifies the tool as a listing operation for invoice schedules. The verb 'list' and resource 'schedules' are specific, and the tool is distinguishable from sibling tools like ghl_invoice_schedule_get (single schedule) and ghl_invoice_schedule_create. However, it could be more explicit that it lists invoice schedules specifically, as 'schedules' alone might be ambiguous without 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?

  The description provides no guidance on when to use this tool versus alternatives. It mentions pagination but does not explain when to use list vs get, or how filters (status, search) alter results. There are no explicit when-to-use or when-not-to-use statements, and sibling tools with different behaviors (activate, cancel) are not differentiated in usage context.

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

• ghl_invoice_update_last_visited_atB
  3.2/5.0
  Behavior3/5

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

  Annotations show readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds the endpoint URL but does not disclose any side effects, authorization needs, or consequences beyond updating a timestamp. It adds some value (endpoint) but lacks deeper 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise with two sentences and an endpoint line. It front-loads the purpose effectively. However, it could be slightly more structured (e.g., separating purpose and endpoint). Overall efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the core action and endpoint but omits return values (no output schema) and error handling. For a simple update tool, this is adequate but not 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?

  The input schema has full coverage (100%) for the single parameter 'body' containing 'invoiceId'. The description adds no additional meaning beyond what the schema already provides (e.g., 'Invoice Id'). Baseline score of 3 applies due to high 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 it updates the last visited timestamp for an invoice by ID. It uses a specific verb and resource. However, it does not explicitly differentiate from the similar sibling tool 'ghl_estimate_update_last_visited_at', which updates a similar timestamp for estimates.

  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 vs alternatives. There is no mention of prerequisites, context, or exclusions. The description only explains what the tool does, not when it should be invoked.

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

• ghl_kb_faq_deleteB
  3.2/5.0
  Behavior2/5

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

  Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds no behavioral details beyond the endpoint, such as irreversibility, authentication needs, or behavior on already-deleted FAQs. IdempotentHint=true is not explained.

  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?

  Two sentences front-load the purpose. The endpoint detail is useful but could be integrated. No unnecessary 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?

  For a simple delete operation, the description is mostly adequate but lacks explanation of idempotent behavior, failure modes, or permission requirements. Given low complexity, it just meets minimum viability.

  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% (one required 'id' param with description and example). The description adds no further parameter explanation, so it provides no additional value over the schema. Baseline 3 applies due to high 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') and the resource ('existing knowledge base FAQ'), with the endpoint providing technical confirmation. It is unambiguous and distinct from sibling tools like ghl_kb_faq_create or ghl_kb_faq_update.

  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 vs. alternatives (e.g., when not to delete, prerequisites, or consequences). The description simply states what it does without usage context.

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

• ghl_location_delete_an_email_sms_templateB
  3.2/5.0
  Behavior2/5

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

  Annotations already convey destructiveHint=true and idempotentHint=true. The description adds only the endpoint details, which are not behavioral. It does not describe side effects, error states, or permission requirements, failing to add value beyond the 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 extremely concise (two sentences) and front-loaded with the action. Every element is necessary and there is no fluff.

  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 delete tool with comprehensive annotations and schema, the description adequately covers the basic information. However, it lacks return value expectations or success/failure indicators, which would be useful but are not critical given the low 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?

  Schema description coverage is 100%, so the schema already documents both parameters (id, locationId). The description does not provide any additional meaning, such as expected formats or constraints, so it meets the baseline without adding value.

  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 (email/sms template) via the endpoint path. While it distinguishes from some siblings, it does not explicitly differentiate from ghl_email_template_delete, which deletes email templates without location context. However, the tool name and endpoint imply a location-specific delete.

  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_email_template_delete or other delete operations. The description lacks any context about prerequisites, 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.

• ghl_location_get_custom_fieldB
  3.2/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe read operation. The description adds the endpoint version detail but does not disclose additional behaviors like permissions, response format, 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very concise (two sentences) and front-loaded with the purpose. However, it includes technical endpoint details that may be unnecessary for an AI agent, slightly reducing efficiency.

  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 read-only tool with two parameters and no output schema, the description is minimally adequate. It does not describe the return value format or any potential edge cases, which would be helpful given the lack of an 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 already describes both parameters with 100% coverage, including an example for 'id'. The tool description adds no extra parameter meaning beyond what the schema provides, so it meets but does not exceed the baseline.

  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 states 'Get Custom Field' and includes the endpoint path, clearly indicating it retrieves a single custom field by locationId and id. It distinguishes from siblings like ghl_location_get_custom_fields (plural) by implying singular retrieval, but does not explicitly differentiate from ghl_custom_field_get_by_id.

  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_custom_field_get_by_id or ghl_location_get_custom_fields. The description only states what it does, with no usage 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.

• ghl_location_get_recurring_task_by_idB
  3.2/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the endpoint version and source details but does not disclose additional behavioral traits like response format or side effects. Given annotation coverage, a 3 is appropriate.

  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 very concise, consisting of a single line with the endpoint. It is front-loaded and easy to read. However, the inclusion of version and source info is somewhat extraneous for most agents, preventing a perfect 5.

  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 tool, the description is minimally adequate. However, it does not specify what the tool returns (e.g., task details, fields). With no output schema, this leaves some ambiguity. The annotations help but completeness is lacking.

  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 descriptions already present for both parameters ('Recurring Task Id' and 'Location Id'). The description does not add any new semantic meaning beyond what the schema provides, so baseline 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 tool's purpose: getting a recurring task by ID. It provides the endpoint URL, which reinforces the action. However, it does not explicitly differentiate from sibling tools like create, delete, or update recurring tasks, which would elevate it to 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 when to use it, when not to, or suggest any alternative tools. The endpoint info is technical but not helpful for usage decisions.

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

• ghl_location_update_custom_valueB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate idempotent and non-destructive behavior. The description adds the endpoint URL and version header but no additional behavioral insight (e.g., partial vs. full replacement, 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very short (2 sentences) with no unnecessary words. However, the brevity sacrifices informative 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?

  For a simple update operation with well-documented schema and annotations, the description is minimally adequate. Missing output schema details (e.g., return type) but not critical for an update.

  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 provides no additional meaning for parameters; it only repeats the endpoint. All parameter details are in 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?

  The description clearly states 'Update Custom Value' and provides the HTTP method and path. This identifies the action and resource. However, it does not differentiate from sibling tools like create, get, or delete custom values, which could be confusing.

  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. The description does not mention prerequisites, when it's appropriate to update vs. create, or any exclusions.

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

• ghl_location_update_tagB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare the tool as non-readonly, idempotent, and non-destructive. The description adds only the HTTP method and version header, which provide technical context but no additional behavioral traits (e.g., what happens if the tag does not exist). It does not contradict annotations.

  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 with two lines, front-loading the purpose. However, it is arguably too minimal and could include a summary sentence 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?

  Given the simple update operation with three required parameters and no output schema, the description is adequate but incomplete. It does not mention the response structure, partial update behavior, or any error conditions. It meets the minimum viable standard.

  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 descriptions for all parameters (body, tagId, locationId). The description adds no additional parameter information beyond the endpoint, so it adds marginal value 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?

  The description explicitly states 'Update tag' and includes the endpoint pattern, clearly indicating the verb (PUT) and resource (tag). This distinguishes it from sibling tools like create, delete, and get tags. However, it is very brief and could be more explicit about the update nature.

  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 (e.g., create or delete tags). It does not mention prerequisites like the tag must exist, nor does it explain the context for updating a tag.

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

• ghl_opportunity_get_lost_reasonB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description's additional details (endpoint, OAuth scopes opportunities.readonly, pagination) add some but not substantial behavioral context. No contradictions with 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 extremely concise, consisting of a title, endpoint info, OAuth scopes, and pagination guidance in a clear line-break structure. Every sentence serves a purpose with no unnecessary text.

  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 7 parameters and no output schema, the description should explain the purpose of parameters like name, query, deleted, getCount, and the expected response format. It only addresses pagination parameters, leaving significant gaps in understanding the tool's behavior and outputs.

  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 baseline is 3. The description adds value by explaining that skip and limit are for pagination and how to use them to get full result sets. Other parameters (name, query, deleted, getCount) are not elaborated beyond the schema, so minor additional benefit.

  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 states 'Get lost reason' which is a specific verb-resource pair. The endpoint URL and OAuth scopes further clarify the tool's purpose. However, it does not explicitly distinguish it from sibling opportunity tools like ghl_opportunity_get or ghl_opportunity_search, so it's not a full 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 pagination guidance ('pass them to page through full result sets') but lacks any context on when to use this tool versus other opportunity tools. There is no mention of prerequisites, alternatives, 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.

• ghl_payment_order_list_notesB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the agent knows it's a safe read operation. The description adds the endpoint and version header but no further behavioral traits. No contradiction with annotations.

  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 very concise with only three lines, including the endpoint. It is front-loaded with the title and action. While efficient, it sacrifices depth.

  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 no output schema and three required parameters. The description does not explain what a 'note' is, nor does it mention pagination, ordering, or response structure. Given the simplicity of the tool, more context would help the agent understand potential 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 67% (2 of 3 parameters have descriptions). The description adds no additional parameter-level details beyond those in the schema. Since coverage is moderate, the description should have provided more context for the undocumented parameter (altId and altType are only partially described).

  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 title 'List Order Notes' and description 'List all notes of an order' clearly state the verb and resource. It is distinct from sibling tools, which are primarily ad management or other payment 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?

  No guidance on when to use this tool versus alternatives like ghl_calendar_appointment_note_list or ghl_contact_get_all_notes. The description merely 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.

• ghl_phone_list_available_numbersB
  3.2/5.0
  Behavior3/5

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

  Annotations already mark this as readOnly and idempotent. The description adds that it searches 'Twilio inventory' and lists OAuth scopes, but does not elaborate on rate limits, pagination, or response behavior. With annotations covering safety, a 3 is appropriate.

  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 core purpose is stated concisely, but the description includes extraneous details about a renaming and version header that are not helpful for tool selection or invocation. This reduces conciseness and clarity.

  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 9 required parameters and no output schema, the description should provide more context about how parameters interact or what the response contains. It only says 'for the given location', leaving the agent without guidance on combining filters like firstPart and lastPart.

  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 all parameters are documented. The description adds no additional meaning or usage context beyond what the schema provides. Baseline score 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 states 'List available phone numbers' and 'Search Twilio inventory for purchasable phone numbers', clearly identifying the tool's purpose of finding purchasable numbers. It distinguishes from siblings like ghl_phone_list_active_numbers by specifying 'purchasable' and 'available'. However, the first line about renaming and a typo is distracting noise.

  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 tool is for purchasing phone numbers by mentioning 'purchasable phone numbers', but does not explicitly contrast with sibling tools like ghl_phone_list_active_numbers or ghl_phone_list_number_pools. No when-not or alternative guidance is provided.

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

• ghl_product_review_deleteB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true, so the deletion behavior is clear. The description adds no extra behavioral context (e.g., whether deletion is reversible, cascading effects, or idempotency). It is consistent with annotations but provides no added value beyond them.

  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 short and to the point, with minimal redundancy. It includes the endpoint and OAuth scopes, which are not strictly necessary but add context without excessive verbosity. It could be slightly more efficient by removing the endpoint line, but overall it is 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 description covers the basic action but lacks completeness. There is no mention of the response format (important since no output schema), no mention of required permissions beyond OAuth scopes, and no link to related operations. For a simple delete, it is adequate but not thorough.

  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 high (75%), and the description does not add any information about parameters beyond what the schema provides. For example, the purpose of altId and altType is not explained. Baseline score of 3 is appropriate given high 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 title and description clearly state this tool deletes a specific product review. It is not a tautology and provides the verb 'Delete' and resource 'Product Review'. However, it does not distinguish itself from sibling tools like ghl_product_review_update or ghl_product_review_bulk_update, so it lacks 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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or mention siblings like ghl_product_review_list or ghl_product_review_update. This is a significant gap for an agent deciding between review-related tools.

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

• ghl_social_get_google_locationsB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the description is not required to repeat that. However, it adds the endpoint and version header, which provides technical context but does not disclose return format, pagination, or error behavior. With annotations covering safety, a score of 3 is appropriate.

  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 very short, consisting of two sentences. It states the purpose and includes the endpoint. No unnecessary information is present, though the endpoint detail could be considered technical noise for an AI agent. However, it is concise and front-loaded with the main action.

  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 operation with 2 parameters and no output schema, the description is minimally adequate. It identifies the resource and endpoint but does not explain what the response contains (e.g., list of location details). Given the simplicity and annotation coverage, a score of 3 is reasonable.

  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 descriptions for both parameters (accountId and locationId). The description does not add any additional meaning or constraints beyond what the schema provides. Therefore, the description meets the baseline but does not enhance parameter understanding.

  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 'Get google business locations', indicating a read operation for Google business locations. The tool name includes 'get' which aligns with the action. Among siblings, there is a 'set' counterpart (ghl_social_set_google_locations), so it distinguishes by operation type. The endpoint URL adds specificity to the resource.

  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_social_set_google_locations. It does not mention scenarios such as retrieving existing locations before updating, or that this is a read-only operation. The annotations indicate readOnlyHint but the description itself lacks usage context.

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

• ghl_social_get_tags_by_idsB
  3.2/5.0
  Behavior2/5

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

  Annotations provide basic read-only/destructive hints but description adds no behavioral context beyond that. Does not disclose potential side effects, authorization needs, rate limits, 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is somewhat repetitive ('Get tags by ids' then 'Retrieve specific tags by their IDs') and includes endpoint details that are not actionable for an agent.

  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, and the description does not explain what the response contains, whether pagination exists, or the structure of the returned data. Incomplete for a tool with nested body 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%, so baseline is 3. The description adds no extra meaning beyond the schema; it repeats 'Tag Ids' but does not clarify format constraints or nesting 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 title 'Get tags by ids' and description 'Retrieve specific tags by their IDs' clearly state the tool's action (get) and resource (tags by IDs). It distinguishes from sibling tool ghl_social_get_tags_location_id which retrieves tags for a location.

  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 specific tag IDs ('Retrieve specific tags by their IDs'), but does not explicitly state when to use this versus alternatives, nor does it mention prerequisites or context.

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

• ghl_store_get_available_shipping_ratesB
  3.2/5.0
  Behavior3/5

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

  Annotations provide readOnlyHint=false and other hints. The description states it returns rates but does not disclose side effects, authentication needs, or rate limits. The POST endpoint could imply mutation, but this is not clarified. The description adds minimal behavioral context beyond annotations.

  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 somewhat repetitive (three sentences with similar meaning) and includes a technical note about the endpoint and correction. It is not excessively long, but could be more streamlined.

  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 no output schema, so the description should explain the return structure. It only says 'returns the shipping rates' without describing the format, fields, or how to interpret the response. Given the complexity of inputs, more guidance is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description highlights key inputs (country, order amount) but does not explain the role of other required parameters like altId, products, etc. It adds some value beyond schema but not comprehensive.

  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 that the tool returns shipping rates for a given country/order-amount combination. It corrects a previous misnomer (zones vs rates), and the name itself is descriptive. While it distinguishes from 'list' and 'get single rate' siblings, it does not explicitly differentiate from other shipping rate 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 when needing rates based on country and order amount, but does not provide explicit when-to-use, when-not-to-use, or alternative tools (e.g., list all rates). No exclusion criteria or context for selecting this over siblings.

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

• ghl_survey_listB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and idempotentHint. The description adds that it's a GET endpoint with surveys.readonly scope and requires pagination, providing some additional behavioral context beyond the boolean hints.

  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 concise with three clear lines. It front-loads the purpose and provides essential technical details without excess verbiage, though it lacks a more organized structure.

  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?

  Missing important context: no explanation of what surveys are, what the 'type' parameter does, that locationId is required, or the output format. It does not differentiate from ghl_survey_get_submissions, leaving gaps for an AI agent.

  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 (25%, only limit has a description). The description only mentions pagination params (skip, limit) but does not explain 'type' or 'locationId', which are undocumented in the schema. It adds some value for pagination but insufficient overall.

  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 starts with 'Get Surveys', which clearly indicates the action and resource. It adds endpoint details and OAuth scopes, distinguishing it from siblings like ghl_survey_get_submissions.

  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 mentions pagination but does not explain when to use this over other survey-related tools or provide use cases.

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

• ghl_user_getB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds OAuth scopes ('users.readonly'), which clarifies authentication requirements but does not describe return behavior, pagination, or other 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very concise (three lines) and front-loads the purpose. It could be slightly more detailed without becoming verbose, but it is appropriately sized for a simple read 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?

  The description is adequate for a straightforward get operation, but it lacks details about the response structure (no output schema) and does not clarify how this tool differs from similar user retrieval tools, which would be helpful given the large context of sibling 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?

  Schema coverage is 100% with one parameter (userId) already documented. The description does not add any semantics or constraints beyond what the schema provides, 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 'Get User' and provides the endpoint, indicating it retrieves a single user by ID. This distinguishes it from sibling tools like create, delete, search, and get_by_location, but the description itself does not explicitly differentiate from those 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 given on when to use this tool versus other user-related tools (e.g., ghl_user_search, ghl_user_get_by_location). The description only provides the endpoint and OAuth scopes, leaving the agent without context for tool selection.

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

• ghl_user_searchB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare read-only and non-destructive nature. Description adds that it uses GET, OAuth scopes, and pagination. Does not mention response structure or behavior beyond pagination, which is useful but not fully comprehensive.

  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?

  Description is short and to the point, with no wasted words. Includes endpoint, scopes, and key pagination note. Could be slightly more streamlined by omitting technical source details, but overall efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given high schema coverage and annotations, the description is adequate but missing details about search behavior (e.g., fuzzy matching, OR conditions) and response structure. Sufficient for basic use but could be improved.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed descriptions for each parameter. Description only explicitly mentions skip and limit for pagination, adding minimal value beyond 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 clearly states 'Search Users' and provides endpoint, making the tool's purpose clear. However, it does not explicitly differentiate from sibling tools like ghl_user_filter_by_email, though the name implies a broader search.

  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 (e.g., ghl_user_get or ghl_user_filter_by_email). Only mentions pagination parameters, not usage context or prerequisites.

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

• ghl_voice_ai_delete_agentB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true and idempotentHint=true; description adds that it deletes 'all configurations' but doesn't reveal potential side effects (e.g., impact on active calls). No contradiction with annotations.

  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?

  Description is concise and front-loaded with purpose. Redundant title line adds minor noise but does not detract significantly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Lacks details on what 'configurations' includes (e.g., actions, settings) and the response format. With no output schema and a simple operation, it is minimally 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 coverage is 100% with inline descriptions. Tool description adds no additional context beyond the schema, meeting baseline for high 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?

  Description clearly states the tool deletes a voice AI agent and its configurations. The verb and resource are specific, and it distinguishes from other delete tools like ghl_voice_ai_delete_action by targeting the agent itself.

  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 (e.g., patching to disable). No prerequisites or exclusions provided, leaving the agent to infer context.

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

• ghl_voice_ai_get_call_logB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, etc. Description adds endpoint and OAuth scope but no further behavioral details beyond what annotations provide.

  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?

  Description is short and includes essential details, though the first line repeats the title. Overall 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?

  For a simple read-only retrieval with no output schema, the description covers the core functionality adequately.

  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 parameter descriptions are already present (100% coverage). The tool description does not add new meaning beyond the schema fields.

  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 it returns a call log by callId. The tool name and description together imply singular retrieval vs the sibling 'get_call_logs' which lists multiple, but it does not explicitly differentiate.

  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 vs alternatives like the list call logs. No prerequisites or context provided.

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

• ghl_ad_fb_integration_createB
  3.3/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, meaning the tool modifies state but is not destructive. The description adds 'Create' which aligns, but does not disclose additional traits such as whether existing integrations are overwritten, rate limits, authentication scopes beyond OAuth scopes listed, or potential side effects. The description leans entirely on annotations for safety profile.

  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 three sentences with no fluff. The first sentence repeats the title (minor redundancy), but the second and third add meaningful context about purpose and endpoint/OAuth scopes. It is efficiently structured and front-loaded with the core action.

  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 no output schema, and the description does not specify return values (e.g., integration ID, success message). Given the complexity of creating an integration, an agent would benefit from knowing what to expect as a result. The description is incomplete for a mutation tool without 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% description coverage for all parameters (pageId, locationId, adAccountId). The description adds context like 'for a location with page and ad account', which groups the parameters semantically. However, it does not provide further details beyond what the schema already offers. 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 title and description clearly state 'Create Facebook integration' with additional detail about creating an ad integration for a location. The verb 'create' and resource 'Facebook ad integration' are specific, and the tool is well-distinguished from sibling tools like `ghl_ad_fb_integration_get` and `ghl_ad_fb_integration_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?

  The description implies the tool is used to create an integration for a location with page and ad account, but it does not explicitly state when to use it versus alternatives like getting or deleting integrations. No prerequisites, ordering, or conditions are mentioned, 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.

• ghl_ad_google_campaign_upsertB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is clear. The description adds endpoint details and OAuth scopes, but does not discuss side effects, conflict handling, or rate limits. It provides modest behavioral context beyond annotations.

  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 concise and front-loaded with the core purpose. It includes some technical details (endpoint, version, scopes) that are useful but could be consolidated. Overall, every sentence adds value without fluff.

  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 complex input schema with many nested objects and no output schema, the description lacks high-level guidance on how to construct the campaign structure, common required fields, or typical usage patterns. It does not compensate 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?

  Schema coverage is 100%, so the input schema already defines all parameters with descriptions. The description only adds a high-level 'full campaign structure' without enriching parameter semantics. Baseline 3 is appropriate as 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 clearly states 'Upsert Google campaign' and 'Create or update a full Google Ads campaign structure', using a specific verb and resource. While it doesn't explicitly differentiate from sibling tools, the mention of 'full' and the verb 'upsert' imply it is for comprehensive campaign creation/update, distinguishing it from get/publish/reporting 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 when to use this tool (to create or update a campaign), but provides no explicit guidance on when not to use it or which alternatives exist. Sibling tools like get, publish, or reporting are not mentioned, leaving the agent to infer from context.

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

• ghl_ad_google_conversion_listB
  3.3/5.0
  Behavior2/5

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

  Annotations already indicate readOnly, idempotent, non-destructive. The description adds only endpoint and OAuth scopes, no additional behavioral context (e.g., pagination, rate limits). Barely adds value beyond annotations.

  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?

  Concise, front-loaded with key info. First line 'Get conversions' is redundant with title, but overall efficient. Minor deduction for 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?

  Lacks output format details and pagination hints despite openWorldHint=true. For a list operation with no output schema, description should clarify structure of the response.

  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 has 100% description coverage for all 6 parameters. Description adds no extra meaning beyond what schema already provides, 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?

  Clearly states it retrieves Google Ads conversion actions for a location, matching the 'list' verb and distinguishing it from siblings like get, delete, or goal_list.

  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 guidance on when to use this vs. alternatives (e.g., get, goal_list), though the name and description imply listing. Could be improved with context about filtering or limits.

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

• ghl_ad_google_segment_listB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds OAuth scope (adPublishing.readonly) and API version, which adds some value. However, it lacks details about pagination, limits, or response format beyond what annotations cover.

  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 concise (two short sentences plus endpoint/scopes). It front-loads the core purpose. The endpoint line adds useful context but is not strictly necessary for tool selection. Overall well-structured without verbosity.

  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 and no description of the return format. For a listing tool, users need to know if it returns an array, pagination info, or other details. This lack leaves the agent uncertain about the response structure.

  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 both parameters described. The description does not add any parameter-specific information beyond what is already in the schema, so 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 title 'Get segments' and description 'Retrieve Google Ads audience segments for a location' clearly indicate a list/read operation for Google Ads segments. It distinguishes from sibling tools like ghl_ad_google_segment_get (single segment) and ghl_ad_google_segment_delete, though it could be more explicit that it returns a list of segments.

  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 guidance on when to use this tool versus alternatives. The name and context imply listing, and sister tools like ghl_ad_google_segment_get exist, but description does not mention when-not-to-use or direct to alternatives.

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

• ghl_agent_studio_update_versionB
  3.3/5.0
  Behavior2/5

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

  Annotations provide destructiveHint=false and readOnlyHint=false, but description does not disclose behavioral details like side effects, permission requirements beyond OAuth scopes, rate limits, or version history impact. For a mutation tool, more transparency is needed.

  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?

  Description is three sentences: first repeats title (redundant), second is action and scope, third is endpoint and scopes. Front-loaded with key info. Minor redundancy but overall 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 no output schema, low schema coverage, and complex nested body, the description should cover return values, error cases, and prerequisites. It only provides endpoint and OAuth scopes, leaving significant gaps for an update 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?

  Input schema has 3 parameters; only 33% have descriptions (body). Description lists categories within the body but does not explain source or versionId. Schema's body sub-fields have descriptions and examples, so part of the burden is carried, but the description does not fully compensate for missing top-level 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?

  Description clearly states the action (update), resource (agent version by versionId), and what can be updated (nodes, edges, variables, configuration). Distinguishes from sibling agent studio tools like create, delete, execute, get, list, promote, update_metadata.

  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?

  Description does not explicitly state when to use this tool vs alternatives. It implies usage by requiring a versionId and body, but no guidance on prerequisites or when to prefer other update tools (e.g., update_metadata).

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

• ghl_brand_board_updateB
  3.3/5.0
  Behavior3/5

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

  The description adds the HTTP method (PATCH) and OAuth scopes, which are beyond the annotations. However, it does not explicitly disclose that it performs a partial update or what the response contains. Annotations already indicate it is not read-only, not idempotent, and not destructive.

  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 relatively concise with three useful pieces of information: purpose, endpoint, and OAuth scopes. However, the first two sentences are redundant, and the structure could be improved by front-loading key details.

  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 lacks information about the response format (no output schema) and does not explain that the 'body' parameter can contain partial updates. Given the nested structure and no output schema, the description is insufficient for an agent to understand the 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?

  Schema description coverage is 100%, meaning all parameters have descriptions in the schema. The tool description adds no additional meaning for the parameters beyond what is already in the schema, so it meets the baseline but does not enhance understanding.

  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 'Update a Brand Board' and 'Updates an existing Brand Board', using a specific verb and resource. It distinguishes from sibling tools like create, delete, and get by the verb, but does not explicitly differentiate from them.

  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 context about the endpoint and required OAuth scopes, implying that a locationId and brand board ID are needed. However, it does not explicitly state when to use this tool over alternatives or provide scenarios for use.

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

• ghl_business_get_businesses_by_locationB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds OAuth scopes (businesses.readonly) and pagination behavior, which are useful. However, it does not disclose response format, rate limits, or error handling. The added value is moderate.

  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 (4 lines) and front-loaded with the title. Each sentence adds value: endpoint, OAuth scopes, pagination. No 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?

  Given the tool's simplicity (read-only list with pagination) and the annotations covering safety, the description covers essential aspects (endpoint, auth, pagination). However, it lacks details about the response structure or what constitutes a 'business'. Could be 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?

  Schema coverage is 0%, so the description must compensate. It explains that limit and skip are pagination params for paging through full result sets, which adds meaning. However, locationId is not described beyond its name. Partial compensation.

  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 ('Get Businesses by Location') and endpoint, distinguishing it from sibling tools like ghl_business_get (single business) and ghl_business_create. It 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 does not provide explicit guidance on when to use this tool versus alternatives. It mentions pagination params but lacks context on when to prefer this over other business retrieval tools. No exclusions or alternatives are mentioned.

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

• ghl_company_getB
  3.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint true, and the description adds details about authentication requirements, endpoint, and OAuth scopes, which go beyond the structured data. There is no contradiction with annotations.

  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 short but contains redundancy ('Get Company' repeated twice with a typo). It could be tightened by removing the duplicate phrase while retaining essential info (endpoint, security, scopes).

  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, the description provides the endpoint and authentication details. However, it lacks any information about the response structure or what fields are returned. Given no output schema, this is a noticeable omission.

  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 only parameter, companyId, is mentioned in the endpoint but not described in the input schema or description. Context shows 0% schema coverage, so the description should explain what companyId is. It only provides an example, which is insufficient.

  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 indicates the action ('Get Company') and resource (company), distinguishing it from sibling tools that handle other entities like contacts, invoices, etc. However, the purpose is only stated via the endpoint and a repeated phrase, not elaborated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states the requirement for an agency-level token and OAuth scopes, which helps in understanding prerequisites. However, it does not provide guidance on when to use this vs. other tools 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.

• ghl_contact_add_to_campaignB
  3.3/5.0
  Behavior2/5

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

  Annotations indicate non-read-only, non-destructive, non-idempotent. Description adds 'empty body' but omits side effects like duplicate handling, overwrite behavior, or required permissions. Minimal extra context beyond 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?

  Extremely concise: two sentences covering the core action and request body constraint. No superfluous information.

  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?

  Adequate for a simple add-to-campaign operation, but lacks details on return value (no output schema), error conditions, and behavior if contact already in campaign. Missing completeness for a full understanding.

  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 basic descriptions for each parameter. Description confirms body is empty but adds no further semantic value. Baseline 3 maintained as schema already provides parameter descriptions.

  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?

  Clearly states it adds a contact to one specific campaign, with an empty request body. The verb 'adds' and resource 'contact to campaign' are explicit, but no direct contrast with sibling tools like remove or add 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Implies usage via the verb 'adds' and mentions empty body, but does not specify when to use versus alternatives (e.g., remove from campaign, add to all campaigns). No prerequisites or exclusions.

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

• ghl_contact_delete_from_workflowB
  3.3/5.0
  Behavior3/5

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

  The description includes OAuth scopes and endpoint details, adding some value beyond the annotations (which already indicate destructiveness). However, it does not describe side effects, irreversibility, or behavior beyond what the annotations imply, so it 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, with only one line for the main purpose and technical details following. It is front-loaded and efficient, though slightly terse.

  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 destructive nature and lack of output schema, the description should explain prerequisites (e.g., contact must be in workflow), error conditions, or confirmation. It fails to provide sufficient context for safe and effective use.

  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 description provides no additional meaning for the parameters beyond what the schema already contains. Thus, it meets the baseline but does not enhance understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Delete Contact from Workflow', which is a specific verb and resource. It directly distinguishes from sibling tools like ghl_contact_add_to_workflow and ghl_contact_delete, 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 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 (e.g., when to remove from workflow vs. delete contact entirely). It lacks context on prerequisites or scenarios 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.

• ghl_contact_delete_noteB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds OAuth scopes (contacts.write), which is useful context not in annotations, but lacks details on irreversibility, error responses, or post-deletion effects.

  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 very concise with no wasted words. It efficiently conveys the endpoint and OAuth scopes. However, it could benefit from a brief usage note without becoming verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  As a destructive operation with no output schema, the description should explain consequences (e.g., permanent deletion) or success response. It omits this critical context, leaving the agent underinformed.

  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?

  Input schema has 100% coverage with descriptions and examples for both required parameters (id, contactId). The description adds no additional parameter-level 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 clearly states the tool deletes a note, using the verb 'Delete' and specifying the resource 'Note'. It distinguishes from sibling tools like ghl_contact_create_note, ghl_contact_update_note, or ghl_contact_get_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 explicit guidance on when to use this tool versus alternatives (e.g., creating, updating, or viewing notes). The description simply states 'Delete Note' 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.

• ghl_contact_remove_from_campaignB
  3.3/5.0
  Behavior3/5

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

  Annotations already provide destructiveHint=true and idempotentHint=true, so the description adds limited behavioral insight. It does disclose OAuth scopes ('contacts.write') and endpoint details (DELETE method, version header), which slightly exceed annotation coverage. No contradictions with annotations.

  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 very brief (one line plus technical metadata). It front-loads the action but includes endpoint details (URL, version, source) that may be redundant for an AI agent. While concise, it could be more structured and agent-friendly.

  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 delete operation with two required parameters and no output schema, the description covers the action and OAuth scopes. However, it does not mention return values, error scenarios, or prerequisites like whether the contact must exist. Annotations fill some gaps, but completeness is adequate rather than thorough.

  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 descriptions and examples for both parameters. The description adds no additional meaning or constraints beyond what the schema already provides. Baseline of 3 is appropriate given 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: removing a contact from a campaign. The verb 'Remove' and resource 'Contact From Campaign' are specific and unambiguous. Among siblings like ghl_contact_add_to_campaign and ghl_contact_remove_from_all_campaigns, this tool is clearly distinguished by targeting a single campaign removal.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives. For example, the sibling ghl_contact_remove_from_all_campaigns exists, but the description does not differentiate the use cases. There is no mention of prerequisites, when not to use, or alternative approaches.

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

• ghl_conversation_deleteB
  3.3/5.0
  Behavior3/5

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

  Annotations already provide destructiveHint=true and idempotentHint=true. The description adds OAuth scopes and HTTP method, but does not disclose side effects (e.g., permanent removal, impact on related data) beyond what annotations imply.

  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 short and front-loaded with the purpose. However, including endpoint details and OAuth scopes adds technical noise that could be omitted for conciseness without losing decision-relevant info.

  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, but the description does not specify what the tool returns (e.g., success status, deleted object). The description lacks information on return values or post-deletion behavior, making it incomplete for a delete 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%, already documenting the parameter with an example. The description adds no new meaning or constraints to the conversationId 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 verb (delete), resource (conversation details), and how (based on conversation ID). It distinguishes from sibling conversation tools (create, get, update, search) by specifying deletion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives, nor prerequisites or consequences. The description only states the action itself, 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.

• ghl_conversation_getB
  3.3/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the endpoint and OAuth scopes (conversations.readonly), aligning with the read-only nature. No contradictions. It provides some value beyond annotations but does not disclose response structure or other behavioral 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?

  The description is extremely concise (3 lines), front-loaded with purpose, and includes essential technical details (endpoint, scopes). Every sentence is necessary and adds value.

  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 covers purpose, endpoint, and auth scopes but omits response structure. With no output schema, the agent may need to know what fields are returned. Given the tool's simplicity, it is marginally adequate but not 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?

  With 100% schema description coverage for the single parameter (conversationId), the description adds no additional parameter meaning beyond what the schema provides. Baseline 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 'Get Conversation details based on the conversation ID', using a specific verb and resource. It distinguishes from sibling tools like ghl_conversation_search (which searches) and ghl_conversation_get_messages (which gets messages). However, it does not specify what 'details' includes, leaving some 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?

  The description lacks any guidance on when to use this tool versus alternatives. No mention of prerequisites, when not to use, or explicit alternatives among the many conversation-related siblings.

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

• ghl_conversation_list_custom_subtypesB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, which fully cover the safety profile. The description adds endpoint details but no new behavioral traits beyond what annotations provide.

  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: three lines with the title, action, and endpoint. Every sentence is necessary, and the key purpose is 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?

  While annotations cover behavioral context, the description omits details about the return structure or output schema. Agents may need to infer the response format from the endpoint path, which is incomplete without output documentation.

  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 description does not add additional meaning to the locationId parameter beyond the schema's 'Location Id' and example. Baseline 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 'Get all custom subtypes for a location' which is specific and matches the name. However, it does not explicitly differentiate from sibling tools like create or update custom subtypes, leaving some ambiguity for agents.

  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. Does not mention prerequisites, context, or when not to use it. The description only states the endpoint and version.

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

• ghl_custom_field_deleteB
  3.3/5.0
  Behavior4/5

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

  Annotations already indicate destructive and idempotent behavior. The description adds value by specifying supported object types, the DELETE endpoint, and OAuth scopes, which provide additional behavioral context beyond annotations.

  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 contains redundant repetition (first line and div both say the same thing). The info block and endpoint details are useful but could be more tightly structured. Some waste exists.

  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 delete tool with one parameter, the description covers supported objects and endpoint details but lacks parameter description and return value information. It is minimally adequate but could be more 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?

  The input schema has one parameter (id) with no description, and the description does not elaborate on its format or meaning beyond 'by Id'. With 0% schema coverage, the description fails to provide essential semantic details for the 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 clearly states the action (delete) and resource (custom field by ID). It also specifies supported object types, which distinguishes it from other custom field tools. However, the repetition of 'Delete Custom Field By Id' reduces clarity slightly.

  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 a constraint (only supports Custom Objects and Company) but does not explicitly state when to use this tool over alternatives or when not to use it. No alternative tools are mentioned.

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

• ghl_email_create_campaignB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false (write operation), destructiveHint=false (not destructive), and idempotentHint=false (not idempotent). The description adds the specific endpoint and OAuth scopes, which are helpful but do not disclose additional behavioral traits such as what the created campaign state is (draft? published?), or whether it can be used immediately.

  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 short (three lines) and front-loaded with the purpose. It includes useful endpoint and OAuth scope details but lacks a structured breakdown. No unnecessary information, but it could be slightly more organized.

  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 omits crucial context for a creation tool: it does not explain what the response will be (e.g., created campaign ID), how this campaign fits into the lifecycle (e.g., it must be edited or scheduled via other tools), or any implications of the nested body structure. Given the complexity (nested object with 8 sub-fields) and no output schema, the description is insufficiently 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?

  Input schema has 100% field description coverage, meeting the high-coverage baseline. The tool description does not add any parameter-level meaning beyond what the schema provides. With baseline at 3, no extra value is contributed.

  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 email campaign', using a specific verb ('Create') and resource ('email campaign'). The name includes 'create_campaign', and sibling tools like ghl_email_delete_campaign, ghl_email_update_campaign, etc., further distinguish this creation action. No ambiguity exists.

  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 prerequisites, when not to use it, or how it differs from other email campaign operations (e.g., update, schedule). The agent receives no decision-making context.

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

• ghl_email_get_campaign_statsB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces this with OAuth scopes (emails/stats.readonly) and provides the endpoint, but does not add further behavioral details like pagination or response structure.

  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 concise, with only four lines. It is front-loaded with the purpose and provides essential technical details (endpoint, version, OAuth scopes). Some may consider the endpoint too technical for an LLM, but overall it is efficiently 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 description lacks information about what statistics are returned and their structure. Since there is no output schema, the description should compensate by describing the return value, which it does not. This makes the tool less complete 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%, so the baseline is 3. The description mentions the endpoint path which implicitly includes locationId, source, and sourceId, but adds no additional meaning beyond the schema's parameter descriptions. It does not elaborate on subSourceId.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it retrieves statistics for email campaigns, workflows, or bulk actions. It explicitly names the three source types, which distinguishes it from sibling tools like ghl_email_get_campaign that return individual campaign details.

  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 versus alternatives. It fails to mention that this is for aggregated statistics and not for fetching individual campaign details, which is available via sibling tools.

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

• ghl_email_template_createB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false (write). The description adds the endpoint and OAuth scopes, which are useful but do not disclose additional behavioral traits like side effects or response behavior. No contradiction with annotations.

  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 short and front-loaded with the purpose. There is slight redundancy ('Create an email template' and 'Create a new email template'), but overall it is efficient and includes endpoint and scopes.

  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 lacks information about the response (no output schema). For a create tool with nested parameters, the agent needs to know what is returned (e.g., the created template object). The endpoint and scopes add some context but do not compensate for this gap.

  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?

  Input schema covers both parameters with descriptions and examples (100% coverage). The description does not add any parameter-level information 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 'Create an email template' with a specific verb and resource. It is easily distinguishable from sibling tools like ghl_email_template_delete or ghl_email_template_list by the action and resource 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?

  The description provides no guidance on when to use this tool versus alternatives such as ghl_email_builder_template_create. No prerequisites, context, 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.

• ghl_estimate_template_previewB
  3.3/5.0
  Behavior2/5

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

  Annotations provide readOnlyHint, destructiveHint, idempotentHint. Description adds OAuth scopes (invoices/estimate.readonly), which is useful authentication context. Otherwise no extra behavioral info.

  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?

  Description is short and front-loaded with purpose. Includes technical details (endpoint, scopes) in a structured manner, but could be slightly more optimized.

  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?

  Tool is simple; annotations cover safety. Lacks information about return format or when to use. Adequate for a read-only preview tool but not fully comprehensive.

  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?

  Description lacks any parameter description beyond what's in schema. Schema coverage is 67%, and description does not compensate with additional context for 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 previews an estimate template, distinct from sibling tools like create/list/delete. The verb 'preview' and title indicate a read-only 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?

  No explicit guidance on when to use vs alternatives. Implicit from annotations (read-only, idempotent) and context, but lacks explicit direction like 'use after listing templates'.

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

• ghl_funnel_listB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that pagination allows paging through full result sets, but does not mention other behavioral traits like required permissions or error handling. No contradiction with annotations.

  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 reasonably concise with three sentences, but includes technical details like file paths that may not be useful for an AI agent. It could be streamlined.

  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 7 parameters, no output schema, and basic annotations, the description should explain what funnels are, the purpose of each parameter, and the expected response format. It only covers pagination and the endpoint, leaving significant 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?

  Schema description coverage is 0%. The description only clarifies that offset and limit are for pagination, leaving the other five parameters (name, type, category, parentId, locationId) unexplained. This does not compensate sufficiently 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 ('Fetch List of Funnels') and the resource ('funnels'). It distinguishes from sibling tools as no other sibling lists funnels specifically.

  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 mentions pagination parameters (offset, limit) and the endpoint, but does not provide explicit guidance on when to use this tool versus alternatives 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.

• ghl_invoice_createB
  3.3/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false and destructiveHint=false, so the description's statement 'API to create an invoice' is consistent. The description adds endpoint and OAuth scopes, which provide some context but no further behavioral traits. No contradiction with annotations.

  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 brief (three lines) and front-loaded with 'Create Invoice'. While it includes somewhat technical details (endpoint, OAuth scopes), it remains efficient with minimal wasted text.

  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 complexity of the nested schema, the description offers no guidance on constructing the body, required fields, or return value. No output schema is provided, and the description does not compensate for this lack.

  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 a single body parameter. The description only repeats that the schema is carried verbatim, adding no semantic value beyond what is already in the input schema. 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 'create' and the resource 'invoice', distinguishing it from sibling tools like ghl_invoice_delete, ghl_invoice_get, etc. The 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 other invoice-related tools (e.g., ghl_invoice_schedule_create, ghl_estimate_convert_to_invoice). There is no mention of 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.

• ghl_invoice_sendB
  3.3/5.0
  Behavior2/5

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

  Annotations provide minimal behavioral hints (not read-only, not destructive). The description adds endpoint and scopes but does not explain side effects like invoice status changes, communication channels, or the significance of the 'action' parameter.

  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?

  Description is concise at four lines, front-loaded with the action. However, it could be better structured as a coherent sentence instead of fragmented details.

  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 complex input schema with nested objects and enum, the description lacks explanation of how parameters interact (e.g., action modes, auto-payment). No mention of prerequisites or how sending affects invoice state.

  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 schema already documents parameters. The description adds no extra meaning beyond what the schema provides, resulting in baseline 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 clearly states the tool sends an invoice by invoice ID. The verb 'send' and resource 'invoice' are unambiguous, and the tool is distinct from siblings like create, delete, or schedule.

  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 guidance on when to use this tool versus other invoice-related tools (e.g., create, schedule). The name implies sending, but context on prerequisites or alternatives is missing.

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

• ghl_invoice_template_listB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare safe read-only behavior; the description adds pagination advice but does not contradict 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?

  Extremely concise: four lines with clear front-loading, no unnecessary wording.

  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?

  Description provides endpoint, auth scopes, and pagination, but lacks details on response shape (no output schema); adequate but not thorough.

  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 parameters are well-documented in schema; description adds minimal extra meaning beyond mentioning pagination.

  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 templates, but it lacks specificity to 'invoice templates'; the tool name provides context.

  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 (e.g., ghl_invoice_template_get or estimate templates); only pagination details are mentioned.

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

• ghl_invoice_template_update_late_fees_configurationB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate a write operation (readOnlyHint=false) with no destructive or idempotent behavior. The description adds the endpoint and version header, but does not disclose additional traits like permissions, side effects, or concurrency. It is adequate but does not go beyond what annotations already imply.

  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 concise with three sentences, covering the purpose, endpoint, and source. It could be restructured to front-load key details, but overall it is efficient and not 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 complexity of nested objects and many sibling invoice-related tools, the description lacks context about the late fees domain, prerequisites, or return values. No output schema exists, and the description does not compensate by explaining what the tool returns or common use cases. It feels incomplete for a configuration update 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?

  Schema coverage is 100% with detailed parameter descriptions (e.g., altId, lateFeesConfiguration). The tool description adds no extra meaning 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 clearly states the action ('update') and the resource ('template late fees configuration'). It distinguishes from sibling tools like ghl_invoice_template_update and ghl_invoice_template_update_payment_methods_configuration by specifying the exact configuration aspect being updated. The endpoint details further clarify 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 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_invoice_template_update for general template updates. There are no prerequisites, scenarios, or exclusions mentioned. The description only gives the endpoint and version, 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.

• ghl_invoice_updateB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate idempotentHint=true, destructiveHint=false, readOnlyHint=false. The description adds 'Update invoice' but no further behavioral context (e.g., whether it performs a partial or full replacement, side effects, or validation). It does not contradict annotations.

  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 concise with three lines, front-loading the core purpose. However, it could be more efficient by omitting endpoint and scope details that might be elsewhere, but overall no fluff.

  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 (many nested parameters, one of many invoice tools) and absence of output schema, the description lacks important context: update scope, response details, field constraints, and differentiation from similar 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?

  Input schema has 100% description coverage with detailed field descriptions. The tool description does not add any additional meaning beyond the schema (e.g., parameter behavior, constraints, or examples). 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 'Update invoice' and specifies the action is by invoice ID. It differentiates from sibling tools like ghl_invoice_create, ghl_invoice_delete, etc. by explicitly naming the verb and resource.

  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 (e.g., create, delete, list). It does not mention prerequisites, partial vs full update, or conditions for use.

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

• ghl_location_create_custom_valueB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate that the tool is not read-only, not destructive, not idempotent, and open-world. The description adds the OAuth scope (locations/customValues.write), which is a behavioral requirement beyond schema. However, it does not disclose effects like duplicate handling or whether the operation replaces existing values, so additional context 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded with the purpose. It includes useful technical details (endpoint, OAuth scopes) but repeats the title in the text. Overall, it is concise and to the point, though minor redundancy exists.

  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 the tool has two parameters (one nested) and siblings for CRUD, the description lacks integration guidance. It does not explain what the tool returns (no output schema), nor does it differentiate when to use this versus other custom value tools. The minimal description leaves gaps for effective usage.

  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 description merely restates the schema information (e.g., 'Request body (schema carried verbatim)'). It adds no extra meaning, such as constraints on name/value or examples beyond the schema's examples.

  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 Custom Value', and the tool name includes 'location_create_custom_value', which unambiguously indicates the action (create) and resource (custom value for a location). The endpoint path further reinforces this. It effectively differentiates from sibling tools like 'update_custom_value' or 'delete_custom_value' by specifying the creation verb.

  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 its siblings (e.g., update, delete, get). No prerequisites or alternative scenarios are mentioned, leaving the agent without context for selection.

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

• ghl_location_get_permissionsB
  3.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and destructiveHint, but the description adds valuable context: the requirement for an agency-level token and a security caveat (scope name mismatch). This exceeds the baseline provided by annotations, though rate limits or response behavior are not mentioned.

  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 verbose and includes extraneous technical details (endpoint, version header, source file) that do not aid an AI agent in selecting or invoking the tool. The core message (agency token requirement and get permissions) could be conveyed in two sentences.

  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 an output schema, the description should explain what the return value contains (e.g., a list of permissions). It does not, leaving the agent without guidance on expected results. The authentication requirement is well-covered, but the response structure is missing.

  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 minimal additional meaning beyond the schema's 'Location Id' description, only restating that it's a location/sub-account. No format or retrieval guidance is provided.

  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 it retrieves permissions for a sub-account/location. The phrase 'Get Sub-Account (Formerly Location) permissions' clarifies the resource. However, it does not explicitly differentiate from sibling tools like ghl_location_update_permissions, relying on the name for distinction.

  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 prominently notes that an agency-level token is required, which is a critical usage constraint. However, it offers no guidance on when to use this tool versus alternatives such as ghl_location_update_permissions, nor does it explain what permissions are being retrieved or how they are structured.

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

• ghl_location_get_timezonesB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the endpoint and OAuth scopes, which are beyond annotations. No additional behavioral traits (e.g., rate limits, pagination) are disclosed.

  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 short but includes redundant lines ('Fetch Timezones' and 'Fetch the available timezones') and implementation details (endpoint, source file) that are not essential for an AI agent. Could be more concise.

  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 read-only tool with one parameter, the description covers purpose, parameter, and OAuth scope. It does not mention the response format (e.g., returns an array of timezone strings), which would add value. Adequate but not 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% (only parameter locationId with a description). The description does not add any additional meaning about the parameter beyond the schema. Baseline 3 for high 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 states 'Fetch Timezones' and 'Fetch the available timezones', clearly indicating the tool retrieves timezones for a location. The verb and resource are specific. It does not explicitly distinguish from sibling tools, but the name and context make it obvious.

  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 OAuth scopes (locations.readonly) and the endpoint, implying it is a read operation. However, it does not explicitly state when to use it vs alternatives or provide any exclusions, leaving usage guidance implicit.

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

• ghl_media_create_folderB
  3.3/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds no behavioral details beyond 'creates a new folder', such as side effects, idempotency, error conditions (e.g., duplicate name), or permission requirements. For a creation tool with openWorldHint=true, more transparency is needed.

  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 concise—three short sentences. The first line 'Create Folder' is somewhat redundant with the action statement. The endpoint detail, while possibly useful, is extra. Still, it is efficient and front-loaded with the purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, but the description does not mention what the response contains (likely the created folder object). It also fails to contextualize required parameters like altId (location) or parentId. For a creation tool, users would benefit from knowing the return value or typical behavior. The description is too sparse for full 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%: all parameters have clear descriptions (e.g., 'Name of the folder', 'Location Id', 'Type of entity (location only)', 'ID of the parent folder (optional)'). The tool description adds no additional parameter information beyond what the schema already provides. 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 states clearly 'Creates a new folder in the media storage', specifying the verb 'creates' and the resource 'folder in media storage'. This distinguishes it from sibling media tools (e.g., upload, delete, list) which operate on files rather than folders.

  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 guidance on when to use or avoid this tool is given. The description does not mention alternatives or conditions. However, the tool name and purpose are clear enough that an AI agent can infer its usage in the context of media folder creation. The lack of explicit guidelines keeps it at a 'implied usage' level.

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

• ghl_opportunity_searchB
  3.3/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, non-destructive. The description adds the need for pagination to overcome the ~100 record limit, which is valuable behavioral context beyond annotations.

  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 paragraph with some redundancy (pagination mentioned twice). It could be more structured and concise.

  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 complex pagination and 20 parameters, the description lacks explanation of the return value structure. However, annotations compensate somewhat, making it moderately 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 parameter descriptions. The description only enumerates the parameters without adding new semantic information 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 it is a search tool for opportunities, listing all filter parameters and pagination details. However, it does not differentiate from the sibling tool ghl_opportunity_search_advanced.

  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 pagination instructions but lacks guidance on when to use this tool versus other opportunity search/retrieval tools. No explicit context for selection among siblings.

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

• ghl_phone_list_active_numbersB
  3.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, but the description adds useful behavioral details: response envelope structure, version-specific changes (isUnderGhl→isUnderLc), pagination mechanism, and OAuth scopes. This exceeds what annotations provide.

  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 somewhat repetitive (first sentence duplicated) and contains technical details (endpoint, version) that could be more concise. However, it is well-structured with key information 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?

  Given no output schema, the description partially compensates by explaining the response envelope and pagination. However, it does not cover the behavior of all parameters (e.g., skipNumberPool, includeRcsSenderIds) or the requirement for locationId. Adequate but with 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?

  Input schema has 100% description coverage, so parameters are already well-documented. The description mentions pagination params but adds minimal new semantics beyond the schema. No additional explanation for searchFilter, skipNumberPool, or includeRcsSenderIds.

  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?

  Clearly states 'List active numbers' with specific verb and resource. While the purpose is clear and aligns with the tool name, it does not explicitly differentiate from sibling tools like ghl_phone_list_available_numbers or ghl_phone_list_number_pools.

  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 vs alternatives such as listing available numbers or number pools. The description does not provide context for appropriate 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.

• ghl_product_collection_deleteB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true, so the description doesn't repeat that. It adds OAuth scopes and endpoint details, which are useful but not critical for behavior. No contradiction with annotations.

  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 brief but includes technical details like endpoint and version header, which may not be necessary for most agents. The first sentence is clear; the rest adds noise.

  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 delete tool with full schema and annotations, the description is adequate. However, missing usage guidelines and behavioral context (e.g., whether deletion is irreversible) reduces 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 coverage is 100% with parameter descriptions. The description only mentions collectionId, adding no new meaning beyond what the schema already provides. Baseline score 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 name and description clearly state the tool deletes a product collection. The verb 'Delete' and specific resource 'product collection' are unambiguous. Sibling tools like create, get, list, and update confirm clear 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 on when to use this tool versus alternatives. Does not mention prerequisites (e.g., collection must exist) or scenarios where deletion is appropriate. The description is purely operational.

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

• ghl_saas_update_saas_subscription_deprecatedB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate non-read-only, non-destructive, and idempotent. The description adds the token requirement and deprecation context, but does not disclose other behavioral traits like side effects 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is somewhat verbose with repeated deprecation notices and includes multiple lines. It front-loads key information but could be more concise.

  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 covers deprecation, token requirement, and purpose, but lacks details about response format, prerequisites, or error handling. Given no output schema, more context would be helpful.

  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 descriptions for each parameter. The description does not add extra meaning beyond what the schema provides, so 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 updates an existing SaaS subscription plan/pricing, correcting a misleading name. It specifies the verb and resource, and differentiates from the deprecated status by mentioning the superseding endpoint. However, it does not explicitly contrast with the non-deprecated sibling tool.

  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 a key requirement (agency-level token) and a deprecation warning preferring the replacement. It lacks explicit when-not-to-use or detailed alternatives beyond the deprecation notice.

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

• ghl_social_fetch_edit_session_calendarB
  3.3/5.0
  Behavior2/5

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

  The description uses 'Fetch' and 'Retrieves' suggesting a read-only operation, but annotations set readOnlyHint to false, indicating potential side effects. The description does not disclose side effects, rate limits, or authorization details beyond the OAuth scopes listed. This contradicts the annotation.

  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 concise with two sentences plus endpoint/scopes. It is front-loaded with the title-like first sentence. Every sentence adds value, though it could be more structured (e.g., bullet points for parameters).

  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 no output schema, the description does not explain the return format or error handling. It explains the purpose (preview of unsaved changes) but omits details like pagination or filtering behavior. The endpoint and scopes are provided, but completeness is moderate for a tool with nested body 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 50% with queueId lacking a description and body having a generic one. The description adds minimal parameter meaning, only hinting at 'draft items within an edit session' which implies sessionId usage. Nested properties are described in schema but queueId's purpose remains 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 it 'Fetch[es] calendar view for an edit session' and explains it retrieves a calendar preview of scheduled posts based on draft items in an edit session. This distinguishes it from siblings like ghl_social_fetch_calendar_list (which fetches actual calendar) and ghl_social_save_edit_session (which commits changes).

  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 ('shows how posts would be scheduled if changes were saved') but does not explicitly state when to use this over alternatives, such as comparing to ghl_social_fetch_calendar_list or ghl_social_start_edit_session. No when-not-to-use guidance is provided.

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

• ghl_social_get_twitter_profileB
  3.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds critical behavioral context: the tool is deprecated and no longer supported (X/Twitter unsupported as of Dec 2024), which is beyond what annotations provide. This is valuable for the agent to avoid using the tool.

  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 not concise due to the inclusion of a large styled HTML warning and endpoint details. The key information (deprecation and purpose) is front-loaded, but the HTML adds unnecessary verbosity for an agent. Adequate but could be cleaner.

  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 no output schema, and the description does not explain return values or additional context beyond the deprecation. For a deprecated tool, the deprecation notice is essential, but overall completeness is average. The annotations mitigate some missing 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 descriptions for both parameters. The description does not add any additional meaning about the parameters beyond what the schema provides, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get Twitter profile', indicating the action and resource. However, the prominent deprecation warning may cause confusion about whether the tool should still be used. It distinguishes from siblings by name, but the deprecation is a significant modifier.

  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 includes a deprecation notice but does not specify when to use this tool vs alternatives. It mentions 'prefer the documented replacement if one exists' but does not name any replacement. No explicit guidance on usage context.

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

• ghl_social_update_queueB
  3.3/5.0
  Behavior3/5

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

  Annotations indicate the tool is not read-only, not destructive, idempotent, and open-world. The description adds the endpoint and OAuth scopes, but does not disclose side effects, what happens on different status changes, or whether changes are reversible. It adds moderate value beyond annotations.

  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 short (three sentences) and front-loads the purpose: 'Update queue settings or status'. It includes endpoint and scopes, which are ancillary but not excessive. It could omit the endpoint detail for conciseness, but overall 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 there is no output schema, the description should explain the response or at least expected outcomes. It does not mention that the queue must exist, what happens on error, or what the response contains. For an update operation, this is a notable gap.

  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 detailed descriptions for all parameters (e.g., status, timeSlots, skipDateTime). The tool description briefly mentions what can be updated (status, time slots, skip dates) but does not add significant meaning beyond the schema. With schema description coverage reported as 50%, the description could compensate more, but it remains minimal.

  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 updates queue settings or status, specifying it can update status (active/paused/deleted), time slots, or skip dates. This distinguishes it from sibling tools like ghl_social_create_queue (creating a queue) and ghl_social_update_queue_item (updating queue items).

  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 when or when not to use this tool versus alternatives like ghl_social_create_queue or ghl_social_fetch_queue_by_id. No prerequisites or exclusions are mentioned, leaving the agent without guidance on tool selection.

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

• ghl_store_delete_shipping_zoneB
  3.3/5.0
  Behavior3/5

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

  The annotations already declare destructiveHint: true, indicating data modification. The description adds the endpoint and ID but no additional behavioral context (e.g., irreversibility, cascading effects). No contradiction with annotations.

  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 short and includes the endpoint, which is useful. However, the second sentence is redundant with the first. Could be more efficient by merging.

  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 delete with 3 parameters and annotations, the description covers the ID but misses explanation of altId and altType. The endpoint detail helps but does not fully compensate for missing parameter semantics.

  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 mentions only shippingZoneId, ignoring altId and altType. The schema description for shippingZoneId is misleading ('ID of the item that needs to be returned' suggests retrieval, not deletion). The description adds no value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Delete shipping zone' and specifies the action with the ID parameter, making the purpose unmistakable. It is distinct from sibling tools like ghl_store_delete_shipping_carrier or ghl_store_update_shipping_zone.

  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 vs. alternatives. It does not mention prerequisites, when not to use it, or provided a comparison with other shipping zone operations.

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

• ghl_store_get_settingsB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds the endpoint URI and source but no additional behavioral details. While it does not contradict annotations, it adds minimal value beyond them.

  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 short (three sentences) but includes a redundant repetition of the title. It is front-loaded with the purpose but could be more concise by removing the first sentence. Overall, it is efficient 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 read tool with two parameters and no output schema, the description covers the basic action and parameters. However, it does not describe the return value or what the store settings represent, which would be helpful. It is adequate but not comprehensive.

  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 mentions parameters 'altId' and 'altType' but adds no meaning beyond what the schema provides. The schema itself has a description for altId ('Location Id or Agency Id') and an enum for altType, so the description is redundant. With only 50% schema description coverage (based on context signals), the description should compensate but does not.

  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 'Store Settings', and it specifies the query parameters (altId and altType). The tool name 'ghl_store_get_settings' is distinct from its siblings, which are mostly ad-related tools, so there is no 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?

  The description provides no guidance on when to use this tool versus alternatives, and it does not mention any prerequisites or exclusions. It simply states the action and parameters 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.

• ghl_user_createB
  3.3/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds no behavioral context beyond the endpoint and scopes. It doesn't mention idempotency or that each call creates a new user (potential duplicates). However, annotations already cover the read/write nature, and the description does not contradict them.

  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 very brief, front-loaded with 'Create User', and includes essential endpoint info. It is efficient with no wasted words, though it could include more context without harming 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 complexity of the input schema (many nested properties, no output schema), the description is too sparse. It lacks information about required fields, response format, error handling, and how to handle optional parameters. The agent may struggle to use 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% as the body parameter includes a generic description. All inner properties have descriptions and examples in the schema. The description adds no additional meaning or usage tips for parameters. 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 'Create User' and provides the endpoint and OAuth scopes. The tool name itself indicates creation, distinguishing it from siblings like ghl_user_update, ghl_user_delete, etc. No 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?

  The description lacks guidance on when to use this tool vs alternatives (e.g., when to use create vs update). No prerequisites, exclusions, or context about when not to use it are provided. The OAuth scopes are mentioned but not explained in terms of usage.

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

• ghl_user_deleteB
  3.3/5.0
  Behavior2/5

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

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds OAuth scopes and a known issue about potential failure, but it contradicts the input schema by claiming 'no input field for userId', which undermines trust. The description provides misleading behavioral info.

  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 includes a verbose known issue block up front, which is important but could be more concise. The core purpose 'Delete User' is clear, but the overall structure is not optimally 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?

  For a simple delete tool with one parameter, the description provides endpoint details, OAuth scopes, and a known issue caveat. Annotations cover destructive and idempotent hints. No output schema exists, so completeness is adequate for the tool's simplicity.

  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 covers the only parameter (userId) at 100% coverage, so baseline is 3. However, the description adds confusing information by stating the parameter is missing, despite the schema including it. This ambiguity reduces the value added 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 'Delete User' and provides the HTTP DELETE endpoint, making the purpose unambiguous. It distinguishes itself from sibling tools like ghl_user_get, ghl_user_update, and ghl_user_create by specifying a 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use (to delete a user) but does not explicitly state exclusions or alternatives. It mentions required OAuth scopes (users.write) which adds some context, but no comparison to other user tools is provided.

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

• ghl_voice_ai_create_actionB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false (write operation). Description adds OAuth scopes and endpoint details, providing moderate behavioral context. Does not disclose side effects beyond creation.

  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?

  Description is short (two sentences plus endpoint/scopes). Front-loaded with purpose. Minor redundancy: 'Create Agent Action' repeats annotation title.

  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?

  Complex tool with many action types (oneOf), but description provides no overview of action types or how to choose one. No output schema, and description doesn't hint at response. Missing high-level 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 description coverage is 100%, so the schema already documents all parameters. The tool description adds no parameter information, but the schema compensates fully. 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 'Create a new action for a voice AI agent' which is a specific verb and resource. It differentiates from sibling tools like delete, update, and get actions.

  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 (e.g., when to create vs update). No prerequisites or context about when this action type is needed.

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

• ghl_ad_fb_ad_duplicateB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description adds the endpoint and OAuth scopes. However, it does not disclose potential side effects (e.g., new ad ID creation) or asynchronous 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 short and front-loaded with purpose. Minor redundancy ('Duplicate ad' and 'Duplicate an existing Facebook ad' are repetitive), but overall efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter, the description covers purpose, endpoint, and scopes. However, it lacks information about the return value (e.g., new ad ID) and does not mention that the adId must refer to an existing ad.

  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 description adds no additional meaning beyond the schema's 'Ad identifier' description. The example value is already 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 clearly states the verb 'duplicate' and the resource 'Facebook ad', making the tool's purpose unambiguous. It naturally distinguishes from sibling tools like delete, pause, resume, and upsert.

  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_ad_fb_adset_duplicate or ghl_ad_fb_campaign_duplicate. It lacks prerequisites or use-case context.

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

• ghl_ad_fb_adset_upsertB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds the endpoint and OAuth scopes, which are useful but do not significantly expand on the behavioral traits beyond the annotations. The 'upsert' behavior is implied but not elaborated (e.g., what fields are 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 extremely concise with three lines: a summary, a one-line explanation, and endpoint/scopes. No superfluous text. 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?

  Despite the detailed schema, the description lacks information about return values (e.g., the created/updated adset ID or status). Since there is no output schema, the description should at least hint at the response. Additionally, it does not mention required integrations or permission checks.

  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 is fully described (100% coverage) with detailed properties and examples. The description does not add any additional meaning beyond what the schema already provides. According to the scoring guidelines, with high schema coverage, baseline is 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the resource ('adset') and the action ('upsert' meaning create or update). This distinguishes it from sibling tools like ghl_ad_fb_adset_delete, ghl_ad_fb_adset_duplicate, etc.

  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, such as the need for an existing Facebook integration or campaign. The description merely states what the tool does without context.

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

• ghl_ad_fb_audience_member_removeB
  3.4/5.0
  Behavior3/5

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

  Annotations indicate destructive and idempotent; description adds endpoint and OAuth scopes but does not elaborate on behavior beyond 'remove'. No contradiction with annotations.

  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?

  Description is concise with three focused lines (purpose, endpoint, scopes). Efficient but could be slightly more 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 removal tool, description is adequate given full schema and annotations. Lacks mentions of prerequisites or constraints (e.g., audience must 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?

  Schema coverage is 100%, so the baseline is 3. Description adds no additional meaning to parameters beyond what 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?

  Description clearly identifies the action ('Remove') and resource ('custom audience member'), and it is distinct from sibling tools like 'add' and 'batch_update'.

  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 vs alternatives (e.g., add, batch update). Does not specify prerequisites or conditions for removal.

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

• ghl_ad_fb_campaign_deleteB
  3.4/5.0
  Behavior3/5

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

  The description conveys destructive behavior ('Delete') and provides endpoint version and OAuth scopes, which adds context beyond annotations. However, it does not disclose consequences (e.g., irreversible, cascading deletions) or response behavior. Annotations already indicate destructiveHint=true, so the burden is partially shared.

  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 short and front-loaded with the purpose. The first sentence repeats the title unnecessarily, but overall it is efficient and contains no filler. Could be slightly tighter by removing the redundant first line.

  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 no output schema and 2 required parameters (including a nested body object), the description provides endpoint and OAuth scopes but lacks information on response format, error handling, or whether deletion is immediate. A more complete description for a destructive action would include at least a brief note on return value or side effects.

  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% (both parameters have descriptive examples and text). The description adds no additional meaning beyond what the schema already provides, meeting the baseline for good 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') and resource ('a Facebook campaign by ID'), and distinguishes from sibling delete tools (e.g., ad, adset) by specifying the resource type. The first line 'Delete campaign' is direct 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?

  No guidance is provided on when to use this tool versus alternatives like ghl_ad_fb_campaign_pause or ghl_ad_fb_campaign_upsert. There is no mention of prerequisites, conditions for use, or when deletion is appropriate (e.g., irreversible action).

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

• ghl_ad_fb_campaign_pauseB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate it's a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds OAuth scopes and endpoint details, and implies it only works on running campaigns, but does not explain error behavior or side effects. No contradiction with annotations.

  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 concise with no unnecessary words. It includes title, action, endpoint, and scopes in a structured format. Minor redundancy from the title line, but overall efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple pause action, the description is mostly adequate. It lacks mention of prerequisites (e.g., campaign must be running), error conditions, and response format. No output schema or return value description is provided.

  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?

  Input schema has 100% parameter coverage with descriptions and examples for campaignId and locationId. The description adds no additional parameter semantics beyond what the schema provides, warranting the baseline 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 clearly states 'Pause a running Facebook campaign', which is a specific verb and resource. The name and description together distinguish this from sibling tools like resume, delete, or duplicate by focusing on pausing a campaign.

  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 does not clarify that it only works on running campaigns or that other tools like 'ghl_ad_fb_campaign_resume' should be used to reverse the action.

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

• ghl_ad_fb_conversation_form_listB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read-only behavior. The description adds endpoint and OAuth scope details, which are useful but do not significantly expand on behavioral traits beyond the annotations. No contradiction is present.

  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 concise with a clear title and purpose statement. It includes endpoint and OAuth details, which may be extraneous for an AI agent but do not cause significant bloat. 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description lacks any information about the return value or output structure. Since no output schema is provided, the agent has no indication of what fields or data the list will contain. This is a notable gap for a list operation, but the annotations and existing details provide moderate 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?

  Input schema coverage is 100%, and the description adds no additional meaning beyond the schema's parameter descriptions ('Is draft', 'Location identifier'). The agent can rely on the schema, but the description does not clarify how or when to use the optional isDraft 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 verb 'get' and 'retrieve' and the resource 'Facebook conversation lead forms'. It distinguishes from sibling tools like ghl_ad_fb_lead_form_get and ghl_ad_fb_page_lead_form_list by specifying 'conversation forms', making the purpose 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?

  No guidance is provided on when to use this tool versus related siblings such as ghl_ad_fb_lead_form_get or ghl_ad_fb_page_lead_form_list. There are no stated exclusions or context for when not to use this tool, leaving the agent to infer usage.

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

• ghl_ad_fb_page_deleteB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint: true, so the description does not need to reiterate destruction. It adds the endpoint and OAuth scopes, which are useful technical details. However, it does not disclose potential side effects (e.g., impact on related campaigns or posts) or confirm irreversibility. The bar is partially lowered due to annotations, but the description could still add context about the operation's finality.

  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 concise, with a title sentence followed by a single clarifying sentence and then technical details (endpoint, OAuth scopes). It is front-loaded with the purpose. No irrelevant information is included, and every line serves a 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 simple nature of a delete operation with two required parameters, the description covers the essential purpose and technical details. However, it does not mention return values (no output schema), error cases, or prerequisites. It is minimally complete for straightforward use but lacks depth for complex 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?

  Schema coverage is 100%; both parameters have descriptions in the input schema (pageId: 'Facebook page ID', locationId: 'Location identifier'). The description does not add any additional meaning or constraints beyond what the schema provides, 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 'Delete page connection' and 'Remove a Facebook page connection from a location', specifying the verb (delete/remove) and resource (Facebook page connection). It distinguishes this from sibling tools like ghl_ad_fb_page_list and ghl_ad_fb_page_set_default, which are about listing or setting default pages.

  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. It lacks context such as prerequisites (e.g., must have an existing connection), limitations, or situations where other tools (like ghl_ad_fb_page_list for checking connections) should be used first.

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

• ghl_ad_fb_page_lead_form_listB
  3.4/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, which cover the safety profile. The description adds the endpoint URL, version header, and OAuth scopes, which are useful but do not reveal new behavioral traits beyond what annotations imply. No contradiction with 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 concise: two sentences plus endpoint/scope details. Every part adds value, and the purpose is front-loaded. 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 list tool, the description covers purpose, endpoint, OAuth scopes, and parameters (via schema). It does not mention return format, but this is often inferred. With annotations providing safety context, the description is fairly 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 description coverage is 100%, so the parameters are already documented. The description reinforces that this is for a specific Facebook page (pageId) but does not add additional meaning beyond the schema descriptions. Baseline 3 is appropriate given high 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 states 'Get page lead forms' and 'Retrieve lead gen forms for a specific Facebook page', clearly indicating the verb (get/retrieve) and resource (lead forms for a page). It distinguishes from siblings like ghl_ad_fb_lead_form_get (single form) and ghl_ad_fb_lead_form_create (create), though it does not explicitly name these 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 on when to use this tool versus sibling tools like ghl_ad_fb_lead_form_get (for a single form) or ghl_ad_fb_conversation_form_list (conversation forms). No when-not-to-use or prerequisite information provided beyond OAuth scopes.

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

• ghl_ad_google_account_listB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds endpoint details (GET) and OAuth scope (adPublishing.readonly), confirming read-only behavior. However, it does not discuss rate limits, response size, or other behavioral traits.

  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 short and front-loaded with the key action. However, the first line 'Get Google ad accounts' is redundant with the annotation title. Overall concise but could be slightly more 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 list tool with no output schema, the description provides purpose and auth details but lacks information on return format (e.g., list of account objects) and pagination behavior. Adequate but with gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both parameters described in the schema (type enum, locationId required). The tool description does not add any additional meaning beyond the schema, so 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 'Get Google ad accounts' and 'Retrieve Google Ads accounts available for the connected user', specifying the verb and resource. The sibling tools include 'ghl_ad_google_account_get' for single account retrieval, so this tool is distinct as a 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 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 such as 'ghl_ad_google_account_get' or other list tools for different ad platforms. The description does not include any when-to-use or when-not-to-use context.

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

• ghl_ad_google_campaign_publishB
  3.4/5.0
  Behavior3/5

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

  Annotations indicate non-read-only and non-destructive behavior. Description adds OAuth scopes and endpoint, but does not disclose whether publishing is reversible 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is short and front-loaded, but the first line 'Publish ad' is redundant with the second line. Otherwise efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Provides endpoint and OAuth scopes, but lacks details on return values or behavior after publishing. Mismatch between tool name ('campaign') and description ('ad') may confuse.

  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 a clear description for the only parameter (adId). Description does not add extra parameter 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 clearly states 'Publish a Google ad and push it live', specifying the verb (publish) and resource (Google ad). This distinguishes it from sibling tools like Facebook or LinkedIn campaign publish tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives (e.g., ghl_ad_google_campaign_upsert for editing). Prerequisites (e.g., ad must be in a publishable state) are not mentioned.

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

• ghl_ad_google_conversion_upsertB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, and the description does not contradict them. It adds endpoint details and OAuth scopes but does not elaborate on upsert behavior (e.g., what happens on conflict, required prerequisites like locationId). The additional context 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loads the purpose ('Upsert conversion'), followed by technical details (endpoint, OAuth). It is efficient but could be streamlined into a single coherent sentence. 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?

  Given no output schema and well-defined parameters in the schema, the description lacks mention of return values or behavior on duplicates. It also does not clarify that the conversion must belong to a location (though locationId is a required parameter). Overall, it is adequate for a simple mutation tool with good 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?

  Schema coverage is 100% with detailed parameter descriptions. The description adds no extra meaning beyond what the schema provides. Baseline 3 applies as the schema carries the burden.

  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 'Upsert conversion' and 'Create or update a Google Ads conversion action,' specifying the verb and resource. It distinguishes from siblings like get, delete, list, and goal_list, 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 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 alternative conversion tools (e.g., ghl_ad_google_conversion_get, ghl_ad_google_conversion_list). It lacks explicit context on when to choose upsert over other operations, leaving the agent to infer from the name alone.

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

• ghl_ad_google_integration_createB
  3.4/5.0
  Behavior3/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent write operation. The description adds endpoints and OAuth scopes, which provide behavioral context (authentication needed). However, it does not mention side effects (e.g., what gets created or modified) or rate limits. The description adds moderate value beyond annotations.

  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 concise with four lines, front-loading the purpose. It includes endpoint and OAuth scopes without unnecessary elaboration. Minor room for improvement in structuring (e.g., bullet points) but efficient overall.

  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 provides endpoint and OAuth context, but lacks information about the response or return value (no output schema). For a creation tool, it would be helpful to indicate what the response contains (e.g., integration ID). Given moderate complexity (3 required params, nested object), completeness is adequate but not thorough.

  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%; each property (mccId, locationId, adAccountId) has a description in the schema. The tool description does not add any additional parameter meaning beyond what the schema already provides. 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 explicitly states 'Create Google integration' and 'Create a Google Ads integration for a location', providing a clear verb+resource. It distinguishes from sibling tools like ghl_ad_google_integration_get by specifying the creation action.

  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 other integration creation tools (e.g., Facebook) or when prerequisites are required. The description does not include context about appropriate use cases or limitations.

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

• ghl_ad_li_campaign_group_publishB
  3.4/5.0
  Behavior3/5

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

  Annotations (readOnlyHint: false, destructiveHint: false) indicate it's a mutation but not destructive. Description adds endpoint and OAuth scopes, but does not disclose behavior such as making the campaign active, potential side effects, or reversibility. Adequate but not detailed.

  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?

  Relatively concise with three lines: redundant title-like line, a more specific action line, and technical details. Could be improved by removing the first line, but overall efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers the action, endpoint, and auth scopes. Lacks information about preconditions (e.g., campaign status), return values (no output schema), and relationship to siblings (e.g., need to upsert first). Minimally complete for a publish 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 coverage is 100% with descriptions for both parameters (adId and body). The description does not add extra semantics beyond what the schema provides, earning the baseline 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 clearly states the verb 'Publish' and the resource 'LinkedIn ad campaign group', with additional context 'push it live'. This distinguishes it from sibling tools like get, upsert, or delete.

  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. Does not mention prerequisites (e.g., campaign must exist and be in draft state) or when not to use it. Relies solely on the tool's name for context.

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

• ghl_ad_li_integration_createB
  3.4/5.0
  Behavior4/5

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

  The description adds behavioral details beyond annotations, including the endpoint URL, API version, and required OAuth scope 'adPublishing.write'. This helps an agent understand authentication and versioning requirements.

  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 somewhat repetitive (first line duplicates title) and includes technical details that are useful but could be more concisely formatted. It is not overly long but has 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?

  For a creation tool with no output schema, the description should explain what is returned (e.g., integration ID) or error handling. It only covers input and endpoint, missing important output 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?

  Since the input schema has 100% coverage with descriptions and examples, the description adds no additional semantic information beyond stating that the body is from the OpenAPI spec.

  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 (Create), resource (LinkedIn Ads integration), and scope (for a location with ad account details). It distinguishes from sibling tools like integration_get.

  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 when to use this tool vs. alternatives. It lacks explicit usage context, prerequisites, or conditions for use.

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

• ghl_ad_li_lead_form_createB
  3.4/5.0
  Behavior3/5

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

  Annotations indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds OAuth scope requirement ('adPublishing.write'), which is useful, but does not elaborate on creation behavior, idempotency, 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is moderately concise but contains redundancy (first line repeats title). It mixes purpose with technical details (endpoint, version, scope), which could be streamlined. No wasted words but could be shorter.

  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 complex nested parameters, schema covers them fully. However, there is no output schema and the description does not mention return values, response structure, or prerequisites (e.g., required integrations). This gap reduces completeness 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 descriptions already provided for all parameters. The tool description does not add further parameter insights beyond what the schema offers, 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?

  Description clearly states the action ('Create a new LinkedIn lead gen form for an ad account'), identifying the specific resource and platform. Distinguishes from sibling tools like Facebook lead form creation by explicitly mentioning LinkedIn.

  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 guidance on when to use this tool versus alternatives. The context is implied from the name and sibling set (e.g., for LinkedIn vs Facebook), but no when-not-to-use or comparison is provided.

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

• ghl_agent_studio_createB
  3.4/5.0
  Behavior3/5

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

  Annotations indicate it's not read-only or destructive. The description adds that it creates with a staging version, which is useful behavioral context. However, it does not disclose potential side effects, failure modes, or permission requirements beyond what annotations already imply.

  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 relatively concise, with the key action and context in the first sentence. The endpoint and scopes info are secondary but acceptable. No wasted words, though it could be slightly more streamlined.

  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 having nested parameters and no output schema, the description lacks details on how to construct the request body (especially the version object) and what the response contains. This is insufficient for an AI agent to correctly invoke the tool without additional knowledge.

  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?

  With 50% schema description coverage, the tool description does not add any parameter-level meaning. It does not explain the 'version' object structure or required fields. The schema provides some descriptions, but the description fails to compensate for the gaps.

  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 creates a new agent with a staging version, using the verb 'Create' and specifying the resource 'Agent'. It distinguishes from sibling tools like delete, list, etc., and adds context about staging and production promotion.

  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 when to use (to create an agent) but does not explicitly state when not to use or provide alternatives among the many sibling tools. No exclusions or contextual guidance beyond the purpose.

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

• ghl_association_createB
  3.4/5.0
  Behavior4/5

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

  Description provides OAuth scopes (associations.write) and endpoint, adding value beyond annotations. Annotations already show readOnlyHint=false and destructiveHint=false, so description confirms write operation and adds scopes.

  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?

  Short and front-loaded with purpose. The note 'will add more in the future' is slightly extraneous but not harmful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Lacks details on response format, error handling, or prerequisites. For a create operation with nested params, an example or clarification of key/label fields 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 coverage is 100% with descriptions and examples for all properties. Description does not add significant meaning beyond the schema; baseline 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 it creates associations between contact-contact and contact-custom objects, with a specific verb and resource. However, it does not differentiate from sibling tools like ghl_association_create_relation.

  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 (e.g., creating relations vs. associations). No when-not-to-use or prerequisites described.

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

• ghl_brand_board_createB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds endpoint and OAuth scope context, which is useful but does not disclose any behavioral traits beyond what annotations provide. No contradictions.

  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 concise (two key sentences plus endpoint/scopes), front-loaded with purpose. No unnecessary words, but the endpoint and OAuth lines could be considered extraneous for an AI agent primarily concerned with functionality.

  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 complexity (nested objects, no output schema), the description is adequate but lacks details about return value, side effects, or validation. The input schema compensates, but the description could better explain what the tool returns.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed parameter descriptions. The description adds 'with logos, colors, and fonts' which aligns with schema but does not provide additional meaning beyond the schema's own 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 'Create a new brand board' and specifies it creates one with logos, colors, and fonts. This is a specific verb+resource, and it distinguishes from sibling tools like ghl_brand_board_create_voice which creates a voice, not a board.

  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 (e.g., update, delete) or prerequisites. It does not mention when not to use it or reference sibling tools.

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

• ghl_brand_board_delete_voiceB
  3.4/5.0
  Behavior3/5

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

  Annotations already provide destructiveHint=true and idempotentHint=true. Description adds endpoint and version context but does not disclose further behavioral traits like data dependencies 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is concise with endpoint detail, though includes slightly redundant first line. Front-loaded with 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?

  Adequate for a simple delete operation with annotations, but lacks error handling or return value information. Minimal 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 examples, so description adds no additional parameter semantics. 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?

  Description explicitly states 'Delete Brand Voice' and 'Delete a brand voice by ID', clearly identifying the action and resource. Distinct from sibling tools like ghl_brand_board_get_voice and ghl_brand_board_create_voice.

  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 vs alternatives, no prerequisites or conditions provided. Only states the operation.

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

• ghl_brand_board_get_voiceB
  3.4/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows this is a safe, idempotent read operation. The description adds no behavioral context beyond stating the endpoint version. It does not disclose error behavior, auth requirements, or rate limits. Therefore, it adds no value beyond annotations.

  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 short (3 sentences) but contains a redundant first line that repeats the title from annotations. While not verbose, the redundancy reduces efficiency. It is front-loaded with 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?

  For a simple retrieval tool with a well-defined schema and annotations, the description is largely adequate. However, it could mention that it returns a brand voice object, or provide any caveats. Given the lack of output schema, the agent might benefit from more details. Still, it is sufficient for basic use.

  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 full coverage (100%) with descriptions and examples for both parameters. The description does not add any additional explanation or context for the parameters. 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 explicitly states 'Get a brand voice by ID', clearly indicating the verb (Get) and resource (brand voice). It distinguishes from sibling tools like list_voices (which lists multiple) and get_by_id (which gets the board, not voice). The inclusion of the endpoint further clarifies 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., list_voices for retrieving all voices, or create_voice for creating). No when-not-to-use or prerequisite information is given. Usage is only implied by the verb and resource.

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

• ghl_calendar_listB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds little beyond endpoint and OAuth scopes. No contradiction, but no additional 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is short and front-loaded with purpose. However, includes potentially unnecessary technical details (endpoint path and source file). No fluff.

  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 list tool with annotations, the description is adequate but lacks output format, pagination info, or usage notes. Missing partial 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 coverage is 100%, so the schema fully documents parameters. The description does not add meaning beyond 'in a location', which is already captured by locationId.

  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 'Get all calendars in a location' with a clear verb and resource, and distinguishes from siblings like ghl_calendar_get (single calendar) and ghl_calendar_event_list (events).

  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 vs alternatives like ghl_calendar_get or ghl_calendar_event_list. Missing context for agent decision-making.

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

• ghl_calendar_notification_createB
  3.4/5.0
  Behavior3/5

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

  The description indicates it's a write operation (complementing readOnlyHint=false) and adds that multiple notifications can be created but limited to a single calendar. However, it does not disclose behavior like idempotency, error states, or effects on existing notifications.

  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 short with two sentences plus endpoint/scopes. It is mostly concise, though the first sentence repeats the title. Key constraints are 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 moderate complexity (array of nested objects) and no output schema, the description lacks critical context: response format, error handling, required OAuth scope details (listed but not explained), and behavior for partial failures or large batches.

  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 50% (body field has a generic description, calendarId has none). The description does not explain calendarId or add meaning beyond the schema; it only implies the body array allows multiple notifications, which is already evident from the schema type.

  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 creates calendar notifications, either one or multiple, and is specific about the resource (calendar) and action (create). It distinguishes from sibling tools like delete, get, list, and update.

  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 by stating 'Create Calendar notifications, either one or multiple' and includes a constraint ('must be for single calendar only'). However, it does not explicitly guide when to use this over alternatives (e.g., update) or provide prerequisites.

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

• ghl_calendar_resource_deleteB
  3.4/5.0
  Behavior3/5

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

  Annotations already provide destructiveHint=true and idempotentHint=true, indicating a destructive, idempotent operation. The description adds context by mentioning OAuth scopes (calendars/resources.write) and confirming the action is a deletion. It does not contradict annotations but adds only modest behavioral context beyond what annotations convey.

  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 verbose, including multiple sentences about deprecated version warnings, endpoint paths, and OAuth scopes that could be condensed or eliminated. The key action is buried after version notes, and the structure is not front-loaded, reducing clarity for quick comprehension.

  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 delete operation, the description covers version, deprecation, and authorization requirements. However, it lacks any mention of the response format or side effects (e.g., success codes, error conditions). With no output schema and a relatively simple tool, the missing return value information leaves completeness slightly below 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 coverage is 100%, so the schema fully describes the two parameters (id and resourceType). The description adds no further meaning or examples beyond the schema for these parameters, justifying a baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'Delete Calendar Resource' and 'Delete calendar resource by ID (Services V1)'. The verb 'delete' and the resource 'calendar resource' are unambiguous, and the tool is clearly distinguished from sibling tools (e.g., create, get, list, update) by being 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description specifies the correct API version and warns against using a deprecated variant (v3), providing clear version guidance. However, it does not explicitly state when to use this tool versus alternatives like ghl_calendar_resource_update or ghl_calendar_resource_create, leaving usage context implied.

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

• ghl_calendar_service_listB
  3.4/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds endpoint and OAuth scopes, which offer operational context but no new behavioral information beyond annotations.

  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 concise, with only four lines. The first line repeats the title but overall there is no unnecessary content, making it efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with no output schema, the description provides endpoint and OAuth details. However, it lacks information about return structure or pagination, leaving some gaps for a complete understanding.

  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 all three parameters (locationId, isPrivate, serviceCategoryId) are already documented in the schema. The description adds no parameter details, meeting the baseline without enhancement.

  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 all services in a location', which specifies verb and resource scope. This distinguishes it from sibling tools like ghl_calendar_service_get (single service) and ghl_calendar_list (list calendars).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage 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_calendar_service_get for a single service. The description simply states what it does without decision support for the agent.

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

• ghl_calendar_service_location_updateB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds the endpoint URL and OAuth scopes, providing some behavioral context beyond annotations. However, it doesn't clarify update semantics (partial vs full replacement) 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise with no wasted words. It includes the endpoint and OAuth scopes, which are useful. However, it could be slightly more structured (e.g., using bullet points for technical details).

  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 update tool with nested body and no output schema, the description includes endpoint and OAuth scopes, which is helpful for authentication context. However, it lacks clarification on partial vs full update and constraints on fields like locationType, leaving some 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 100%, so the baseline is 3. The description itself does not add any additional meaning or examples beyond what is already 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 title 'Update Service Location' and description 'Update an existing service location' clearly state the action (update) and resource (service location). Among sibling tools like create, delete, get, and list, this tool is unmistakably the update variant.

  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 (e.g., create, delete), no prerequisites, and no conditions. It only states the operation, 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.

• ghl_calendar_updateB
  3.4/5.0
  Behavior3/5

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

  Annotations already provide idempotentHint, readOnlyHint, and destructiveHint, so the description's additional endpoint and OAuth scope details are helpful but not critical. No behavioral contradictions or new disclosures beyond 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?

  Three concise sentences: title, action, endpoint, OAuth scopes. No redundant information. Front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the complex schema with many nested objects, the description does not clarify update behavior (e.g., partial vs full replace), return type, or prerequisites. No output schema exists, but description omits any mention of response. Incomplete for a tool of this 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?

  Input schema has 100% coverage with descriptions for all properties, including examples and enums. The description only notes 'Request body (schema carried verbatim...)' which adds no semantic value. Baseline 3 is appropriate since 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 'Update Calendar' and 'Update calendar by ID', which is a specific verb+resource combination. It distinguishes from sibling tools like create, get, delete, and list by focusing on the update 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 on when to use this tool versus alternatives such as ghl_calendar_create or ghl_calendar_get. The description only provides the endpoint and OAuth scopes, without contextual usage advice or prerequisites.

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

• ghl_chat_widget_createB
  3.4/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. Description adds endpoint, API version, and OAuth scopes, but does not detail side effects, error behavior, or what occurs on success. Some value beyond annotations but still leaves gaps.

  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 concise (5 lines) and front-loaded with purpose. Includes relevant technical details (endpoint, version, scopes) without unnecessary text. Every sentence adds value, though it could be slightly more streamlined.

  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 complexity (nested objects, no output schema), the description does not explain the return value or error handling. It covers the basic intent and auth requirements but misses key completeness aspects for a creation 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?

  Schema coverage is 100%, so baseline is 3. The description does not elaborate on parameters; it only mentions the endpoint. The schema itself is very detailed with examples, so the description adds minimal 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 clearly states the verb and resource: 'Creates a new chat widget for the given sub-account.' It adds endpoint and OAuth scopes, and the title reinforces the purpose. Siblings include other chat widget tools (get, list, update, delete, patch), so creation is distinct.

  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 vs. alternatives like update or patch. No prerequisites, context, or exclusions provided. The OAuth scopes hint at authorization needs but not usage context.

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

• ghl_chat_widget_deleteB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint: true and readOnlyHint: false. The description adds that it is a 'soft-delete' and mentions promotion of another widget if it was default, which provides useful behavioral context beyond the annotations.

  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 brief but includes unnecessary technical details like endpoint, version header, and OAuth scopes, which clutter the description for an AI agent. Could be more concise without losing essential information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with two well-documented parameters, the description is fairly complete. It mentions key behavior (soft-delete, default widget promotion) and no output schema is needed for a delete. Minor gap: no mention of idempotency (though annotation says true).

  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?

  Both parameters have descriptions in the input schema (100% coverage). The description does not add any additional meaning beyond what the schema already provides. 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 'Delete Chat Widget' and explicitly says 'Soft-deletes a chat widget', which is a specific verb+resource. It also distinguishes from sibling tools like create, get, list, patch, update by focusing on deletion.

  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 vs alternatives. Does not specify prerequisites, when not to use, or compare with other chat widget tools like update or patch.

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

• ghl_conversation_ai_delete_actionB
  3.4/5.0
  Behavior4/5

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

  Description discloses that deletion is permanent and cannot be undone, and provides OAuth scope (conversation-ai.write) and endpoint details. This adds significant value beyond annotations which only indicate destructiveness.

  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?

  Concise and front-loaded with the action statement. Includes necessary technical details without verbosity, though endpoint info could be considered extra.

  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 delete tool with no output schema, the description covers purpose, irreversibility, required permissions, and resource identification. Lacks mention of prerequisites or response behavior.

  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?

  No parameter descriptions in the description text. Schema coverage is only 50% (actionId described), but the description adds no insight into agentId or any parameter semantics.

  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 'Permanently deletes an action' with a specific verb and resource. It distinguishes from sibling tools like ghl_conversation_ai_delete_agent by targeting 'action' specifically.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives like update_action or create_action. The warning about irreversibility provides caution but no comparative usage context.

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

• ghl_conversation_live_chat_agent_typingB
  3.4/5.0
  Behavior3/5

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

  Annotations provide some info (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds the endpoint and OAuth scopes, and clarifies it's a typing indicator (not a message). However, it does not disclose potential side effects (e.g., overwriting previous typing status), rate limits, or idempotency 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 concise, with the main purpose front-loaded. It includes relevant technical details (endpoint, OAuth scopes) without excessive fluff. Minor improvement could be a clearer separation of purpose and technical info.

  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 typing indicator tool, the description covers the basic purpose and parameters. However, it lacks information about return values (no output schema) and does not provide guidance on when to use this tool versus other conversation messaging tools among the many siblings.

  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 descriptions for all parameters. The description does not add any additional meaning or context beyond what the schema provides. Baseline 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 is for sending a typing indicator in live chat. It specifies 'Agent/Ai-Bot is typing a message indicator' and 'will call this when they are typing a message.' However, it does not explicitly differentiate from sibling tools like ghl_conversation_add_inbound_message or ghl_conversation_send_message, which are for actual 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 description implies usage when an agent or AI bot is typing in a live chat message. It does not provide explicit when-not-to-use scenarios, alternatives, or prerequisites. The context from sibling tools is not leveraged to guide selection.

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

• ghl_email_delete_campaignB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint: true and idempotentHint: true, so the destructive nature is clear. The description adds OAuth scopes, which is useful for authorization context, but does not elaborate on consequences or reversibility.

  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 very short (three sentences) and to the point. It includes the title, a single-sentence summary, and technical details. Could be more conversational, but efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with two required parameters and clear annotations, the description covers the basics. However, it lacks usage guidance and return value information (no output schema). Adequate but not thorough.

  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 100% of parameters with brief descriptions ('Campaign ID', 'Location ID'). The tool description adds no additional meaning beyond what the schema provides, warranting a baseline 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 clearly states 'Delete Campaign' and 'Delete a campaign', with the tool name reinforcing the action. It distinguishes itself from siblings like ghl_email_create_campaign or ghl_email_get_campaign, making 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 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, prerequisites, or conditions. The description is purely factual without context.

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

• ghl_estimate_createB
  3.4/5.0
  Behavior3/5

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

  The description adds endpoint details and OAuth scopes, but does not disclose any behavioral traits beyond what the annotations already provide 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Concise and front-loaded, but the title and description are slightly redundant; no wasted words overall.

  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 input schema is thorough, but the description does not hint at the return value (e.g., created estimate ID) nor provide context about estimates vs invoices.

  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 comprehensive descriptions and examples; the description does not add meaning beyond the schema, so baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The title and description clearly state 'Create New Estimate' with verb+resource, and the sibling tools confirm it's distinct from other estimate 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?

  No guidance on when to use this tool vs alternatives; no prerequisites or conditions are mentioned.

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

• ghl_estimate_listB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds the endpoint and authentication details but does not disclose additional behavioral traits like rate limits or response structure, relying heavily on annotations.

  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 relatively concise and front-loaded with the title and core verb. It includes endpoint, version, OAuth scopes, and pagination note, with minimal fluff.

  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 9 parameters and no output schema, the description covers pagination and auth but does not explain the return format or field details. While not requiring output schema, more context on result structure 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 covers 89% of parameter descriptions. The description only repeats limit and offset without adding new meaning, so it provides no additional semantic value beyond 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?

  The description clearly states the tool lists estimates and is a paginated GET endpoint. However, it does not differentiate from similar sibling tools like ghl_invoice_list or ghl_estimate_create, missing an opportunity to clarify when this list is appropriate.

  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 mentions pagination parameters and OAuth scopes, providing some usage guidance. However, it lacks explicit context on when to use this tool over alternatives, such as filter-based search or other list tools.

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

• ghl_funnel_fetch_redirects_listB
  3.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context about pagination behavior and required OAuth scopes, which is consistent and provides additional transparency without contradiction.

  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 concise at 5 sentences, front-loads the purpose, and structures information logically (purpose, endpoint, scopes, pagination). No redundant sentences.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Lacks output schema and does not describe return format. Covers pagination but omits details on locationId and search parameters. Annotations provide safety but leave gaps in usage context for a list 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?

  With 0% schema description coverage, the description does not explain the purpose of locationId, search, or the exact meaning of limit/offset beyond pagination. It adds little semantic value over the parameter names.

  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 states 'Fetch List of Redirects' and 'Retrieves a list of all URL redirects', clearly identifying the verb and resource. It distinguishes from sibling tools like ghl_funnel_create_redirect by focusing on reading a list. However, it does not explicitly contrast with other list 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 provides pagination usage guidance ('limit, offset — pass them to page through full result sets') and mentions OAuth scopes, but does not include explicit when-to-use or when-not-to-use instructions compared to alternatives. The guidance is present but minimal.

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

• ghl_invoice_template_updateB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate it's read-only false, not destructive, and idempotent. The description adds OAuth scopes and endpoint details but does not elaborate on behavior beyond mutation. No contradiction with annotations.

  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 brief (three lines) but includes a redundant first line that repeats the title. It is structured with a purpose statement, a detailed API line, and scopes, which is efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite high complexity (nested body, no output schema), the description provides minimal context beyond the endpoint and scopes. It does not explain response format, partial updates, or side effects, which would be helpful.

  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 schema fully documents parameters. The description adds no additional parameter-level meaning, only references the templateId implicitly via the endpoint.

  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 'Update template' and specifies that it updates an invoice template by ID via a PUT endpoint. This distinguishes it from sibling tools like create, delete, get, and list which have different actions.

  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 (e.g., when to update late fees configuration or payment methods). No prerequisites (e.g., template must exist) or conditions are mentioned.

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

• ghl_kb_crawler_delete_urlsB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds 'Delete trained pages' which aligns but does not provide additional behavioral context such as permanence, required permissions, or side effects. With annotations present, the description adds minimal 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 very concise: two lines stating the purpose and endpoint. Every sentence is informative and front-loaded. No unnecessary 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?

  No output schema is provided, and the description does not explain what the response looks like or error scenarios. For a destructive operation, more context about the outcome or confirmation behavior would be helpful.

  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 descriptions for all parameters. The tool description does not add any additional meaning beyond what is already in the schema, such as clarifying relationships between parameters or usage patterns.

  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 'Delete trained pages' as the action, which is a specific verb and resource. The endpoint information confirms the operation. This distinguishes it from sibling tools like ghl_kb_crawler_list_urls (list) and ghl_kb_crawler_train (train).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives such as ghl_kb_delete_knowledge_base for deleting the entire knowledge base. The description does not provide context 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.

• ghl_kb_faq_updateB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate mutability, idempotency, non-destructiveness. The description adds endpoint info but no behavioral context beyond annotations.

  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?

  Description is brief and front-loaded with purpose, but includes endpoint information that is unnecessary for an AI agent.

  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?

  No output schema and description does not explain return values or error handling. Adequate but not 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%, so the description does not need to explain parameters. Baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Update an existing knowledge base FAQ', specifying the verb and resource. It distinguishes from sibling tools like create and delete.

  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, no prerequisites or context provided.

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

• ghl_kb_get_knowledge_base_by_idB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds the endpoint and version header but does not disclose additional behaviors like response structure or error scenarios.

  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 with two sentences, no unnecessary information, and gets straight to the point. Every word adds value.

  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 read-only retrieval tool with one parameter and no output schema, the description conveys the core function. However, it lacks information about the return value or potential errors, which would aid an agent in using the result.

  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 0% description coverage, and the tool description does not elaborate on the knowledgeBaseId parameter beyond implying its purpose. The parameter name is self-explanatory, but no format or constraints are provided.

  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 knowledge base by ID') and resource, using a specific verb and resource identifier. It distinguishes from sibling tools like ghl_kb_list or ghl_kb_create_knowledge_base by focusing on retrieval by a unique ID.

  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 (e.g., ghl_kb_list for browsing). There is no mention of prerequisites or context for invocation.

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

• ghl_link_get_by_idB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and no destructiveness. The description adds endpoint version and OAuth scopes, but these are not critical behavioral traits. No contradictions.

  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?

  Description is concise at three lines. The first line is redundant with the title, but overall it is front-loaded and without waste. Minor improvement possible by removing the endpoint repetition.

  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 simple read operation, annotations, and schema coverage, the description is adequate. However, it does not specify return value or response structure (no output schema), which could be helpful for an AI 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?

  Input schema covers both parameters with descriptions (100% coverage). The description does not add further 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 states 'Get a single link by its ID', clearly indicating the verb (Get), resource (link), and the uniqueness constraint (by ID). This distinguishes it from sibling tools like ghl_link_list and ghl_link_search_trigger.

  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. The description does not mention when not to use it or compare with similar link tools.

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

• ghl_location_get_custom_valueB
  3.4/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, destructiveHint, and idempotentHint, so the description carries minimal burden. It adds the endpoint version header but no additional behavioral traits (e.g., permissions, pagination, or response shape). No contradiction with annotations.

  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?

  Extremely concise: one line for purpose and one for endpoint details. However, the endpoint version information could be considered noisy for an agent. Still, it is front-loaded and efficiently communicates the essential information.

  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 operation (get a custom value by ID) and the presence of annotations indicating safety, the description is adequate but lacks mention of what the response contains or any error conditions. No output schema exists, so the description could provide more 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 descriptions for 'id' and 'locationId'. The tool description repeats the endpoint template but adds no semantic value beyond the schema. Baseline 3 is appropriate as 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?

  Description states verb 'Get' and resource 'Custom Value', clearly indicating a read operation. The tool name mirrors this, and siblings like 'ghl_location_create_custom_value' and 'ghl_location_delete_custom_value' provide contrast, making 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 Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus similar tools like 'ghl_location_get_custom_values' (plural). The endpoint is provided but no context on prerequisites or typical use cases. It does not differentiate from siblings or indicate alternatives.

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

• ghl_location_get_tag_by_idB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds the endpoint and version, but does not discuss potential errors, rate limits, or authentication. With annotations covering safety, a 3 is appropriate.

  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 very concise (two lines) and front-loaded with purpose. Includes endpoint details which are somewhat technical but useful. Could be slightly more structured but efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-id tool with 2 params and no output schema, the description is minimally complete. It explains the action and endpoint, but lacks any mention of the response structure (e.g., returns a tag object). Adequate but could improve.

  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?

  Input schema has 100% coverage with descriptions 'Tag Id' and 'Location Id'. The description adds no additional meaning about parameter origin, format, or constraints. Baseline 3 is correct as 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 'Get tag by id', which is a specific verb+resource. The endpoint details confirm it's a GET operation. It distinguishes from siblings like ghl_location_get_tags (list all tags) and ghl_location_create_tag (create).

  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. For example, it doesn't mention that you need the tagId or that this is for retrieving a single tag versus listing all tags with ghl_location_get_tags.

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

• ghl_marketplace_delete_chargeB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true and idempotentHint=true. Description adds endpoint details and OAuth scope but does not elaborate on consequences of deletion (e.g., irreversible, impact on billing). Does not contradict annotations.

  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?

  Description is concise (three lines) with essential info (purpose, endpoint, scopes). No fluff, but endpoint details may be redundant for an AI agent.

  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?

  No output schema; description does not explain return value or behavior on success/failure. Lacks mention of preconditions (e.g., charge must exist). Adequate but not 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 has 100% coverage with description for chargeId. Description does not add extra meaning beyond the schema. Baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states 'Delete a wallet charge', a specific verb and resource. It distinguishes from sibling tools like ghl_marketplace_get_charges and ghl_marketplace_get_specific_charge by focusing on deletion.

  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 (e.g., ghl_marketplace_get_charges for listing). Missing prerequisites or context about required auth (charges.write scope mentioned but not explained).

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

• ghl_marketplace_get_specific_chargeB
  3.4/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating safe read-only behavior. The description adds no additional behavioral context beyond repeating the purpose. No mention of rate limits, caching, or other traits.

  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 short and front-loaded with the core purpose. The additional technical details (endpoint, OAuth scopes) are brief and not excessive, though they may be considered non-essential. Overall, it is concise.

  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 operation with one parameter and full schema coverage, the description is minimally adequate. However, it lacks any mention of return format, relationship to other marketplace billing tools, or prerequisites. Could be 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?

  Schema description coverage is 100%, and the parameter 'chargeId' is well-described in the schema as 'ID of the charge to retrieve'. The tool description does not add any extra meaning beyond the schema, thus baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Get specific wallet charge details'. The verb 'Get' and resource 'specific wallet charge details' are precise. It distinguishes itself from siblings like 'ghl_marketplace_get_charges' (lists multiple charges) and 'ghl_marketplace_charge' (likely creates a charge).

  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 details of a single charge, as opposed to listing charges. However, it does not explicitly state when to use this tool versus alternatives like 'ghl_marketplace_get_charges'. No direct comparisons or exclusions are provided.

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

• ghl_media_bulk_delete_filesB
  3.4/5.0
  Behavior3/5

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

  The description discloses the soft-delete/trash behavior, which aligns with the destructiveHint: false annotation. However, it does not add further behavioral context beyond what annotations already provide (e.g., idempotency, open-world hint). No contradiction detected.

  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 (two sentences plus endpoint info) with no fluff. It is front-loaded with the title and verb.

  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 lacks details about the response (no output schema) and does not clarify whether folders are handled differently from files. The endpoint info is extraneous for tool usage. More context would be beneficial.

  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, so each parameter is documented. The tool description does not add extra meaning beyond the schema, meeting 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 verb ('Bulk Delete/Trash') and the resource ('Files or Folders'). It distinguishes from siblings like ghl_media_delete_file (singular) and ghl_media_bulk_update_files (update) by specifying the bulk and soft-delete nature.

  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. The sibling ghl_media_delete_file exists for single file deletion, but no comparison or when-not-to-use information is provided.

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

• ghl_oauth_get_installed_locationB
  3.4/5.0
  Behavior4/5

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

  Annotations already indicate readOnly, idempotent, non-destructive. Description adds critical behavioral context: agency-level token requirement and pagination usage. No contradiction with annotations.

  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?

  Description has redundancy (repeats 'Get Location where app is installed' twice) and is not tightly structured. While not overly long, it could be more concise and better organized.

  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 10 parameters, no output schema, and annotations present, the description covers auth, legacy status, and pagination but lacks explanation of return structure. It partially meets needs but has 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 has 100% parameter description coverage, so baseline is 3. Description adds minor value by flagging pagination parameters (skip, limit) and OAuth scopes, but does not elaborate beyond what schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states it gets a location where an app is installed, but the singular name conflicts with the plural endpoint and pagination parameters, suggesting it actually lists multiple locations. This ambiguity reduces clarity. Sibling tool 'ghl_oauth_get_installed_locations' further muddies distinction.

  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?

  Explicitly states required token type (agency-level) and notes it is a legacy twin with a preference for v3 alternative. This provides clear guidance on when and why to use the tool, but does not cover all alternatives.

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

• ghl_opportunity_update_statusB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate non-read-only, non-destructive, idempotent. The description adds OAuth scope requirement (opportunities.write), which is useful. However, no details about side effects or response behavior are provided. Does not contradict annotations.

  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?

  Description is concise (three lines) with clear structure: title, endpoint, OAuth scopes. The version header and source info are arguably unnecessary but not harmful. No wasted words beyond that.

  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?

  Simple tool with full schema coverage. Lacks mention of return value or success indication. For a status update, it would be helpful to know what the response contains. Sibling tools are numerous but that doesn't demand more detail.

  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 baseline 3 applies. The description does not add parameter details beyond the schema; it only mentions the endpoint. No extra semantic enrichment for 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 updates the opportunity status, and the endpoint PATH /opportunities/{id}/status reinforces this. It distinguishes from sibling tools like ghl_opportunity_update and ghl_opportunity_create by focusing solely on status updates.

  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 does not mention that this tool is specifically for status changes, while ghl_opportunity_update exists for other field updates. The agent is left to infer this 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.

• ghl_payment_custom_provider_update_capabilitiesB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds OAuth scopes but no additional behavioral context (e.g., whether calling affects existing subscriptions, rate limits, or side effects). It partially relies on annotations.

  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 three short sentences with no unnecessary text. It includes helpful technical details (endpoint, OAuth scopes) but could be slightly more actionable. Overall efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one required parameter (body) and no output schema, the description provides the endpoint and OAuth scopes but does not explain the mutual exclusivity of companyId/locationId or the expected response. The schema covers the parameter details, but the description could be 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?

  Schema coverage is 100% with descriptions for all parameters, including the nested properties companyId, locationId, and supportsSubscriptionSchedules. 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 identifies the action ('Toggle capabilities'), the resource ('marketplace app capabilities'), and the scope ('tied to the OAuth client'). It effectively distinguishes this from sibling tools like ghl_payment_custom_provider_create or ghl_payment_custom_provider_get_config.

  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 guidance on when to use this tool versus alternatives like create or delete. It lacks prerequisites, conditions, or scenarios for use, leaving the agent without explicit decision support.

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

• ghl_payment_integration_provider_createB
  3.4/5.0
  Behavior4/5

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

  Beyond annotations, the description adds critical behavioral context: the endpoint requires a marketplace-app token and specifies the OAuth scope (payments/integration.write). It also indicates the underlying providers (Authorize.net, NMI). This is valuable information not present in annotations.

  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 relatively concise and front-loaded with the purpose. However, it includes redundant phrasing (e.g., 'Use this endpoint') and technical details (endpoint, version) that could be streamlined.

  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 covers purpose and authentication, but it does not describe the expected response format or possible errors. Since there is no output schema, the agent lacks information about what the tool returns after creation.

  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. The description does not add any additional parameter details beyond what the schema already provides, which meets the baseline expectation of 3.

  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 creates a white-label integration provider built on Authorize.net or NMI. It uses specific verbs and resources, but lacks explicit differentiation from sibling tools like ghl_payment_custom_provider_create or ghl_payment_integration_provider_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 does not provide guidance on when to use this tool versus alternatives. There is no mention of when not to use it or which sibling tools to consider for different scenarios.

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

• ghl_payment_integration_provider_listB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds endpoint details and pagination behavior but does not disclose additional traits beyond what annotations cover.

  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 somewhat verbose, repeating the title and including redundant phrases. It contains multiple sentences but could be more concise without losing 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?

  Given no output schema, the description should explain the response structure, but it only says 'retrieves a paginated list'. It omits details about item fields, sorting, or error handling, leaving gaps in completeness.

  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 100%, but the description claims filtering by 'name' which is not a parameter in the input schema. This is misleading. It correctly mentions pagination parameters but adds confusion.

  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 white-label integration providers, with specifics on pagination and filtering. It distinguishes from siblings by focusing on 'whitelabel' integration providers, which is a unique subset.

  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 explains customization via filtering and pagination, and mentions OAuth scopes, but does not contrast with alternative tools (e.g., create or other list tools) or specify 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.

• ghl_payment_order_create_fulfillmentB
  3.4/5.0
  Behavior3/5

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

  Annotations indicate non-readOnly, non-destructive, non-idempotent. Description adds OAuth scopes and endpoint details but does not disclose potential side effects, error behavior, or success response format. It is adequate but not thorough.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is concise, including only essential information: purpose, endpoint, and OAuth scopes. No redundant text, but could be slightly more 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?

  Given no output schema, the description lacks information about return values. It covers the core purpose and technical details but misses usage context and response handling.

  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 descriptions for all parameters. The description does not add additional meaning beyond what is in the schema, so it meets the 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 it 'Create order fulfillment' and explains it facilitates fulfilling an order. This is a specific verb+resource combination, and the sibling tools include other payment operations, making this tool distinct.

  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 listing or getting orders. It does not specify prerequisites or scenarios where this should be avoided.

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

• ghl_product_collection_createB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the OAuth scope and endpoint but no behavioral details about side effects, idempotency, or error handling. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the title and purpose. It includes essential endpoint and OAuth info. However, it is slightly minimal; could include a brief note about the body requirements.

  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 complexity (nested body schema) and no output schema, the description is somewhat complete. It provides the endpoint and OAuth scopes but lacks information about the response format or validation rules. Sufficient for a creation tool but could be improved.

  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 schema itself describes all parameters well. The description adds no additional semantic meaning beyond the schema. 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 (Create) and the resource (Product Collection) with a specific scope (for a specific location). It distinguishes itself from sibling product_collection tools (delete, get, list, update) by its create nature.

  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 compared to alternatives (e.g., product_collection_update). No prerequisites or conditions for use are mentioned.

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

• ghl_product_collection_getB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe and read-only. The description adds the endpoint and OAuth scopes but no additional behavioral context beyond what annotations provide.

  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?

  Description is concise with two sentences: one for purpose, one for technical details. It avoids fluff but could be slightly restructured for clarity. 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?

  With no output schema, the description could mention what the response contains (e.g., 'returns full collection object'). It is adequate for a simple read operation but lacks completeness regarding returned data.

  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 has 2 parameters with descriptions, examples, and 100% coverage. The description does not add further explanation, but the schema is sufficient. 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 'Get Details about individual product collection', specifying the verb 'Get' and the resource 'product collection'. It distinguishes from siblings like ghl_product_collection_create and ghl_product_collection_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?

  No usage guidelines provided beyond the endpoint and OAuth scopes. There is no guidance on when to use this tool versus alternatives, nor any context about prerequisites or limitations.

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

• ghl_product_collection_updateB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate idempotentHint=true and destructiveHint=false. Description adds OAuth scopes and method (PUT), but does not disclose side effects, error conditions, or behavior beyond what annotations provide. No contradiction.

  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?

  Description is concise with three lines, front-loaded with purpose. Includes technical details (endpoint, scopes) that are useful but not excessive. No wasted sentences.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Lacks usage guidance and return value information (no output schema). Annotations and schema cover safety and parameters, but the description does not fill gaps like error handling or dependencies. 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?

  Schema coverage is 100%, so the description need not repeat parameter details. It mentions collectionId in the description but adds no semantic value beyond the schema. 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 'Update a specific product collection with Id :collectionId', using a specific verb (Update) and resource (product collection). Sibling tools like create, delete, get, and list make the update intent distinct.

  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 (e.g., create vs update) or prerequisites. Only endpoint and OAuth scopes are provided, lacking 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.

• ghl_product_createB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate non-destructive and non-read-only behavior. The description adds OAuth scopes and endpoint details, which are useful but do not disclose other behavioral traits like side effects or reversibility. Context 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is relatively short but contains redundancy (title repeats in first sentence). It could be trimmed without losing information, but it is not 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?

  The description does not mention the response format or what the created product object contains, which is important for a creation tool. It also fails to explicitly list required parameters or provide usage tips for the nested schema, leaving gaps in 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 coverage is 100% with descriptions for all properties, so the description adds no extra parameter meaning beyond generic instructions. Baseline of 3 is appropriate as the schema already provides full parameter semantics.

  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 explicitly states 'adding a new product to the system', which clearly defines the verb and resource. It distinguishes from sibling tools that handle other product operations (update, delete, list, etc.) by focusing on creation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool versus alternatives, such as when to update instead of create. It only instructs to 'ensure required information is provided', which is generic and not helpful for decision-making.

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

• ghl_product_price_listB
  3.4/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by disclosing OAuth scopes (products/prices.readonly), pagination behavior via limit/offset, and filter capability via the 'ids' parameter. This goes beyond structured fields.

  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 concise with four sentences covering purpose, endpoint, scopes, and pagination. Information is front-loaded and efficient, though the technical details (endpoint, headers) could be more integrated.

  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, 2 required, and no output schema. The description covers purpose, endpoint, auth scopes, and pagination, but does not describe the return format or data structure, which is a gap given the lack of 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?

  With 100% schema coverage, the baseline is 3. The description mentions 'filtering prices' (referring to ids) and pagination, but does not add meaningful detail beyond what the schema already provides (e.g., `example` and `description` fields).

  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 'List Prices for a Product' and explains the tool retrieves a paginated list of prices for a specific product. The verb 'List' and resource 'prices' are specific and unambiguous, though it does not explicitly differentiate from sibling tools like ghl_product_price_get.

  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 (e.g., ghl_product_price_get for a single price). The description focuses on technical details like endpoint and OAuth scopes but omits contextual usage advice.

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

• ghl_saas_enable_location_deprecatedB
  3.4/5.0
  Behavior3/5

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

  The description adds token requirement and plan restriction beyond annotations, which are minimal. However, it does not detail side effects or what enabling SaaS entails beyond the schema, leaving some 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.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is verbose and repetitive, containing HTML-like formatting and duplicate deprecation notices. It could be streamlined to front-load key information.

  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?

  Provides necessary context for a deprecated tool, including replacement endpoint and authorization requirements. Lacks information on whether the tool still functions or if calls will fail.

  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 description adds no extra value for parameters. The schema already documents parameter purposes and constraints effectively.

  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 enables SaaS for a sub-account (location) and is deprecated, superseded by another endpoint. The purpose is specific and distinguishable from sibling tools like ghl_saas_enable_location.

  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?

  Explicitly states it requires an agency-level token, is only available on the Agency Pro plan, and is deprecated in favor of a replacement. Provides clear context for when it might be used and when to avoid it.

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

• ghl_saas_update_location_wallet_balanceB
  3.4/5.0
  Behavior3/5

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

  The description adds context beyond annotations: it clarifies the mutation operation ('adds/adjusts'), partial update support, and security requirement. However, it does not disclose side effects (e.g., impact on billing), rate limits, or behavior when updateMask is omitted. Annotations already indicate non-read-only and non-destructive, so the description adds moderate value.

  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 concise (few sentences) and front-loads critical information (security requirement, purpose). It avoids verbose details and is well-structured for quick comprehension.

  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 no output schema, so the description should explain the return value; it does not. It includes endpoint, OAuth scopes, and security requirement, but omits expected response, error conditions, and behavior for full vs partial updates. Overall adequate but with notable gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema documents all parameters. The description mentions the updateMask field (not present in schema) which adds some semantic guidance but may cause confusion as it's not a parameter. The description does not elaborate on parameter meaning beyond what the schema 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 adds/adjusts complimentary wallet credits for a specific location, with a specific verb ('adds/adjusts') and resource (location wallet balance). It distinguishes from the getter sibling tool implicitly, but 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description includes a critical usage prerequisite (agency-level token) and mentions partial updates via updateMask. It does not explicitly state when to use this tool versus alternatives (like create vs update), but the context of siblings provides some guidance.

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

• ghl_snapshot_get_latest_pushB
  3.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds beyond that by specifying the required agency-level token, the HTTP method (GET), and the exact endpoint path, which enhances behavioral 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 concise with four short lines. It front-loads the important security note and then states the purpose. Minor redundancy ('Get Last Snapshot Push' appears twice) but overall efficient.

  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 output schema, the description should describe the return value (status). It only says 'get status' without details. Parameters are also unexplained. The tool's safety profile is covered by annotations, but context on behavior and results is lacking.

  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 does not explain any parameter. Although snapshotId and locationId appear in the endpoint string, companyId is not mentioned, and none are defined meaningfully. This fails to add 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?

  The description clearly states it retrieves the latest snapshot push status for a location, using the verb 'Get' and specifying the resource. It distinguishes from sibling tools like ghl_snapshot_create_share_link and ghl_snapshot_list by focusing on the latest push.

  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 obtaining the latest push status but lacks explicit guidance on when to use this tool versus alternatives like ghl_snapshot_get_pushes_between_dates. The token requirement is a prerequisite, not a usage guideline.

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

• ghl_social_category_getB
  3.4/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, indicating a safe read operation. The description adds only the endpoint URL but does not disclose additional behavioral traits like error handling, permission requirements, or response structure beyond what annotations imply.

  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?

  Description is concise with two semantically meaningful lines and an endpoint reference. No redundant text, but could be slightly more structured. Minor improvement possible.

  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 two required parameters and no output schema, the description is minimally adequate. However, it lacks details on return values, error conditions, or any constraints, which would help for 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% with adequate parameter descriptions ('Category Id', 'Location Id'). The description adds no new meaning beyond the schema, so 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?

  Description clearly states 'Get categories by id' and 'Retrieve a specific category by its ID', which directly indicates the tool retrieves a single category by its ID. This distinguishes it from sibling tools like ghl_social_category_list that list categories.

  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?

  Description provides the API endpoint but offers no explicit guidance on when to use this tool versus alternatives for listing or fetching categories. Usage is implied through the name and endpoint, but no comparisons or when-not-to-use advice is given.

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

• ghl_social_csv_finalizeB
  3.4/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false, aligning with mutation (scheduling). Description discloses scheduling behavior but lacks details on idempotency, failure modes, or effects of repeated calls. No contradiction with annotations.

  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 relatively concise but includes redundant repetition of the operation title and raw endpoint details that may be noise for an AI agent. The key action is stated upfront.

  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 is provided, and the description does not indicate return value (e.g., success status, scheduled post details). Given it is a finalization action, the agent is left unaware of what the response contains.

  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 schema describes all parameters. The description adds endpoint details but no additional semantic meaning for parameters like relationship between id and locationId. 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 states the tool 'Finalizes a previously uploaded CSV import and schedules all its posts for publishing'. The name and action are distinct from siblings like ghl_social_csv_upload (upload) and ghl_social_csv_list (list).

  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 after a CSV upload but does not explicitly state when to use vs alternatives or provide exclusion criteria. No guidance on prerequisites or error handling.

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

• ghl_social_delete_csv_postB
  3.4/5.0
  Behavior3/5

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

  Annotations (destructiveHint=true) already declare destructiveness; description adds context (CSV import) but no additional behavioral detail. Adequate but not enriched.

  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?

  Short and front-loaded with title, but includes endpoint details that are redundant; could be slightly more concise.

  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?

  Simple delete operation; description covers basic purpose but lacks info on permanence or side effects, which is acceptable given 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?

  Schema coverage is 100% with basic descriptions; description adds no further meaning beyond what schema provides, resulting in baseline 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?

  Description clearly states the action (delete) and resource (a specific post from a CSV import) with endpoint, distinguishing it from sibling delete tools like ghl_social_delete_post.

  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_social_delete_post; no prerequisites or exclusions mentioned.

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

• ghl_social_fetch_queuesB
  3.4/5.0
  Behavior1/5

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

  The description indicates a read-only operation ('Retrieves') and includes OAuth scope 'socialplanner/category.readonly', but the annotations set readOnlyHint=false, creating a contradiction. The description does not disclose any side effects or additional behavioral traits beyond the annotations, which are themselves inconsistent.

  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 concise, covering the core purpose in the first sentence and adding technical details (endpoint, OAuth scopes) in subsequent lines. It is front-loaded and free of superfluous information, though the technical details could be seen as extraneous.

  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?

  No output schema is provided, so the description must convey return value information. It states 'paginated list of all category queues' but lacks detail on the structure or fields of a queue, leaving some ambiguity for an agent. Adequate for a basic list operation but incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for all parameters. The description adds context beyond the schema by stating that the result is a 'paginated list' and excludes deleted items, which enriches parameter understanding (e.g., skip/limit for pagination).

  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: 'Fetch category queues for a location' and elaborates with 'Retrieves a paginated list of all category queues for a given location, excluding any that have been marked as deleted.' It uses specific verbs and identifies the resource and scope, distinguishing it from siblings like ghl_social_fetch_queue_by_id.

  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 does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance or prerequisites. Usage is implied by the verb 'Retrieves', but without explicit comparisons or exclusions, it scores 3.

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

• ghl_social_get_accountB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare the tool as read-only, non-destructive, and idempotent. The description adds the endpoint URL and OAuth scopes, which are useful but not essential behavioral details. It does not elaborate on side effects or response nuances.

  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 concise at three lines. However, the first line 'Get Accounts' is redundant with the title, slightly reducing efficiency. Overall, 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.

  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 (1 param, no output schema) and supportive annotations, the description is adequate but could be improved by mentioning the response structure (e.g., list/array) or any pagination 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 coverage is 100% with one parameter (locationId). The description reinforces its usage in the endpoint URL but adds no new semantic information beyond the schema's minimal 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 clearly states the tool retrieves a list of accounts and groups, which distinguishes it from sibling tools that focus on specific platforms (e.g., Facebook, Instagram). The verb 'Get' and resource 'accounts and groups' 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 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_social_get_oauth_accounts or ghl_social_get_facebook_page_group. No context on prerequisites or use cases is given.

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

• ghl_social_get_comment_listB
  3.4/5.0
  Behavior1/5

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

  The description implies a read operation ('List comments'), but the annotation readOnlyHint is false, indicating it is not read-only. This is a contradiction. The description does not disclose any write or side effects, nor does it address authentication, rate limits, or other behavioral traits beyond what the annotations provide.

  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 sentences and an endpoint note. It is front-loaded with the primary purpose, with no wasted words 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?

  Without an output schema, the description fails to explain the response format, pagination metadata, or any behavioral details like permissions or rate limits. This leaves significant gaps for an AI agent to understand the tool's complete 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 coverage is 100%, so the description adds marginal value. It summarizes the roles of parameters like parentId, skip/limit, sortBy, originIds, and search, which helps but does not significantly extend the schema's own detailed 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 tool lists comments for a post or thread, using a specific verb and resource. It distinguishes between scoping to a post or a comment thread via parentId, which differentiates it from sibling tools like ghl_social_get_post or ghl_social_create_comment.

  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 on when to use the tool (for listing comments scoped to a post or thread) and describes pagination, sorting, and filtering parameters. However, it does not explicitly state when not to use it or mention alternatives like ghl_social_create_comment for adding comments.

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

• ghl_social_save_edit_sessionB
  3.4/5.0
  Behavior3/5

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

  The description adds behavioral context beyond annotations: it specifies that changes are applied to the live queue and the session is closed. However, it does not detail irreversibility, side effects, or the state of the queue after the operation. Annotations already indicate mutation (readOnlyHint=false) but not destructiveness.

  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 relatively concise with four lines covering purpose, behavior, endpoint, and OAuth scopes. Some technical details (endpoint, OAuth) are not essential for an agent, but no fluff is present.

  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 lacks important context for a commit-like operation: it does not mention that an active edit session is required, how the queue state changes, or error conditions. Given no output schema, more explanatory detail would be helpful.

  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 provides no additional information about parameters; it does not explain queueId, sessionId, locationId, or keepInDraft. The schema already covers some properties (e.g., keepInDraft), but with 50% schema coverage, the description should compensate, which it does not.

  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 'Save edit session changes' and explains that it applies staged changes and closes the edit session. This distinguishes it from sibling tools like start_edit_session, discard_edit_session, and fetch_edit_session_calendar.

  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 is used to finalize an edit session by applying changes and closing it, but it does not explicitly state when to use it versus alternatives, nor does it mention prerequisites like having an active edit session.

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

• ghl_social_set_accountsB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation behavior is expected. The description adds endpoint and OAuth scopes but no additional behavioral traits like side effects, authorization requirements beyond scopes, or idempotency. With annotations covering the basics, a score of 3 is appropriate.

  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?

  Description is short and to the point, but the first line 'Set Accounts' is redundant with the tool name. The remaining content is efficient. One unnecessary line prevents a 5.

  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 mentions CSV import context, which is helpful. However, there is no output schema, and no explanation of how this tool fits in a larger workflow (e.g., after CSV upload, before posting). Siblings include related CSV import tools, but the description does not connect them.

  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 all parameters are documented in the input schema. The description does not add any parameter meaning beyond what is in the schema. Baseline 3 is correct.

  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 'Set social media accounts for a CSV import to publish posts to', which is a specific verb+resource combination. This distinguishes it from other social tools like ghl_social_post_create or ghl_social_get_account.

  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 implies a CSV import workflow but does not explain prerequisites, order of operations, or when to call this tool instead of other social account management tools.

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

• ghl_social_start_edit_sessionB
  3.4/5.0
  Behavior4/5

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

  The description adds value beyond annotations by explaining that changes are staged until saved or discarded, and it specifies the endpoint and OAuth scopes. This provides behavioral context that complements the annotations, though it doesn't mention potential side effects like locking.

  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 concise, front-loading the main purpose, and includes additional context like endpoint and scopes without unnecessary fluff.

  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 complexity (nested parameters, no output schema), the description could be more complete by explaining the body structure and what the session enables. It adequately covers the basic flow but lacks detail on return values or post-session steps.

  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 the parameters (queueId, body) beyond the schema. With 50% schema coverage, the description should clarify the parameter meanings, but it adds no semantic value.

  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: starting or resuming an edit session for queue items, with a draft copy created. This distinguishes it from sibling tools like ghl_social_discard_edit_session and ghl_social_save_edit_session.

  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 mentions 'Start or resume an edit session' but does not explicitly provide guidance on when to use it versus alternatives, such as prerequisites or when not to use it. The OAuth scopes are listed but no usage context beyond that.

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

• ghl_social_update_queue_itemB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false (mutation), destructiveHint=false, and idempotentHint=true. The description adds endpoint details and OAuth scopes but does not discuss partial vs full updates, idempotency, or what happens upon success. It adds minimal value beyond annotations.

  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 concise with three sentences plus endpoint and OAuth scopes. There is no fluff, though the first sentence is redundant with the title. Structure is clear and scannable.

  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 complexity (nested objects, many parameters, no output schema), the description lacks completeness. It does not cover the response format, error handling, or confirm whether the update is partial or full. Missing guidance on required prerequisites or consequences.

  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 (33%), and the description does not compensate. It mentions 'content or variations' but does not explain the body parameters meaningfully. The 'body' field description is a tautology. Parameter documentation largely relies on the schema 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 clearly states the action ('Updates'), the resource ('an item in a queue'), and the scope ('content or variations of a specific item within a category queue'). It distinguishes this tool from siblings that create, delete, fetch, or clone queue items.

  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 the endpoint and OAuth scopes but does not explicitly state when to use this tool versus alternatives like create, clone, reset, or start edit session. It implies modification of existing items but lacks guidance on prerequisites or when not to use.

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

• ghl_store_upsert_settingsB
  3.4/5.0
  Behavior3/5

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

  The description confirms create/update behavior but does not elaborate on side effects, partial updates, or concurrency. Annotations already indicate non-idempotent and non-destructive; description adds minimal extra context beyond the endpoint info.

  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 adequate but includes redundant phrases and technical endpoint details that could be streamlined. It front-loads the core purpose but could be more 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 nested schema and no output schema, the description should indicate what the tool returns (e.g., the created/updated settings). It lacks this information, leaving the agent without expected response structure.

  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 baseline is 3. The description only reiterates 'by altId and altType' without adding meaning beyond the schema's parameter 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 tool creates or updates store settings, and specifies the identifying parameters altId and altType. It distinguishes from siblings like ghl_store_get_settings by its upsert behavior.

  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 when to use (to create or update settings by altId and altType) but provides no explicit guidance on when not to use it or alternatives like ghl_store_get_settings for read-only needs.

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

• ghl_user_filter_by_emailB
  3.4/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false, yet the operation appears to be a search (read). The description does not clarify this inconsistency or mention any side effects. It does disclose security requirements and OAuth scopes, but lacks details on rate limits 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is relatively concise, prioritizing important security info at the start. It includes endpoint details and scopes. Could be slightly more streamlined, but overall 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 description provides endpoint, version, and security context. However, it lacks guidance on pagination and return format (no output schema). The schema covers skip/limit, but the description does not help the agent understand how to iterate results.

  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 described in the schema (100% coverage). The description reiterates key fields like companyId, deleted, and emails but adds no new meaning beyond the schema descriptions.

  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 filters users by email, including company ID and deleted status. It distinguishes itself from sibling user tools by noting the agency-level token requirement, but does not explicitly contrast with other user search 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 mentions that an agency-level token is required and that this differs from other /users/* ops, providing a usage constraint. However, it does not explicitly state when to use this tool over alternatives like ghl_user_search, leaving the agent to infer the use case.

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

• ghl_user_get_by_locationB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds deprecation status and OAuth scopes, but does not expand on behavioral traits like rate limits 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.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is repetitive with multiple deprecation warnings ('DEPRECATED per spec', 'DEPRECATED per official docs', 'Deprecated.') and includes extraneous details like endpoint, version header, and source. It could be reduced to a single sentence.

  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 deprecated tool, it sufficiently explains what to use instead and basic parameters. However, it lacks output schema details and does not handle the sole parameter thoroughly.

  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 only mentions locationId without explaining its semantics (e.g., format, source). It also references other parameters for the replacement endpoint, which is unnecessary for this tool.

  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 states the tool is deprecated and superseded by another endpoint, but still clearly indicates its purpose: 'Get User by Location.' It distinguishes from siblings by pointing to the replacement. However, the deprecation message is verbose and slightly cluttered.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly advises against using this tool: 'Deprecated. Use GET /users/search instead.' Also mentions parameters for the replacement, providing clear alternative guidance.

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

• ghl_ad_fb_ad_deleteA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds OAuth scope 'adPublishing.write' and endpoint details, but does not disclose side effects, undoability, or other behavioral nuances beyond 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 extremely concise: one line for purpose, then endpoint and scope. No superfluous words, front-loaded with the action.

  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 delete tool with good annotations and schema, the description covers basic context (endpoint, version, OAuth). However, it omits response format or return value details, which is a minor gap without 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?

  Schema coverage is 100%, so baseline is 3. The description does not add parameter-level details beyond what the schema already provides (adId and body).

  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 'Delete a Facebook ad by ID' with a specific verb and resource, and the name distinguishes it from sibling tools for duplicate, pause, etc. It provides clear intent.

  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 pause or duplicate. No prerequisites or contextual usage advice is given.

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

• ghl_ad_fb_audience_member_addA
  3.5/5.0
  Behavior3/5

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

  Annotations indicate a write operation (readOnlyHint=false) with idempotentHint=true. Description adds endpoint, HTTP method, scopes, but doesn't elaborate on side effects or return values. No contradiction with annotations.

  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?

  Concise: includes purpose, endpoint, scopes in a few lines. Could front-load essential info more, but overall 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?

  Tool has low complexity, schema fully describes parameters, and no output schema needed. Description is sufficient for typical usage.

  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?

  Input schema covers all parameters with descriptions and examples. Description does not add extra meaning beyond the schema, so 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 states the verb 'Add' and the resource 'custom audience member' with a specific target 'Facebook custom audience'. It effectively distinguishes from sibling tools like remove and batch update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives such as batch update or remove. Prerequisites like audience existence or OAuth setup are not mentioned.

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

• ghl_ad_fb_audience_updateA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, indicating safe, repeatable updates. The description adds the endpoint path, version, and OAuth scopes (adPublishing.write) but does not clarify partial vs. full replacement or error behavior. No contradiction with annotations.

  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 short (three lines) and front-loaded with the core purpose. However, the first sentence ('Update custom audience') is redundant with the tool's name, slightly reducing conciseness. Overall, every line serves a purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, and the description does not hint at the response format (e.g., updated audience object). For a state-changing operation, this missing information reduces completeness, though annotations partially compensate with idempotentHint.

  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?

  Input schema coverage is 100% with descriptions for all parameters (audienceId, body with locationId, name, description). The description only restates that name and description can be updated, adding no new semantic 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 clearly states the verb 'Update' and the resource 'custom audience', and specifies which fields can be updated ('name or description'). It distinguishes this tool from sibling tools like audience_get, audience_delete, and audience_member_ operations, as it is the only update-specific audience tool.

  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 explains what the tool does but does not provide explicit guidance on when to use it versus alternatives (e.g., member add/remove tools). Usage is implied by the resource name, but no exclusions or comparisons are given, leaving the agent to infer context.

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

• ghl_ad_fb_campaign_publishA
  3.5/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, which the description supports by stating 'push it live'. The description adds the endpoint and OAuth scopes, but does not explain side effects (e.g., whether the operation is irreversible) or rate limits. It adds some context beyond annotations but not extensively.

  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 relatively concise (5 lines) and includes key operational details (endpoint, OAuth scopes). However, the first line 'Publish campaign' is redundant with the title, slight optimization possible.

  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 tool with 2 parameters and no output schema, the description provides the endpoint and OAuth scopes, which are essential for invocation. It also states the effect ('push it live'). Missing details like response format or error handling, but adequate for basic use.

  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 descriptions and examples for both parameters. The description does not add any additional meaning beyond what the schema already provides, so 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 explicitly states 'Publish a Facebook campaign and push it live to Facebook', which clearly identifies the action (publish) and the resource (Facebook campaign). This distinguishes it from sibling tools like pause, resume, or delete.

  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 versus alternatives. It lacks conditions, prerequisites, or comparisons to sibling tools such as ghl_ad_fb_campaign_pause or ghl_ad_fb_campaign_upsert.

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

• ghl_ad_fb_campaign_resumeA
  3.5/5.0
  Behavior3/5

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

  Annotations indicate not readOnly (write operation), not destructive, not idempotent. Description adds OAuth scopes and endpoint details but does not disclose behavior on already-active campaigns or potential 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is fairly concise but includes redundant first line 'Resume campaign' matching title. Technical details useful but could be more streamlined.

  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 and description does not explain return values, success/error conditions, or asynchronous behavior. Incomplete for a realistic agent 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?

  Schema coverage is 100%, so baseline 3. Description adds no additional meaning to parameters beyond what 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?

  Description clearly states 'Resume a paused Facebook campaign', which is a specific verb+resource. It distinguishes from sibling ghl_ad_fb_campaign_pause.

  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 guidance on when to use vs alternatives. The context implies use when a campaign is paused, but lacks explicit when-not or sibling differentiation.

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

• ghl_ad_fb_targeting_searchA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that it's a GET request with OAuth scope adPublishing.readonly, but this does not significantly enhance transparency beyond what annotations provide. No contradiction with annotations.

  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 brief and front-loaded with the core purpose. The inclusion of endpoint and OAuth scopes adds technical detail, but these could be considered redundant given the schema and annotations. Overall, it is well-structured and 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 annotations and high schema coverage, the description is adequate for a read-only search tool. It does not describe return values, but this is acceptable without an 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?

  Schema coverage is 100%, so the description adds minimal value. It mentions 'Facebook geo-locations and interests' which hints at the type parameter but does not elaborate on specific parameter behaviors or formats.

  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 searches Facebook geo-locations and interests for ad targeting. This distinguishes it from sibling tools like ghl_ad_google_targeting_search and ghl_ad_li_targeting_search, which target different platforms.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit usage guidance is provided. The description does not specify when to use this tool versus alternatives, nor does it mention prerequisites or context for its invocation.

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

• ghl_ad_google_audience_upsertA
  3.5/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds OAuth scopes (adPublishing.write) and endpoint details. It does not contradict annotations but adds limited behavioral context beyond what annotations already convey.

  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 concise (4 lines) and front-loads the purpose. Including endpoint and OAuth scopes adds useful context without excessive verbosity. A slight deduction for including technical details that might be better placed elsewhere.

  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 complexity (nested objects, no output schema), the description lacks important context. It does not explain how the upsert works (e.g., create vs update logic based on resourceName), response structure, or error handling. The schema partially compensates, but the description should provide more operational 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?

  Input schema has 100% description coverage, providing rich detail for each parameter. The tool description adds no additional meaning beyond the schema, so 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 upserts a Google Ads combined audience. 'Upsert audience' and 'Create or update a Google Ads combined audience' specify the verb and resource. The tool name and siblings (get, list) differentiate it from other audience operations.

  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 does not explicitly state when to use this tool versus alternatives (e.g., separate create/update, or other platform audience tools). The name and basic description imply use for audience creation/update, but no exclusion criteria or alternative guidance is provided.

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

• ghl_ad_google_conversion_deleteA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint: true and readOnlyHint: false. The description adds the endpoint and OAuth scopes but does not elaborate on additional behavioral traits like irreversibility, required permissions beyond scopes, or rate limits. It does not contradict annotations.

  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 brief and includes essential information (action, resource, endpoint, scopes). It could be slightly more structured but is efficient with no unnecessary 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 delete operation without an output schema, the description is reasonably complete: it specifies the action, resource, identifier, and endpoint. Annotations cover the destructive nature. It could mention that it is irreversible, but that is implied by destructiveHint: true.

  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 input schema fully documents the three parameters (isDraft, locationId, conversionId). The description does not add any semantic details beyond the schema, 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.

  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 ('a Google Ads conversion action by ID'). It distinguishes itself from sibling delete tools (e.g., ghl_ad_google_account_delete, ghl_ad_google_segment_delete) by specifying the exact resource type.

  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_ad_google_conversion_upsert or other delete tools. It does not mention prerequisites, when not to use, or contextual triggers.

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

• ghl_ad_google_integration_getA
  3.5/5.0
  Behavior3/5

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

  Annotations already convey read-only, idempotent, and non-destructive traits. The description adds the OAuth scope and endpoint details, which provide some additional context but do not significantly expand on behavioral traits beyond what annotations provide.

  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 concise with a clear hierarchy: title, purpose statement, and technical details. It is well-structured and avoids unnecessary repetition, though the technical details could be slightly trimmed.

  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, strong annotations, and full schema coverage, the description adequately explains what the tool does. However, it does not describe the output format (no output schema), but this is not a major gap for a straightforward retrieval 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 input schema has 100% coverage with clear descriptions for both parameters ('Is draft' and 'Location identifier'). The description does not add any further meaning beyond the schema, so 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 verb 'Get' and 'Retrieve' and specifies the resource 'Google Ads integration details for a location'. It distinguishes the tool from sibling tools like create and delete by indicating its read-only nature.

  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 versus alternatives. It lacks explicit context for when to retrieve integration details versus other Google Ads tools like account or campaign retrieval.

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

• ghl_ad_google_segment_upsertA
  3.5/5.0
  Behavior4/5

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

  Annotations already indicate idempotent and non-destructive write behavior. The description adds value by specifying the exact endpoint and required OAuth scopes (adPublishing.write), which are not in annotations. This helps the agent understand authorization needs and the API contract.

  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 concise (3 lines) and front-loaded with the purpose. However, it could be more structured (e.g., separate sections for purpose, endpoint, auth) to improve readability.

  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 complex tool with nested input schema (rule-based lists, members) and no output schema, the description is too minimal. It does not explain the overall segment structure or what the response contains, relying entirely on the 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?

  Schema description coverage is 100%, so the input schema already documents all parameters fully. The description adds no extra meaning beyond noting the body is from the OpenAPI spec; it does not explain complex nested structures like rule-based user lists or member types.

  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 'Create or update a Google Ads audience segment' with a clear verb (upsert) and specific resource (Google Ads audience segment). It distinguishes from sibling tools like list, delete, get, and offline_job_create by focusing on the upsert 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 on when to use this tool versus alternatives such as ghl_ad_google_audience_upsert or other segment operations. The description does not mention when not to use it or provide context for switching between create and update behavior.

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

• ghl_ad_li_account_deleteA
  3.5/5.0
  Behavior3/5

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

  Annotations provide destructiveHint=true, readOnlyHint=false, and idempotentHint=true, which are consistent with description. The description adds technical details (endpoint, OAuth scopes) but does not disclose deeper behavioral traits like whether the deletion is reversible, what side effects occur, or response behavior. No contradiction with annotations.

  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 relatively concise but includes some redundant phrasing ('Delete ad account' appears in both title and description). It includes endpoint and OAuth info, which adds value but could be more tightly 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 is simple with two required parameters and no output schema. The description provides enough context for basic understanding but lacks information about the return value (e.g., success confirmation). It does not explain what happens after deletion or if any cleanup occurs.

  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 descriptions for both parameters (locationId, adAccountId). The tool description does not add any additional parameter meaning beyond what the schema provides, so 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 action ('Delete ad account' / 'Remove a LinkedIn ad account connection from a location') and the resource (LinkedIn ad account connection). It distinguishes from sibling tools that operate on different platforms (e.g., ghl_ad_fb_account_delete, ghl_ad_google_account_delete) and from read/list tools (ghl_ad_li_account_get, ghl_ad_li_account_list).

  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 removing a LinkedIn ad account connection from a location, but does not explicitly state when to use this tool versus alternatives (e.g., other platform delete tools) or provide prerequisites, exclusions, 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.

• ghl_ad_li_campaign_group_getA
  3.5/5.0
  Behavior3/5

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

  Description and annotations are consistent: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds little beyond the annotations (e.g., endpoint details) but does not contradict them.

  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?

  Description is short and to the point, but the endpoint line is technical detail that might be better placed elsewhere. Still, it remains concise without unnecessary verbiage.

  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 retrieval tool with good annotations, the description covers the basic purpose and includes endpoint/scopes. No output schema means return format is not described, but the tool's simplicity mitigates this. Could mention error cases or required permissions beyond OAuth scopes.

  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?

  Input schema has 100% coverage with descriptions for all 3 parameters. The description adds no additional meaning about parameters, so 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?

  Title and description clearly state the tool retrieves a LinkedIn ad campaign group by ID. However, it does not distinguish from sibling tools like ghl_ad_li_campaign_group_upsert or ghl_ad_li_campaign_group_publish, missing an opportunity to clarify when to use this read-only 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 when you have an ad ID and want details, but offers no explicit guidance on when to use this tool versus alternatives like listing or reporting tools. No when-not statements or error scenarios are provided.

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

• ghl_ad_li_targeting_searchA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds value by noting OAuth scopes (adPublishing.readonly), endpoint details, and version header. This provides useful behavioral context beyond annotations.

  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 concise with three distinct parts: brief title, specific purpose sentence, and technical details (endpoint, version, scopes). No redundant information, though the first line ('Search targeting options') partly repeats the annotation title.

  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 is provided, and the description does not explain what the search returns (e.g., list of matching targeting options, pagination hints). For a search tool, this omission leaves the agent uncertain about the response structure, warranting a lower score.

  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 input schema already documents all four parameters with descriptions and examples. The description does not add additional meaning per parameter beyond listing example facets (e.g., locations, industries). Meets 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 tool searches LinkedIn targeting facets like locations, industries, and job titles. The verb 'search' and resource 'LinkedIn targeting options' are specific, and the mention of LinkedIn distinguishes it from sibling tools (e.g., ghl_ad_fb_targeting_search, ghl_ad_google_targeting_search).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives like Facebook or Google targeting search. The description does not mention when not to use it or provide context for selection. It merely states what it does.

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

• ghl_affiliate_commission_listA
  3.5/5.0
  Behavior4/5

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

  Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds value by mentioning pagination ('Pagination params: skip, limit'), which is beyond what annotations provide. No contradictions with annotations.

  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 mostly concise, with a clear title and purpose sentence. The endpoint details and pagination note are relevant, though the version header and source info may be extraneous for AI agents. No unnecessary repetition.

  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 9 parameters and no output schema, the description covers basic purpose and pagination but lacks details on filter semantics and return structure. While functional for a simple list tool, it does not fully equip the agent for nuanced usage.

  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 67%, but the description only addresses 'skip' and 'limit' as pagination parameters. It does not explain the meaning or usage of other parameters like 'query', 'status', 'toDate', 'fromDate', or 'campaignId', leaving the agent with incomplete context.

  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 ('Retrieve the list of commissions') and the resource ('for a location'), which distinguishes it from sibling tools like 'ghl_affiliate_list' and 'ghl_affiliate_payout_list'. The verb 'Retrieve' is specific and aligns with the read-only nature.

  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 guidance on when to use this tool versus similar tools (e.g., ghl_affiliate_list, ghl_affiliate_payout_list). It includes OAuth scopes and endpoint details but lacks explicit context for selection.

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

• ghl_affiliate_payout_listA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds minor context: it's a GET endpoint with readonly OAuth scopes and pagination parameters. No contradictions. The additional behavioral details are useful but not critical, as annotations already convey the 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 efficient with four sentences: title-like statement, purpose, endpoint details, and pagination guidance. It is front-loaded with the core purpose. Minor redundancy with the title 'List Payouts' but overall very concise and easy to parse.

  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 9 parameters and no output schema, the description covers the core functionality but lacks details on important params like start/end date filters and status options. It does not describe the response format, which would be helpful given no output schema. The description is adequate for simple usage but incomplete for complex queries or understanding returned data.

  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 56% (5 of 9 params have descriptions). The description adds value by explaining the pagination params 'skip' and 'limit' as pagination mechanism. However, other params (start, end, status) are not elaborated beyond schema examples. The description improves understanding for pagination but not for other parameters, so a 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 tool retrieves the list of payouts for a location, using the verb 'Retrieve' and resource 'payouts'. This distinguishes it from the sibling tool 'ghl_affiliate_commission_list' which is for commissions, not payouts. The endpoint and OAuth scopes further reinforce the purpose.

  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 through the context of listing payouts and mentions pagination, but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. It lacks guidance on prerequisites or when not to use it, though the name and purpose are clear enough for basic selection.

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

• ghl_business_getA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as false, covering key behavioral traits. The description adds extra context like the HTTP method, version header, and OAuth scopes, which enhances transparency beyond annotations.

  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 very concise and front-loaded with the core action 'Get Business'. It includes relevant technical details without unnecessary verbosity, though it could be slightly more 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 is simple with one parameter and read-only, but without an output schema, the description does not explain the return value or business object structure. The OAuth scopes and endpoint add context, but the absence of return description leaves a 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 0%, and the description does not explain the 'businessId' parameter or its purpose. For a single required parameter, the description should explicitly state what the ID represents to aid correct 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 'Get Business' and provides the endpoint and OAuth scopes, which makes the purpose unambiguous. It is distinguishable from sibling tools like 'ghl_business_get_businesses_by_location' which lists businesses, and 'ghl_business_create' which creates a business.

  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 implies getting a single business by ID, there is no explicit mention of context or exclusions, leaving the agent to rely on naming conventions alone.

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

• ghl_calendar_group_validate_slugA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate non-read-only, non-destructive, and open world. Description adds endpoint and scopes but no new behavioral traits beyond what annotations provide. Consistent with annotations.

  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?

  Short and front-loaded but has minor repetition ('Validate group slug' appears twice). Includes useful endpoint and OAuth details efficiently.

  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 and description does not specify what the tool returns (e.g., a boolean or object). For a validation tool, the return value is crucial for an agent to process the 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?

  Schema coverage is 100% with descriptions for both parameters. The description does not add any additional meaning beyond the schema. 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 'Validate group slug' and clarifies the action as checking availability. It distinguishes from sibling tools like create/update by focusing on validation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or alternatives provided. While the validation purpose is clear, there is no guidance on when to prefer this over other tools like ghl_calendar_group_create.

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

• ghl_calendar_notification_updateA
  3.5/5.0
  Behavior3/5

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

  Annotations provide idempotentHint and not destructive, but description adds OAuth scopes. However, it does not disclose whether updates are partial or full, or what happens to omitted fields. Behavioral context beyond annotations 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise (four sentences) and front-loaded with purpose. The endpoint and OAuth scopes are useful but could be omitted or integrated better. 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?

  Given the complexity of the body schema and absence of output schema, the description lacks details on update behavior (partial vs full) and response. Annotations cover idempotency, but overall completeness is adequate but not thorough.

  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?

  Two required params (calendarId, notificationId) have no description in schema or description. Body param has detailed schema but description does not elaborate on its usage beyond 'by id'. Schema coverage is 33%, and description adds no parameter 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 it updates a notification by ID, differentiating it from create, delete, get, and list siblings. The verb 'Update' and resource 'notification' are specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for updating existing notifications but does not explicitly state when to use this or exclude alternatives. No guidance on prerequisites or when not to use.

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

• ghl_calendar_schedule_unassignA
  3.5/5.0
  Behavior3/5

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

  Annotations already mark destructiveHint=true. The description adds context that it 'removes the association by removing the calendarId from the schedule', but does not elaborate on side effects, reversibility, or return behavior.

  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 somewhat repetitive across sentences (e.g., 'Removes...' repeated). While clear, it could be more concise.

  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 2-parameter tool with no output schema, the description covers the basic action and OAuth scopes. However, it does not describe the result of the operation (e.g., success response) or prerequisites.

  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 both parameters described in the schema. The description does not add any additional 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 clearly uses the verb 'removes' and specifies the resource ('user availability schedule association from a calendar'). It distinguishes from the sibling tool 'ghl_calendar_schedule_assign' by being the inverse 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 does not explicitly state when to use this tool versus alternatives. While the sibling 'ghl_calendar_schedule_assign' provides contrast, no direct guidance is given.

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

• ghl_chat_widget_getA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description does not need to repeat these. It adds endpoint and OAuth scopes, but these do not disclose new behavioral traits beyond what annotations provide.

  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 concise with a clear first sentence. However, the inclusion of endpoint, version, source, and OAuth scopes adds technical detail that may not be essential for an AI agent's decision-making.

  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 operation with two required string parameters and no output schema, the description covers the core purpose. It is adequate but could benefit from a brief note distinguishing it from list or get_public_config.

  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 descriptions for both parameters ('The chat widget ID', 'The location ID'). The description does not add any extra parameter-level meaning, 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 'Returns a single chat widget by ID,' specifying the verb (get) and resource (chat widget). It distinguishes itself from sibling tools like list, create, update, delete, and get_public_config by focusing on a single widget retrieval.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives (e.g., list or get_public_config). The lack of context for usage decisions makes it less helpful for an AI agent.

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

• ghl_contact_get_taskA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds the HTTP method (GET), version header, and OAuth scopes, which provide marginal extra context but no new behavioral traits.

  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 with two lines: the title and the endpoint/scopes. It is front-loaded with the essential purpose and contains no unnecessary 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?

  For a simple retrieval tool with no output schema, the description provides the endpoint and authentication context. However, it lacks any explanation of the return format or response fields, leaving the agent without full understanding of the output.

  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 descriptions for both parameters (taskId, contactId). The description does not add any 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get Task', and the endpoint path specifies retrieving a task by contactId and taskId. This distinguishes it from sibling tools like ghl_contact_get_all_tasks (list) and ghl_contact_create_task (create).

  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. No prerequisites, context, or exclusions provided. The description only includes technical details without usage advice.

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

• ghl_conversation_ai_update_actionA
  3.5/5.0
  Behavior3/5

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

  Beyond annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description adds that it modifies configuration and lists changeable fields. However, it does not clarify whether the update is partial (PATCH) or full replacement (PUT), nor does it describe errors, auth details beyond scope, or side effects. Annotations already cover safety; description adds modest value.

  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 relatively concise with three sentences plus endpoint/scope details. It front-loads the purpose. However, including low-level technical info (endpoint version, source file) adds noise. For a complex tool, it strikes a reasonable balance.

  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 complexity of the input schema (nested objects, many action types) and no output schema, the description lacks crucial context. It does not explain the different action types (triggerWorkflow, updateContactField, etc.) or how to structure the 'details' property. Return values and error conditions are not mentioned, leaving the agent underinformed for correct 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 mentions modifiable fields (name, description, trigger conditions, behavior settings) but these are already detailed in the schema. With 67% schema description coverage, the description adds minimal new meaning. The schema already provides examples and structure for the complex 'details' property.

  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 updates an existing action's configuration, specifying modifiable aspects (name, description, trigger conditions, behavior settings). This distinguishes it from sibling create, delete, get, and list 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 modifying existing actions but provides no explicit guidance on when to use this tool versus alternatives like create, delete, or other update tools. No when-not or alternative tool mentions.

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

• ghl_conversation_cancel_scheduled_email_messageA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true and idempotentHint=true. Description adds 'delete' which aligns. Does not disclose side effects or error scenarios beyond the deletion 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?

  Concise with three sentences plus endpoint/scope details. The endpoint and OAuth scopes are technical but acceptable. No unnecessary 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 deletion tool with only one required parameter, the description covers the basic action. Missing return value description but adequate given standard 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 coverage is 100%, so the schema fully documents the one required parameter emailMessageId. The description only repeats 'messageId' without adding semantic nuance 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 'Cancel a scheduled email message' with specific verb and resource. The tool name reinforces this. It distinguishes from sibling ghl_conversation_cancel_scheduled_message by specifying 'email'.

  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 the generic sibling ghl_conversation_cancel_scheduled_message. The description does not mention prerequisites or context for use.

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

• ghl_conversation_cancel_scheduled_messageA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true. The description adds endpoint details and OAuth scopes, confirming the delete operation. It does not contradict annotations but lacks side-effect details.

  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 concise with three sentences covering purpose, usage, and endpoint. It is front-loaded with the action. The technical endpoint details could be separated but it's efficient overall.

  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 tool with one parameter and no output schema, the description adequately covers the cancel action, required parameter, and authorization scopes. Missing response details but acceptable given 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?

  Schema coverage is 100% with description 'Message Id'. The description adds 'Post the messageId for the API to delete a scheduled message', which does not substantially enhance understanding 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 (cancel) and the resource (scheduled message). It distinguishes from the sibling 'ghl_conversation_cancel_scheduled_email_message' by specifying 'message' without 'email' qualifier.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or when-not-to-use guidance is provided. No alternatives are mentioned among the many sibling conversation tools.

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

• ghl_conversation_get_message_transcriptionA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, destructiveHint, openWorldHint. The description adds OAuth scopes, which is useful for authorization context, but no additional behavioral traits beyond what annotations state.

  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 repeats the tool name in the first line, then rephrases. It includes endpoint and scopes which are helpful but could be more concise. Structure is adequate but not 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?

  Given no output schema, the description does not describe the response format or error conditions. For a read tool with good annotations, it's minimally adequate but could explain expected output.

  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 both parameters are well-described. The description only paraphrases 'passing the message id', adding no new 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: get transcription by message ID. It specifies the resource (transcription) and the identifier (message ID). This distinguishes it from siblings like download_message_transcription.

  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 endpoint and OAuth scopes but does not explicitly guide when to use this tool versus alternatives (e.g., download vs get transcription). No guidance on prerequisites or exclusions.

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

• ghl_custom_field_get_by_object_keyA
  3.5/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating safe read behavior. The description adds important contextual details: the limited support scope and required OAuth scopes (locations/customFields.readonly), which are not in annotations.

  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 contains redundant text (title repeated), HTML markup (div, p tags), and includes endpoint details and OAuth scopes that could be trimmed or better organized. It is somewhat verbose and not optimally concise.

  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 read-only operation with rich annotations, the description covers the essential scope limitation but omits any indication of the response structure or data format. While not critical due to the tool's simplicity, return value details would improve completeness.

  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 add any parameter-level details beyond the input schema. The objectKey parameter's prefix requirement is already in the schema description, and locationId is completely undocumented in both schema and description. With 50% schema coverage, the description fails to compensate for the missing parameter 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 states 'Get Custom Fields By Object Key' and specifies that it only supports Custom Objects and Company (Business). This correctly identifies the tool's purpose and distinguishes it from related tools like ghl_custom_field_get_by_id.

  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 the supported object types (Custom Objects and Company) via the info box, which guides when to use this tool. However, it does not mention alternatives or explicitly exclude unsupported objects beyond 'supported today', which would make it clearer.

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

• ghl_email_get_bulk_action_campaignA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and idempotentHint. The description adds the HTTP method (GET) and OAuth scope (emails/campaigns.readonly), which provide useful behavioral context beyond annotations. No contradictions.

  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 sentences for purpose, then endpoint and scopes. No filler, front-loaded with the core action.

  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 covers purpose, endpoint, and required scopes. However, it lacks any information about the response structure or return value. Given no output schema, a brief note on what is returned 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?

  Both parameters (campaignId, locationId) are fully described in the input schema with examples and descriptions. The description adds no additional meaning; baseline 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 explicitly states 'Get a single bulk action campaign by its ID', using a specific verb and resource. It clearly distinguishes from the sibling list tool (ghl_email_list_bulk_action_campaigns) by specifying 'single'.

  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. It does not mention the list counterpart or any prerequisites or contextual triggers.

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

• ghl_email_list_bulk_action_campaignsA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds endpoint and OAuth details but does not provide significant behavioral context beyond what is already available.

  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 relatively concise and front-loaded with the title and action. Including endpoint details may be slightly verbose, but overall 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?

  No output schema exists, but the description does not describe the return structure or fields. For a list tool, hinting at the response format is important for 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 coverage is 100% (7 parameters all described). The description only mentions limit and offset for pagination, adding 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 clearly states 'List Bulk Action Campaigns' and 'Get list of bulk action campaigns for a location', providing a specific verb and resource. It distinguishes from sibling tools like 'ghl_email_get_bulk_action_campaign' (single item) and 'ghl_email_list_campaigns' (general campaigns).

  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 includes OAuth scopes and pagination parameters, giving technical context for use. However, it does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria.

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

• ghl_email_template_deleteA
  3.5/5.0
  Behavior3/5

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

  Annotations already provide destructiveHint=true and idempotentHint=true. The description adds OAuth scopes and endpoint details, which provide some behavioral context (e.g., authorization needed). However, it doesn't elaborate on irreversibility, cascading effects, or error conditions. The description adds modest value beyond annotations.

  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 concise (three sentences) and front-loaded with the main purpose. It includes technical details (endpoint, version, scopes) that are useful for an agent but not excessive.

  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 delete operation with full schema coverage and descriptive annotations, the description is adequate. It provides OAuth scopes and endpoint path. Could mention irreversibility, but overall complete enough for a straightforward 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?

  Schema coverage is 100% with descriptions and examples for both parameters. The description adds no additional meaning beyond what the schema provides (e.g., no format constraints or relationships). 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 'Delete' and the resource 'a template' (email template). The endpoint path distinguishes it from siblings like ghl_email_template_create or ghl_email_template_get. It 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?

  No guidance on when to use this tool vs alternatives. It does not mention prerequisites, alternatives (e.g., archiving vs deleting), or any conditions for safe use. The description only states what the tool does, not when to invoke it.

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

• ghl_email_template_importA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate a non-destructive write operation. The description adds OAuth scopes and endpoint details, which provide some behavioral context, but does not describe side effects or what happens on success/failure.

  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 concise with four short lines, no wasted words. However, the endpoint and OAuth info could be considered technical noise for an MCP context, slightly reducing front-loaded clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema and the tool being a mutation, the description lacks expected return value information, error handling hints, or confirmation of required fields. It is minimal for a complete understanding.

  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 schema fully documents parameters. The description adds no extra meaning beyond what the schema's property descriptions already provide, earning the baseline 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 clearly states 'Import an email template' and 'Import a template from a provider URL', specifying the verb and resource. It distinguishes from siblings like ghl_email_template_create by highlighting the import-from-URL mechanism.

  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 when to use (importing from a provider URL) and lists supported providers in the schema, but does not explicitly contrast with other email template tools (create, update, etc.) or provide exclusions.

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

• ghl_invoice_schedule_activateA
  3.5/5.0
  Behavior3/5

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

  Annotations indicate it is not read-only and not destructive. The description adds that it activates and starts sending, but lacks details on side effects (e.g., immediate sending vs scheduled start) or behavior if already active. 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description contains redundancy and grammatical errors ('Schedule an schedule invoice'), and includes endpoint/OAuth scopes which, while useful, add extra length. Not optimally concise.

  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 nested objects and no output schema, the description provides basic purpose and endpoint but lacks details on response or autoPayment configuration. There is room for more complete 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?

  Input schema coverage is 100%, so parameters are well-defined. The description does not add meaning beyond the schema, e.g., explaining altId/altType/liveMode or autoPayment. 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 that the tool activates a previously created but not-yet-scheduled recurring invoice, with a specific verb and resource. It distinguishes from sibling tools like ghl_invoice_schedule_create and ghl_invoice_schedule_update_and_activate by focusing on activation.

  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 activating a schedule that is not yet sending, but it does not explicitly specify when to use this tool versus alternatives like ghl_invoice_schedule_update_and_activate. No when-not or exclusion criteria are provided.

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

• ghl_location_delete_recurring_taskA
  3.5/5.0
  Behavior3/5

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

  Annotations already provide destructiveHint=true and idempotentHint=true, which the description implicitly confirms with 'DELETE'. The description adds the endpoint version and source but does not elaborate on side effects, authorization needs, or error behavior. It does not contradict 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 extremely concise with two lines, front-loading the purpose and including relevant endpoint details. Every word contributes value.

  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 straightforward delete tool with annotations covering destructiveness and idempotency, the description is adequate but lacks usage guidance and response details. The context is minimally 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?

  Schema coverage is 100% with clear descriptions for both id and locationId. The description does not add any additional meaning or constraints beyond what the schema provides, so it meets the 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 'Delete Recurring Task' and provides the full endpoint path with parameters, making the action unambiguous. It distinguishes from sibling tools like create, update, and get recurring tasks.

  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 (e.g., other delete operations or other recurring task operations). The description simply states what it does without 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.

• ghl_location_delete_tagA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, which convey key behavioral traits. The description adds the HTTP method and endpoint but does not elaborate on side effects like irreversibility or tag removal from associated entities, providing only minor additional context beyond 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 extremely concise: two sentences with no superfluous text. The first sentence states the purpose, and the second provides the endpoint for technical reference. Every element earns its place, maintaining high efficiency.

  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 delete tool with no output schema, the description covers the basic action and endpoint. However, it omits details like idempotent behavior (e.g., deleting an already-deleted tag), error handling, and return value expectations, leaving 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the two parameters (tagId, locationId), with brief descriptions in the schema. The description does not add extra meaning or clarify parameter usage beyond what the schema already provides, so it meets the baseline but adds no 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?

  The description clearly states 'Delete tag', specifying the action (delete) and resource (tag). Among siblings like ghl_location_create_tag, ghl_location_update_tag, and ghl_location_get_tag_by_id, this tool uniquely identifies the delete operation, distinguishing it effectively.

  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 (e.g., ghl_location_update_tag for deactivation). The description lacks context for selection, such as prerequisites or scenarios where deletion is appropriate.

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

• ghl_location_get_tagsA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and idempotentHint. The description adds OAuth scope details (`locations/tags.readonly`), which clarifies access requirements but doesn't contradict annotations.

  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 brief and front-loaded with the action. Technical details (endpoint, OAuth) are included but don't detract from clarity.

  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 retrieval operation with one required parameter, the description provides sufficient context including the endpoint and required scope. No output schema exists, but the return type is implied.

  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 'locationId' described as 'Location Id'. The description adds no additional parameter semantics 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 clearly states it gets tags for a sub-account (location). The verb 'Get' and resource 'Tags' are specific, and it contrasts with sibling tools that create or delete 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?

  No guidance on when to use this tool versus alternatives like `ghl_location_get_tag_by_id` or search. No when-to-use or when-not-to-use context provided.

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

• ghl_marketplace_chargeA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds endpoint details and OAuth scopes, which provide some behavioral context beyond annotations. However, it does not disclose side effects, idempotency implications (idempotentHint=false), or what happens on success/failure.

  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 very concise (3 lines) with no redundant information. It front-loads the purpose and includes essential technical details (endpoint, scopes) without verbosity.

  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 complexity (nested body object, 10 parameters, no output schema), the description is minimal. It omits explanation of return values or behavior on error, but the schema compensates. It is 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?

  Schema description coverage is 100%, so the parameter semantics are adequately documented in the schema. The description adds no additional meaning or usage hints for parameters beyond what's already in the input 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 'Create a new wallet charge', which is a specific verb+resource. This distinguishes it from sibling tools like ghl_marketplace_delete_charge or ghl_marketplace_get_charges.

  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 its siblings or any prerequisites. The description only provides the endpoint and OAuth scopes, but does not explain context such as 'use this to bill a sub-account' vs other methods.

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

• ghl_marketplace_get_chargesA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds endpoint info, OAuth scopes, and pagination behavior. No contradictions, but beyond annotations the added context 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 extremely concise, three lines covering purpose, endpoint, OAuth, and pagination. 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 7 optional parameters and no output schema, the description is adequate but lacks details on response format, error scenarios, or result limits. Annotations fill safety gaps but more behavioral context (e.g., 'returns an array') 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%, so the schema fully documents all parameters. The description adds no extra parameter meaning beyond what is already provided in the input 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 'Get all wallet charges' clearly states the action (Get) and resource (wallet charges), with the scope 'all' distinguishing it from siblings like ghl_marketplace_get_specific_charge. The endpoint and OAuth scopes confirm a read 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 explicit guidance on when to use this tool versus alternatives (e.g., get_specific_charge). Pagination hints are provided but not comparative usage context.

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

• ghl_marketplace_migrate_connectionA
  3.5/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false, so a write operation is expected. The description adds that it validates app configuration, stores credentials safely in encrypted storage, and manages token lifecycle. However, it doesn't disclose idempotency behavior, side effects of repeated calls, 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 relatively concise, with the main purpose stated upfront. The endpoint and OAuth scopes add technical context but are not redundant. One or two sentences could be removed without losing core 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?

  Given the complexity of the input schema (nested object with many fields) and no output schema, the description lacks details about the return value, error handling, and the precise semantics of 'migration' (e.g., whether it overwrites or creates new). This leaves 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 100%, so the baseline is 3. The description adds some context (e.g., 'validates the app configuration') but does not provide per-parameter guidance beyond what the schema already offers.

  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 migrates external authentication connection credentials (basic or oauth2) for a specific app and location. It uses specific verbs and resources, and the purpose is distinct from sibling tool names like marketplace_charge or marketplace_get_charges.

  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 when to use (migrating external auth credentials) but provides no explicit guidance on when not to use or alternatives. 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.

• ghl_media_bulk_update_filesA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare non-destructive and idempotent. The description adds that it updates metadata or status, providing some context beyond annotations. However, it does not disclose potential side effects, authentication requirements, or rate limits. The mention of 'status' is vague and not reflected 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise with three lines covering purpose, action, and endpoint. No redundant information. The endpoint line, while technical, is not wasteful. Could be slightly more structured but overall efficient.

  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 (nested body, 3 required subfields, no output schema), the description is insufficient. It should mention the required fields (altId, altType, filesToBeUpdated) and what can be updated (e.g., name). The reference to 'status' is misleading. Schema descriptions fill some gap, but the tool description itself lacks 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 coverage is 100%, so baseline is 3. The description adds minor value by saying 'metadata or status', but the schema only shows 'name' as an updatable field (no 'status'). This slight inaccuracy reduces the benefit. The description does not elaborate on the meaning or constraints of parameters 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 it updates multiple files/folders in bulk. The verb 'Bulk Update' and the phrase 'Updates metadata or status of multiple files and folders' precisely define the action. This distinguishes it from sibling tools like ghl_media_update_file (single file) or ghl_media_bulk_delete_files.

  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 bulk updates but provides no explicit guidance on when to choose this tool over alternatives. No mention of prerequisites, when-not-to-use, or comparisons with sibling tools like ghl_media_update_file for single updates.

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

• ghl_opportunity_getA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate read-only, idempotent, non-destructive. The description adds endpoint and OAuth scopes, which provide technical context. However, no behavioral details about response or side effects beyond what annotations cover.

  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 very brief, with no extraneous content. It front-loads the purpose and includes essential technical details in a structured manner.

  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 tool, the description covers purpose and technical details. However, it lacks any indication of the return structure or contents, which may be needed since no output schema is provided.

  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 a clear description for the 'id' parameter. The tool description adds no additional semantic 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 clearly states 'Get Opportunity' and provides the endpoint, indicating the resource and action. Among siblings like 'ghl_opportunity_create', 'ghl_opportunity_delete', etc., this is well distinguished.

  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 such as 'ghl_opportunity_search' or 'ghl_opportunity_get_lost_reason'. The OAuth scopes are stated, but no context on prerequisites or exclusions.

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

• ghl_payment_order_record_paymentA
  3.5/5.0
  Behavior3/5

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

  The description adds behavioral context beyond annotations by stating it does not process a live charge and updates order status to 'Paid'. However, it does not disclose other potential side effects (e.g., whether it sends notifications, handles partial payments, or fails on already-paid orders). With annotations providing readOnlyHint=false, the description slightly enhances transparency but remains incomplete.

  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 moderately concise but contains redundancy (e.g., 'Record Order Payment' repeated) and includes technical details (endpoint, OAuth scopes) that may not be necessary for an AI agent. It could be streamlined to a single clear sentence without losing value. It is not excessively verbose but not optimally concise.

  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 schema covers parameters fully and no output schema exists, the description adequately captures the core functionality. However, it omits important context like handling of partial payments (even though schema includes isPartialPayment), error conditions, or prerequisites (e.g., order must exist and be unpaid). The description is sufficient for basic use 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?

  Input schema coverage is 100%, with all parameters and nested fields having descriptions. The description adds no additional parameter meaning beyond what the schema already provides. Baseline score of 3 is appropriate as the schema carries the full burden.

  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 records a manual/offline payment against an order and explicitly distinguishes it from processing a live charge. The verb 'records' and resource 'payment against an order' are specific, and the detail about updating order status to 'Paid' adds clarity. The tool is well-differentiated from potential siblings like ghl_invoice_record_payment by its name and description.

  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 when to use the tool (to record a payment and update status) but does not provide explicit alternatives or when-not-to-use scenarios. There is no mention of when to use related tools like ghl_invoice_record_payment or constraints like requiring the order to be unpaid. Guidance is adequate but lacks depth.

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

• ghl_payment_subscription_getA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the endpoint path and OAuth scopes, which provide extra context beyond annotations, but no information about errors, rate limits, 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is mostly concise with four sentences. The first sentence repeats the title, but overall it is well-structured with endpoint and OAuth details included.

  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 operation, the description is adequate. It specifies the resource, endpoint, and authentication scope. The lack of output schema is acceptable given the tool's straightforward nature.

  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 description does not need to add parameter detail. The description does not enhance understanding beyond the schema, meeting the baseline of 3.

  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 tool name and description clearly state it retrieves a subscription by ID using a GET request. However, it does not explicitly differentiate from the sibling list tool (ghl_payment_subscription_list), relying on the name convention alone.

  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 usage context ('fetch details for a single subscription') but lacks when-not or alternative tool guidance. Prerequisites or exclusions are absent.

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

• ghl_payment_subscription_listA
  3.5/5.0
  Behavior4/5

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

  Annotations already provide safety profile (read-only, idempotent). The description adds behavioral details such as pagination support, filtering options, OAuth scopes, and endpoint specifics, which go beyond what annotations alone convey.

  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 somewhat verbose, with repetition of 'List Subscriptions' and a paragraph that could be more concise. However, it is well-structured with front-loaded purpose and includes endpoint details.

  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 no output schema, the description covers filtering and pagination but omits return structure, error handling, and default ordering. It is adequate but could provide more detail on what fields are returned and any rate limits.

  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 schema already documents all 13 parameters. The description provides a high-level overview of filtering capabilities but does not add significant new semantic meaning beyond what is in 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?

  The description clearly states 'List Subscriptions' and explains it retrieves a paginated list with filtering. It implicitly distinguishes from the sibling 'get' tool for subscriptions, but does not explicitly differentiate from other list tools in the payment domain.

  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 context on when to use (for paginated listing with filters) and mentions OAuth scopes and pagination parameters. However, it lacks explicit guidance on when not to use or alternatives (e.g., for a single subscription, use ghl_payment_subscription_get).

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

• ghl_saas_get_agency_plans_deprecatedA
  3.5/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds only token requirement and endpoint, which is useful but not rich behavioral context. No additional traits (e.g., rate limits, pagination) are disclosed.

  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 somewhat repetitive (two deprecation notices) and includes the title 'Get Agency Plans' redundant with annotations. It could be more concise by merging the deprecation warnings.

  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 fetch tool with full annotations and single parameter, the description provides adequate context (deprecation, token, endpoint). However, it lacks any mention of response structure or potential errors, which 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 coverage is 100% with a single parameter already described. The description merely restates 'for a given company ID' without adding new semantic details, so it meets the baseline but adds no extra value.

  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 fetches agency subscription plans for a company ID and explicitly marks it as deprecated with a superseding endpoint. While it distinguishes itself from siblings via deprecation, it does not name the exact replacement tool, leaving minor ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage guidelines are strong: deprecation warning explicitly tells the agent to prefer the replacement, and the required agency-level token is stated. However, it lacks an explicit 'do not use' directive or direct reference to the non-deprecated sibling tool.

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

• ghl_saas_get_location_subscription_deprecatedA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds important context: the need for an agency-level token and the endpoint details. No contradiction with annotations.

  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 somewhat verbose with repeated deprecation notices and redundant endpoint info. Key information (deprecation, token requirement) is front-loaded, but could be more concise.

  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 deprecated tool with no output schema, the description provides necessary context (deprecation, alternative, endpoint, token requirement) but does not describe return values. Adequate for decision-making but not 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?

  Parameter coverage is 100% as both parameters have descriptions in the schema. The description does not add further detail about the parameters beyond 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?

  The description clearly states the tool is deprecated, superseded by another endpoint, and fetches subscription details for a specific location. It identifies the verb (Get) and resource (Location Subscription Details) but does not explicitly distinguish from the non-deprecated sibling ghl_saas_get_location_subscription.

  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 indicates deprecation and suggests an alternative, and specifies that an agency-level token is required. However, it lacks explicit guidance on when to use this tool versus the non-deprecated version, leaving the agent to infer.

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

• ghl_saas_update_saas_subscriptionA
  3.5/5.0
  Behavior4/5

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

  Annotations indicate idempotentHint=true and destructiveHint=false, which are consistent with the update operation. The description adds context about the required agency token and the operation's purpose, complementing the annotations without contradiction.

  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 somewhat verbose with redundant phrases ('Update SaaS subscription' appears twice) and includes non-essential endpoint information. While front-loaded with key points, it could be more concise without losing clarity.

  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 covers purpose and auth requirements but lacks details on parameter semantics and return values. Given the nested body and multiple required fields, more guidance on using the tool correctly would improve completeness. No output schema is provided, which is acceptable but the description could compensate.

  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 50% description coverage, with property descriptions being minimal (e.g., 'Company ID'). The tool description does not elaborate on how parameters like subscriptionId or body affect the subscription plan/pricing change, missing an opportunity to add meaning beyond 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?

  The description clearly states the tool updates an existing SaaS subscription's plan/pricing for a location, using specific verbs and resources. It also corrects a misleading previous name. However, it does not explicitly differentiate from similar sibling tools like ghl_saas_update_rebilling.

  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 requires an agency-level token and notes the security restriction (Agency-Access-Only), providing clear guidance on when the tool can be used. It does not mention alternatives or when not to use it, but the token requirement is a strong usage signal.

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

• ghl_social_create_queueA
  3.5/5.0
  Behavior3/5

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

  The description adds value beyond annotations by revealing that the queue is created in draft status and that published posts are auto-added. However, it does not discuss error scenarios, rate limits, or authorization details beyond the OAuth scopes already listed. The annotations are minimal, so the description carries significant burden but still leaves 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?

  The description is very concise, with three short sentences that all contribute information: the purpose, the draft status and auto-add behavior, and the endpoint and OAuth scopes. It is front-loaded and contains no fluff.

  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 (a nested body object) and no output schema, the description covers the basic function and activation workflow. However, it lacks information about expected response format, potential errors, or what 'draft status' means in practice. This is 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 has 100% description coverage, with each parameter documented. The description itself does not add any additional parameter semantics beyond what is already in the schema. According to the guidelines, when schema coverage is high, the baseline is 3, and no extra value is provided here.

  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 that it creates a new category queue in draft status, with published posts auto-added. It distinguishes from update tools (e.g., ghl_social_update_queue) by mentioning 'Use update endpoint to activate.' However, it does not explicitly differentiate from ghl_social_create_queue_item, which creates items within a queue.

  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 context by stating that the queue is created in draft status and that the update endpoint should be used to activate it. It does not mention when not to use this tool or provide explicit alternatives among the many sibling tools, such as ghl_social_fetch_queues or ghl_social_update_queue.

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

• ghl_ad_fb_ad_pauseA
  3.6/5.0
  Behavior3/5

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

  Annotations provide readOnlyHint=false and destructiveHint=false, indicating mutation. Description adds endpoint and OAuth scopes but does not disclose behavior for edge cases (e.g., pausing an already paused ad) or describe side effects beyond the API call itself.

  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 short (3 lines) and includes useful endpoint and OAuth scope information without redundancy. It is front-loaded with the action and resource.

  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, and the description covers the endpoint and OAuth scopes. However, it lacks information about expected response or error conditions (e.g., ad not found, ad already paused). Given no output schema, more context would be helpful.

  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 descriptions for both parameters ('Ad identifier', 'Location identifier'). The description adds no additional meaning beyond what the schema already provides, 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 title 'Pause ad' and description 'Pause a running Facebook ad' use a specific verb+resource (pause + ad) and clearly distinguish this tool from sibling tools like ghl_ad_fb_ad_resume (resume) and ghl_ad_fb_adset_pause (pause ad set).

  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 is for pausing a running ad but provides no explicit guidance on when to use it over alternatives, nor does it mention prerequisites (e.g., ad must be running) or exclude cases like already-paused ads.

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

• ghl_ad_fb_adset_pauseA
  3.6/5.0
  Behavior4/5

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

  Annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) are consistent with a mutation that is non-destructive and non-idempotent. The description adds endpoint details (POST) and OAuth scopes (adPublishing.write), which provide additional behavioral context. No contradictions.

  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 concise (two lines plus endpoint/scopes) and front-loaded with the core action. Every sentence adds value. Minor extra details (endpoint version, source) are useful but not disruptive.

  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 pause action with full schema coverage and annotations, the description is minimally viable. However, it lacks info on state behavior (e.g., error if already paused, ability to resume) and no output schema is provided, leaving some gaps for a complete understanding.

  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?

  Input schema covers 100% of parameters with descriptions and examples. The description adds no extra meaning beyond the schema—no parameter semantics, formats, or constraints are elaborated. 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: 'Pause an ad set' and 'Pause a running Facebook ad set'. The verb 'pause' combined with the resource 'ad set' makes the purpose unambiguous. Sibling tools include both pause and resume variants, so this tool is distinctly identified.

  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 delete or resume. It does not specify prerequisites (e.g., ad set must be running), exclusions, or context for proper invocation. This lack of usage direction limits the agent's ability to decide correctly.

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

• ghl_ad_fb_adset_resumeA
  3.6/5.0
  Behavior3/5

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

  Annotations indicate non-readOnly and non-destructive. Description adds OAuth scopes (adPublishing.write) and endpoint details, but does not describe the effect of resuming (e.g., ad set starts delivering) 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 relatively concise with two clear sentences plus endpoint details. The endpoint line is somewhat verbose but provides useful context.

  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 2 required parameters and no output schema, the description is adequate but lacks details on return value, prerequisites (ad set must exist and be paused), and potential errors.

  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?

  Input schema covers 100% of parameters with descriptions and examples. The description does not add extra 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 clearly states the action ('Resume ad set') and the specific scenario ('Resume a paused Facebook ad set'). This distinguishes it from sibling tools like pause or 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?

  The description implies the tool is for paused ad sets but does not explicitly state when to use or avoid it. No alternatives are mentioned.

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

• ghl_ad_fb_campaign_duplicateA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds technical details like endpoint and OAuth scopes but does not elaborate on behavioral traits such as whether ad sets and ads are also duplicated, or the impact on the original campaign. The added value beyond annotations 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise (3 lines) and front-loads the core purpose. It includes useful technical details (endpoint, OAuth scopes) without being verbose. Could be slightly more informative but remains efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a duplication tool with no output schema, the description lacks details on what exactly is duplicated (e.g., whether it includes ads and ad sets), the expected response, and preconditions like campaign existence. Sibling tools exist for finer-grained duplication, so this context is important.

  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?

  With 100% schema coverage, the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides (campaignId and body.locationId descriptions). No additional context or examples are given.

  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 'Duplicate campaign' and elaborates 'Duplicate an existing Facebook campaign'. The verb 'duplicate' and resource 'Facebook campaign' are specific and unambiguous. It distinguishes from sibling tools like ad or adset duplication.

  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 is for duplicating Facebook campaigns but does not provide explicit guidance on when to use it versus alternatives, nor any prerequisites or exclusions. Sibling duplication tools exist but no differentiation is offered.

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

• ghl_ad_fb_current_user_getA
  3.6/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint, destructiveHint, idempotentHint. Description adds endpoint details and OAuth scopes, enhancing transparency. Does not cover edge cases or response behavior, but annotations carry the main safety profile.

  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?

  Concise with clear structure: action, endpoint, scopes. Source file reference adds minor verbosity but does not hinder understanding.

  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?

  No output schema; description does not specify response fields. Annotations cover safety, but for a read operation, lack of return value details reduces 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 coverage 100% with descriptions for both parameters. Description adds no further meaning beyond what the schema provides, 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?

  Description clearly states 'Get current Facebook user' and 'Retrieve the authenticated Facebook user profile for a location'. Specific verb and resource, distinguishable from sibling tools like ghl_ad_fb_account_get.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool vs alternatives like account_get or campaign_get. Mentions OAuth scopes but does not provide context for selection among many similar read operations.

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

• ghl_ad_fb_integration_deleteA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate destructive and idempotent behavior. The description adds OAuth scopes (adPublishing.write) and the endpoint, which provides some additional transparency, but does not elaborate on side effects or consequences.

  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 (four lines) and front-loaded with the main action. Every piece of information (endpoint, version, OAuth scopes) is relevant and 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 delete operation with one parameter and no output schema, the description is adequately complete. It specifies the location scope and OAuth requirement, though it could mention expected success response.

  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% (body with locationId described as 'Location identifier'). The description adds no extra meaning beyond the schema, so 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 action ('Delete Facebook integration' and 'Remove the Facebook ad integration from a location') and the specific resource. Sibling tools like create and get provide clear 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?

  The description does not provide guidance on when to use this tool vs. alternatives (e.g., creating or getting integration). No prerequisites or context about when deletion is appropriate.

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

• ghl_ad_fb_pixel_listA
  3.6/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds the HTTP method (GET) and OAuth scopes, consistent with read-only behavior. However, it does not disclose additional behaviors such as pagination, response format, or error handling, so it adds limited value beyond 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 extremely concise: a clear purpose line, a brief explanation, and technical details in three lines. No redundant information, and all sentences earn their 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?

  Despite conciseness, the description is incomplete for a list tool with 4 parameters and no output schema. It omits details about optional parameters, filtering, pagination, and the structure of the returned data. The agent would lack critical context to use the tool 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 100%, with all parameters described with examples. The description adds no extra parameter-level meaning, so baseline score of 3 applies. It does not explain relationships between parameters or optional 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 clearly states 'Get conversion pixels' and 'Retrieve Facebook conversion pixels for a location'. It specifies the verb 'Get' and resource 'conversion pixels', distinguishing it from sibling tools like ghl_ad_fb_pixel_upsert which handles creation/updates.

  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 does not explicitly state when to use this tool versus alternatives like pixel_upsert or other listing tools. It mentions 'for a location' but lacks guidance on filtering or when not to use it, leaving the agent to infer from the name alone.

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

• ghl_ad_google_conversion_goal_listA
  3.6/5.0
  Behavior4/5

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

  The description aligns with annotations (readOnlyHint=true, etc.) and adds useful behavioral context like the specific OAuth scope required ('adPublishing.readonly'). It does not contradict annotations. While the description could mention the non-destructive nature, annotations already cover that.

  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 concise, starting with a clear purpose statement followed by essential technical details. Every sentence adds value (purpose, endpoint, version, scopes). Could be slightly more structured but efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with two parameters and no output schema, the description covers the essential: locationId, optional isDraft, and required scopes. However, it does not mention that the tool returns a list of conversion goals, pagination behavior, or any result structure. Adequate but could be 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?

  Input schema coverage is 100%, so baseline is 3. The description does not add meaningful semantics beyond the schema: 'locationId' is described as 'Location identifier' and 'isDraft' as 'Is draft'. No elaboration on the meaning of 'isDraft' in this context. No additional value.

  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 it retrieves Google Ads conversion goals for a location. The verb 'Get' and resource 'conversion goals' are specific. However, it does not explicitly differentiate from sibling tools like ghl_ad_google_conversion_list or ghl_ad_google_conversion_get, which might cause confusion for an AI agent.

  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 endpoint details and OAuth scopes but offers no explicit guidance on when to use this tool versus alternatives. It implies usage for listing conversion goals but lacks exclusions or context about preferred scenarios.

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

• ghl_ad_google_segment_offline_job_createA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate a write operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds endpoint and OAuth scopes, but these are technical details rather than behavioral traits like job processing or return values. No new behavioral insights beyond 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 very concise, with a clear header line, one line explaining the purpose, and then endpoint and scopes. Every sentence adds value without repetition or fluff.

  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 having no output schema, the description does not hint at what the tool returns (e.g., job ID, status). The creation process's nature (synchronous or async) is unmentioned. This lack of output context leaves a significant gap for an effective create 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 coverage is 100% with descriptions and examples for all parameters. The description does not add any explanation beyond what the schema provides, so it meets the baseline but does not enhance understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool creates an offline user list job for uploading users to a Google customer match list. It uses a specific verb (Create) and resource (offline user list job), and the sibling tools like ghl_ad_google_segment_upsert are for different purposes, so this tool is well-distinguished.

  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 uploading users to a customer match list but does not explicitly state when to use this tool versus alternatives or provide conditions for not using it. No exclusions or alternatives are mentioned, offering only implied guidance.

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

• ghl_ad_li_ad_status_updateA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate it's a mutation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds OAuth scopes and endpoint details, which provide additional context but no further behavioral traits like rate limits or reversibility.

  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 short and front-loaded with the core purpose ('Update ad status' and 'Pause or resume...'). It includes relevant technical details (endpoint, OAuth scopes) without unnecessary 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 4 parameters, nested body, and no output schema, the description provides adequate context about the tool's role in LinkedIn ad management but lacks details like the effect of ARCHIVED vs PAUSED or how isDraft modifies 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?

  Input schema coverage is 100% with basic descriptions (e.g., 'Ad identifier', 'Location identifier'). The description does not add extra meaning beyond the schema, which already documents required and optional fields and their enums.

  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 updates ad status for LinkedIn ads, campaigns, or ad groups, and specifies the actions (pause/resume/archive). This distinguishes it from sibling tools like ghl_ad_li_campaign_group_upsert or ghl_ad_li_account_delete, which have different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for pausing, resuming, or archiving LinkedIn ad objects, but does not explicitly compare with alternative tools or provide when-not-to-use scenarios. Some guidance is present via the specific actions listed.

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

• ghl_ad_li_campaign_group_reporting_getA
  3.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint. The description adds endpoint details (GET, version header, OAuth scopes), confirming safe, read-only behavior. However, no mention of rate limits, error handling, or response format.

  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 brief (two sentences plus technical details). It is front-loaded with purpose. The version header and source file reference add minor noise but overall structure is clean.

  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?

  No output schema exists, and the description does not mention the response format or that the 'fields' parameter controls which metrics are returned. For a reporting tool, this is a gap; however, the description is adequate 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?

  Schema coverage is 100%, so baseline is 3. The description only references campaignGroupId in the endpoint without adding new semantics. Other parameters are well-described in the schema, but the description does not enhance parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('get campaign group reporting' and 'retrieve reporting metrics'), the specific resource ('LinkedIn campaign group'), and implicitly distinguishes from sibling tools like ghl_ad_li_campaign_group_get (which likely retrieves details, not metrics).

  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 usage guidance is provided. The description does not explain when to use this tool over other reporting tools (e.g., ghl_ad_li_reporting_get) or indicate prerequisites. The agent must infer from the name alone.

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

• ghl_ad_li_campaign_group_upsertA
  3.6/5.0
  Behavior3/5

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

  Annotations already provide idempotentHint=true and destructiveHint=false. The description adds that the tool includes campaigns and ads, and mentions OAuth scopes, but does not disclose additional behavioral traits like error handling, limits, or the effect of create vs update. No contradiction with 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 extremely concise: two clear sentences plus endpoint and OAuth scopes. Every piece of information serves a purpose, and the primary action is 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 complexity nested objects, many parameters, and no output schema, the description is insufficient. It does not mention what the response contains (e.g., the upserted campaign group ID), nor does it clarify that locationId is required. More detail on return values and error handling is needed.

  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. The tool description adds high-level context ('Create or update a LinkedIn ad campaign group with campaigns and ads') but does not add significant meaning beyond the schema descriptions. 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 ('Upsert') and resource ('ad campaign group'), and specifies that it creates or updates a LinkedIn ad campaign group including campaigns and ads. This distinguishes it from sibling tools like get, publish, and reporting.

  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 for upserting LinkedIn ad campaign groups, but provides no explicit guidance on when to use this tool versus alternatives (e.g., separate create/update tools, or Facebook/Google equivalents). No when-not-to-use or prerequisite information is given.

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

• ghl_ad_li_reporting_getA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds that it's a GET request and mentions OAuth read scope, but does not provide additional behavioral context beyond what annotations convey. No contradiction.

  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 four sentences, front-loaded with purpose. It includes some technical details (endpoint version, source) that could be trimmed but remains clear and relatively concise.

  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 no output schema and 7 parameters, the description does not explain the return format, pagination, or filtering via entityUrns. It covers main functionality but lacks details on response and edge cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description adds 'configurable pivot and time grouping' but does not enhance understanding of parameters beyond the schema's own 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 it retrieves LinkedIn Ads analytics data with configurable pivot and time grouping. It distinguishes from siblings like ghl_ad_li_campaign_group_reporting_get by being a general reporting tool, and includes endpoint and OAuth scopes.

  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 it's the general LinkedIn ad reporting tool but does not explicitly state when to use vs alternatives. No when-not or what conditions trigger its use are mentioned.

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

• ghl_blog_get_all_authors_by_locationA
  3.6/5.0
  Behavior4/5

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

  Annotations already confirm read-only, idempotent, non-destructive behavior. The description adds value by specifying the HTTP method (GET), OAuth scopes, and pagination parameters, which inform the agent about how to page through results.

  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 reasonably short but redundant (repeats 'Get all authors'). It includes unnecessary technical details like endpoint path and version header, which could clutter the description. Could be more 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?

  No output schema is provided, yet the description does not explain the structure of returned authors (e.g., fields, format). It also omits prerequisites or behavior beyond pagination. For a list tool with required parameters, this is 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%, so the baseline is 3. The description mentions locationId and pagination params but provides no additional detail beyond what the schema already contains. No extra semantic value is added.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it retrieves all blog authors for a given location ID. The verb 'Get' and resource 'authors' are specific, and the sibling tool for categories distinguishes this tool's purpose.

  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 listing authors by location, but it does not explicitly guide when to use this tool versus alternatives like the categories tool. No exclusion criteria or alternative recommendations are provided.

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

• ghl_calendar_event_schedule_createA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that OAuth scope 'calendars.write' is required, but does not disclose other behavioral traits like error handling, idempotency, or effects on existing schedules. With annotations present, the bar is lower; the description adds minimal context beyond what annotations provide.

  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 three sentences long and includes endpoint details and OAuth scopes. However, the first sentence repeats the title, slightly reducing efficiency. Overall, it's well-structured and concise.

  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 explains the core functionality and includes endpoint and OAuth details. However, it lacks information about return values (no output schema), prerequisites (e.g., calendar existence), error handling, or potential constraints. For a tool with nested objects and no output schema, this is adequate but not 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 description coverage is 100%, so baseline is 3. The description restates that calendarId and body (with rules and timezone) are required, which is already in the schema. No additional parameter semantics or usage tips are provided.

  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 an availability schedule specifically for an event calendar, using a specific verb (Create) and resource (event calendar availability schedule). This distinguishes it from sibling tools like ghl_calendar_schedule_create (generic schedule) and ghl_calendar_event_schedule_get/update.

  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 indicates the context (event calendar) but does not explicitly state when to use this tool versus alternatives (e.g., ghl_calendar_schedule_create). No 'when not to use' or alternative tool names are provided.

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

• ghl_calendar_service_booking_updateA
  3.6/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=false (mutation), destructiveHint=false, and idempotentHint=true. The description adds OAuth scopes (calendars/events.write) and endpoint version, which provide useful authorization and API context beyond the 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 three lines long, front-loaded with the title, and every sentence provides essential information (verb, resource, endpoint, OAuth scopes). No superfluous content.

  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 good annotations and schema coverage, the description is minimal for a complex mutation tool with nested parameters and no output schema. It lacks details about the response format, side effects, or which fields can be updated, making it less 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% and each parameter has a description in the schema. The tool description does not add any additional parameter information, so it meets the baseline but does not exceed it.

  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 'Update Service Booking' and 'Update an existing service booking', which is a specific verb+resource. It distinguishes from sibling tools like create, delete, get, and list by explicitly stating 'update'.

  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_calendar_service_booking_create. No context about prerequisites or conditions for updating a booking is given.

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

• ghl_calendar_service_getA
  3.6/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, which cover safety and idempotency. The description adds the OAuth scopes and endpoint version, providing minor additional behavioral context but no significant new insights.

  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 plus endpoint and OAuth info. It is extremely concise, front-loads the purpose, and contains no redundant text.

  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 getter tool with one parameter and no output schema, the description covers the essential information: purpose, endpoint, and required OAuth scopes. It is sufficiently complete for an agent to use correctly, though return structure is not described.

  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?

  With 100% schema description coverage (the single parameter serviceId is documented in the schema), the description adds no extra meaning about the parameter. The baseline of 3 is appropriate, as the description does not compensate with additional 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 title 'Get Service by ID' and description clearly specify the action (get) and resource (service by ID). It distinguishes from sibling tools like ghl_calendar_service_create, ghl_calendar_service_list, etc., which operate on the same resource differently.

  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 (e.g., listing services) or when not to use it. There is no mention of prerequisites or scenario-specific advice.

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

• ghl_conversation_create_custom_subtypeA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the role requirement. However, it does not elaborate on idempotency (idempotentHint=false) or other behavioral details like duplicate handling. It adds some value beyond annotations but not much.

  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 concise, with two lines and a sentence. However, the first line 'Create Custom Subtype' is redundant with the second line. It could be streamlined without losing information. Good front-loading of the action.

  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 covers the purpose and required role, but lacks information about the return value or confirmation (e.g., ID of created subtype). Since there is no output schema, the agent would benefit from knowing what the response contains. The nested object body is adequately handled by the 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?

  Schema coverage is 100%, with both required parameters and nested body properties fully described in the schema. The description adds no additional semantics beyond what the schema provides. It does include endpoint info but that is not parameter-specific. 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: 'Create a new custom subtype for a location.' It specifies the resource (custom subtype) and the verb (create). It distinguishes from sibling tools like 'ghl_conversation_list_custom_subtypes' and 'ghl_conversation_update_custom_subtype' by focusing on creation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It mentions the required role ('Requires agency or account admin role') but does not explicitly state when to use this tool versus alternatives. The context implies it's for creating rather than listing or updating, but no explicit guidance is given.

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

• ghl_conversation_get_contact_unsubscription_statusA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description only adds endpoint details and version, not additional behavioral context like error handling or performance 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 two sentences long, front-loaded with purpose, and minimally wastes words. The endpoint line is mildly redundant but not harmful.

  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?

  Description covers the essential purpose and parameter optionality but lacks details about return structure or behavior on missing contact, which is notable given no 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?

  Schema description coverage is 100%, and the description repeats the optionality of the email parameter without adding new meaning. No extra value beyond 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 ('Get'), the resource ('subscription statuses'), and the scope ('for a contact (all emails or specific email)'), making it unambiguous and distinguishing it from sibling 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 does not provide explicit when-to-use or alternative guidance. However, the tool is unique among siblings for retrieving unsubscription status, so usage is implied from the purpose.

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

• ghl_conversation_searchA
  3.6/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the HTTP method (GET), OAuth scopes, and pagination parameters, which are consistent. However, it does not elaborate on other behavioral aspects such as rate limits, error handling, or result format, beyond what annotations already indicate.

  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 concise, with four sentences covering purpose, endpoint, scopes, and pagination. It is front-loaded with the main action. The inclusion of technical details like the version header and source file may be slightly extraneous but does not detract significantly.

  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 explains the tool's capability to search with filters and pagination, but given the lack of an output schema, it does not describe the return structure. The schema has 21 parameters with many enums, so more context on the response and how results are organized 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%, and the description does not repeat or add meaningful extra meaning for parameters beyond the schema. The mention of pagination exists in the description but adds no detail beyond what the 'limit' parameter already provides. 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 searches conversations and returns matching results with sorting and filtering. The verb 'Search' and resource 'Conversations' are explicit, and it distinguishes from sibling conversation tools that perform other operations like create, get, or update.

  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 conversations with filters but does not provide explicit guidance on when to use this tool versus alternatives. No exclusion criteria or mention of when not to use it is given, which limits clarity for an AI agent deciding among many conversation-related tools.

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

• ghl_conversation_updateA
  3.6/5.0
  Behavior3/5

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

  Annotations provide idempotentHint=true and destructiveHint=false, but description adds endpoint and OAuth scopes. No further behavioral details like partial vs full update or error scenarios. Marginal added value.

  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?

  Concise at 5 lines with front-loaded purpose. Endpoint and scopes included. Minor structural improvement possible, but overall efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema; moderate complexity with nested body. Annotations cover safety, description gives endpoint. Lacks high-level operation semantics like update type (partial/full) and field behavior. Adequate but not 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 parameter descriptions. Description does not add additional meaning or context to parameters, so 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?

  Description clearly states the verb 'Update', resource 'conversation details', and method based on conversation ID. It distinguishes from sibling tools like create, delete, get.

  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?

  Indicates update operation and references conversation ID, but does not specify when to use vs alternatives or what not to do. Lacks explicit usage boundaries.

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

• ghl_conversation_user_subscription_changeA
  3.6/5.0
  Behavior3/5

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

  The description discloses a key side effect: 'Legal forms are automatically created for user-initiated resubscribe actions on custom subscriptions.' However, it does not address idempotency, rate limits, or outcomes if the subscription is already in the desired state. Annotations provide no additional behavioral hints, so the description carries the full burden and only partially fulfills it.

  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 three sentences: title, purpose/behavior, and endpoint. It front-loads the core purpose and is reasonably concise. The endpoint line could be omitted as it's technical detail, but the overall structure is efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the nested input schema and no output schema, the description covers the main action and side effects but omits prerequisites, required parameters, and expected return. The endpoint info provides context but does not substitute for missing output 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 input schema has 100% coverage with descriptions for all parameters, including detailed enums and examples for subscription_action. The description adds high-level context ('Supports individual custom subscription changes and resub all functionality') but does not augment specific parameter meanings beyond the schema. 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 'Process subscription change initiated by a user (admin/agent)' and enumerates supported actions (individual custom subscription changes, resub all). This provides a specific verb and resource, distinguishing it from sibling tools like ghl_conversation_get_contact_unsubscription_status.

  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 when to use (user-initiated subscription changes) but does not explicitly state when not to use or mention alternatives. The mention of 'legal forms are automatically created' gives context, but no direct guidance on tool selection versus siblings like status-check or subtype creation tools.

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

• ghl_custom_menu_get_by_idA
  3.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds endpoint details, OAuth scopes, security requirement, and response content. No contradictions. Provides behavioral context beyond the annotations.

  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?

  Description contains multiple pieces of info (auth warning, title, fetch description, endpoint, scopes) but some redundancy (title appears in both annotation and description). Could be more streamlined.

  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 tool with one parameter and no output schema, the description covers purpose, auth, endpoint, and response content. Lacks error handling details but is mostly 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% for the single parameter 'customMenuId', which has a clear description. The description does not add extra parameter-specific details but includes the ID in the endpoint path. 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?

  Description clearly states 'Get Custom Menu Link' and 'Fetches a single custom menus based on id'. It specifies the resource and action, and implies retrieval of a single configuration. However, it does not explicitly differentiate from sibling tools like list, but the verb 'Get' and 'single' make it clear.

  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?

  Provides important auth context: requires agency-level token and OAuth scope. Does not explicitly state when to use this vs. other custom menu tools (e.g., list or update). Usage is implied but not formalized.

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

• ghl_custom_menu_updateA
  3.6/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false and idempotentHint=true, consistent with an update operation. The description confirms it requires authentication and permissions but adds little beyond the annotations. No contradiction.

  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 relatively concise and front-loads the critical security requirement. It includes endpoint and OAuth scopes, but could be slightly tighter without losing essential info.

  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, the description does not mention return values. The tool has many nested parameters, and while the description covers key usage constraints, it lacks completeness on behavioral details such as what the successful response contains.

  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 description does not add parameter-specific details beyond what the schema provides. The agency-level token note is a useful context but not parameter semantics.

  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 'Updates an existing custom menu for a given company' with specific verb and resource. It does not explicitly differentiate from sibling tools like ghl_custom_menu_create or ghl_custom_menu_delete, but the name and context make the purpose clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a critical usage constraint: 'REQUIRES AN AGENCY-LEVEL (Company) TOKEN' and mentions OAuth scopes. However, it does not state when to use this tool versus alternatives like ghl_custom_menu_create or ghl_custom_menu_delete.

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

• ghl_email_builder_template_updateA
  3.6/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false, consistent with an update operation. The description adds no additional behavioral details beyond the endpoint and scopes. It does not contradict annotations.

  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 concise, with the most critical information (legacy status, action, endpoint) in the first two sentences. It avoids unnecessary details, though the endpoint and OAuth scopes could be moved to structured fields.

  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 no output schema and a complex input schema. The description does not explain how to construct the body or what the response looks like. For a mutation tool with nested parameters, this is insufficient for an AI agent to use 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 input schema has a single 'body' parameter with many nested properties. The description does not explain any of these fields beyond what the schema provides. The schema itself only has a generic description for 'body'. The description adds no value for parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this is a legacy email builder template update endpoint, distinct from the v3 template family, and summarizes the action as 'Update a template'. This effectively differentiates it from sibling tools like ghl_email_template_update.

  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 marks this as legacy and distinct from v3 templates, guiding when to use it. It also provides OAuth scopes. However, it does not provide explicit criteria for choosing between this and other update tools, but the differentiation is sufficient.

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

• ghl_email_template_updateA
  3.6/5.0
  Behavior4/5

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

  Annotations (readOnlyHint=false) indicate mutation; description does not contradict. The description adds the API endpoint and OAuth scopes, providing useful auth context beyond annotations. No additional behavioral details but no contradictions.

  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?

  Short two-sentence description including endpoint and scopes. Efficient but could benefit from structured formatting (e.g., bullet list). 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?

  Tool has nested body and no output schema, but description does not mention return values or error conditions. For a simple update, the description is adequate but lacks context on prerequisites or side effects.

  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?

  Input schema has 100% description coverage, so the schema already explains each parameter. The tool description does not add any extra meaning beyond endpoint and scopes. 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 ('Update') and the resource ('email template'). It distinguishes this tool from siblings like 'create' or 'delete' by its name and verb. The endpoint details reinforce the 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?

  No explicit guidance on when to use this tool versus alternatives (e.g., create, delete). No mention of prerequisites, context, or scenarios where updating is appropriate. The description only provides the endpoint and OAuth scopes.

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

• ghl_estimate_updateA
  3.6/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds endpoint details and OAuth scopes, which clarify authentication and request routing. No contradictions, and it enhances the safety profile beyond 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 very concise: a one-sentence purpose, followed by technical details. Every sentence adds value, and the structure front-loads the core action. No unnecessary 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?

  The description does not mention the response format or return value. With no output schema, the agent lacks critical information about what the tool returns after a successful update. This is a significant gap for a complex nested 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?

  Schema description coverage is 100%, so each parameter has detailed descriptions and examples in the schema. The tool description adds no additional parameter semantics beyond the schema, achieving baseline adequacy.

  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 'Update an existing estimate with new details'. This specifies the verb (update) and the resource (estimate), and distinguishes it from sibling tools like create, delete, list, and send.

  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 vs alternatives like ghl_estimate_create or ghl_estimate_send. The description does not provide any context for decision-making or exclusion criteria.

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

• ghl_funnel_get_pages_count_by_idA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the endpoint path (GET /funnels/page/count) but does not disclose additional behavioral traits such as response format or pagination behavior. It neither contradicts nor significantly enhances the 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 three sentences long, front-loading the core purpose and providing the endpoint path. Every sentence adds value, and there is no extraneous text.

  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 count tool, the description covers the basic purpose and endpoint. However, it lacks details about the return value structure and does not explain the optional 'name' parameter, making it less complete for an agent that needs to interpret the response or use all parameters 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 0%, and the description only vaguely references 'given query parameters' without explaining the purpose or constraints of name, funnelId, or locationId. The optional 'name' parameter is particularly ambiguous. The description fails 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 title 'Fetch count of funnel pages' and description clearly state the verb ('Fetch count') and resource ('funnel pages'). The name and sibling ghl_funnel_get_pages_by_id provide contrast, making the tool's specific 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 mentions 'based on the given query parameters' but does not explicitly state when to use this tool over siblings like ghl_funnel_get_pages_by_id. No guidance on prerequisites or context is provided, leaving the agent to infer usage from the name and endpoint.

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

• ghl_funnel_update_redirect_by_idA
  3.6/5.0
  Behavior4/5

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

  Annotations indicate mutation but not destructive. Description adds OAuth scope requirement which helps with authorization context. No contradiction with annotations. However, does not disclose other traits like rate limits 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description includes useful technical details (endpoint, version, OAuth scopes) but repeats title and could be more concise. Some redundancy with title in first sentence.

  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?

  Covers purpose, endpoint, and auth scopes but lacks response description, error handling, or additional context for a simple update tool. Adequate but not thorough.

  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 50% and description does not add meaningful detail beyond what schema provides. 'using details provided in the request payload' is vague. No explanation of how 'id' or 'body' fields affect 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?

  Clearly states it updates an existing URL redirect, specifies HTTP method and resource path. Distinguishes from sibling tools like create, delete, get by focusing on update 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?

  Implies usage for modifying existing redirects when ID is known, but does not explicitly state when to use vs alternatives like create/delete. No exclusions or prerequisites mentioned beyond the required ID.

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

• ghl_invoice_deleteA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true. The description adds the endpoint URL and OAuth scopes but does not elaborate on side effects (e.g., permanent deletion, impact on related records). Acceptable but minimal extra 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 extremely concise (two sentences plus endpoint and scopes). No redundant information; every line serves a purpose.

  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 delete operation without output schema, the description covers the action, endpoint, and auth requirements. It could mention the expected response (e.g., 200 OK) or confirm irreversibility, but overall sufficient for basic completion.

  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?

  Input schema has 100% description coverage, so the baseline is 3. The description does not add any parameter-level meaning beyond what the schema provides. It could explain the role of altId/altType (e.g., location context) but does not.

  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 'invoice', and specifies it operates by invoice id. It distinguishes itself from sibling invoice tools (like create, update, void) by focusing on deletion.

  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, nor any prerequisites or conditions (e.g., invoice must exist, not paid). The agent is left to infer usage from the name alone.

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

• ghl_invoice_record_paymentA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds the OAuth scope 'invoices.write', which provides authentication context. However, it does not elaborate on side effects (e.g., updating invoice balance) or response behavior beyond the annotation set.

  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 contains redundant phrases like 'Record a manual payment for an invoice' and 'API to record manual payment for an invoice by invoice id,' which repeat the same information. The first sentence and endpoint/scopes are useful, but the repetition wastes space.

  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 nested objects and no output schema, but the description gives no indication of what happens after the payment is recorded (e.g., response, invoice balance update). It also does not explain the required sub-fields like altId, altType, etc., beyond schema descriptions. The context is incomplete for a complex mutation.

  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 schema already documents all parameters. The description does not add any additional parameter meaning beyond what is in the schema. 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 it records a manual/offline payment against an invoice and explicitly differentiates from processing a live charge. This provides a specific verb-resource combination and distinguishes it from sibling tools like ghl_invoice_create or ghl_invoice_void.

  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 includes 'Does not process a live charge,' giving clear exclusion for when not to use it. However, it does not explicitly name alternative tools for live charges, which are present among sibling tools. The guidance is clear but lacks alternative references.

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

• ghl_invoice_template_getA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint, idempotentHint, and non-destructive. Description adds GET endpoint and OAuth scopes but no further behavioral details like response structure 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is concise with three focused lines: purpose, endpoint, OAuth scopes. Minor grammar issue ('an template') but overall efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists; description provides endpoint and OAuth scopes, which aids authorization context. However, lacks explanation of return format or template content. Adequate for a simple GET but not 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 descriptions for all 3 parameters. Description mentions 'template id' but adds no semantics beyond schema. 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 tool retrieves a template by ID using 'Get an template' and 'API to get an template by template id'. It distinguishes from sibling CRUD operations (create, delete, list, update).

  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 a single template but does not explicitly state when to use vs. alternatives like ghl_invoice_template_list. No when-not guidance or alternatives mentioned.

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

• ghl_location_updateA
  3.6/5.0
  Behavior3/5

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

  The description complements annotations by stating OAuth scopes and token requirements. However, it does not clarify whether the update is partial or full replacement, nor does it mention response behavior or side effects beyond the mutation.

  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 most critical information (token requirement, action, endpoint). Every sentence adds value, and there is no repetition or fluff.

  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 an output schema, the description does not explain what the tool returns after a successful update, nor does it cover error handling or validation behavior. This makes it incomplete for an agent to fully understand the tool's effects.

  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 descriptions, so the tool description does not need to add parameter details. However, the schema's body description is generic ('carried verbatim from OpenAPI spec'), providing no additional insight for the agent.

  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 that the tool updates a Sub-Account (formerly Location) by putting data to the endpoint. It distinguishes itself from sibling tools like create, get, delete, and search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description specifies that it requires an agency-level token, but does not explicitly state when to use this tool over alternatives like create or search. Usage context is implied but not formally guided.

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

• ghl_location_update_permissionsA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate idempotent and non-destructive. Description adds agency token requirement but does not explain whether updating permissions replaces or merges with existing ones. No contradiction with annotations.

  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?

  Description is concise, with a clear security warning upfront. However, the structure could be improved by separating the security requirement from the tool 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?

  Covers security and endpoint, but lacks explanation of how the permissions array is applied (replace vs merge) and does not describe the response. Partial coverage given no 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?

  Schema has 100% description coverage for both parameters. Description adds no additional meaning to parameters beyond 'Update Permissions' and the endpoint.

  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 clearly states it updates sub-account (location) permissions and provides the endpoint. However, it does not differentiate from the similar sibling tool ghl_location_get_permissions, missing an opportunity to clarify read vs write.

  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?

  Explicitly requires an agency-level token, which is a strong usage constraint. But no mention of when not to use or alternatives (e.g., use get_permissions to read).

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

• ghl_location_upload_file_custom_fieldsA
  3.6/5.0
  Behavior3/5

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

  Adds context about the multipart format and no JSON alternative, beyond annotations. But omits details on success/error responses, file size limits, or other behavioral traits that would fully inform the agent.

  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?

  Very concise: two sentences plus endpoint and scopes. Critical info is front-loaded, no unnecessary 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?

  Covers essential aspects (purpose, content type, endpoint, scopes), but lacks output schema details, error handling, and file constraints. Adequate but not comprehensive.

  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?

  Description clarifies that the body contains 'the file plus its associated customField id/name', which is not evident from the schema alone. Schema has 'id' and 'maxFiles' but 'customField id/name' is added 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?

  Clearly states 'Uploads File to customFields' and specifies the endpoint. However, it does not distinguish from similar upload tools like ghl_form_upload_custom_files or ghl_media_upload_file, relying on the endpoint and name for differentiation.

  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?

  Explicitly states that the body must be multipart/form-data and not JSON, and provides OAuth scopes. However, it lacks guidance on when to use this tool versus alternatives 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.

• ghl_media_list_filesA
  3.6/5.0
  Behavior4/5

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

  Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint false) already indicate safe read operation. Description adds value by mentioning pagination with offset/limit and OAuth scopes (medias.readonly). This enhances transparency beyond annotations.

  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?

  Description is cluttered with an irrelevant regression check note at the beginning ('Regression check...'), which does not help an AI agent. The core purpose is buried. Should be front-loaded with the main functionality.

  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 10 parameters, 5 required, and no output schema, the description provides endpoint, OAuth scopes, and pagination hint, but lacks explanation of response structure or detailed parameter roles. The regression note wastes space.

  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 all parameters have descriptions. Description mentions pagination params (offset, limit) but does not add meaning beyond what schema provides. No additional clarification for required 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?

  Description clearly states 'Get List of Files/ Folders' and 'Fetches list of files and folders from the media storage'. The verb 'Fetches' and resource 'list of files and folders' are specific, and the tool is distinct from siblings like upload, delete, or update operations.

  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?

  Description implies usage for listing files/folders but does not explicitly state when to use versus alternatives, nor does it provide when-not or alternative tool recommendations. OAuth scopes and pagination notes are helpful but not usage guidance.

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

• ghl_opportunity_remove_followersA
  3.6/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint and idempotentHint. Description adds endpoint details (DELETE) and OAuth scopes, clarifying its destructive nature. No contradiction with annotations.

  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?

  Very concise with no wasted words. Front-loaded with purpose. Could benefit from structuring but is efficient 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?

  Covers purpose, endpoint, and auth. Lacks details on return value (expected behavior), permanence of removal, or relationship to followers. Adequate given low complexity but could be 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?

  Schema coverage is 100% with descriptions for all parameters (id, body, isRemoveAllFollowers). Description adds no additional meaning beyond what the schema already provides, so baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('removal of one or all followers') and the target resource ('opportunity'). It distinguishes from sibling tools like ghl_contact_remove_followers by specifying 'opportunity'.

  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 (e.g., ghl_opportunity_add_followers, ghl_opportunity_update). Missing prerequisites 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.

• ghl_opportunity_updateA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and idempotentHint=true. The description adds OAuth scopes and verifies the body against a DTO, but does not disclose the return format (e.g., updated opportunity object or success message), effects of missing fields, or error scenarios.

  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 reasonably concise, containing two paragraphs with key information. However, the first paragraph is a run-on list of fields that could be more structured. No unnecessary fluff.

  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 no output schema and complex nested parameters, the description lacks information about the response format or success indicators. The agent cannot infer what the tool returns upon update. The endpoint and OAuth scopes are helpful but not 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?

  With 100% schema coverage, the description mainly re-lists fields already described in the schema. It adds minimal semantic value beyond confirming the fields are 'verified present' against a DTO, which is not critical for agent understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Update Opportunity' and lists the specific fields that can be updated (pipelineId, name, pipelineStageId, etc.), making the tool's purpose unmistakable. It also provides the endpoint and HTTP method, reinforcing the update action.

  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 for updating existing opportunities but does not explicitly differentiate from sibling tools like ghl_opportunity_create or ghl_opportunity_upsert. No guidance on prerequisites (e.g., opportunity must exist) or when not to use this tool is provided.

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

• ghl_payment_coupon_createA
  3.6/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with creation. The description adds OAuth scopes and endpoint details, but does not disclose failure modes, idempotency limitations, or side effects beyond creation. Adequate but not thorough.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and includes endpoint and OAuth scopes. It is front-loaded with the title and a clear explanation. However, it is slightly redundant (title repeated) and could be tightened by removing minor fluff. Still efficient overall.

  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 a complex input schema with nested objects, but the description does not explain the return value or error conditions. For a creation tool, it would be helpful to mention what is returned (e.g., created coupon ID). Lacks completeness for full agent guidance.

  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 schema already documents all parameters. The description mentions 'discount amount, validity period, usage limits, and applicable products' but adds no new meaning beyond what is in the schema. 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 creates a new promotional coupon, which is a specific verb+resource combination. It inherently distinguishes from sibling tools like ghl_payment_coupon_delete/get/list/update by focusing on creation. No vague language.

  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 advises using the endpoint to set up promotional offers and discounts, which provides general context. However, it does not specify when to avoid using this tool or mention alternatives (e.g., when to use update instead). No explicit exclusion criteria.

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

• ghl_payment_custom_provider_create_configA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description's 'create' is consistent. It adds endpoint and OAuth scopes but does not disclose idempotency, error behavior, or side effects beyond basic mutation.

  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 concise with three lines, front-loaded with the purpose. It efficiently includes endpoint and OAuth scopes, but could be slightly more structured or include a brief note on the config's 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?

  Given no output schema, the description lacks information about the response format or what is returned. It covers the basic purpose and input, but omits details like the created config ID or any prerequisite steps, making it minimally viable.

  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 all parameters described in the schema. The description adds no extra meaning beyond reiterating 'for given location'; it does not clarify the nested structure or relationships between 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 'Create new provider config' and specifies it creates a payment config for a given location. The tool name includes 'config', distinguishing it from sibling 'ghl_payment_custom_provider_create', which likely creates the provider itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for creating a payment config for a specific location but does not provide explicit guidance on when to use this tool versus alternatives like update or get config, nor does it mention 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.

• ghl_product_bulk_editA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate write operation (readOnlyHint false) and non-idempotent. The description adds the 'max 30 entities' constraint and urges caution, but does not disclose failure behavior, atomicity, or side effects beyond editing. No contradiction with annotations.

  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 concise with two main sentences plus endpoint info, but includes a redundant title phrase ('Bulk Edit Products and Prices'). It is front-loaded with the key action and constraint.

  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 complex bulk operation with nested objects and no output schema, the description covers max entities and endpoint but lacks details on return values, error handling, or success criteria. The caution about scope is helpful 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 100% (all parameters have descriptions). The tool description does not provide additional meaning beyond what is already in the schema (e.g., altId, altType, products). 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 states it performs bulk edits on multiple products and their prices, with a max of 30 entities. This differentiates it from single product tools (ghl_product_update, ghl_product_create) and sibling bulk tools (ghl_product_bulk_update) by specifying the scope and adding a caution about target scope.

  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 warns to 'review the target scope carefully' and notes a max of 30 entities, but does not explicitly compare with alternative tools (e.g., ghl_product_bulk_update, ghl_product_update). It lacks when-to-use vs when-not-to-use guidance for an agent to choose optimally among siblings.

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

• ghl_product_inventory_listA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the tool is clearly safe. The description adds OAuth scopes and endpoint details but does not disclose rate limits, error handling, or response behavior beyond what annotations imply.

  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 short with three clearly separated sections: a title, a purpose paragraph, and endpoint/scopes. It is efficient with no wasted words, though it could benefit from a bullet-style structure for the endpoint details.

  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 covers pagination and OAuth scopes, but lacks information about the response format, error handling, or rate limits. Given the absence of an output schema, the description could be more complete to guide the agent on expected return data.

  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?

  With 80% schema description coverage, the schema already documents most parameters. The description only generically mentions 'query parameters' without adding specific details about altId, search, or pagination behavior, so it provides minimal added 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?

  The description clearly states 'retrieve a paginated list of inventory items', which is a specific verb-resource combination. The tool name and description distinguish it from sibling tools like 'ghl_product_list' (lists products) and 'ghl_product_inventory_update' (updates 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 says to use this endpoint to fetch details for multiple items based on query parameters, and mentions pagination. However, it does not explicitly state when not to use it or provide alternatives for single-item retrieval, leaving usage guidance implied.

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

• ghl_product_review_updateA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true, which the description does not contradict. The description adds endpoint details and OAuth scopes but does not elaborate on behavioral aspects like side effects or response behavior. It is adequate but not enhanced beyond annotations.

  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 concise at four lines, front-loading the purpose and then providing endpoint and scope info. No fluff, but it could be slightly more structured (e.g., bullet points) for readability.

  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 nested objects in the input schema and no output schema, the description covers the high-level purpose and technical details (endpoint, scopes) but does not explain the response or any side effects. It is adequate but lacks full context for a complex nested input.

  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 parameter details are already fully documented in the schema. The description mentions 'status, reply, etc.' but adds minimal extra meaning beyond the schema's property 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 verb 'Update' and the resource 'Product Reviews', and explicitly lists what can be updated (status, reply, etc.). It is distinct from sibling tools like ghl_product_review_delete or ghl_product_review_list.

  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 guidance on when to use this tool versus alternatives such as ghl_product_review_bulk_update or ghl_product_review_delete. Usage is implied by the description ('update a particular review'), but no exclusions or comparisons are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_product_store_set_inclusionA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false, so it's a write operation. The description aligns with this but does not disclose side effects, idempotency, or behavior on existing state. Given annotations are present, the description adds endpoint and scopes but no deeper 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded with the key action. It contains a slight redundancy ('Action to include/exclude the product in store' repeats the first sentence) but overall is efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter tool with an object body, the description provides the main purpose and endpoint. It does not explain the body structure (covered by schema) or return values. Given no output schema, it is adequate but could include a usage example or note on error conditions.

  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 schema already documents all parameters. The description does not add significant meaning beyond what is in the schema (e.g., it repeats action enum but does not explain altId, altType, or productIds further). 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 action: includes or excludes a product from a store's storefront listing. It specifies the verb (include/exclude) and the resource (product in store listing), and it distinguishes from sibling tools like product creation or 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 mentions the action parameter and OAuth scopes but does not explicitly state when to use this tool versus alternatives (e.g., ghl_product_store_set_priority) or when not to use it. The usage context is implied but lacks direct guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_allow_attach_rebillingA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses state-changing behavior (sets payment_pending, optionally stores config) and preconditions. No contradiction with annotations (readOnlyHint=false, destructiveHint=false). Adds context beyond annotations.

  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?

  Well-structured with key information front-loaded: auth requirement, action, preconditions, and endpoint. Minor redundancy with title repeated, but overall efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers security, precondition, action, and endpoint, but lacks return value or error information. No output schema, so description could better specify expected outcomes.

  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 descriptions for all parameters. Description provides overall context but does not significantly add new semantic meaning beyond what the schema already explains.

  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?

  Clearly states the tool marks a SaaS sub-account as awaiting rebilling attach and optionally stores rebilling configuration. Distinguishes from sibling tools by being specific to this action, though not explicitly contrasted with similar tools like ghl_saas_update_rebilling.

  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?

  Provides a precondition (sub-account must be in setup_pending state) and authentication requirement (agency-level token). However, lacks guidance on when not to use this tool or alternatives to consider.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_bulk_enableA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds security context beyond annotations (agency token required). Annotations indicate non-read-only and non-destructive, which align with 'enable'. No further behavioral details like idempotency 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Concise at three sentences, front-loading the critical security requirement. Could be slightly more structured but is efficiently scoped.

  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 bulk operation with nested body and no output schema, the description lacks details about actionPayload, version differences, return values, and error cases. Incomplete for the tool's 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?

  The description does not explain any parameters; the schema covers body properties but companyId is undocumented. Schema description coverage is 50%, and the description fails to compensate, especially for the missing companyId 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 clearly states 'Enable SaaS mode for multiple locations with support for both SaaS v1 and v2', using a specific verb and resource. It distinguishes from siblings like *bulk_disable* and *enable_location*.

  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?

  Explicitly warns 'REQUIRES AN AGENCY-LEVEL (Company) TOKEN — spec security is Agency-Access-Only', guiding token choice. Lacks explicit when-not or alternatives, but sibling names imply single location enable/disable alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_get_agency_plansA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value by explicitly stating the security requirement ('REQUIRES AN AGENCY-LEVEL (Company) TOKEN') and clearly describing the action as fetching plans. No contradiction with annotations.

  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 reasonably concise, with a front-loaded security note that is important for correct usage. It contains no redundant sentences, but the inclusion of the full endpoint URL may be unnecessary for an AI agent and could be considered slightly 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?

  Given the complexity (many sibling tools, 100+ tools) and the absence of an output schema, the description is somewhat minimal. It does not explain what agency subscription plans are, what the return format looks like, or how the result can be used. The security note and endpoint info are helpful but could be expanded with more behavioral 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 has one required parameter 'companyId' (string) with 0% description coverage. The description adds meaning by stating 'for a given company ID', confirming the parameter's role. However, it does not provide additional details like format, constraints, or examples, which would have been beneficial given the lack of schema descriptions.

  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 states 'Fetch all agency subscription plans for a given company ID', using a specific verb ('Fetch') and resource ('agency subscription plans'). It clearly identifies the tool's function. However, it does not explicitly differentiate from similar sibling tools like 'ghl_saas_get_plan' or 'ghl_saas_get_location_subscription', which would have been helpful for disambiguation.

  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 a key usage prerequisite: it requires an agency-level token. It also gives the endpoint and version. However, it does not guide on when to use this tool versus alternatives (e.g., when to use 'get_agency_plans' vs 'get_plan'). No explicit when-not or alternative tools are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_get_planA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark readOnlyHint=true. Description adds GET endpoint and agency-token requirement, providing valuable behavioral context beyond annotations.

  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?

  Description is relatively concise but slightly cluttered with endpoint details mixed with purpose; still front-loaded with critical token warning.

  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 and no parameter descriptions; missing response format, pagination, or additional context beyond token requirement.

  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 description does not explain required parameters 'planId' or 'companyId', failing to add meaning beyond the bare 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?

  Description clearly states verb 'Fetch' and resource 'SaaS plan by plan ID', distinguishing it from siblings like ghl_saas_get_agency_plans (list all plans) and deprecated versions.

  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 explicit token requirement ('REQUIRES AN AGENCY-LEVEL TOKEN') indicating when to use, but lacks when-not or alternatives to siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_pause_locationA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds the security requirement but does not explain the effects of pausing (e.g., whether it can be reversed) or side effects. No contradiction with annotations.

  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?

  Three sentences, front-loaded with critical security info. Slightly redundant ('Pause location' and 'Pause Sub account') but overall 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?

  No output schema; description does not mention return values, reversibility, or how to resume. The openWorldHint indicates possible undocumented side effects. Missing important context for a state-changing 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 50% (only body nested properties have descriptions; locationId lacks description). The tool description does not add any parameter semantics or explain the meaning of the 'paused' field or companyId.

  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 'Pause' and the resource 'Sub account / location', distinguishing it from sibling tools like ghl_saas_enable_location. The endpoint and action 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly requires an agency-level token, providing a key usage constraint. However, it does not contrast with alternatives (e.g., deprecated version, enable) or specify 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.

• ghl_snapshot_get_pushes_between_datesA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond annotations by specifying the token requirement (Agency-Access-Only) and noting that 'from'/'to'/'lastDoc' are required despite generic names. It also provides the endpoint and version header. Annotations already include readOnlyHint and idempotentHint, so the description complements them with authorization context.

  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 moderately concise but contains redundant phrasing (e.g., the title sentence repeated). It front-loads the critical token requirement in all caps, which is good, but could be streamlined. The structure is acceptable but not optimized for quick scanning.

  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 an output schema and 6 parameters (5 required), the description lacks explanation of the response format, error handling, or detailed pagination mechanics. It states 'Pagination params: limit — pass them to page through full result sets' but does not describe the structure of the returned list or cursor usage, leaving the agent with incomplete 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 description coverage is 67% (4 of 6 parameters have descriptions). The description adds marginal value by reiterating that 'from'/'to'/'lastDoc' are required query params and mentioning pagination via 'limit'. However, it does not explain 'companyId' or 'snapshotId' beyond the schema, and the schema already provides examples and format for 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 clearly states the tool's action: 'Get list of sub-accounts snapshot pushed in time period', with a specific verb ('Get') and resource ('sub-accounts snapshot pushed in time period'). It distinguishes from siblings like 'ghl_snapshot_get_latest_push' and 'ghl_snapshot_list' by emphasizing the date range aspect.

  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 mentions the agency-level token requirement and that 'from'/'to'/'lastDoc' are required query params, implying usage for date-range queries. However, it does not explicitly state when to use this tool versus alternatives like 'ghl_snapshot_get_latest_push' or 'ghl_snapshot_list', nor does it provide 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.

• ghl_social_delete_current_active_post_and_schedule_nextA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include destructiveHint=true, making the destructive behavior explicit. The description adds the auto-scheduling behavior and endpoint details (OAuth scopes, version). No contradictions, but could disclose more about failure scenarios or queue empty case.

  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?

  Three sentences: one states purpose, one explains behavior, one gives endpoint and scopes. No fluff, but the endpoint info could be better integrated. Front-loaded with the action.

  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 and description does not explain response behavior, error handling, or how to get the required postId. For a tool that both deletes and schedules, more detail 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?

  50% schema coverage: locationId has a description, postId does not. The description only mentions postId in the endpoint path but does not explain its meaning or how to obtain it. Schema already documents locationId, so value added is minimal.

  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 tool name and description clearly state the action (delete active post) and secondary action (schedule next). It distinguishes from siblings like ghl_social_delete_post which only deletes without scheduling.

  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 explains the tool's effect (delete scheduled active post and auto-trigger next scheduling). It implies context but lacks explicit when-not or alternative tool guidance. Given siblings that handle other deletion scenarios, the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_discard_edit_sessionA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond annotations by specifying that it deletes all staged changes without affecting the live queue. Annotation readOnlyHint=false is consistent, and destructiveHint=false is somewhat clarified by the 'without affecting the live queue' safety note. OAuth scopes are also included.

  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 sentences plus endpoint and OAuth details. It is front-loaded with the main action and wastes no 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 covers the core action but lacks details on prerequisites (e.g., needing an active edit session), return value or success/error indicators, and potential side effects. For a 2-parameter tool with nested objects, more context would be beneficial.

  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 coverage is only 50%, with queueId undocumented. The tool description does not explain any parameters; it relies entirely on the schema. While the schema partially describes body properties, the description adds no further clarification for 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 purpose: 'Discard edit session changes' and 'Cancels the edit session and deletes all staged changes without affecting the live queue.' It uses a specific verb and resource, and distinguishes itself from sibling tools like save_edit_session by emphasizing it does not affect the live queue.

  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 versus alternatives like saving the edit session. It lacks explicit context for the user to choose between discard and other related actions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_fetch_calendar_listA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations exist but don't fully clarify read-only behavior (readOnlyHint=false though it's a read operation). The description adds endpoint and OAuth scopes but doesn't disclose potential side effects or behaviors beyond the obvious fetch 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 concise with three sentences covering purpose, return, filtering, endpoint, and scopes. It is front-loaded but could be slightly more compact.

  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 explains what is returned (scheduled posts) and filtering options, but lacks details on pagination, response format, or how calendar view is structured. Given no output schema, more context would be helpful.

  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 schema already documents parameters well. The description adds minimal extra meaning beyond restating 'date range' and 'filtering by categories and accounts'. 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 it 'Get scheduled posts calendar view' and explains it returns scheduled posts from active queues within a date range, with filtering by categories and accounts. This is specific and distinguishes from sibling tools like ghl_social_get_posts or ghl_social_fetch_queues.

  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 a calendar view of scheduled posts but provides no explicit guidance on when to use this tool over alternatives. No when-not-to-use or sibling comparisons are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_fetch_queue_by_idA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is clear. The description adds behavioral context by noting that the response includes a count of posts with errors, which is beyond what annotations provide.

  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 relatively concise, with three sentences covering purpose, response details, and endpoint. It front-loads the purpose but includes endpoint and scopes which, while useful, add length. Overall 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?

  For a simple retrieval with two parameters and no output schema, the description provides enough context: it explains what is fetched, mentions the error count in the response, and specifies the endpoint. It is adequate for decision-making.

  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% (only locationId has a description). The tool description does not add any parameter meanings beyond the schema; it does not explain queueId or provide examples for it. It fails to compensate for the missing parameter 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 'Fetch a category queue by ID' and 'Retrieves the details of a single category queue by its unique ID,' which is a specific verb-resource pair. It distinguishes from sibling tools like ghl_social_fetch_queues (list) and ghl_social_create_queue (create).

  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 when-not-to-use, prerequisites, or comparisons with other queue-related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_store_list_shipping_ratesA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds pagination behavior and endpoint details, but does not cover potential issues like rate limits, default page size, or data filtering. It adds some value beyond annotations but not extensive.

  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 three sentences plus a title. It is mostly concise, though the endpoint details are technical but not overly verbose. Could be slightly tighter but still efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 5 parameters, 3 required, 80% schema coverage, and no output schema, the description covers the main purpose and pagination. However, it does not explain the expected return structure or data fields, which would be helpful for an agent without an 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?

  Schema description coverage is 80%, so most parameters are already documented. The description adds context for pagination parameters ('pass them to page through full result sets'), but does not elaborate on altId, altType, or shippingZoneId beyond what 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 the tool lists shipping rates for a specific shipping zone, with verb 'retrieve a list of shipping rate'. It distinguishes from sibling tools like 'get_shipping_rate' (single) and 'get_available_shipping_rates' (different function).

  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 mentions pagination usage but does not provide explicit guidance on when to use this tool versus alternatives like ghl_store_get_shipping_rate or ghl_store_get_available_shipping_rates. Usage context is implied but not directly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_store_list_shipping_zonesA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. Description adds pagination behavior and endpoint info, but no additional behavioral traits beyond annotations.

  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?

  Description is short, front-loaded with purpose, and includes endpoint and pagination info efficiently. Minor grammatical awkwardness but no wasted 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?

  Covers purpose, pagination, and endpoint. Missing mention of `withShippingRate` parameter and sorting/filtering. Adequate for a simple list tool with 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?

  Schema coverage is 80% with descriptions for most params. Description mentions pagination (limit, offset) but adds little beyond schema. 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 title and description clearly state the tool lists shipping zones. The sibling `ghl_store_get_shipping_zone` retrieves a single zone, distinguishing this list tool.

  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 mentions pagination (limit, offset) but does not explicitly contrast with sibling tools like create, update, or delete, nor state 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.

• ghl_voice_ai_get_agentA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnly, idempotent, non-destructive. The description adds endpoint and OAuth scopes, but doesn't reveal additional behavioral traits beyond what's annotated.

  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?

  Short and direct, but includes redundant title line. Efficient overall, no wasted sentences.

  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?

  No output schema, so description should hint at return structure. It only says 'detailed configuration and settings', which is vague. Parameter coverage is complete, but output context is lacking.

  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 has 100% coverage with descriptions for both parameters. The description doesn't add extra meaning 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 the verb 'Retrieve' and the resource 'detailed configuration and settings for a specific voice AI agent', distinguishing it from siblings like list, create, delete, etc.

  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 as a simple GET for an agent's details, but no explicit when-to-use or alternative guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_voice_ai_patch_agentA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false and destructiveHint=false, so description adds value by specifying the HTTP method (PATCH) and OAuth scopes (write). However, it does not disclose potential side effects, error behavior, or that omitted fields are unchanged (implied by PATCH). Additional context like reversibility 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is short and front-loaded with the purpose. It includes essential technical details (endpoint, version, OAuth) without fluff. Could be slightly more streamlined by omitting redundant source file, but it remains efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a PATCH operation with a complex nested body and no output schema, the description does not mention response format, error conditions, or prerequisites (e.g., agent existence). The openWorldHint annotation is not elaborated upon. Completeness is adequate for a basic understanding but lacks depth.

  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 in the input schema is well-documented with defaults, rules, and constraints. The tool description adds minimal parameter value beyond the schema, meeting the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Title 'Patch Agent' and description 'Partially update an existing voice AI agent' clearly state the verb (partially update) and resource (existing voice AI agent). Distinguishes from sibling tools like create, delete, get, and list.

  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?

  Description includes endpoint, version header, and OAuth scopes but does not explicitly state when to use this tool versus create or update alternatives. The term 'partially update' implies usage context, but no when-not-to-use or alternative recommendations are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_voice_ai_update_actionA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate idempotent and non-destructive mutation. The description adds minimal behavioral context beyond restating the update nature. No additional traits like error handling or prerequisites are 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 extremely concise (two sentences) and front-loaded with the key action. No redundant or wasted words; every sentence 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?

  Despite high complexity (nested oneOf body with many action types), the description is minimal. It does not help the agent understand the overall structure or that the body varies by actionType. No output schema or additional context provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed parameter descriptions. The description does not add additional meaning beyond what the schema already provides; 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 tool updates an existing voice AI agent action, with a specific verb and resource. It distinguishes from sibling tools like create, delete, and get actions.

  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 guidance on when to use this tool versus alternatives. The name and context imply it's for updating existing actions, but the description lacks when-not-to-use or alternative tool references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_audience_deleteA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description provides the endpoint URL and OAuth scopes, adding context beyond the annotations (destructiveHint, idempotentHint). It clearly indicates the destructive nature and that it's idempotent, but does not detail side effects beyond deletion.

  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 core action, followed by endpoint and auth details. No redundant information; every sentence adds value.

  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 covers what the tool does, the endpoint, and auth scopes, but lacks error conditions, prerequisites (e.g., need for Facebook integration), or return values. Adequate for a simple delete operation but not fully 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?

  Schema coverage is 100%, so baseline is 3. The description does not add additional parameter semantics beyond what is already in the schema fields.

  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 'Delete a Facebook custom audience by ID', specifying the verb (delete) and resource (Facebook custom audience). It distinguishes itself from sibling tools like ghl_ad_fb_audience_get and ghl_ad_fb_audience_list by focusing on deletion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives such as other delete tools or non-delete audience operations. It does not mention prerequisites 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.

• ghl_ad_fb_campaign_reporting_getA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false. The description adds the OAuth scope 'adPublishing.readonly' and the endpoint details, which are useful but not critical behavioral traits. It does not disclose error handling, data freshness, or pagination behavior. No contradiction with 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 extremely concise and well-structured. It starts with the action ('Get campaign reporting'), provides a clear one-line explanation, and then lists the endpoint and OAuth scopes. 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the high schema coverage (100%) and no output schema, the description adequately specifies inputs but fails to explain what reporting metrics are returned (e.g., impressions, clicks, spend). This omission leaves the agent uncertain about the tool's output, which is important for a reporting endpoint.

  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 descriptions and examples, providing 100% coverage. The description does not add any additional meaning or context for the parameters beyond what the schema already provides, so the baseline score 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 tool's purpose: 'Get campaign reporting' and 'Retrieve reporting metrics for a specific Facebook campaign'. The verb 'Retrieve' and resource 'reporting metrics for a specific Facebook campaign' are specific and distinct from sibling tools like ghl_ad_fb_campaign_get (which gets campaign details) and ghl_ad_fb_reporting_get (which is likely for broader Facebook reporting).

  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 by specifying 'for a specific Facebook campaign', but it does not explicitly guide when to use this tool versus alternatives (e.g., ghl_ad_fb_reporting_get, ghl_ad_google_campaign_reporting_get, or reporting for ad sets). No exclusions or alternative mentions are provided, leaving the agent to infer from the name and endpoint.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_reporting_listA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint, idempotentHint, etc. The description adds endpoint and OAuth scopes, but these are standard and not critical for behavioral understanding. No disclosure of additional traits beyond annotations.

  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?

  Description is concise with 4 lines covering purpose, endpoint, and OAuth scopes. It is front-loaded with the purpose. Minor improvement could be a more structured format separating purpose from technical details.

  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 schema coverage and annotations, the description is adequate. However, no output schema is provided, and while the tool returns a list, the exact fields are not mentioned. Still, the context is sufficient for most usage 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?

  Input schema has 100% coverage with parameter descriptions, so the description adds minimal extra meaning. It restates that it returns a list, but that is inferred 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 it retrieves a list of Facebook campaigns, adsets, or ads with reporting data, using a specific verb and resource. It distinguishes itself from siblings like ghl_ad_fb_reporting_get which likely returns a single report.

  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 guidance on when to use this tool versus alternatives such as ghl_ad_fb_reporting_get or other list tools. The usage is implied by the type of list, but no exclusions or preferences are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_google_account_deleteA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds OAuth scope (adPublishing.write) and endpoint info but does not elaborate on behavioral impacts (e.g., irreversibility, cascade effects). No contradictions with 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 extremely concise: a title, a one-sentence purpose, and necessary technical details (endpoint, version, OAuth scopes). No unnecessary words; every sentence adds value.

  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 delete tool with two parameters and no output schema, the description provides the essential purpose and technical details. However, it lacks context on prerequisites, consequences, or typical use cases, making it adequate but not thorough.

  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 descriptions for both parameters. The tool description adds no additional parameter context or usage tips beyond what the schema already provides. 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?

  Title and description clearly state the action (delete/remove) and resource (Google Ads account connection from a location). The naming 'ghl_ad_google_account_delete' and sibling tools (e.g., ghl_ad_google_account_get) make the purpose unambiguous and distinct.

  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 mentions OAuth scopes and endpoint details but does not explicitly state when to use this tool versus alternatives like get or list. No prerequisites or exclusions are provided. It is adequate but lacks direct guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_google_account_getA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, destructiveHint false, so safety is clear. Description adds endpoint URL and OAuth scopes (adPublishing.readonly), which provides additional behavioral context beyond annotations. No contradictions.

  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?

  Description is short (two sentences plus endpoint info) and front-loaded. However, the first two sentences are slightly redundant ('Get ad account details' and 'Retrieve details...'). Still concise overall.

  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, the description provides endpoint, OAuth scopes, and parameter context (via schema). No output schema, but return behavior is implied. Could mention what fields are returned, but not critical. Complete enough.

  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 descriptions for all three parameters. The tool description does not add any additional meaning or constraints beyond what is already in the input schema. 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?

  Description clearly states 'Get ad account details' and 'Retrieve details of a specific Google Ads account'. Verb+resource is precise. Distinguishes from siblings like ghl_ad_google_account_list (list) and ghl_ad_google_account_delete (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?

  Description implies usage through the verb 'get' and specifying 'specific', but does not explicitly state when to use this vs. list or other alternatives. No when-not-to-use guidance. Adequate but lacking explicit context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_google_asset_upsertA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate mutability (readOnlyHint false). Description adds useful behavioral context: the specific endpoint (POST /ad-publishing/google/assets) and required OAuth scope (adPublishing.write). No contradictions with 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?

  Extremely concise: three lines covering title, purpose, endpoint, and scopes. No filler, front-loaded with key info.

  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?

  Adequate given rich schema and annotations. Lacks mention of asset types (CALL, SITELINK, LEAD_FORM) and dynamic payload shape, but schema covers that. No output schema, but description doesn't explain 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 baseline is 3. Description does not add extra meaning beyond what the schema provides. The body parameter and its nested structure are fully defined 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?

  Clearly states the tool does an upsert of Google Ads creative assets, using specific verbs 'Create or update'. Distinguishes from sibling tools like list (ghl_ad_google_asset_list) and other upsert tools (ghl_ad_google_audience_upsert).

  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 vs alternatives (e.g., when to use ghl_ad_google_asset_list instead). No scenarios or exclusions mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_google_conversion_getA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds endpoint details, version, and OAuth scopes, but does not disclose additional behavioral traits beyond annotations. No contradiction.

  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?

  Description is concise with four lines including endpoint, version, source, and OAuth scopes. Every sentence provides value, and the structure is clear.

  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 no output schema, the description does not explain the return structure. It adequately describes the input but lacks details on what the response contains. For a simple get tool, it is minimally complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for all three parameters. The description does not add meaning beyond what the schema provides. Baseline 3 for high 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 'Get conversion by ID' and 'Retrieve a specific Google Ads conversion action by ID', specifying the verb (get) and resource (conversion), distinguishing it from siblings like list or upsert.

  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 does not explicitly state when to use this tool versus alternatives like ghl_ad_google_conversion_list or ghl_ad_google_conversion_upsert. Usage is implied (when you have a specific ID), but no explicit guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_li_account_listA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, and non-destructive. Description adds endpoint, version header, and OAuth scopes, giving useful behavioral context without contradicting 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?

  Very concise: two lines for purpose plus additional technical details. Front-loaded and 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?

  Lacks return type or output format details, which would be helpful for a list tool. However, with readOnlyHint and openWorldHint, the behavioral risk is low, and parameters are fully described in 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?

  Schema covers both parameters (locationId, isDraft) with descriptions. Description adds no extra parameter info, so baseline 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?

  Description clearly states 'Get LinkedIn ad accounts' and 'Retrieve LinkedIn Ads accounts available for the connected user'. Purpose is specific and distinguishes from sibling tools like 'get' and 'delete' via the 'list' verb, though not explicitly compared.

  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?

  Implied usage for listing accounts under the connected user, with endpoint and OAuth scopes provided, but no explicit when-to-use or when-not-to-use compared to alternatives like ghl_ad_li_account_get.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_agent_studio_get_by_idA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds value by detailing the return content (metadata and non-deleted versions) and constraints (active status, required locationId). No contradiction with annotations.

  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 concise, front-loaded with the title, and includes necessary details like endpoint and OAuth scopes. However, it could be slightly more focused on behavioral aspects rather than technical endpoint info.

  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 no output schema, the description adequately mentions the return content (metadata and versions). However, it lacks details on error conditions, response size limits, or parameter formats, leaving some gaps for a complete understanding.

  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 explains that locationId is required and agentId is the agent ID, but does not describe the 'source' parameter. This is insufficient for full parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets a specific agent by ID for a specified location, returning all versions. It distinguishes from siblings like list or delete by specifying the exact resource and action.

  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 a single agent but does not explicitly state when to use this tool versus alternatives like list or execute. It provides context on required parameters and active status but lacks explicit exclusions or alternative tool names.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_blog_update_postA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds endpoint and OAuth info but does not disclose behavioral traits beyond annotations, such as immutability of certain fields 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description includes unnecessary technical details (version header, source) that could be omitted. It is not as concise as it could be, but it front-loads 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?

  The tool is complex with nested body and many required fields, but no output schema. The description lacks info on partial updates, idempotency behavior, or error responses. Annotations and schema partially compensate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so description adds marginal value. However, it includes helpful hints about author and categories needing IDs from other APIs, which goes beyond schema examples.

  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 updates a blog post and provides the endpoint and OAuth scope. It distinguishes from sibling tools like ghl_blog_post_create and ghl_blog_post_list.

  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 technical details but does not explicitly state when to use this tool versus alternatives like create or delete. No guidance on 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.

• ghl_brand_board_list_voicesA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, etc., covering safety. Description adds endpoint and pagination details but no extra behavioral traits (e.g., rate limits, auth, or data freshness). OpenWorldHint is not explained.

  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?

  Three short sentences covering title, action, endpoint, and pagination. However, the first line repeats the title already available. Could be tightened slightly, but overall efficient and front-loaded.

  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 no output schema, the description explains how to retrieve all results via pagination. Missing details like default sorting or response structure, but annotations and schema compensate. Mostly complete 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 coverage is 100% with each parameter described. Description adds context that limit/offset are used for pagination, but does not enhance meaning beyond schema. For full schema coverage, 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?

  Title 'List Brand Voices' and description 'Get list of brand voices for a location' clearly state the verb (list/get) and resource (brand voices scoped by location). Distinguishes from sibling tools like ghl_brand_board_get_voice (single) and ghl_brand_board_create_voice (create).

  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?

  Description mentions pagination with limit/offset but does not explicitly state when to use this tool vs alternatives (e.g., get_voice for a specific voice). No direct guidance on when not to use or preference over siblings. Agent must infer from tool names.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_event_deleteA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructive and idempotent hints. Description adds no extra behavioral context (e.g., permanence, effects on related data).

  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?

  First sentence is clear, but subsequent lines are redundant (repeats 'Delete Event') and include technical endpoint/scopes that clutter the description.

  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?

  Covers purpose, alternatives, and auth scopes, but does not explain expected response or clarify the ambiguous body parameter, 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 coverage is 100% with descriptions. Description restates eventId purpose but adds no clarity on the empty body 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?

  Clearly states it deletes any calendar event (appointment or block-slot) by ID, distinguishing from type-specific siblings for create/get/update.

  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?

  Explicitly references sibling tools for type-specific operations, providing clear guidance on when to use this tool vs alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_resource_updateA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate non-read-only and non-destructive behavior. The description adds value by stating the required OAuth scopes (calendars/resources.write), the specific endpoint, and the deprecation status. No contradiction with annotations.

  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 verbose and mixes version info, deprecation warnings, endpoint details, and OAuth scopes before stating the core purpose. The main action ('Update Calendar Resource') is buried in the middle. A more concise, front-loaded structure would improve clarity.

  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 lacks information about the response or return value, which is important given there is no output schema. It does include deprecation and version context, but for a mutation tool, details on what the update returns (e.g., updated resource object) 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 has 100% coverage with descriptions for all three parameters (id, resourceType, body). The description does not add additional parameter-level details beyond what the schema provides, 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 states 'Update Calendar Resource' and 'Update calendar resource by ID', making the verb and resource explicit. It distinguishes from sibling operations (create, get, list, delete) by specifying 'update'.

  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 useful usage context: it notes the API version (2021-04-15), warns against using the deprecated v3 version for resource endpoints, and explicitly states the tool is deprecated with a suggestion to prefer a replacement if one exists. However, it does not explicitly contrast with sibling update tools or specify when-not-to-use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_schedule_listA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description aligns with annotations (readOnlyHint=true) and adds behavioral context: it uses a search endpoint (GET /calendars/schedules/search), OAuth scopes (calendars.readonly), and supports pagination. These details go beyond the annotations' metadata.

  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 short and to the point, with a clear first sentence followed by additional details. It could be more structured (e.g., bullet points for filters and pagination), but it is not verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description lacks information about the response structure (e.g., return format, pagination metadata). Since there is no output schema, the description should hint at what the agent can expect from the tool. This is a notable gap.

  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 parameter descriptions. The description adds minimal value by mentioning pagination params (skip, limit) and summarizing filters, but does not elaborate on parameter format or behavior 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 verb 'list' and resource 'user availability schedule'. It distinguishes from siblings like ghl_calendar_schedule_get via the 'list' semantics and explicit mention of filters (location, calendar, user).

  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?

  While the description explains what the tool does and supports pagination, it does not explicitly state when to use this tool vs alternatives (e.g., ghl_calendar_schedule_get) or provide exclusion criteria. Usage context is implied by the name and filters but not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_contact_remove_followersA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide destructiveHint=true and idempotentHint=true. The description adds OAuth scopes (contacts/write) and HTTP method (DELETE), which are useful behavioral details beyond the annotations. No contradiction.

  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 minimal and to the point, with no redundant information. It is efficient, though the endpoint details could be formatted more readably.

  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 an output schema, the description should mention what the response looks like (e.g., success/error indication). It also lacks context about side effects or typical use cases, making it incomplete for a simple destructive 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?

  Schema coverage is 100% with descriptions for both parameters. The description does not add any additional meaning beyond what is already in the schema, so baseline score 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 'Remove Followers' and includes endpoint details. The tool name and description unambiguously indicate the action (removing followers from a contact) and distinguish it from its sibling 'ghl_contact_add_followers'.

  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 guidance on when to use this tool versus alternatives like 'ghl_contact_add_followers' or 'ghl_opportunity_remove_followers'. The description lacks context about when removal is appropriate or any prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_contact_updateA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds that tags are overwritten (a partial destructive behavior) and lists confirmed fields. However, it does not clarify whether the update is partial or full replacement, nor does it describe the return value or error conditions. Given no output schema, this is a moderate gap.

  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 front-loaded with a regression verification note that may be more relevant to developers than AI agents. It contains multiple details (regression, endpoint, OAuth scopes) but could be more concise. The structure is logical but wastes some characters on metadata.

  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 complexity of the input schema (nested objects like dndSettings, customFields) and no output schema, the description provides critical tag behavior but lacks details on return values, error handling, and whether other fields are partially updated. Schema descriptions compensate, but the description alone is not 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?

  Input schema has 100% coverage with descriptions for every property. The description does not add significant parameter semantics beyond the schema, except for the note about tags overwriting. Given high schema coverage, a 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 'Update Contact. Update a contact using contactId.' and specifies the HTTP method (PUT) and endpoint. It distinguishes from sibling tools by explicitly noting that the 'tags' field overwrites the full tag list, contrasting with incremental tag updates via ghl_contact_add_tags and ghl_contact_remove_tags.

  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 guidance on when to use this tool versus alternatives for tag management, directing to separate tools for incremental changes. It also mentions OAuth scopes (contacts.write) for authorization context. However, it does not specify when to use this tool over other contact update methods like ghl_contact_upsert.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_ai_get_generationA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value by listing exactly what data is retrieved (System Prompt, FAQ chunks, etc.) and providing the endpoint URL and OAuth scopes, which are beyond the annotations.

  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 mostly concise, listing key facts in a bullet-like format. However, it redundantly repeats the title 'Get the generation details' as the first sentence. The technical details (endpoint, scopes) are useful and appropriately placed.

  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 partially compensates for the lack of output schema by listing the components returned. However, it does not mention error conditions, response format, pagination, or rate limits. Given that it's a read-only retrieval with no output schema, more contextual detail would be beneficial.

  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%: only messageId has a brief description ('Message Id'), and source is defined as an enum without description. The tool description does not elaborate on parameter meaning, usage, or how to determine the correct source value. It adds no extra semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it retrieves 'generation details' and lists specific components (System Prompt, Conversation history, etc.). It is distinct from sibling tools like ghl_conversation_ai_create_agent which create or modify AI agents, not retrieve generation data.

  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 does not explicitly state when to use this tool vs alternatives. While the purpose is clear, there is no guidance on prerequisites or conditions (e.g., when to use this over ghl_conversation_get_message). Implicitly it's for inspecting AI generation internals, 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.

• ghl_custom_field_create_folderA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate a write operation (readOnlyHint false). The description adds OAuth scopes and endpoint URL, but lacks details on side effects, idempotency, or error conditions. For a creation tool, more behavioral context (e.g., what happens if folder exists) would be valuable.

  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 short and front-loaded with the core purpose. However, it includes redundant HTML formatting and a repeat of the title, which could be streamlined. Overall, it is efficient but has minor noise.

  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 does not describe the return value (e.g., folder ID, success indicator). For a creation tool, this is a significant gap. Additionally, it does not explain what a custom field folder is or how it relates to custom fields, leaving the agent without full context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear descriptions for each parameter. The description adds context by noting which objects are supported, which directly clarifies the 'objectKey' parameter's allowed values. This extra guidance goes beyond what the schema alone 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 it creates a custom field folder and specifies supported objects (Custom Objects, Company). The tool name and description differentiate it from sibling tools like ghl_custom_field_create, which creates individual fields, not folders.

  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 supported objects but provides no explicit guidance on when to use this tool versus alternatives (e.g., ghl_custom_field_update_folder, ghl_custom_field_delete_folder). The info note about supported objects is helpful but incomplete for context-aware selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_email_get_campaignA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds endpoint and OAuth scopes, which provide some context but not significant behavioral details beyond 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?

  Description is short, front-loaded with purpose, and includes essential details like endpoint and scopes. No wasted text.

  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?

  No output schema exists, and description does not explain what fields the response contains. For a simple get-by-ID tool, this is adequate but could be 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?

  Input schema has 100% coverage with descriptions and examples for both parameters. The description adds no additional meaning beyond 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 tool retrieves a single email campaign by its ID, using a specific verb and resource. It distinguishes from sibling tools like list and create by focusing on a single entity retrieval.

  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 one campaign by ID but does not explicitly compare with alternatives like list or search tools. Sibling tools exist but no guidance on when to choose this over others.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_estimate_convert_to_invoiceA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds OAuth scopes and endpoint details but does not disclose whether the estimate is automatically marked as invoiced or other 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description repeats the purpose three times ('Creates a new invoice from an accepted/existing estimate', 'Create Invoice from Estimate', 'Create a new invoice from an existing estimate'), making it less concise. It is front-loaded but could be trimmed.

  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 explains the core action and includes endpoint and OAuth scopes, but lacks details about return values, prerequisites (e.g., estimate must be accepted), and behavior of the 'markAsInvoiced' parameter. For a simple creation tool, it is somewhat complete but has gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for all parameters. The description does not add extra 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 'Creates a new invoice from an accepted/existing estimate', which is a specific verb+resource. It distinguishes from sibling estimate and invoice tools by specifying the conversion 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 implies when to use this tool (converting an accepted/existing estimate to an invoice) but does not explicitly state when not to use or compare to alternatives like ghl_invoice_create.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_estimate_deleteA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint true and idempotentHint true. The description adds the endpoint URL and required OAuth scopes (invoices/estimate.write), providing useful behavioral context beyond annotations. It does not, however, describe error conditions 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?

  The description is extremely concise with no wasted words, front-loading the purpose in the first sentence and providing endpoint/scopes in subsequent lines.

  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?

  While the schema covers parameters and annotations cover safety, the description could be more complete by explaining the requirement for body.altId and body.altType, or clarifying what happens after deletion. Given the simplicity of the tool, the current description is adequate but not thorough.

  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 descriptions for both parameters (estimateId and body with nested altId/altType). The description adds no additional parameter context, 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 title 'Delete Estimate' and description 'Delete an existing estimate' clearly state the tool's purpose. The name ghl_estimate_delete uses a specific verb+resource, and it is distinct from sibling tools like ghl_estimate_create and ghl_estimate_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, such as prerequisites (e.g., estimate must exist) or when not to use it (e.g., if already deleted). A simple usage hint would improve clarity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_invoice_listA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds OAuth scopes (invoices.readonly) and pagination behavior, which are beyond the annotations. No contradictions.

  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 very concise, with only 5 lines that front-load the purpose, provide endpoint and scope, and give pagination guidance. Every sentence is necessary and no fluff.

  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 sparse for a tool with 12 parameters including many filters (search, status, date range, sorting, payment mode). It does not summarize common use cases or hint at the response format, which is needed since there is no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with parameter descriptions. The description adds value by explaining the pagination parameters (limit, offset) and their usage for paging through results, which is not fully clear from schema descriptions 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 'List invoices' and specifies the endpoint and OAuth scope. It implies retrieval of multiple invoices, but does not explicitly differentiate from the single invoice retrieval tool (ghl_invoice_get) among 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 description mentions pagination parameters and how to use them ('pass them to page through full result sets'), but lacks explicit guidance on when to use this tool versus alternatives like ghl_invoice_get or ghl_invoice_search. Filtering capabilities (search, status, date range) are not highlighted.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_invoice_schedule_getA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds endpoint details and OAuth scopes, which are useful context. However, it does not disclose behavior like error responses or what happens if the schedule doesn't exist. Given the annotation coverage, a score of 3 is appropriate.

  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 relatively concise at four lines. However, the first line 'Get an schedule' is redundant given the title. The rest provides useful endpoint and scope information. It could be slightly more concise by removing the first line, but overall 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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read operation with three well-documented parameters, no output schema, and strong annotations, the description provides essential context: the endpoint and OAuth scopes. It does not explain return values or error cases, but these are not always required. The tool is adequately described given its 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 input schema has 100% coverage with descriptions and examples for all three parameters (scheduleId, altId, altType). The description does not add any additional meaning beyond the schema; it only repeats the endpoint. Baseline 3 is correct since the schema already documents the parameters well.

  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 an schedule' and 'API to get an schedule by schedule id', using a specific verb ('get') and resource ('schedule'). This distinguishes it from sibling tools that perform other operations like activate, cancel, create, delete, list, update, etc.

  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 does not explicitly state when to use this tool versus alternatives. It only describes what it does. There is no mention of prerequisites (e.g., needing a scheduleId from a list call) or when not to use it. The differentiation from siblings is implied by the verb 'get' but not articulated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_kb_crawler_list_urlsA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. Description adds HTTP method (GET) and version header, but does not disclose additional behavior like rate limits, permissions, or data volume. No contradiction with annotations.

  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?

  Two concise sentences with no redundancy. First sentence states purpose, second adds endpoint and pagination context. Could be slightly more structured but is efficient.

  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 does not explain the return format (e.g., list of URLs, pagination metadata). It also omits mention of required parameters knowledgeBaseId and locationId. For a 5-param tool with no output schema, the description is insufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed parameter descriptions. Description mentions pagination params but adds minimal extra meaning beyond the schema (e.g., 'pass them to page through full result sets' hints at usage but is not substantial). 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?

  Description clearly states 'Get all trained page links by knowledge base', using a specific verb and resource. The title matches, and it distinguishes from sibling crawler tools (e.g., delete, discover) as a read-only 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Description provides endpoint details and pagination guidance ('pass them to page through full result sets'), indicating how to retrieve complete data. However, it does not explicitly contrast with alternative sibling tools like ghl_kb_crawler_discover.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_kb_faq_createA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate the tool is not read-only, destructive, or idempotent. The description adds no behavioral details beyond 'Create', such as side effects, authorization needs, or duplicate handling. With annotations present, the description contributes minimally.

  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 covering purpose and endpoint. No wasted words; front-loaded with key information.

  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 one nested parameter. However, the description omits what the response contains (e.g., created FAQ ID) and lacks details about error states or success confirmation. Adequate for basic use but incomplete for full agent understanding.

  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?

  Input schema has 100% description coverage for the `body` parameter and its nested properties. The description does not elaborate on parameter semantics beyond what the schema already provides, meeting the baseline expectation.

  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 FAQ inside a knowledge base, uses a specific verb ('Create'), and distinguishes from sibling tools like delete, list, and update.

  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 an FAQ to a knowledge base but lacks explicit guidance on when to use this vs alternatives like updating or deleting. 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.

• ghl_object_search_recordsA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds context about the POST method and OAuth scopes (objects/record.readonly), but does not elaborate on behavioral traits such as permissions, rate limits, or side effects beyond what annotations provide.

  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 front-loaded with the main purpose and uses line breaks for readability. However, it includes a documentation link and endpoint details that, while useful, add length. Still efficient with little wasted text.

  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 lacks any mention of the return value or output format, which is critical given no output schema. It does not clarify pagination behavior or response structure. This gap reduces completeness for a search 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?

  Schema description coverage is 100% (all properties have descriptions, albeit minimal like 'Page'). The description lists the parameters but adds no new semantic meaning or examples beyond the schema. 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 title and description clearly state 'Search Object Records' with specific verb and resource. It distinguishes itself from sibling create/update/delete operations by noting that the body is fully specified in OpenAPI, and mentions supported objects like custom objects and 'business'.

  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 tool is for searching records and that the body parameters are fully specified, unlike sibling ops. It includes OAuth scopes and endpoint, but does not explicitly state when not to use or list alternatives beyond the sibling reference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_payment_order_listA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds endpoint info and OAuth scopes but no additional behavioral traits beyond what annotations cover. No contradictions.

  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 about 5 sentences, front-loaded with title and purpose. It includes endpoint and OAuth details which are useful but somewhat redundant. Could be slightly more 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?

  For a list tool with 13 parameters and no output schema, the description adequately explains filtering capabilities and pagination (limit/offset mentioned). Missing response structure but annotations keep it safe. Mostly 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% (all 13 parameters have descriptions). The description lists filter categories (name, status, payment mode, etc.) but does not add meaning beyond the schema. Baseline 3 due to full 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 title 'List Orders' and description clearly state it retrieves a paginated list of orders with filtering options. It distinguishes itself from sibling tools like ghl_payment_order_get (single order) and ghl_payment_order_list_fulfillments (specific list).

  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 listing orders but does not explicitly state when to use this tool versus alternatives like ghl_payment_order_get or ghl_payment_order_list_notes. No when-not-to-use guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_product_getA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's claim of retrieval is consistent. Description adds no extra behavioral details beyond annotations, but also no contradictions.

  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?

  Description is five sentences, front-loaded with purpose, and includes endpoint and OAuth scopes. It is efficient but could be slightly more streamlined without losing essential 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?

  No output schema exists, but the description does not describe the response structure. For a get tool, this is a gap; the agent does not know what fields the product information contains.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All three parameters are fully described in the input schema (100% coverage). The description does not add any additional parameter guidance 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 clearly states it retrieves a single product by ID; the name and verb (get) align; it differentiates from sibling tools like product_list and product_bulk_edit by specifying 'single product'.

  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 says 'Use this endpoint to fetch details for a single product', which clearly indicates when to use this tool. It does not explicitly list alternatives or when not to use, but the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_product_price_createA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description reveals that this tool performs a write operation (create), consistent with annotations (readOnlyHint=false, destructiveHint=false). It also discloses OAuth scopes and endpoint details. However, it does not discuss side effects (e.g., immediate availability of the price) or error scenarios. No contradiction with annotations.

  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 fairly concise, front-loading the purpose and including key details like endpoint and OAuth. However, there is minor redundancy ('Create Price for a Product' repeated in the title and first sentence), and the instruction 'Ensure required information is provided' adds little value. Overall, 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?

  Despite high schema coverage, the description fails to mention the return value (no output schema is provided). For a creation tool, knowing the response format is crucial. It also omits error conditions or prerequisites beyond OAuth. The description is incomplete for effective usage.

  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?

  Input schema coverage is 100% with detailed parameter descriptions. The description's general statement about 'specified details' adds no new meaning beyond what the schema already provides. Therefore, a baseline score of 3 is appropriate, as the description does not need to compensate.

  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 price for a product, using the verb 'Create' and specifying the resource ('Price'). It distinguishes from sibling tools like ghl_product_price_delete, ghl_product_price_get, ghl_product_price_list, and ghl_product_price_update, which have different actions. The endpoint and OAuth scopes further clarify 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides basic usage instruction ('Use this endpoint to create a price') but does not explicitly guide when to use this tool versus alternatives like update or delete. The sibling tools are not referenced, so the agent must infer differentiation from names. OAuth scopes are mentioned, adding some context, but no exclusions or prerequisites are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_product_price_deleteA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds OAuth scope info and endpoint details, which are useful. However, it does not disclose potential side effects (e.g., if deletion is blocked when price is in use) or reversibility, limiting 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 structured with title, purpose, endpoint, and OAuth scopes. It is mostly concise, though it repeats the title in the first sentence. Overall efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description does not explain the return value (expected for no output schema) or clarify the role of the required `locationId` parameter, which is not in the endpoint URL. This leaves gaps for correct 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?

  Input schema coverage is 100% with clear descriptions for each parameter. The description does not add any additional semantic info beyond what the schema provides, 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 tool deletes a price by ID for a product, with specific endpoint and OAuth scopes. It differentiates from sibling CRUD tools (create, get, list, update) by focusing on deletion.

  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 says 'Use this endpoint to remove a price from the system,' which clearly indicates when to use it. However, it does not provide explicit exclusions or alternatives, though sibling tools make the context obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_product_price_updateA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds behavioral context by including the HTTP endpoint and OAuth scopes (products/prices.write), which helps confirm the mutation is scoped. No contradictions with annotations.

  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 paragraph of moderate length, including the endpoint and scopes. It is reasonably concise but could be more succinct by removing the repeated title phrase. Overall, it is well-structured and front-loaded with the purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complex nested body schema (many optional fields) and no output schema, the description lacks guidance on what the response contains (e.g., the updated price object) or how to handle partial updates. It does not compensate for the missing output schema or explain potential side effects.

  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 input schema already documents all parameters with descriptions and examples. The description does not add significant semantic value beyond stating the required IDs (productId, priceId) and the body's purpose (update details). 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 tool updates a price by ID for a product, using specific verbs ('Update Price by ID for a Product') and resource identifiers (price ID and product ID). It is easily distinguished from sibling tools like create, delete, get, and list 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides basic usage context: 'Use this endpoint to update details for a single price based on the provided price ID and product ID.' However, it does not explicitly contrast with alternatives (e.g., when to use this vs. product_price_create) or mention any prerequisites or edge cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_bulk_disableA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds security context (agency token) beyond annotations, but does not describe side effects or what 'disable' entails (e.g., reversible, billing impact). Annotations do not contradict the description.

  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?

  Description is concise with important warning front-loaded. Some redundancy ('Disable SaaS for locations' appears twice) reduces polish slightly.

  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?

  Provides essential information (endpoint, token requirement) but lacks details on return value, error conditions, and post-disable effects. Partially complete given no output schema.

  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%, but the description adds no new parameter details. 'companyId' is mentioned in the endpoint but its purpose is not explained. The description relies on the schema for parameter 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 action (disable), resource (SaaS for locations), and input (locationIds). It also includes the endpoint, distinguishing it from sibling tools like ghl_saas_bulk_enable and ghl_saas_enable_location.

  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?

  Explicitly requires an agency-level token, telling the agent when this tool is appropriate. It implies not to use without such a token or for single-location operations, though it does not list alternative tools explicitly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_get_locations_by_stripe_idA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only and idempotent behavior. The description adds security requirement (agency token) and endpoint version, but does not describe output format or side effects. It adds some value beyond annotations but is 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is somewhat repetitive (two similar sentences about getting locations) and could be more concise. However, it is front-loaded with the security warning and includes endpoint info, so it is reasonably 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?

  No output schema, so description should cover response. It does not mention what the response contains or if pagination exists. Given 3 required params and no output schema, the description is incomplete for full understanding.

  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%, so description should compensate. It explains that customerId and subscriptionId are stripe identifiers and required, but does not explain companyId or provide format or examples. Adds some meaning but insufficient for missing schema 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 it retrieves locations by stripe customer or subscription ID, with companyId requirement. It distinguishes from the deprecated version by noting parameter requirement differences, 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: requires agency-level token, both customerId and subscriptionId are required, and differentiates from the deprecated twin. This helps the agent decide when and how to use the tool correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_create_queue_itemA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds that the tool creates a new item and offers two modes (session or direct), but does not disclose further behavioral traits beyond what annotations and the input schema already provide.

  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: 4 sentences, first sentence is the core action, then adds usage modes and endpoint/scopes. No wasted words, information is 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?

  Given the complexity of nested objects and no output schema, the description is sparse. It does not explain the difference between session and direct modes, prerequisites, or return format. However, the input schema has extensive inner descriptions, so the description is minimally complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 50% of parameters with descriptions (e.g., body has many nested property descriptions, but queueId has no description). The tool description does not add meaning for queueId or emphasize key parameters beyond the schema. Baseline is 3 due to moderate 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 'Create a new item in the queue' and 'Adds a new post item to a queue,' specifying the exact verb and resource. It distinguishes from siblings like ghl_social_create_queue (which creates a queue) and ghl_social_update_queue_item (which updates).

  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 mentions using sessionId for edit sessions or directToQueue for immediate addition, but does not provide explicit guidance on when to choose this tool over alternatives like ghl_social_clone_queue_item or ghl_social_update_queue_item. Usage context is implied but not contrasted.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_csv_uploadA
  3.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description excels here: it explicitly states that the tool requires a pre-encoded multipart/form-data payload, that `body` is sent verbatim, and that the `file` parameter is binary CSV. These critical behavioral details go far beyond annotations (which only mark readOnlyHint=false and destructiveHint=false) and help avoid common mistakes.

  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 moderately concise but includes verbose endpoint details (path, version, source) that could be condensed. The critical behavioral note about pre-encoding is front-loaded, but there is some redundancy (e.g., 'Upload CSV' repeated). It could be tighter.

  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 complexity (multipart upload with special payload requirements), the description covers essential behavioral aspects like payload construction, required parameters, and OAuth scopes. It does not mention success/error responses, but there is no output schema to describe them. Overall it provides adequate context for correct usage.

  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?

  With 100% schema coverage, the schema already documents both parameters. However, the description adds crucial context: `body` is sent verbatim to GHL, and the caller must provide a pre-encoded multipart payload. This clarifies the parameter's real usage beyond the schema's 'Request body' description.

  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 uploads a CSV file for bulk social media posting, which is a specific verb-resource pair. It also distinguishes from media upload by noting there is no URL-based alternative. However, it doesn't explicitly differentiate among sibling social tools beyond this one 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?

  The description provides no explicit guidance on when to use this tool vs alternatives. It mentions there is no URL-based alternative unlike media upload, but does not specify scenarios or prerequisites like having a pre-encoded payload. Sibling tools are abundant but no selection criteria are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_fetch_available_categoriesA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the return format (categories with statuses), pagination behavior, and required OAuth scopes. There is no contradiction with annotations.

  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 front-loaded with the core purpose and includes essential technical details (endpoint, OAuth, pagination) in a concise paragraph. It avoids unnecessary verbosity, though the first line is somewhat repetitive with the annotation title.

  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 no output schema, the description adequately covers the tool's purpose, return statuses, pagination mechanism, and auth requirements. It could be improved by describing the response structure more fully, but it is sufficient for selection and 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?

  Schema coverage is 100%, so the baseline is 3. The description only adds marginal value by explaining that skip and limit are for pagination, which is already implied in the schema. No additional semantic meaning is provided for q or locationId.

  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 (get categories) and the resource (categories with queue status). It specifies the three possible statuses, making the purpose specific. However, it does not explicitly differentiate from sibling tools like ghl_social_fetch_queues or ghl_social_category_list, so it slightly misses the top score.

  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 mentions pagination parameters (skip, limit) and provides endpoint and OAuth scopes, but it lacks explicit guidance on when to use this tool versus alternatives. There is no 'when-to-use' or 'when-not-to-use' context, so usage is inferred rather than directed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_get_tiktok_business_profileA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, idempotent, non-destructive. Description adds endpoint and version header but no additional behavioral context like response format or authorization requirements.

  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?

  Extremely concise: one line for purpose, one for endpoint. No unnecessary words, 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?

  Adequate for a simple read tool with annotations, but lacks distinction from sibling tools and guidance on obtaining IDs. Contextual completeness is moderate.

  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 for parameters are minimal. The description adds the URL path which hints at parameter order but no extra semantics. Schema coverage is 100%, baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it gets a TikTok Business profile, distinguishing it from sibling tools like ghl_social_get_tiktok_profile. The verb 'Get' and resource 'TikTok Business profile' are specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool vs alternatives (e.g., personal profile). Context is implied by the name but not elaborated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_post_createA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds value by disclosing a known live regression (important behavioral trait) and advising that failures may be server-side, not client-side. It also lists OAuth scopes and links to platform limitations, providing context beyond structured metadata.

  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 relatively long but well-structured, starting with a critical regression warning (front-loading important info). It uses paragraphs and bullet points in the schema, though the main description text could be more concise. Every sentence serves a purpose, but some redundancy exists with the schema content.

  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 complexity (multiple platforms, nested objects, many parameters), the description covers the key aspects: supported platforms, customization, error handling, OAuth scopes, and a link to platform limits. No output schema exists, but the description does not need to explain return values per rules. It misses some details on post-publishing behavior but is 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%, so the baseline is 3. The description does not add significant parameter-level meaning beyond what the schema already provides (each parameter has extensive descriptions). The only addition is a reference link to platform limitations, which is marginally helpful but does not deepen understanding of individual 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 that the tool creates posts for all supported platforms, mentions customization per channel, and references platform-specific details. The verb 'Create post' plus the resource 'posts' makes the purpose unmistakable. While it does not explicitly differentiate from sibling tools like ghl_social_edit_post, the name and description suffice for clear identification.

  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_social_edit_post or ghl_social_delete_post. It does not specify prerequisites, preferred situations, or when not to use it. The only contextual advice is about handling failures (server-side issue), which is about troubleshooting, not selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_account_getA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations set readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which align with the retrieval purpose. The description adds useful behavioral context: the required OAuth scopes (adPublishing.readonly) and the API endpoint. This goes beyond annotations without contradiction.

  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 concise and front-loaded with the purpose. It includes three brief lines (purpose, endpoint, OAuth scopes) without unnecessary fluff. Slightly longer than strictly necessary due to endpoint details, but still efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, and the description does not mention the structure or nature of the return data. For a simple retrieval tool with three parameters and no enums, the description could benefit from indicating what fields are in the response. The endpoint and OAuth scopes are useful, but the lack of return value information is a gap.

  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 all three parameters (isDraft, locationId, adAccountId) already documented with descriptions and examples. The description adds no additional meaning beyond the schema, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get ad account details' and 'Retrieve details of a specific Facebook ad account'. It specifies the verb (Get/Retrieve) and the resource (ad account details). The name distinguishes it from sibling tools like 'ghl_ad_fb_account_delete' and 'ghl_ad_fb_account_list'.

  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 does not explicitly state when to use this tool over alternatives like 'ghl_ad_fb_account_list'. It provides endpoint and OAuth scopes but lacks prerequisites or exclusion criteria. The context is implied by the tool name, but no explicit guidance is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_account_listA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral context beyond annotations: endpoint details, version header, OAuth scopes, and pagination behavior. No contradictions with annotations.

  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 concise with 5 lines, each adding relevant info: title, clarification, endpoint, scopes, pagination. No wasted words, but could be more structured (e.g., bullet points).

  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 5 parameters and no output schema, the description explains pagination but lacks details on 'type' and 'fetchAll' parameters. Response structure is not hinted at. Adequate but not complete for a list tool with multiple optional filters.

  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 baseline is 3. The description mentions pagination params (limit) but does not explain other parameters like locationId, next, type, or fetchAll. Adds some value but insufficiently covers all 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 'Get ad accounts' and 'Retrieve Facebook ad accounts available for the connected user', specifying the resource (Facebook ad accounts) and action (list). This distinguishes it from sibling tools like ghl_ad_fb_account_get which retrieves a single account.

  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 mentions pagination params and OAuth scopes but does not explicitly state when to use this tool versus alternatives. Usage is implied via context of sibling tools, but no direct guidance on when-not or alternatives is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_ad_resumeA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description includes the HTTP endpoint (POST) and OAuth scopes (adPublishing.write), which adds behavioral context beyond the annotations. Annotations already indicate non-read-only and non-destructive, so the description adds value with specific auth and method details.

  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 concise with minimal extra lines, though it includes technical metadata (endpoint version, source) that may not be essential for an agent. Still, it is front-loaded and non-redundant.

  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 covers the action and endpoint but lacks any mention of return value or success indication. Since there is no output schema, the description could provide more context about the outcome.

  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 parameters described in the input schema. The description adds no additional parameter explanations, so 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 'Resume a paused Facebook ad', which specifies the verb (resume) and the resource (paused Facebook ad). Among siblings, there is a distinct 'pause' tool, so it is well-differentiated.

  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 resuming paused ads but provides no explicit guidance on when to use this tool versus alternatives, 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.

• ghl_ad_fb_ad_upsertA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false, which the description supports by stating 'upsert' (idempotent) and 'Create or update' (not destructive). The description adds endpoint and OAuth scopes, which provide some additional context, but does not elaborate on behavior beyond the annotations.

  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 concise (two sentences plus endpoint/scopes) and front-loaded with the core purpose. The endpoint and scopes are arguably extraneous for an AI agent but do not significantly harm conciseness.

  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 complex nested input schema and no output schema, the description is minimal. It does not explain return values, prerequisites (e.g., existence of campaign/adset), or validation. Annotations and schema coverage compensate partially, but for a complex upsert operation, more contextual guidance would be beneficial.

  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 schema itself documents parameters thoroughly. The description does not add any parameter-specific meaning beyond what the schema provides, resulting in a baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Upsert ad' and 'Create or update a Facebook ad', providing a specific verb and resource. It distinguishes from sibling tools like ghl_ad_fb_ad_delete, ghl_ad_fb_ad_duplicate, etc., by focusing on upsert functionality.

  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 for creating or updating ads via 'Create or update a Facebook ad'. However, it does not provide explicit exclusions or compare with alternatives like ghl_ad_fb_ad_duplicate for duplication scenarios. Still, the context is clear enough given the sibling set.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_audience_member_batch_updateA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description aligns with annotations (readOnlyHint=false) by indicating a mutating operation. It adds context about using CSV or smart lists, but does not disclose additional behavioral traits such as rate limits, prerequisites, or what happens during partial failures. The idempotentHint=true annotation is 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 three lines: title, key functionality, and endpoint/OAuth scopes. It is efficient and front-loaded with the most important information. The inclusion of endpoint and OAuth details is somewhat extraneous for tool selection but does not detract significantly.

  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 adequately outlines the purpose and input methods, but lacks details on expected output (no output schema) and concrete guidance on how to use CSV vs smart lists. Given the tool's moderate complexity, the description is acceptable 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?

  Schema coverage is 100%, with all parameters having descriptions and examples. The description mentions 'CSV or smart lists' which maps to csvPath and smartlistIds, but adds no new semantic meaning beyond what the schema provides. 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 it is a batch update for audience members, specifying add/remove operations via CSV or smart lists. The name and title reinforce this, and it is distinct from sibling tools like ghl_ad_fb_audience_member_add/remove which handle individual members.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description mentions two input methods (CSV or smart lists), giving context for usage. However, it does not explicitly state when to prefer this batch tool over the individual add/remove sibling tools, nor does it provide exclusions or alternative recommendations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_campaign_getA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint=true, destructiveHint=false) already indicate safe reading. The description adds endpoint and OAuth scope, providing authorization context. However, it does not elaborate on response structure, pagination, or rate limits. Since annotations cover most behavioral traits, description adds moderate 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 very concise: two short sentences plus technical details. Key information (what it does) is front-loaded. There is no redundancy or unnecessary text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that it is a simple read operation with idempotent and read-only annotations, the description covers the core functionality. It hints at return contents (linked entities). However, it could explicitly mention that it returns campaign details as well, but overall it's sufficiently complete for a tool of this 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?

  Schema coverage is 100%, so the schema already documents all parameters. The description mentions 'linked adsets and ads' which relates to the 'fields' parameter, but it does not add new meaning or interactions beyond what the schema provides. 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 'Retrieve' and the resource 'Facebook campaign with linked adsets and ads'. It distinguishes this read operation from sibling tools that mutate campaigns (delete, pause, duplicate, etc.) and other read tools like list or get without linked entities.

  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 mentions retrieval of linked adsets and ads, which implies it should be used when those are needed, but it does not explicitly state when to use it vs. alternatives (e.g., a simple campaign get or list). There is no guidance on prerequisites or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_integration_getA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, providing a strong safety profile. The description adds the endpoint and OAuth scopes (adPublishing.readonly), confirming read-only access, but does not disclose further behavioral traits like rate limits 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 very concise: three lines covering action, endpoint, and OAuth scopes. No fluff, front-loaded with the core verb and resource.

  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 operation with comprehensive annotations, the description covers the resource, endpoint, and authentication. However, it lacks a description of the return value, which would be helpful since no output schema exists.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description does not add any additional meaning to parameters beyond what the schema already provides (e.g., locationId, isDraft). Thus, no extra 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?

  The description clearly states the verb 'Get' and 'Retrieve', the resource 'Facebook ad integration', and the scope 'for a location'. It distinguishes this tool from siblings like create and delete. The endpoint and OAuth scopes reinforce the purpose.

  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 integration details but lacks explicit guidance on when to use this tool vs alternatives (e.g., create, delete). No when-not-to-use or exclusion criteria are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_lead_form_getA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  While annotations already indicate read-only, idempotent, and non-destructive behavior, the description adds specific OAuth scopes (adPublishing.readonly) and the endpoint URL, which provide valuable context about authentication and API versioning beyond the annotations.

  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 concise at four lines, with the purpose front-loaded. It includes the endpoint and OAuth scopes, which are useful but not essential; no redundant sentences are present.

  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?

  There is no output schema, and the description does not specify the return format or content of the lead form. For a read tool, the agent might need to know what fields are returned; however, the annotations provide some 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 descriptions and examples for all three parameters. The description adds no additional meaning beyond the schema, meeting the baseline for parameter semantics.

  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 lead form by ID' and 'Retrieve a specific Facebook lead form by its ID', using a specific verb and resource. It distinguishes from sibling tools like list or create lead form tools by emphasizing retrieval by 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 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 lead form by ID but does not explicitly state when to use versus alternatives like listing forms. No guidance on prerequisites or exclusions is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_page_instagram_account_listA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds the endpoint, version, and OAuth scopes, providing useful authorization context beyond annotations. However, it does not describe the return format or pagination 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 relatively concise, with the purpose stated first. However, it includes technical details like version header and source that may not be essential for an AI agent, slightly reducing clarity.

  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 simple list operation and existing annotations/schema, the description covers the basic functionality. However, without an output schema, it would be helpful to mention the return structure (e.g., list of Instagram account objects) for 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%, so the description adds minimal semantic value beyond what is already in the input schema. It mentions the endpoint path, which reinforces the pageId parameter's role, but does not provide additional explanation for 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 retrieves Instagram accounts linked to a specific Facebook page. It uses a specific verb ('Get') and resource ('Instagram accounts for page'), distinguishing it from siblings like ghl_ad_fb_page_list or ghl_social_attach_instagram_page_group.

  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 should be used when needing to retrieve Instagram accounts for a page, but it does not explicitly state when to use it versus alternatives or mention prerequisites. No exclusion criteria or usage context is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_page_listA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying the exact endpoint URL, version header, and OAuth scope (adPublishing.readonly), which provide concrete behavioral and authorization details beyond annotations. No contradictions.

  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 concise, with four lines covering title, summary, endpoint, and OAuth scope. It avoids redundancy and is easy to parse. Minor improvement could be structuring as bullet points, but overall it is efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with no output schema, the description covers core purpose, endpoint, and authorization. However, it omits any details about the return format, pagination, or expected response structure, which could be helpful for an agent. Given the tool's low complexity, 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?

  Input schema has 100% parameter description coverage (locationId and fetchExisting both have descriptions). The description does not add any extra meaning or usage details for these parameters, so it meets the baseline without further enhancement.

  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 'Get Facebook pages' and 'Retrieve Facebook pages associated with the connected account,' clearly identifying the resource (Facebook pages) and action (list/retrieve). This distinguishes it from sibling tools like ghl_ad_fb_page_delete or ghl_ad_fb_page_instagram_account_list, which operate on different aspects of Facebook pages.

  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 does not provide explicit guidance on when to use this tool versus alternatives. While the endpoint and OAuth scopes are given, there is no mention of prerequisites, limitations, or exclusion criteria. The context from sibling tools implies this is for listing pages, but no direct comparison or when-not-to-use advice is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_google_campaign_getA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, providing safety context. The description adds endpoint and OAuth scopes but no additional behavioral traits beyond what annotations imply. For a getter, this is adequate but not enhanced.

  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 plus endpoint and OAuth scopes. Front-loaded with the core action. No redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple getter with annotations, the description provides endpoint, version header, and OAuth scopes, which are useful operational details. Lacks output schema info but not required. Fairly complete given tool 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?

  Schema coverage is 100% with each parameter having a description. The description does not add any extra parameter semantics beyond what the schema provides. Baseline score 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 'Get Google campaign by ID' and 'Retrieve a specific Google Ads campaign by ID', providing a specific verb and resource. It differentiates from sibling tools like upsert and publish by focusing on retrieval.

  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 guidance on when to use this tool versus alternatives. The description only states the basic function; it doesn't mention prerequisites or scenarios where other tools might be better. Implicitly, it's for fetching a campaign, but lacks comparative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_google_current_user_getA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the HTTP GET endpoint and OAuth scopes, providing auth context. No contradictions exist, but additional behavioral details (e.g., rate limits, effect of isDraft) are absent.

  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 concise, front-loading the purpose and including endpoint, version, source, and OAuth scopes. Every sentence adds relevant information, though the endpoint details could be streamlined.

  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?

  No output schema exists, yet the description does not hint at the return structure or shape of 'user info.' While endpoint and scopes are given, the lack of return type information leaves a gap for a read-only 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?

  Input schema coverage is 100% with both parameters (isDraft, locationId) having descriptions. The description does not enhance parameter semantics beyond the schema, so a 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 'Get current Google user' and 'Retrieve the authenticated Google user info for a location,' using a specific verb and resource. This effectively distinguishes it from sibling tools like ghl_ad_fb_current_user_get and ghl_ad_li_current_user_get by specifying 'Google' and 'ad-publishing.'

  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 does not explicitly state when to use this tool versus alternatives. Context like 'Google user' and 'location' hints at its domain, but no when-not or alternative tool references are provided. While it mentions OAuth scopes, usage guidelines remain implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_google_target_interest_listA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds OAuth scopes and endpoint details but does not disclose behavioral traits beyond what annotations provide. No contradictions are present.

  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: a header line, a one-sentence purpose, and then technical metadata. It is front-loaded with the essential purpose and contains no unnecessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the read-only and idempotent annotations, full schema coverage, and the simple list retrieval nature, the description is adequate. Missing output schema details are not critical for this tool's use.

  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 baseline is 3. The description does not elaborate on parameters beyond the schema's own descriptions (e.g., enum values for type). No additional meaning is added.

  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 affinity and in-market audience options for Google Ads targeting. The verb 'Get' and resource 'target interests' directly matches the tool name. Among Google Ads siblings like targeting_search or audience_list, this tool's purpose is distinct and well-defined.

  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 explains what the tool does but does not explicitly state when to use this tool versus alternatives like ghl_ad_google_targeting_search. No exclusions or context for selection are provided, leaving the agent to infer from the tool name and sibling context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_li_current_user_getA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds endpoint details and OAuth scopes (adPublishing.readonly) but does not describe side effects beyond what annotations imply. No contradiction.

  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 four lines, concise, and well-structured. It includes endpoint, version header, and OAuth scopes. 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read operation with only 2 parameters, the description is adequate but lacks details on return values or examples. Annotations cover safety. Could be improved with a note about the response format.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers 100% of parameters with descriptions (locationId, isDraft). The description does not add any additional meaning beyond the schema. Baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get current LinkedIn user' and specifies it retrieves authenticated user info for a location. The endpoint and OAuth scopes are provided, distinguishing it from sibling tools like ghl_ad_google_current_user_get and ghl_ad_fb_current_user_get.

  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 does not explicitly compare to alternatives, but the tool name and description indicate it is for LinkedIn. Sibling tools for other platforms exist, and the description implies when to use this tool (when LinkedIn user info is needed). Lack of explicit exclusion of other tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_agent_studio_deleteA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds value by specifying 'all its versions', revealing the cascade delete behavior, and listing the OAuth scopes. No contradiction with annotations.

  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 short but includes a redundant first line ('Delete Agent') that repeats the title. The remaining two sentences are functional but could be merged or streamlined.

  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 destructive nature and lack of output schema, the description explains the core effect (deleting agent and versions) and provides endpoint details. However, it omits return value information and does not address parameter semantics, leaving gaps for an agent.

  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 parameters (source, agentId, locationId) beyond implying agentId is a path parameter. The agent gets no information about the meaning or required roles of these 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 ('Deletes an agent and all its versions'), with a specific verb and resource. It distinguishes from sibling tools like ghl_agent_studio_create or ghl_agent_studio_list.

  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 about what deletion entails (including all versions) and includes endpoint and OAuth scopes. However, it lacks explicit when-not-to-use guidance or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_brand_board_get_by_locationA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true. The description adds useful context: pagination parameters (limit, offset), OAuth scopes, and the endpoint path. No contradiction with annotations.

  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 relatively concise, though it repeats 'Get Brand Boards' twice. The key information (retrieves all by location, pagination, auth) is 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?

  The description covers endpoint, pagination, and OAuth scopes. However, it does not mention the response format (likely a list), pagination behavior (e.g., next page tokens), or filtering options (search, deleted) which are present in the schema. Adequate but could be 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?

  Schema coverage is 100%, so the description does not need to explain parameters. It mentions pagination (limit, offset) but not search or deleted. Baseline 3 is appropriate as 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 states 'Retrieves all Brand Boards for a specific location', which is a specific verb (retrieves) and resource (brand boards) with a clear filter (by location). It distinguishes from sibling tools like create, delete, or get_by_id.

  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 brand boards for a location, but does not provide explicit when-to-use, when-not-to-use, or alternatives. No guidance on when to use this versus related tools like get_by_id.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_event_schedule_updateA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false, which are consistent with an update operation. The description adds 'Only provided fields will be updated' (partial update behavior) and includes OAuth scopes ('calendars.write'), which are critical behavioral constraints not in annotations. It does not mention error handling or side effects, but the added context is valuable.

  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 concise, consisting of two short paragraphs. It front-loads the purpose and then provides essential details (partial update, endpoint, scopes). Every sentence adds value, though the endpoint info could be considered supplementary. Overall, it is efficiently 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 description lacks an explanation of the return value (no output schema), and the partial update behavior is stated but not fully clarified (e.g., whether rules are merged or replaced). Given the complexity of nested objects and the absence of an output schema, the description could be more complete by clarifying merge semantics or success/error responses.

  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 does not add significant meaning beyond the schema; it only reiterates 'calendar ID is provided in the path' and 'Only provided fields will be updated,' which is a general behavioral note rather than parameter-specific semantics.

  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 'Update event calendar availability schedule' and elaborates 'Update the availability schedule for a specific event calendar.' It uses a specific verb and resource, and distinguishes itself from sibling tools like ghl_calendar_event_schedule_create and ghl_calendar_event_schedule_get.

  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 mentions 'Only provided fields will be updated,' which implies a partial update pattern. However, it does not explicitly specify when to use this tool versus alternatives (e.g., create or get), nor does it provide exclusions or prerequisites. The usage guidance is implied but not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_schedule_createA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds the specific endpoint and OAuth scopes, which provide some behavioral context. However, it does not disclose other traits like error handling, idempotency, or side effects beyond creation. No contradiction with 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 concise: two purposeful sentences plus essential endpoint and scope information. No superfluous words. Front-loaded with the action and resource.

  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 nested parameter structure and lack of output schema, the description provides a clear overview and the schema covers input details. The addition of endpoint and OAuth scopes enhances completeness. Minor gap: no mention of return value or expected response format, but this is acceptable for a create tool when output schema is absent.

  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?

  Input schema has 100% coverage with descriptions for all parameters. The description merely lists parameter categories ('rules, timezone, location, user and calendar associations') without adding new semantic details beyond what the schema already provides. 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?

  Description clearly states 'Create user availability schedule' and elaborates with 'Create new schedule with specified rules, timezone, location, user and calendar associations.' It uses a specific verb and resource, and the tool name itself distinguishes it from sibling tools (e.g., update, delete, assign).

  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 does not explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied by the tool name and context of sibling tools (create vs. update/delete/assign), but there is no guidance on prerequisites or decision criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_schedule_deleteA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds value by specifying that the deletion permanently removes all associated rules and cannot be undone, and provides endpoint and OAuth scope 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?

  The description is very concise: a title line, one key behavioral statement, and endpoint/scopes. No wasted words, front-loaded with purpose.

  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 delete tool with no output schema, the description covers the action, outcome, and permissions. It lacks information about prerequisites or error handling but is largely 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 a clear description for the 'id' parameter. The tool description does not add additional parameter information, so baseline score 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 first line 'Delete user availability schedule' clearly states the verb (Delete) and resource (user availability schedule). The additional sentence explains permanence and rule deletion, distinguishing it from other schedule tools like create, update, or unassign.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives such as ghl_calendar_schedule_unassign. The description implies usage via the delete operation but does not clarify contexts or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_schedule_updateA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide idempotentHint and destructiveHint=false, and the description adds valuable context: it is a PUT endpoint, requires OAuth scopes 'calendars.write', and clarifies that only provided fields are updated (partial update). No contradiction with annotations.

  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 three sentences: purpose, what fields can be updated and that fields are optional, and endpoint details. It is front-loaded with the core action. Could be slightly tighter by merging the first two sentences, but overall 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?

  Given the tool has 2 parameters and no output schema, the description covers purpose, usage (partial update), and endpoint. It does not explain what the response looks like or error handling, but for an update tool this is acceptable. Sibling tools provide context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with full descriptions, but the tool description adds the key insight that 'All fields are optional - only provided fields will be updated,' indicating a partial update behavior. This goes beyond the schema which just lists fields.

  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 'Update user availability schedule' and specifies that it modifies rules, timezone, and name. The name and description clearly indicate an update operation. However, it does not explicitly distinguish from sibling tools like create or delete, though the context implies it.

  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 says 'Modify an existing schedule' and 'All fields are optional - only provided fields will be updated,' which gives usage context. But it does not explicitly state when to use this tool versus alternatives (e.g., create), nor does it mention 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.

• ghl_calendar_service_booking_listA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only and idempotent. The description adds key behavioral detail: no pagination (limit/offset) and results bounded by required date range. Does not mention rate limits or response size but sufficient with annotations.

  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?

  Description has 5 sentences but feels scattered: opens with parameter format, then title, then description, then endpoint and scopes. Title line 'Get Service Bookings' is redundant. Could be more organized.

  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 5 parameters, no output schema, and annotations, the description covers required filters, optional filter, date range bounding, and OAuth scopes. Lacks mention of response format but reasonable for a list 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?

  Schema covers all 5 parameters with descriptions and examples. The description reiterates startTime/endTime as epoch milliseconds and notes no limit/offset, but adds little beyond schema. Baseline 3 applies due to full 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 it retrieves service bookings for a location within a date range, with an optional service location filter. It distinguishes from sibling tools (e.g., get, create) by focusing on listing.

  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 filtering by date range and location but does not explicitly contrast with alternative tools or specify 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.

• ghl_chat_widget_cloneA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false and destructiveHint=false, so the description's 'Creates a copy' is consistent. It adds endpoint and OAuth scopes but doesn't detail side effects, rate limits, or what happens to the original widget. This is adequate but not thorough.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise with four focused lines: title, summary, endpoint, and OAuth scopes. No superfluous content, well-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 covers purpose, endpoint, and auth, but lacks mention of return value or response format. For a clone operation, this is minor but notable. Given no output schema, a brief note on what is returned 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 coverage is 100% with good parameter descriptions. The description does not add 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 clearly states 'Creates a copy of an existing chat widget in the same sub-account', which is a specific verb+resource. It distinguishes from sibling tools like create, update, delete, get, and list by focusing on cloning.

  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 does not provide explicit guidance on when to use this tool versus alternatives like create or update. It implies usage by stating it clones, but lacks context on when cloning is preferred over other operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_chat_widget_get_public_configA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the critical behavioral context that this is a public endpoint and requires no authentication, which goes beyond what annotations provide. This is significant for the agent's decision-making.

  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 begins with a verbose auto-generated name collision note that is irrelevant for an agent selecting the tool. The key purpose ('public widget-embed config fetch') is buried. It contains multiple disconnected sentences and could be streamlined to front-load the essential information.

  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, the description only vaguely states 'Returns widget configuration by ID.' It lacks detail on the response structure. However, for a simple read-only config fetch tool with good annotations, it is minimally adequate but not fully informative.

  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 50%: only 'id' has a description ('The chat widget ID'). The description reaffirms that config is fetched 'by ID' but does not explain the 'version' parameter beyond its default and example in the schema. With half the parameters lacking documented meaning, the description does not fully compensate.

  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 'Get Widget Config' and 'Returns widget configuration by ID.' It identifies the tool as the public widget-embed config fetch, distinct from other chat-widget ops. The initial note about name collision is distracting but does not obscure the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states 'no security/auth requirement for it, unlike other chat-widget ops,' providing clear guidance on when to use this tool (public config without auth) versus siblings that require auth. This is strong, direct usage advice.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_contact_get_duplicateA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses endpoint, OAuth scopes, URL encoding, and the duplicate-checking business logic. Annotations already declare readOnlyHint, idempotentHint, and non-destructive; description adds useful context without contradiction.

  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 moderately concise but includes redundancy (title repeated) and technical endpoint details that could be trimmed. The key information is present, but structure could be tighter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Lacks description of the response format or error conditions, which would be helpful given no output schema. The business logic and parameter constraints are well covered, but the agent is left without info on what the tool returns.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but the description adds critical business logic (at least one parameter required) and URL encoding details, which are not in the schema. This enhances understanding beyond 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?

  The description clearly states the tool finds duplicate contacts using email or phone, with business logic based on the 'Allow Duplicate Contact' setting. This distinguishes it from other contact tools like ghl_contact_get_by_id or ghl_contact_search_advanced, though explicit differentiation is absent.

  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 explicit guidance that at least one of `number` or `email` must be supplied, explains the priority of search fields based on settings, and mentions URL encoding requirements. It does not explicitly say when to avoid this tool, but the purpose implies it's only for duplicate detection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_contact_listA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds value by noting pagination parameters (startAfterId, startAfter, limit) and OAuth scopes, but does not dive into edge cases or error states. The description does not contradict annotations.

  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 repeats 'Get Contacts' twice and includes a verbose deprecation note with a URL, making it longer than necessary. The core information is present but would benefit from trimming redundant text.

  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 no output schema, the description could describe the response structure (e.g., list of contact objects). However, the pagination details and deprecation context provide useful operational guidance. The tool is simple enough that this is 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 coverage is 100% with each parameter having a description. The description adds minimal extra meaning beyond listing pagination params and their role. 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 tool is deprecated, returns a simple paginated list filtered by optional free-text query, and distinguishes itself from the advanced search sibling ghl_contact_search_advanced. It explicitly mentions the verb 'get' and the resource 'contacts'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance: 'prefer ghl_contact_search_advanced (POST /contacts/search) for new integrations' and 'Kept registered for legacy callers,' indicating when to use this tool versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_contact_remove_from_all_campaignsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true and idempotentHint=true. The description confirms the destructive action ('removes the contact from every campaign') and provides OAuth scopes, but adds no additional behavioral context beyond the annotations.

  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 somewhat verbose with metadata (version, source, OAuth), but it front-loads the core purpose and is structured logically. Not overly long for the information provided.

  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 only one required parameter, no output schema, and rich annotations, the description covers all necessary context effectively. It includes OAuth scopes and endpoint details, making it complete for an agent to use 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 schema has 100% coverage with one required parameter (contactId) described as 'Contact Id'. The description repeats the parameter via the endpoint path but adds no extra 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 clearly states the tool removes a contact from every campaign, using a specific verb and resource. It also distinguishes itself from sibling tools like ghl_contact_remove_from_all_campaigns_legacy by noting it's the 'v3-preferred 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 by stating it's the preferred variant, but it does not explicitly say when to use this tool versus alternatives like ghl_contact_remove_from_campaign. No when-not or direct comparison provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_ai_update_agentA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate non-read-only, non-destructive, idempotent behavior. The description adds endpoint, OAuth scopes (conversation-ai.write), and mentions updatable fields, which aligns and provides extra context. No contradictions.

  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 concise with 4 sentences, front-loaded with purpose. The redundant 'Update Agent' header is minor. Endpoint and OAuth scopes are efficiently included.

  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 no output schema, the description lacks information about what the API returns. While it covers purpose, permissions, and updatable fields, the absence of return value details is a gap for a mutation 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?

  Schema coverage is 100% for both parameters (agentId, body). The description does not add parameter-specific details beyond the schema; it only broadly mentions updatable fields. 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 'Updates an existing AI agent's configuration' with a specific verb (Update) and resource (existing AI agent). It distinguishes from sibling tools like create, get, delete agents.

  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 for modifying an existing agent but does not explicitly state when to use or when not to use. No alternatives or exclusion criteria are mentioned, 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.

• ghl_custom_field_createA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false and destructiveHint=false, which the description aligns with by stating 'Create'. The description adds OAuth scopes and a note about limited object support, providing context beyond annotations. However, it does not disclose behavior on duplicate field keys or idempotency, which annotations already flag as false.

  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 relatively short and front-loaded with the purpose. However, it contains unnecessary HTML formatting and repetitive text ('Create Custom Field' twice), slightly reducing efficiency. Overall, it is clear and compact.

  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 complexity (nested schema, no output schema), the description covers the tool's scope and OAuth needs but omits the return value structure. For a creation tool, providing expected output would improve completeness. The schema carries the bulk of parameter detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds no additional parameter meaning; it only mentions supported objects indirectly, which does not enhance the schema's provided 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 'Create Custom Field' and specifies the supported objects (Custom Objects and Company), making the tool's purpose unambiguous. It distinguishes itself from sibling tools like ghl_custom_field_delete and ghl_custom_field_update by its action (create) and scope limitation.

  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 mentions that the tool only supports Custom Objects and Company today, providing some guidance on when to use it. However, it does not explicitly state when not to use it or suggest alternatives for unsupported objects, leaving the agent to infer.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_email_builder_template_createA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate it's a write operation (readOnlyHint false) and not idempotent. The description adds endpoint details and version but doesn't disclose side effects, error behavior, or concurrency 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?

  Short and focused, with key information front-loaded. One sentence for purpose, then technical details. No fluff but could be more structured with separate sections.

  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?

  Missing output schema, no explanation of the complex nested body parameters or their relationships. The description provides endpoint and scopes but not enough to fully understand usage beyond basic creation.

  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 100% for the single parameter, but the description of the parameter is generic. It doesn't explain the meaning of enum values like 'type' (html, folder, etc.) or 'importProvider', which would help the agent choose correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it creates a new email builder template, explicitly calling it 'Legacy' and distinguishing it from the v3 template family. The verb 'Create' and resource 'template' are specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says it's a legacy API distinct from v3 templates, guiding when to use this vs. alternatives. Also specifies required OAuth scopes, which helps with authorization context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_email_get_workflow_campaignA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, which convey the key behavioral traits. The description adds endpoint details and OAuth scopes but does not contradict or significantly extend beyond 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 extremely concise with three lines: purpose, endpoint, and OAuth scopes. It is front-loaded with the most critical information and contains no unnecessary 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?

  The tool has no output schema, and the description does not mention the return value structure or format. While a read tool returning a campaign object is implied, the lack of return value description leaves the agent uncertain about what data 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?

  The input schema has 100% coverage with simple descriptions ('Campaign ID', 'Location ID'). The description's endpoint URL reinforces parameter roles, but adds minimal 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 clearly states 'Get Workflow Campaign by ID' and 'Get a single workflow campaign by its ID', specifying the action (get) and resource (workflow campaign by ID). It distinguishes this tool from sibling tools like ghl_email_get_campaign (for regular campaigns) and ghl_email_list_workflow_campaigns (for listing).

  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 purpose is clearly contextualized as retrieving a single workflow campaign by ID, but the description does not explicitly provide when-not-to-use or compare with alternatives. However, the sibling tool names are distinct enough that an agent can infer the appropriate use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_email_schedule_campaignA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds the status constraint, but does not elaborate on the effects of different schedule types (immediate, scheduled, batch, etc.) or potential error conditions. With annotations already providing safety signals, the description adds modest 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 concise and front-loaded with the action. It includes essential information (status constraint, endpoint, OAuth scopes) in minimal text. No unnecessary words 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?

  Despite 100% schema coverage, the description lacks high-level context about the tool's complexity. It does not mention the variety of schedule types (immediate, scheduled, batch, rss, smart_send), A/B testing, or recipient configuration. The endpoint and scope are included, but important nuances like prerequisites (valid locationId, campaignId) and return values (no output schema) are missing. The description is too minimal for a tool with many nested options.

  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 every parameter and nested property is documented in the input schema. The description adds no additional parameter meaning beyond the endpoint reference. Baseline score of 3 is appropriate for high 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 'Schedule or start' and the resource 'email campaign'. It specifies the campaign must be in draft, cancelled, or paused status, differentiating it from create/update/delete/list siblings like ghl_email_create_campaign and ghl_email_update_campaign.

  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 a clear usage constraint: the campaign must be in specific statuses. It includes OAuth scopes (emails/campaigns.write) indicating required permissions. However, it does not explicitly state when to use this tool vs alternatives like ghl_email_create_campaign or ghl_email_update_campaign, nor what happens if the campaign is already scheduled.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_estimate_template_listA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the HTTP method (GET), OAuth scope (invoices/estimate.readonly), and pagination behavior. No contradiction with annotations.

  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?

  Description is concise with 5 lines, including endpoint and scopes. The first line repeats the title, which is minor redundancy. Overall well-structured 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 tool with no output schema, the description lacks details about return format or filtering behavior. It adequately covers list and get-by-ID functionality but misses guidance on search parameter usage and response structure.

  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 80%, so baseline is 3. The description adds pagination context ('pass them to page through full result sets') but is slightly misleading by saying 'by ID' when there is no dedicated ID parameter (search is used). This adds marginal value beyond 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?

  Description clearly states 'List Estimate Templates' and specifies it can get a list or a specific template by ID. This distinguishes it from sibling create/delete/update/preview tools, providing a specific verb and resource.

  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 mentions pagination parameters but provides no guidance on when to use this tool versus alternatives like ghl_estimate_template_preview. Usage context is implied but not explicitly described.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_invoice_generate_numberA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the endpoint (GET) and OAuth scopes, confirming it's a safe, idempotent read operation. No contradictions.

  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 4 lines including endpoint and scopes, which is concise but could be streamlined. It front-loads the purpose, but includes implementation details (endpoint, OAuth) that may not be essential for agent selection.

  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 is simple (2 params, read-only, idempotent), the description adequately covers purpose and the key parameter. No output schema exists, but the agent can infer the return type from the tool name. Sufficient for a simple query.

  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 2 required params: altId (with description 'Location Id') and altType (enum, no description). The description mentions 'for the given location', which maps to altId, but adds no new meaning beyond the schema. Schema coverage is 50% (altId described, altType not).

  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 generates an invoice number for a given location, using the verb 'Get' and specifying the resource 'next invoice number'. It distinguishes from sibling invoice tools like create, delete, list, etc.

  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 guidance on when to use this tool vs alternatives like ghl_invoice_create. The description does not mention conditions or exclusions, leaving the agent to infer from the tool name and endpoint.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_invoice_get_settingsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark it as readOnly, idempotent, and non-destructive. The description adds specific endpoint (GET /invoices/settings) and OAuth scopes, providing helpful context beyond what annotations offer. No contradiction.

  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 brief, using four lines to convey purpose, endpoint, version, and auth scopes. Every sentence is pertinent; no unnecessary 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 lacks information about the return value (no output schema). Given the tool is read-only and returns settings, mentioning what settings are returned (e.g., payment methods, late fees) would improve completeness. However, it is clear enough for an API-savvy agent.

  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 50% (altId has a description, altType only has an enum). The description says 'for the given location' but does not clarify the difference between altId and altType or their formats. The description adds no value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves invoice settings for a given location. The title 'Get Invoice Settings' and the first line reinforce this. It is distinct from sibling invoice tools (e.g., ghl_invoice_get for individual invoices) by specifying 'settings'.

  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 OAuth scopes (invoices.readonly) implying read usage, but no explicit guidance on when to use this tool versus alternatives, nor any exclusions or preconditions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_invoice_schedule_cancelA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Description adds value beyond annotations by clarifying that already-sent invoices are unaffected. Annotations already declare destructiveHint=false, but the description explains the scope of 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  First sentence is clear and front-loaded, but there is redundancy (e.g., 'Cancel an scheduled invoice' and endpoint info) and a minor grammatical error ('an scheduled'). Still concise overall.

  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?

  Description covers the tool's effect but does not mention return values, error handling, or whether the schedule itself is deleted. With no output schema, more details could be helpful.

  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 description does not add additional meaning for parameters beyond what the schema already provides. 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?

  Description clearly states 'Stops all remaining not-yet-sent occurrences of this recurring/scheduled invoice' with specific verb and resource, and distinguishes from sibling tools like delete or update.

  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?

  Description does not explicitly state when to use this tool vs alternatives like ghl_invoice_schedule_delete or ghl_invoice_schedule_update. Usage is implied from the name, but no guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_location_get_conversation_channelA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. Description adds OAuth scope 'locations.readonly' and endpoint method (GET), reinforcing safe read-only behavior. No contradictions.

  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?

  Description is mostly concise but includes redundant title repetition. Core information is front-loaded in the second line. Technical endpoint details are useful but add slight clutter.

  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?

  No output schema, so description does not mention return format or fields. Tool is simple (2 params, enum), but completeness would benefit from indicating the response structure (e.g., list of providers).

  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 clear descriptions for both parameters. Description does not add new semantic meaning beyond restating the type filter; it matches the schema's enum.

  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' and the resource 'conversation channel providers configured for a location' with a specific filter by type (SMS or Email). This distinguishes it from other location and conversation tools among 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?

  Description provides the purpose but no explicit guidance on when to use this tool versus alternatives. No 'when not to use' or alternative tool mentions. The endpoint and OAuth scope are provided but not usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_marketplace_has_fundsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnly, idempotent, non-destructive. The description adds the HTTP method (GET) and OAuth scopes, but does not describe the return format or any side effects. It adds some value beyond 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 extremely concise, with each piece of information adding value: the purpose, endpoint, and OAuth scopes. 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 parameter-less, read-only tool with comprehensive annotations, the description is largely complete. It could mention the response type (e.g., boolean), but the purpose is clear enough.

  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 no parameters, and schema coverage is 100%. The description adds no parameter details, but none are needed. Baseline 4 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 'Check if account has sufficient funds' uses a specific verb and resource, clearly distinguishing it from sibling marketplace tools like ghl_marketplace_charge or ghl_marketplace_get_charges.

  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 vs alternatives, such as checking funds before charging. It only states the action without context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_object_delete_recordA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true, indicating a safe destructive operation. The description adds that the tool deletes by ID and lists supported objects, but does not disclose additional behavioral traits such as error handling, permission requirements, or side effects beyond what annotations imply.

  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 short and to the point, but contains minor redundancy ('Delete Record' repeated from title). The endpoint information is useful but could be condensed. Overall, it is efficient without excessive verbosity.

  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 destructive nature and lack of output schema, the description adequately covers the basic operation. However, it lacks guidance on prerequisites (e.g., record existence) or post-deletion effects, which would help an AI agent handle errors or confirm success. The absence of return value details is acceptable but leaves room for improvement.

  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 descriptions for both parameters (id and schemaKey). The tool description does not add any parameter-level details beyond what the schema provides, so it meets the 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 ('Delete Record By Id') and the resource ('Supported Objects are business and custom objects'). The verb and resource are unambiguous, and it distinguishes itself from sibling object tools like create, update, and get by focusing solely on deletion.

  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 specifies the objects it applies to (business and custom objects) and provides the endpoint, which implies the required parameters (schemaKey, id). It does not explicitly state when to use this tool over alternatives like batch delete or soft delete, but the name and context make the usage clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_opportunity_deleteA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Description adds OAuth scope (opportunities.write) and endpoint path, which are not in annotations. Annotations already declare destructiveHint=true and readOnlyHint=false, so the description complements rather than contradicts.

  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?

  Extremely concise: three lines with no fluff. Front-loaded with the core action 'Delete Opportunity', followed by essential technical details.

  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 delete-by-id tool with no output schema, the description covers the essential action, endpoint, and OAuth scopes. Lacks explicit mention of consequences (e.g., cascading effects), but annotations handle risk transparency.

  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 a single 'id' parameter well-described. Description adds no additional parameter context, so 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?

  Description explicitly states 'Delete Opportunity', which is a specific verb and resource. It distinguishes from sibling opportunity tools (e.g., create, get, update) and other delete tools due to the unique resource type.

  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 (e.g., updating opportunity status instead of deleting). No context on prerequisites or side effects beyond the action itself.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_opportunity_search_advancedA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are present but do not describe side effects beyond basic hints. The description adds OAuth scopes and pagination guidance but no behavioral details like rate limits or data modification. For a search tool, this is acceptable but adds modest value over annotations.

  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 relatively concise, front-loads key information (method, distinction, docs reference), but has some redundancy (first sentence and later 'Search Opportunities based on combinations of advanced filters'). Slightly verbose but overall efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complex nested body and lack of output schema, the description should ideally provide more response context or usage examples. It references external docs for pagination, which is helpful but incomplete for a standalone definition. Still, it covers the essential usage guidance.

  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 description lists the required body fields but does not add meaning beyond what the schema already provides. 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 it's an advanced filter-combination search for opportunities using POST, and explicitly distinguishes it from the simpler GET-based ghl_opportunity_search sibling tool. The verb 'search' and resource 'opportunities' are specific.

  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 clear context on when to use this tool vs. the alternative (ghl_opportunity_search for simple field-filter) and references external pagination guidance. However, it does not explicitly state when not to use it or provide exclusionary criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_payment_custom_provider_get_configA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context by specifying the API endpoint and OAuth scopes (payments/custom-provider.readonly), which aligns with the annotations and provides useful permission 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?

  The description is extremely concise with no wasted words. It front-loads the purpose and adds essential details (endpoint, OAuth scopes) in a structured manner. Every sentence serves a clear purpose.

  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 has a single parameter, high schema coverage, and annotations covering safety, the description is fairly complete. However, it does not describe the return value or structure, which would be helpful since there is no output schema. The endpoint and OAuth scopes add useful 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 a single parameter (locationId) described as 'Location id'. The description does not add additional meaning beyond the schema, so it meets the baseline but does not enhance parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Fetch given provider config' and 'fetching an existing payment config for given location', using a specific verb and resource. It distinguishes this read operation from sibling tools like create, delete, and update config tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or suggest other tools for related tasks.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_product_collection_listA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying the endpoint, OAuth scopes, and pagination behavior, which is consistent with the annotations. No contradictions.

  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 relatively short and front-loaded with the purpose. However, it redundantly states 'Internal API to fetch the Product Collections' after the title, which could be removed to improve conciseness.

  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 covers purpose, endpoint, OAuth, and pagination, but lacks explanation of what a product collection is or what the response contains (no output schema). For a tool with 6 parameters and no output schema, more context would be beneficial.

  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 parameter descriptions. The description only repeats that limit and offset are for pagination, which adds no new meaning beyond the schema. Baseline score for high coverage is 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Fetch Product Collections' and includes endpoint details, making the purpose unmistakably about listing product collections. It is distinct from sibling tools like create/delete/get/update.

  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 list of product collections, but does not explicitly state when to use this tool over alternatives (e.g., when to use get vs list). No exclusions or context about appropriate scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_product_inventory_updateA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate the tool is not read-only (readOnlyHint=false). The description adds value by specifying the endpoint method (POST), OAuth scopes (products/prices.write), and the bulk nature of the operation. However, it does not disclose potential side effects, idempotency, rate limits, or other behavioral details beyond what annotations provide.

  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: only three sentences that cover the action, resource, fields, endpoint, and scopes. Nothing is wasted, and the key information is front-loaded.

  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 complexity (nested objects, single parameter with array of items) and the presence of annotations, the description adequately covers the purpose, key fields, and authentication. It could mention that the update is a full replacement or idempotency, but overall it is sufficiently complete for a bulk update 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?

  With 100% schema description coverage, the baseline is 3. The description mentions 'available quantity and out-of-stock purchase settings', which map to the schema's 'availableQuantity' and 'allowOutOfStockPurchases' fields, but does not add significant meaning beyond what the schema already defines.

  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 Inventory' and specifies the resource (multiple items) and the fields updated (available quantity and out-of-stock purchase settings). It effectively distinguishes from sibling tools like ghl_product_inventory_list (read-only) and other product tools by focusing on inventory bulk update.

  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 explains when to use the tool (bulk update inventory for multiple items) but does not provide explicit guidance on when not to use it or suggest alternatives. No comparison to similar tools like ghl_product_bulk_update is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_bulk_disable_deprecatedA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds the deprecation status and auth requirement (agency-level token). No contradiction detected.

  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 verbose and repetitive, stating deprecation multiple times and mixing endpoint details with prose. Could be streamlined into a concise sentence.

  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?

  As a deprecated tool, the description covers replacement and required token. However, it lacks details on side effects, reversibility, and return values (no output schema). Adequate but incomplete for full operational 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 clear descriptions. The description adds minimal value by mentioning locationIds in the context of disabling, but does not elaborate on format or constraints beyond 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?

  The description clearly states it disables SaaS for locations and explicitly marks the tool as deprecated with a superseding endpoint. The purpose is specific and distinguishes from siblings via deprecation note.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: deprecated, superseded by another endpoint, and requires an agency-level token. This tells the agent when not to use it and what alternative to prefer.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_snapshot_listA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds context about agency-level authentication and the scope of snapshots (own and imported), but does not disclose additional behavioral traits like pagination or rate limits.

  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 concise with three sentences, but includes technical endpoint details (URL, version header) that are likely unnecessary for an AI agent. The important constraint (agency token) is 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?

  The description does not explain return values, pagination, or what 'own and imported' means in practice. Given no output schema, the agent lacks information about the response structure. However, for a simple list operation, 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?

  The input schema has 100% description coverage for its single parameter (companyId), so the baseline is 3. The description does not add any further meaning to the parameter 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 it retrieves a list of all own and imported Snapshots, distinguishing it from other snapshot operations like creating share links or getting push history. The verb 'Get' and resource 'Snapshots' are explicit, and the agency-level token requirement further clarifies 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 explicitly mandates an agency-level token (Agency-Access-Only), guiding the agent on when this tool is applicable. It does not explicitly state when not to use or name alternatives, but the token constraint effectively differentiates from location-scoped tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_csv_listA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by clarifying it's a paginated list (not a single status check), disclosing the endpoint, and noting required parameters (userId). This goes beyond annotations, but it does not detail response behavior or side effects, which are minimal for a read 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 front-loaded with the main purpose and pagination notes. It includes endpoint and version details that may be redundant given the schema, but overall it's well-structured with minimal waste. A slightly more concise version could omit the endpoint line.

  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 covers the tool's basic function, pagination, and required parameters. However, with no output schema, it does not describe the return format (e.g., list of batch objects with status fields), which would be helpful for an agent to understand the response. Given the tool's simplicity and annotations, it is adequate but not 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%, so baseline is 3. The description explicitly mentions skip/limit for pagination and userId as required, adding context. However, it does not explain other parameters like includeUsers or isFromTemplate, which are in the schema but lack additional clarification in 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 clearly states the tool lists the status of ALL CSV bulk-import batches for a location, using a specific verb and resource. It distinguishes itself from a potential single-status check by noting the operationId is misleading, and the tool name (csv_list) contrasts with siblings like ghl_social_csv_finalize, ghl_social_csv_upload, and ghl_social_delete_csv.

  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 mentions pagination support (skip/limit) and that userId is required, providing usage context. However, it does not explicitly state when to use this tool versus alternatives (e.g., when to use list vs. get for individual status), nor does it give exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_delete_likeA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds valuable context: the ID is the Highlevel comment ID (not native), it works for any comment level, and platform limitations. This goes beyond the annotations to clarify 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 relatively concise and front-loaded with the action. The first line ('Unlike a comment') somewhat repeats the title (which is null), but overall it's well-structured with clear sections for platforms and endpoint.

  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, the description adequately explains the input parameters and constraints. However, it lacks any mention of the return value (e.g., empty body on success) or error cases, making it slightly incomplete for a tool with no 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?

  Input schema coverage is 100%, so the schema already documents all three parameters thoroughly. The description repeats some parameter info (e.g., id source, platform enum) but adds the endpoint and version header. It doesn't provide new 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 clearly states the action ('Unlike a comment' and 'Remove a like') and the resource (comment), with specific details about the ID type and supported platforms. It implicitly distinguishes from the sibling 'create_like' by being the removal counterpart.

  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 lists supported platforms and explicitly notes Instagram is not supported, which helps avoid errors. However, it does not provide guidance on when to use this tool versus 'create_like', prerequisites (e.g., must have liked first), 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.

• ghl_social_get_statisticsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses OAuth scopes (socialplanner/statistics.readonly) indicating read-only behavior. No mention of side effects; annotations consistent except for readOnlyHint false. Does not explain why endpoint is POST.

  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?

  Concise main description with defaults; endpoint and scopes appended. Slightly verbose but well-structured with front-loaded 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?

  Covers input behavior and defaults well, but missing output description (no output schema exists). Needs to describe what kind of analytics data is returned.

  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 description does not add meaning beyond what the schema already provides for 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?

  Clearly states verb 'retrieve' and resource 'analytics data for multiple social media accounts.' Distinguishes from siblings which are ad-related or social post management 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?

  Implies usage for retrieving social media statistics with date defaults, but no explicit guidance on when to use vs alternatives like ghl_social_get_posts.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_store_delete_shipping_rateA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, so the description adds the endpoint and ID parameter. It does not disclose additional behavioral traits like side effects (e.g., cascading deletes) or authorization requirements. With annotations covering the destructive nature, the description is minimally 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 concise (two sentences) and front-loaded with the action. It includes the endpoint for clarity 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 delete operation with no output schema, the description provides essential information (ID and endpoint). It could mention that the shipping zone must exist or that deletion is irreversible, but overall 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 description coverage is 75%, and the description only reiterates the shippingRateId parameter. It does not add meaning beyond the schema for the other three parameters (shippingZoneId, altId, altType). Baseline 3 is appropriate as the schema does most of the work.

  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 shipping rate') and specifies the resource ('shipping rate with Id :shippingRateId'). It distinguishes itself from sibling tools like create, update, and get shipping rates by explicitly 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. The name and description imply deletion, but no usage context is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_voice_ai_list_agentsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, etc. Description adds value by disclosing OAuth scopes (voice-ai-agents.readonly), pagination behavior, and endpoint details. This goes beyond the annotations, providing clear 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is concise at four lines, front-loading the purpose. Includes necessary technical details (endpoint, version, scopes) without excessive verbosity. Each sentence adds value, though the endpoint block could be seen as slightly dense.

  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?

  No output schema is provided, so description should compensate by explaining return format. It states 'retrieve a paginated list of agents' but does not detail the structure of the list (e.g., array of agent objects with fields). This leaves some ambiguity for the 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%, so baseline is 3. The description mentions pagination params for paging through result sets, but does not add significant new meaning beyond what is already in the schema descriptions (e.g., page, pageSize, locationId). Adequate but not enhanced.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states 'List Agents' and 'Retrieve a paginated list of agents for given location.' This provides a specific verb (retrieve/list) and resource (agents), and distinguishes from other agent tools like create, delete, or patch agents.

  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?

  Description mentions required locationId and pagination parameters, but does not explicitly contrast with alternatives like ghl_voice_ai_get_agent (single agent retrieval) or state when not to use this tool. Implied usage is for listing all agents, 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.

• ghl_ad_fb_audience_getA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnly, idempotent, non-destructive. The description adds the endpoint URL and OAuth scopes, which provide extra behavioral context beyond 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?

  Very concise, front-loaded with purpose, includes critical endpoint and OAuth details. No unnecessary words.

  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 read tool with no output schema and two required parameters, the description is fully sufficient, covering endpoint, scopes, and purpose.

  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?

  100% schema coverage means the schema already describes all parameters. The tool description does not add any additional meaning or examples beyond what the input 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 the tool gets a specific Facebook custom audience by its ID, with the verb 'Get' and resource 'custom audience'. It distinguishes from sibling tools like list and update.

  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 vs alternatives like list or update. The description assumes the user knows to use it when they have an audience ID but does not explicitly state it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_conversation_form_createA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate non-readonly, non-destructive, and open world. The description adds endpoint details and required OAuth scope (adPublishing.write), which are behavioral constraints not covered by annotations. No contradictions.

  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, with two key sentences plus endpoint and OAuth info. No superfluous text. Information is 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?

  While the description covers endpoint and OAuth, it lacks details on response format, error handling, or prerequisites (e.g., existing Facebook integration). No output schema exists, so more context would be beneficial. Adequate but not 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%, so the schema already documents all required fields. The description adds no extra semantic meaning beyond the schema; it merely repeats the schema verbatim. 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 'Create' and the resource 'Facebook conversation lead form'. It distinguishes from siblings like ghl_ad_fb_conversation_form_list (list) and ghl_ad_fb_lead_form_get (get lead form) by specifying the action and resource type.

  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 endpoint and OAuth scopes but does not explicitly state when to use this tool versus alternatives (e.g., when not to use it, prerequisites). Usage context is implied but not clearly delineated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_pixel_upsertA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Description adds endpoint details and OAuth scopes beyond annotations. Annotations already indicate idempotent and non-destructive, so description complements but does not repeat. Could be more explicit about behavior (e.g., idempotency), 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?

  Very concise: 4 lines with no redundant information. Front-loaded with purpose, followed by technical details. Every sentence adds value.

  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?

  Completeness is adequate given annotations, but missing clarification of return value (no output schema). Description should mention what the API returns to help agent understand response.

  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 already has 100% coverage with descriptions and examples for all parameters. Description does not add extra meaning beyond the schema, so 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?

  Clearly states 'Upsert conversion pixel' and 'Create or update a Facebook conversion pixel configuration', specifying verb and resource. Distinguishes from sibling tool ghl_ad_fb_pixel_list which is for listing pixels.

  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?

  Implied usage is to create or update, but no explicit guidance on when to use versus alternatives (e.g., list tool for reading). Lacks when-not-to-use or prerequisite context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_li_account_getA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the HTTP method (GET), API version, and required OAuth scope (adPublishing.readonly), which helps the agent understand authorization and side-effect profile.

  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 brief and front-loaded with the purpose. It contains four lines, each providing distinct value (purpose, endpoint, version, scopes). Slightly redundant with the title but overall 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?

  For a simple read operation with annotations present, the description covers endpoint, scopes, and basic purpose. Without an output schema, the description could mention typical response fields, but it is adequate for a 2-parameter get 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?

  Schema coverage is 100% with both parameters having descriptions and examples. The description does not add any parameter-specific information beyond what is already in the schema, so it meets the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get ad account details' and 'Retrieve details of a specific LinkedIn ad account', distinguishing it from sibling tools like delete and list operations. 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides endpoint and OAuth scope details which imply usage context, but does not explicitly state when to use this tool versus alternatives like ghl_ad_li_account_list. No when-not-to-use or exclusion guidance is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_li_integration_getA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, making the safety profile clear. The description adds value by specifying the exact endpoint and OAuth scopes (`adPublishing.readonly`), which goes beyond annotations. However, it does not disclose potential error conditions (e.g., what happens if location not found) or rate limits. Hence, strong but not perfect.

  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, with a clear title, a one-sentence explanation of the action, and then technical details (endpoint, version, OAuth scopes) in a compact format. Every sentence is necessary and front-loaded. 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?

  For a simple GET operation with two parameters, the description covers the purpose, required parameter, and authentication. However, it lacks any information about the response format or what fields the integration details contain. Since there is no output schema, the agent might need more context on what data to expect. Additionally, it does not mention if the integration must exist or what happens if it doesn't. Adequate but with 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 covers 100% of parameters with descriptions: `locationId` ('Location identifier') and `isDraft` ('Is draft'). The description does not add any extra meaning beyond the schema. Since schema coverage is high, baseline is 3. The tool name and description already imply locationId is the key parameter, so no further semantic value is provided.

  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 LinkedIn integration' and 'Retrieve the LinkedIn Ads integration details for a location', specifying the exact resource ('LinkedIn Ads integration details') and the scope ('for a location'). The title reinforces this. It is well-differentiated from sibling tools like ghl_ad_fb_integration_get and ghl_ad_google_integration_get by platform name.

  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 does not provide explicit guidance on when to use this tool versus alternatives. It includes technical details like endpoint and OAuth scopes, but lacks 'when to use' or 'when not to use' instructions. The agent must infer from the tool name and context that it is for retrieving LinkedIn integration details, but no contrast with create/update/delete siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_agent_studio_executeA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already show readOnlyHint=false (modifies state) and destructiveHint=false. The description adds session management details but does not elaborate on potential side effects (e.g., agent triggering workflows) beyond stating it executes the agent. This 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 concise and well-structured: a brief intro, bullet points for session management, and endpoint/scopes info. Every sentence adds value without repetition or fluff.

  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 covers the core function and session management adequately but lacks details about the response structure (beyond 'complete agent output'), error conditions, or prerequisites beyond active status. Given no output schema, more detail on the response 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 low (33%)—only body has a structured description. The description adds value by emphasizing locationId requirements and session management for executionId. However, it does not describe agentId or source, and the nested parameters are mostly handled by 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 executes an agent and returns a non-streaming JSON response. It distinguishes itself from siblings like ghl_agent_studio_create, ghl_agent_studio_get_by_id, and the deprecated execute variant by focusing on execution and session management.

  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 usage context: agent must be active, locationId required, and session management rules (omit executionId for first message, include for continuation). However, it does not explicitly compare to alternatives or state 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.

• ghl_agent_studio_listA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and no destructiveness. The description reinforces this by noting it lists active agents and requires locationId, and mentions OAuth scopes (agent-studio.readonly). No contradictions with annotations.

  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 has some redundancy (e.g., repeats 'List Agents' from the title) but is front-loaded with key facts. Could be more concise by integrating the title line into the first sentence.

  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?

  No output schema is provided, so the agent must infer the return shape. The description covers input parameters and pagination but lacks details about the response format, which is important 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 only 20% (only isPublished has a description). The description explains limit, offset for pagination and locationId as required, but does not explain the 'source' parameter. It adds some meaning but not comprehensive.

  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 'Lists agents (paginated via limit/offset)' and distinguishes from a get-by-id lookup. It specifies the resource (agents) and the action (list), differentiating it from siblings like ghl_agent_studio_get_by_id.

  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 explicitly states locationId is required for optimal performance and supports pagination. It also notes it's not a get-by-id lookup, guiding users away from using it for single agent retrieval. However, it doesn't explicitly mention when to use alternatives like get_by_id for specific lookups.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_agent_studio_list_deprecatedA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint true, destructiveHint false, idempotentHint true. The description adds significant behavioral context: it lists only agents with published production versions, requires locationId, supports pagination with limit/offset, specifies the endpoint URL, OAuth scopes, and version header. No contradiction with annotations.

  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 somewhat redundant with repeated deprecation notices and multiple endpoint references. It is front-loaded with the key message but could be more streamlined.

  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?

  No output schema exists, and the description does not explain the return format. For a deprecated tool, the provided endpoint, OAuth scopes, and pagination details are adequate, but the lack of output description limits 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 coverage is 0%, so the description must compensate. It clarifies locationId as required and explains limit/offset for pagination. However, the 'source' parameter is not described, and parameter details are brief. It adds some meaning but not full clarity for all 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 lists active agents with a published production version and explicitly identifies it as deprecated with a direct reference to the replacement (ghl_agent_studio_list). This distinguishes it from siblings effectively.

  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 advises using the replacement tool and provides the new endpoint. It mentions required parameters (locationId) and pagination. However, it lacks explicit guidance on scenarios where using this deprecated tool might still be necessary, though the deprecation message implies avoidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_association_get_by_idA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the specific HTTP method (GET), endpoint path, required OAuth scopes (associations.readonly), and API version. This contextualizes the behavioral traits beyond the 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 extremely concise (three lines) and front-loads the core purpose. It efficiently includes endpoint details and OAuth scopes. No superfluous 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?

  Given no output schema, the description should explain what the response contains or its structure, but it does not. It also omits prerequisites, error conditions, or pagination. While annotations cover safety, the description is incomplete for a retrieval 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?

  There is only one required parameter (associationId). The description implies it is the identifier to look up, which aligns with the parameter name. However, with 0% schema description coverage, the description does not elaborate on the format, constraints, or examples for the associationId. It is adequate but lacks detail.

  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 association by ID' and specifies the types (SYSTEM_DEFINED / USER_DEFINED). The verb 'get' and resource 'association by ID' are unambiguous, distinguishing it from sibling tools like ghl_association_get_by_key_name or ghl_association_get_by_object_key.

  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 mentions it can retrieve both system-defined and user-defined associations, but it does not provide guidance on when to use this tool over alternatives like ghl_association_get_by_key_name or ghl_association_get_relations_by_record_id. No explicit when-to-use or when-not-to-use advice.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_association_listA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds useful context: OAuth scopes, pagination behavior, and the exact endpoint, which goes beyond annotations to disclose operational details.

  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 concise, with purpose stated upfront and additional details (endpoint, OAuth, pagination) in a structured manner. The renaming note is slightly extraneous but adds context without bloating.

  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 3 parameters and no output schema, the description covers purpose, OAuth, pagination, and endpoint. It lacks description of the return format, but given the tool's simplicity and the presence of annotations, 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 0%, so the description must compensate. It explains that skip and limit are pagination parameters and implies locationId is the sub-account ID. However, it lacks detailed semantics (e.g., format, default values, or examples beyond the schema's minimal examples).

  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: 'Get all associations for a sub-account / location' and 'Get all Associations'. It distinguishes from siblings by being the only list operation among association tools, and the renaming note clarifies its evolution from 'find' to 'list'.

  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 basic guidelines: it mentions OAuth scopes (associations.readonly) and pagination parameters (skip, limit) for paging through results. However, it does not explicitly state when to use this tool versus other association tools 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.

• ghl_blog_post_listA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. The description adds valuable behavioral context: paginated (limit, offset), requires blogId and limit, and the exact endpoint and OAuth scope. No side effects are mentioned (as expected for read-only), but the pagination details enhance transparency.

  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 contains some redundancy, e.g., 'Get Blog posts by Blog ID' repeated, and information about the API title could be streamlined. It is not excessively long but could be more concise. The structure includes a clear first sentence defining purpose, but the rest is somewhat messy.

  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 6 parameters and no output schema, the description covers main purpose, required params, pagination, and authentication. However, it omits explanation of locationId or the status/searchTerm filters, and does not hint at the response structure. It is 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?

  The description explains blogId, limit, and offset as required for pagination, but fails to explain locationId (required) or the optional status and searchTerm parameters beyond the schema's minimal documentation. Schema coverage is low (17%), and the description does not fully compensate.

  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 'Lists all posts for a given blogId' and explicitly distinguishes it from a single-post fetch. The verb 'lists' and resource 'posts for a given blogId' are specific. Among siblings like ghl_blog_post_create and ghl_blog_update_post, this tool's purpose is distinct as a 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description mentions required parameters (blogId + limit), pagination, and OAuth scope. It implies this tool is for listing all posts, not a single post, but does not explicitly list alternative tools or when not to use. The context is clear but lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_brand_board_set_default_voiceA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate a write operation (readOnlyHint=false) and non-destructive behavior. The description adds the key behavioral trait that the previous default will be unset, which is beyond the structured annotations. However, it does not cover authentication or permission requirements.

  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 three sentences long, including an endpoint line. The first sentence restates the title unnecessarily, but overall it is efficient and structured with no irrelevant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple write operation with no output schema, the description covers the main behavior and side effect. It does not specify return values or error cases, but given the low complexity, the information is sufficient for an agent to 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?

  Schema coverage is 100% with basic descriptions for locationId and brandVoiceId. The description does not add any additional parameter semantics, 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 sets a brand voice as default for a location, using the verb 'Set'. It distinguishes from sibling tools like create_voice, update_voice, and get_voice by specifying the default-setting action.

  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 explains when to use the tool (to set a default brand voice) but does not provide explicit guidance on when not to use it or mention alternatives among siblings. The side effect of unsetting the previous default is noted, but no exclusions or prerequisites are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_getA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds OAuth scopes (calendars.readonly) and endpoint details, which provide valuable behavioral context beyond annotations.

  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 concise and front-loaded with purpose. It includes endpoint and auth details in a structured manner. Minor redundancy (first line repeats title) but overall 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?

  For a simple read-only tool with one parameter and no output schema, the description covers purpose, parameter reference, endpoint, and auth. It is sufficiently complete for an agent to use 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 schema description coverage is 100% for the single parameter (calendarId described as 'Calendar Id'). The description does not add new details about the parameter beyond restating it in context. 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 'Get calendar by ID', specifying the action (get) and resource (calendar) with the method (by ID). The tool name and endpoint reinforce this, distinguishing it from sibling tools like ghl_calendar_list (list all) and ghl_calendar_create (create).

  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 calendar ID but does not explicitly compare with alternative tools or state when not to use it. The endpoint and OAuth scopes provide some context, but no guidance on selecting among siblings is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_list_free_slotsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark read-only and idempotent. The description adds valuable behavioral context: the 31-day date range constraint, epoch milliseconds requirement, and endpoint details. This goes beyond the structured annotations.

  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 front-loaded with the most important warning, but contains redundancy (the title 'Get Free Slots' appears both as a header and in the sentence). Some lines (endpoint, scopes) could be moved to a separate field. Still reasonably 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 description covers the core operation, constraints, and optional parameters. It lacks details about response format or pagination, which could be important for a listing tool. However, given the absence of an output schema, the description provides minimal but sufficient context for use.

  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?

  With 100% schema description coverage, the schema already documents each parameter. However, the description adds critical clarification that startDate/endDate must be epoch milliseconds (not ISO strings) and reinforces the 31-day limit, which the schema notes but doesn't emphasize the unit 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 tool retrieves free slots for a calendar within a date range, using a specific verb and resource. It distinguishes itself from sibling calendar tools by focusing on free slots, and includes critical detail about epoch milliseconds format.

  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 checking availability within a date range with optional timezone/user filters, but does not explicitly state when to use this tool versus alternatives like ghl_calendar_event_list or ghl_calendar_list_blocked_slots. No when-not-to-use guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_resource_listA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnly, idempotent, non-destructive. Description adds version (2021-04-15), deprecation of v3 variant, OAuth scopes (calendars/resources.readonly), and pagination details. No contradictions.

  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?

  Contains necessary details but repeats 'List Calendar Resources' and includes deprecated block syntax. Could be more concise and better structured with bullet points.

  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?

  Covers version, scopes, pagination, but lacks output schema or response structure details. Since no output schema exists, description should hint at return fields. Pagination usage is explained, but not how response indicates pagination state.

  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 has 4 parameters with 25% description coverage. Description mentions resourceType, locationId, and pagination params (limit, skip), adding context that limit/skip are for pagination. But doesn't explain resourceType enum values beyond schema. Partial improvement over 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?

  Clearly states the verb 'List' and resource 'Calendar Resources', with filtering by resourceType and locationId. Distinct from sibling tools like ghl_calendar_resource_create.

  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 explicit version information, deprecation warning, OAuth scopes, and pagination instructions. Lacks explicit when-not-to-use or alternatives among siblings, but the deprecation note serves as a warning against using the wrong version.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_schedule_getA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds value by disclosing the return content: 'rules, timezone, and associated calendars/users'. This provides behavioral context beyond the annotations, though no side effects or additional constraints are mentioned.

  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 concise, with 4 lines covering title, behavior, endpoint, and OAuth scopes. It is front-loaded with the core purpose. The endpoint and OAuth details are useful but could be considered auxiliary. No unnecessary 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?

  Given the tool's simplicity (one parameter, no output schema), the description sufficiently covers purpose, parameter, and return details. Annotations handle side effects. Sibling differentiation is clear via the get-by-ID pattern. No major gaps for an agent to select and 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?

  Schema coverage is 100% (1 parameter with description). The description repeats that the tool gets a schedule by 'unique identifier' but adds no new semantics beyond what the schema already provides. 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 gets a user availability schedule by its unique identifier. The verb 'get' and the phrase 'retrieve a specific schedule by its unique identifier' precisely define the action and resource. It is easily distinguishable from sibling tools like ghl_calendar_schedule_list, which lists schedules.

  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 you have a schedule ID, but it does not explicitly compare with sibling tools like list or create. There is no guidance on when not to use or when alternatives are better. The usage context 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.

• ghl_calendar_service_booking_deleteA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description aligns by stating 'Delete' and adds useful behavioral context such as the HTTP endpoint and required OAuth scopes (calendars/events.write). No contradictions exist.

  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 concise, consisting of three short lines that convey the action, endpoint, and OAuth scopes. It is efficiently structured with no unnecessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with one parameter, the description is sufficiently complete. It includes the endpoint and OAuth scopes, which are helpful for execution. No output schema is needed, so no gaps remain.

  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 single parameter (bookingId) with type, example, and description. The description does not add additional parameter semantics 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 'Delete Service Booking' and 'Delete a service booking by ID', which explicitly identifies the verb (delete) and resource (service booking). Among siblings, there are distinct create, get, list, update, and delete variants, making this tool easily distinguishable.

  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 states the basic operation (delete by ID) but does not provide explicit guidance on when to use this tool versus alternatives like updating or listing bookings. Usage is implied by the name and operation, but no when-to-use or when-not-to-use context is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_contact_get_by_business_idA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds OAuth scopes (contacts.readonly) and the pagination behavior (limit, skip, startAfter). This provides additional context beyond 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 concise: it states the purpose, endpoint, OAuth scopes, and pagination instructions in a single paragraph with no redundant information.

  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 no output schema, the description could mention the return format (e.g., array of contacts). It provides OAuth scopes and pagination guidance but omits response structure. The mention of 'full result sets' implies pagination behavior but not the shape of results.

  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 description's role is reduced. It lists pagination params and adds usage context ('pass them to page through full result sets') but does not add new semantic meaning beyond the 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 'Get Contacts By BusinessId' and the name reinforces it. It is specific (get contacts by a business ID) and distinguishable from siblings like ghl_contact_get_by_id (single contact) and ghl_contact_list (other filters).

  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 mentions pagination params and advises to 'pass them to page through full result sets,' which provides some usage guidance. However, it does not explicitly state when to use this tool vs other contact retrieval tools (e.g., ghl_contact_get_by_id, ghl_contact_list) or specify prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_ai_get_action_by_idA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by detailing what is returned (configuration, agents, performance metrics) and including endpoint info. No contradictions.

  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 concise and front-loaded with the purpose. It includes additional details (endpoint, scopes) without being verbose. A few words could be trimmed but overall 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?

  Given there is no output schema, the description explains the return value (configuration, agents, performance metrics). It also provides endpoint and auth scopes. Could mention error handling but adequate for a read 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?

  Schema coverage is 50% (one of two parameters has a description). The description does not add extra meaning beyond the schema; it only mentions the endpoint path which is implicit. 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 'Retrieves' and the resource 'action' with its identifier. It distinguishes from sibling tools that create, delete, or list actions by specifying it gets detailed information for a specific action. The title also reinforces the purpose.

  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 an action ID and need details, but it does not explicitly compare with alternatives like list_actions or update_action. No exclusion or when-not-to-use guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_custom_menu_listA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds security context (agency token) and pagination behavior, but does not significantly extend beyond annotations. No contradiction.

  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 well-structured with clear sections (token requirement, overview, endpoint details, OAuth, pagination). It is front-loaded with the important warning. It could be slightly more concise by removing redundant phrases like 'This endpoint allows clients to retrieve...'.

  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 list tool with 5 parameters, high schema coverage, and readOnly/idempotent annotations, the description covers essential aspects: token requirement, filtering via query and locationId, and pagination. It is missing output description and sort options, but these are not critical for a basic 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 coverage is 100%, so baseline is 3. The description adds a minor note on pagination purpose but does not add substantial meaning beyond what the parameter descriptions already provide.

  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 resource 'Custom Menu Links', and explains it fetches a collection based on criteria. It distinguishes from sibling tools like create, delete, get_by_id, update by being a 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a critical prerequisite (agency-level token) and explains pagination (skip, limit) for full result sets. However, it lacks explicit guidance on when to use vs. not use alternatives, though the listing context is clear from siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_email_builder_template_deleteA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint=true and idempotentHint=true. Description adds legacy context and endpoint version but no additional behavioral details beyond annotations. Adequate but not exceptional.

  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?

  Extremely concise: two short sentences and endpoint info. Front-loaded with key legacy context. No unnecessary 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?

  With simple two-param schema no output schema, description covers legacy status and endpoint. Missing typical response behavior (e.g., success code, error cases) but adequate for a straightforward delete operation. Not 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 has 0% parameter descriptions. Description partially compensates by showing path parameters in endpoint, but doesn't explain what locationId or templateId represent or acceptable formats. Baseline 3 due to 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?

  Clearly states it is a legacy API for deleting email builder templates (2021-era), distinguishes from v3 template family, and provides specific verb and resource. No confusion about what it does.

  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?

  Explicitly notes legacy status and non-interchangeability with v3 templates, guiding agents to use only for older email builder templates. Lacks explicit alternatives but the distinction is strong enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_email_template_getA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the endpoint and OAuth scopes but does not contradict annotations. It provides some context beyond annotations, but the behavioral traits are well-covered by annotations, so the contribution is modest.

  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 concise, containing only necessary information: a clear statement of purpose, endpoint, and OAuth scopes. It is front-loaded with the key action. No unnecessary fluff. While it could be slightly more streamlined, it is still well-structured and 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?

  Given that this is a simple read-only GET operation with no output schema, the description is sufficiently complete. It tells the agent what the tool does, the required parameters (via schema), and the required OAuth scope. The agent can confidently invoke it. A return value description would be nice but is not essential for a well-known resource type.

  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 both parameters (locationId and templateId) with examples. The description does not add any additional meaning or constraints beyond what is already in the schema. Baseline score of 3 is appropriate when schema covers all 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 'Get Email Template by ID' and 'Get a single email template by its ID'. The verb 'Get' is specific, and the resource 'email template' is unambiguous. This distinguishes it from sibling tools like 'ghl_email_template_list' (get all) and 'ghl_email_template_create' (create), making its purpose immediately clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides the endpoint and OAuth scopes, implying that this tool is used when you have the specific ID of the template. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'if you need a single template by ID, use this; for all templates use list'). The clarity is good but lacks explicit guidelines.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_email_template_listA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, idempotent, non-destructive. The description adds endpoint details, OAuth scopes, and pagination behavior ('page through full result sets'), providing useful context beyond annotations. No contradictions.

  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 sentences, front-loaded with purpose. Each sentence adds value: purpose, endpoint/oauth, pagination guidance. No fluff or repetition. 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?

  Description covers core behavior (list by location, pagination) but does not summarize the response shape or the include/filtering capabilities. Although schema covers them, a brief summary would improve completeness. Adequate but not exceptional.

  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 description does not need to add param details. It briefly mentions pagination params but adds no new meaning beyond what the schema provides. Score is baseline for full 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 'List templates' and 'Get list of templates by location', using a specific verb and resource. It distinguishes from sibling tools like ghl_email_template_get (single) and other list tools, providing unambiguous purpose.

  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 mentions pagination params and the need for locationId, which guides usage, but it does not explicitly compare with alternatives or state when not to use. Usage is implied through naming but not explicitly guided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_kb_faq_listA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds pagination mechanics (limit, lastFaqId) and endpoint details, which is helpful but does not discuss rate limits, authentication, or response format. With annotations covering most behavioral traits, the description adds marginal value.

  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 four sentences with some redundancy (title repeated), but it remains focused and front-loaded. It efficiently states purpose, retrieval, endpoint, and pagination 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 operation with pagination, the description covers the main purpose and pagination behavior. It does not mention empty results or response structure, but without an output schema, this is acceptable. Required params are clearly indicated in the 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?

  Schema coverage is 100%, with all parameters described. The description reinforces pagination semantics for limit and lastFaqId but adds little beyond what the schema provides. 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 tool retrieves all FAQs for a knowledge base with pagination support. It uses a specific verb ('Get') and resource ('FAQs by knowledge base'), distinguishing it from sibling tools like create, delete, or update.

  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 (listing FAQs for a KB with pagination) but does not explicitly state when not to use it or mention alternatives. It implies usage for retrieving all FAQs, which is reasonable given sibling operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_link_search_triggerA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds endpoint version, OAuth scopes, and pagination guidance, which enrich context beyond 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?

  Very concise: 5 sentences covering purpose, endpoint, scopes, and pagination. No redundant or filler 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?

  Lacks explanation of what 'trigger links' are, how query parameter filters results, and how this compares to ghl_link_list. Output schema absent, but not heavily needed for a search 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?

  Input schema has 100% description coverage, so parameters are already documented. Description only adds brief mention of skip/limit as pagination params; no added semantics for query or locationId beyond 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?

  Description clearly states 'Get list of links by searching' with endpoint and OAuth scopes. Sibling tools have create/delete/get/update verbs, so this search tool is distinctly identifiable.

  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?

  Mentions pagination via skip/limit and OAuth scopes but does not explicitly state when to use this tool vs alternatives like ghl_link_list or provide exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_location_createA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false and destructiveHint=false; the description confirms this is a creation operation and adds security requirements (agency token, plan, OAuth scopes). This provides useful context beyond annotations.

  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 includes redundant HTML formatting and duplicates the tool title. It could be more concise without the markup and repeated phrases.

  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 complex nested schema and no output schema, the description provides the endpoint and OAuth scopes but lacks details about the response format or error handling. It is adequate but not thorough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed descriptions for each property. The description adds no additional meaning beyond stating the schema is verbatim from the OpenAPI spec. Baseline 3 is appropriate as 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 creates a sub-account (location) under a companyId, noting the agency-level token requirement and plan restriction. It distinguishes itself from sibling tools, which are for other location operations (e.g., custom fields, tags).

  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 the tool requires an agency-level token and is only available on the Agency Pro plan. It provides OAuth scopes and endpoint details, giving clear context for when to use. No explicit 'when not to use' or alternatives, but the tool is unique among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_location_deleteA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true; description adds irreversibility and explains the effect of the deleteTwilioAccount parameter, providing useful context beyond structured fields.

  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?

  Key information is front-loaded (token requirement, irreversibility). However, the description includes repeated phrases and extra details like endpoint, version, and source file, which could be trimmed 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?

  Covers essential aspects: purpose, security, irreversibility, and key parameter behavior. For a destructive tool with no output schema, it is sufficiently complete. Could mention typical response but not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (baseline 3). The description adds meaningful context for deleteTwilioAccount (controls Twilio sub-account deletion) beyond the schema description. LocationId is simple and needs no extra explanation.

  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?

  Clearly states it deletes a sub-account (formerly location) from the agency and notes irreversibility. However, the description repeats 'Delete Sub-Account (Formerly Location)' multiple times, which is redundant but still clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly requires an agency-level token and mentions OAuth scopes, setting clear preconditions. Does not explicitly mention when not to use this tool or alternatives, but the name and context imply it's for deletion only.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_location_getA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds context beyond annotations: it specifies the HTTP method (GET), the endpoint path, version header, and required OAuth scopes (locations.readonly). This clarifies the read-only nature and authorization needs. No contradictions with annotations.

  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 efficient with three lines: purpose, action, and technical details. The first line could be merged, but overall it is front-loaded and 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 (single parameter, no output schema), the description provides adequate context including endpoint, version, and OAuth scopes. It lacks mention of response structure or error cases, but these are not critical for such a straightforward retrieval.

  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 parameter 'locationId' described as 'Location Id'. The description reinforces that this is the sub-account ID, but adds no new semantic details. 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 tool retrieves details of a sub-account by its ID, using 'Get' and specifying the resource and parameter. It distinguishes itself from sibling tools like ghl_location_search and ghl_location_get_tags by focusing on a single location retrieval by ID.

  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 should be used when a specific location ID is known, but it does not explicitly guide when to prefer this over alternatives like ghl_location_search or ghl_location_get. No exclusions or usage context beyond the parameter.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_marketplace_get_installer_detailsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, and the description adds details about the endpoint, version header, and OAuth scopes, providing additional behavioral context without contradiction.

  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 concise with a clear title, short functional sentence, and essential metadata (endpoint, scopes), but could be slightly more streamlined by removing redundant title 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 read-only tool with rich annotations, the description covers the purpose, endpoint, and required scopes, though it omits return format details (partially mitigated by listing returned entities).

  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 description for appId is adequate; the tool description does not add extra meaning or usage hints for the parameter beyond what is 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 clearly states the verb 'Fetches' and the resource 'installer details' for the authenticated user, distinguishing it from sibling marketplace tools that deal with charges or uninstallation.

  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 includes OAuth scopes and authentication context, but lacks explicit guidance on when to use this tool versus other marketplace tools (e.g., charge operations) or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_marketplace_get_rebilling_configA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds endpoint details (HTTP method, version header, source file) and OAuth scopes, confirming it's a safe read operation without contradicting annotations.

  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 relatively concise, front-loading the purpose in the first sentence. However, it repeats similar information in the second paragraph. Overall efficient, but minor 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 getter with two required params and good annotations, the description provides the endpoint, authentication details, and a brief note on return value (subscription and usage plans). Could mention potential response structure, but 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?

  Both parameters have descriptions in the input schema (100% coverage). The description adds no additional meaning beyond what the schema provides, so the baseline score 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 retrieves rebilling config for an app subscription and usage plans. It uses specific verb 'Get' and resource 'rebilling config', and the detailed endpoint differentiates it from sibling marketplace tools like ghl_marketplace_charge.

  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 is for reading rebilling configuration for the authenticated sub-account, but does not explicitly state when to use it versus alternatives. No mention of prerequisites or conditions 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.

• ghl_payment_custom_provider_deleteA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already set destructiveHint=true, but the description expands on what destructive means: 'Any in-flight or future payment flows depending on it will fail.' This adds critical behavioral context beyond the annotation flag. Also includes OAuth scopes. However, no output schema is mentioned, which is acceptable for a delete 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 reasonably concise, front-loading the purpose and key consequence in the first sentence. Subsequent lines add endpoint and OAuth scopes, which are somewhat redundant but not excessive. Could be slightly tighter but overall 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?

  For a delete operation with no output schema, the description covers the effect (provider removal, payment flow failure) and includes endpoint details. It does not explicitly state the response format, but the behavior is adequately described. Annotations provide idempotentHint for retries. Completeness is good given the tool's 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?

  With 100% schema description coverage, the schema already documents locationId with example and description. The description adds no further meaning about the parameter, so it meets the baseline but does not enhance understanding 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 it 'permanently removes the custom payment provider integration itself (not just its config)', which is a specific verb-resource pair. It distinguishes from siblings like ghl_payment_custom_provider_create_config by explicitly noting it's not just config deletion. The consequence for payment flows further clarifies scope.

  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 explains when to use (to permanently remove integration) and warns about consequences. However, it does not explicitly state when not to use or mention alternatives (e.g., disconnect_config, update_capabilities). The guideline is implicit but lacks comparative context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_product_updateA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this tool is a mutation (readOnlyHint=false) but not destructive (destructiveHint=false) and idempotent (idempotentHint=true). The description adds context by specifying the HTTP method (PUT), endpoint path, and required OAuth scopes ('products.write'), which is beyond the annotations.

  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 relatively concise, but it redundantly restates the tool name 'Update Product by ID' in the title and first sentence. The endpoint and OAuth scope details are useful but could be more integrated. Overall, it is appropriately sized with minimal waste.

  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 has a complex input schema with many optional fields, but the description provides enough context for a standard update operation. There is no output schema, so the description does not explain return values, but the update operation's typical behavior is implied. The description is adequate for an agent to understand the tool's purpose.

  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 descriptions for all parameters. The tool description does not add any additional meaning beyond what is already in 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?

  Clearly states 'Update Product by ID' and explains it modifies information for a specific product using its unique identifier. The verb is specific (update) and the resource is clearly identified as a product, distinguishing it from sibling tools like ghl_product_create, ghl_product_get, etc.

  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 a single product by ID, but does not explicitly state when to use this tool versus alternatives (e.g., creating, deleting, or listing products). No exclusion criteria or context for when not to use it is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_bulk_enable_deprecatedA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds some behavioral context beyond annotations (e.g., token requirement, version header, endpoint). However, it does not discuss rate limits, error handling, or side effects. Annotations are sparse, so more detail would be beneficial.

  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 contains some redundancy (deprecation notice appears twice). It could be more concise and better structured, though all necessary information is present.

  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 deprecated tool, the description adequately covers purpose, usage, and replacement. However, it lacks details about return values or consequences of using the deprecated endpoint. Given the absence of an output schema, some additional 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 coverage is 100% with descriptions for all parameters. The description does not add significant additional semantics beyond what the schema already provides, so baseline score 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 purpose: 'Bulk Enable SaaS' and 'Enable SaaS mode for multiple locations with support for both SaaS v1 and v2.' It also explicitly notes deprecation and supersession, distinguishing it from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states the tool is deprecated and superseded by POST /saas/bulk-enable-saas/{companyId}, guiding the agent not to use it. It also specifies the required token type: 'REQUIRES AN AGENCY-LEVEL (Company) TOKEN.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_update_rebilling_deprecatedA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds the token requirement but lacks further behavioral insights (e.g., side effects, reversibility). No contradiction with annotations.

  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 contains redundant deprecation statements (two similar lines) and repeats the endpoint URL. It could be more concise while maintaining clarity.

  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 deprecated tool with sibling replacement, the description adequately provides deprecation guidance and authentication requirement. However, it lacks details about the response or error scenarios, which are not covered by annotations or 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?

  Schema coverage is 100% with descriptions for all parameters. The description adds no new parameter-level information 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 'Bulk update rebilling for given locationIds,' which is a specific verb+resource. The tool name includes '_deprecated' and the description explicitly mentions it is superseded, differentiating it from the non-deprecated sibling 'ghl_saas_update_rebilling'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states 'DEPRECATED per spec — superseded by POST /saas/update-rebilling/{companyId}' and prefers the documented replacement. It also notes 'REQUIRES AN AGENCY-LEVEL (Company) TOKEN,' giving clear when-to-use and 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.

• ghl_social_delete_csvA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provided destructiveHint=true and idempotentHint=true. The description adds context by specifying that all associated posts are also deleted, clarifying the scope of destruction. No contradiction with annotations.

  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 short: three lines. The first line 'Delete CSV' is redundant with the tool name and title. The core purpose is captured in the second line. The endpoint line adds technical detail but is acceptable. Could be slightly more concise by omitting the first line.

  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 two parameters and clear annotations. The description explains the key effect. However, it does not specify the response on success (e.g., nothing returned) or error handling. Still, it is adequate given the low 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 both parameters with 100% coverage (CSV Id, Location Id). The description does not add any additional meaning beyond what the schema provides. 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 deletes a CSV import and all its associated posts. The verb 'Delete' and resource 'CSV import' are specific. It distinguishes from sibling tools like ghl_social_delete_csv_post (which deletes a single post) and ghl_social_csv_list (listing imports).

  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 does not explicitly state when to use this tool vs alternatives like ghl_social_delete_csv_post. It implies usage by describing the scope (entire import vs single post), but lacks explicit guidance on prerequisites or when not to use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_get_csv_postA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already indicate a safe read operation. The description adds behavioral context by mentioning pagination params (skip, limit) and how to page through results, which enhances transparency beyond 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 concise with three sentences, front-loading the purpose and including endpoint and pagination details. Every sentence adds value without unnecessary fluff.

  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?

  While the description covers purpose, parameters, and pagination, it lacks details about the return value structure. Since there is no output schema, the agent would benefit from knowing what fields are included in the response. However, for a simple read operation with good annotations and schema, it is fairly 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%, so the schema already documents all parameters. The description only reinforces the pagination behavior without adding new meaning beyond what's in the schema, resulting in a baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and the resource 'details of a specific CSV import including its posts', distinguishing it from sibling tools like ghl_social_delete_csv_post (delete) and ghl_social_csv_list (list).

  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 when to use (when needing details of a specific CSV import and its posts) but does not explicitly state when not to use or mention alternatives. The naming convention among siblings provides some context, but the description itself lacks guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_reset_queue_itemA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond annotations by specifying that the tool discards modifications and resets to original state. Annotations include destructiveHint=false, which is consistent. The endpoint and OAuth scopes are also 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?

  The description is concise (two sentences plus endpoint and scopes), front-loaded with purpose, and every sentence adds value.

  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 covers the main behavioral effect but lacks information about response format, error states, prerequisites (e.g., item existence), or side effects. Given no output schema, more detail would be beneficial.

  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 low (33%), and the description does not compensate by explaining queueId or itemId beyond their appearance in the endpoint URL. The body parameter is described but only with a generic note.

  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 'reset' and the resource 'queue item', and explains the effect: 'resets to its original state, discarding any modifications made.' This differentiates it from siblings like update or 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?

  The description implies usage for reverting modifications but does not explicitly state when to use this tool versus alternatives like update or delete. It lacks 'when not to use' or comparison to siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_account_deleteA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint=true and idempotentHint=true. The description adds critical context: it removes a 'connection' from a location, not the actual Facebook ad account. This clarifies the scope and prevents misuse. No contradictions with 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?

  Extremely concise: two sentences plus endpoint/OAuth details. Front-loaded with purpose. 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?

  The description covers the essential purpose, scope (connection removal), endpoint, and OAuth requirements. It is complete enough for most usage scenarios, though it lacks explicit guidance on alternatives.

  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 clear parameter descriptions (adAccountId: 'Ad account identifier', body.locationId: 'Location identifier'). The description does not add extra semantic 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 tool deletes/removes a Facebook ad account connection from a location. It uses specific verb 'Delete' and resource 'ad account connection', distinguishing it from sibling delete tools for ads, ad sets, campaigns, etc.

  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 guidance on when to use this tool versus alternatives like ghl_ad_fb_account_get or other delete tools. The context implies it's for disconnecting an account from a location, but lacks explicit when-to-use or when-not-to-use instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_adset_deleteA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true, so the destructive nature is clear. The description adds the HTTP endpoint, version header, and required OAuth scopes (adPublishing.write), which are beyond annotations and provide useful 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 concise (4 lines), front-loaded with the title, and includes essential endpoint and auth details without extraneous text. Every sentence adds value.

  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 delete operation, the description covers the endpoint, version, and OAuth scopes. Missing details on success/error responses and irreversibility, but overall adequate given 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?

  Schema coverage is 100% with both parameters having descriptions. The description mentions 'by ID' but adds no extra meaning beyond the schema. 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 explicitly states 'Delete ad set' and 'Delete a Facebook ad set by ID', clearly indicating the verb (delete) and resource (Facebook ad set). This differentiates it from sibling tools for duplicate, pause, resume, and upsert.

  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 no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites (e.g., existence of ad set) or side effects. Usage is implied but not elaborated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_google_segment_getA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds the endpoint version and OAuth scopes, which provide useful technical context but do not contradict annotations. It adds value beyond annotations without repeating them.

  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 brief sentences plus endpoint/scope details. It front-loads the purpose with 'Get segment by ID' and then adds retrieval context. 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 simple read operation with provided annotations and schema, the description is complete enough. It explains the operation and gives API-specific details (endpoint, version, OAuth scopes). No output schema exists, so return value documentation is not expected.

  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 description does not need to add parameter details. It provides no parameter information beyond what the schema already documents, which is acceptable per the 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 'Get segment by ID' and 'Retrieve a specific Google Ads audience segment by ID', using a specific verb (retrieve) and resource (segment by ID). It distinguishes from siblings like ghl_ad_google_segment_list, ghl_ad_google_segment_delete, etc.

  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 when-not-to-use guidance is provided. The description only states the operation. However, for a simple retrieval tool, the name and context sufficiently imply usage, but it does not mention alternatives or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_li_lead_form_listA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the endpoint and OAuth scopes, providing technical context without contradicting annotations. It does not, however, explain return format or pagination.

  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 long, front-loaded with the purpose, and contains no extraneous words. Every sentence adds value.

  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 provides the endpoint and OAuth scopes, which adds useful context. However, there is no output schema, and the description does not describe the response format or pagination behavior, which would be helpful 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 coverage is 100% with all parameters described. The description does not add any new information about parameters 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get lead forms' and 'Retrieve LinkedIn lead gen forms for an ad account.' It uses a specific verb-resource combination and the name 'ghl_ad_li_lead_form_list' distinguishes it from sibling tools like 'ghl_ad_li_lead_form_create'.

  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 indicates when to use the tool (to retrieve lead forms) but provides no explicit guidance on when not to use it or alternatives. While the name suggests listing, no exclusions or comparisons are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_affiliate_listA
  4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by specifying the HTTP method (GET), OAuth scope (affiliate-manager.readonly), and pagination mechanics, which go beyond what annotations provide. No contradictions.

  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 relatively concise, with two main sentences plus technical details (endpoint, OAuth, pagination). It could be more structured, but it efficiently conveys core information without excessive verbosity.

  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 and no output schema, the description fails to explain many input parameters (e.g., query, active, date filters) and does not describe the return format or behavior beyond pagination. This leaves the agent underinformed for effective usage.

  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?

  Input schema coverage is low (25%), with only locationId and limit having descriptions. The description adds pagination context for skip and limit but does not explain the meaning or usage of query, active, toDate, fromDate, and campaignId, leaving a significant gap in parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'List Affiliates' and 'Retrieve the list of affiliates for a location,' clearly specifying the verb and resource. The name and title align, and the tool is distinct from siblings like ghl_affiliate_get (single affiliate) and ghl_affiliate_commission_list (commissions).

  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 context by mentioning endpoint, OAuth scope, and pagination, implying usage for listing affiliates. However, it does not explicitly state when to use this tool versus alternatives (e.g., ghl_affiliate_get for a single affiliate) 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.

• ghl_agent_studio_get_by_id_deprecatedA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds that it returns all versions and requires active status, plus OAuth scopes. No contradictions.

  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 somewhat verbose, repeating deprecation notices multiple times. Could be more concise by consolidating the deprecation warning.

  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 is deprecated, the description adequately explains its status and provides a replacement. However, lack of output schema means return value expectations are not covered, but for a deprecated tool 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?

  Schema coverage is 0%, so description must compensate. It mentions agentId and locationId implicitly and states locationId is required, but does not describe the source parameter. Partial 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 it is a deprecated endpoint to get a specific agent by its ID for a specified location, including all versions. The purpose is clear despite the deprecation emphasis.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly instructs to use the replacement tool ghl_agent_studio_get_by_id instead, specifies required parameter locationId, and notes the agent must have active status. Provides clear when-to-use and alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_brand_board_get_by_idA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint, idempotentHint, destructiveHint. Description adds OAuth scopes and endpoint details, which are useful. No contradictions.

  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?

  Extremely concise: three lines covering purpose, endpoint, and scopes. No unnecessary words. Front-loaded with the most important information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-id operation with full annotations and schema coverage, the description is complete. The absence of an output schema is acceptable for a read 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 coverage is 100% with descriptions for both parameters. Description does not elaborate on parameters, but schema already provides adequate meaning. 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 action ('Retrieves a specific Brand Board by its ID') and the resource. It distinguishes from sibling tools that create, delete, or update brand boards.

  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 guidance on when to use this tool versus alternatives. The description only states what it does, not when to prefer it over other brand board tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_deleteA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint=true and idempotentHint=true. The description adds OAuth scopes 'calendars.write' and endpoint details, enhancing transparency. It does not contradict 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 very concise with three lines: title, action, and endpoint/scopes. Every sentence provides value without fluff, and the key information is front-loaded.

  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 delete-by-ID tool, the description is fairly complete. It includes endpoint, OAuth scopes, and clarifies the action. It does not mention possible cascading effects on related entities (e.g., events), but annotations cover idempotency and destructiveness.

  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% (calendarId described as 'Calendar Id' with example). The description does not add extra parameter semantics beyond implying the ID identifies the calendar, so 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 states 'Delete Calendar' and 'Delete calendar by ID', specifying the verb (delete) and resource (calendar). It distinguishes from siblings like ghl_calendar_get, ghl_calendar_list, etc., by focusing on deletion. The endpoint and OAuth scopes further clarify the action.

  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 does not explicitly state when to use this tool versus alternatives, such as ghl_calendar_event_delete for events or ghl_calendar_update for modifications. However, the name and context make it clear it's for deletion, providing implicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_group_update_statusA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds behavioral context by clarifying that the operation can both enable and disable despite the endpoint name, and specifies OAuth scopes. No contradictions with annotations.

  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 relatively concise, front-loading the key behavioral clarification. However, it includes endpoint metadata (PUT, version, source) that might be extraneous for an AI agent, but this does not significantly harm usability.

  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?

  No output schema is provided. The description does not mention what the tool returns (e.g., updated group object or success status). For a simple toggle tool, this is a notable gap that could lead to agent confusion.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters documented. The description adds value by explaining the semantics of the isActive field (toggle behavior), which goes beyond the schema's brief 'Is Active?' 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 clearly states that the tool updates the status (enable/disable) of a calendar group, explicitly clarifying that the isActive field toggles both directions. This distinguishes it from sibling tools like ghl_calendar_group_update, which handle other group properties.

  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 explains the behavior of the isActive field and provides OAuth scopes, but does not explicitly state when to use this tool versus alternatives like ghl_calendar_group_update. No guidance is given on prerequisites or context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_contact_bulk_update_tagsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Provides context beyond annotations: explains the API endpoint, version source, and the rename from an incorrect auto-generated name. Annotations (readOnlyHint=false, destructiveHint=false) are consistent. No contradictions.

  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?

  Contains some redundancy (e.g., 'Update Contacts Tags' appears twice in the description). Could be more concise while retaining essential details. Still clear and front-loaded.

  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?

  Comprehensive for a bulk update tool with no output schema. Covers operation, required fields, endpoint, version, and rename context. Lacks constraints like maximum contact count or error handling, but sufficient for most use cases.

  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?

  Input schema has 100% coverage, but description adds value by clarifying the `type` parameter's role (add|remove semantics) and summarizing required body fields (contacts, tags, locationId) and optional removeAllTags flag.

  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 bulk add/remove tags across contacts, explains path param `type` selects add|remove semantics, and notes the name correction. Distinguishes from similar sibling tools like ghl_contact_add_tags and ghl_contact_remove_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?

  Implicitly suggests usage for bulk operations via name and content, but does not explicitly state when to use this tool vs alternatives (e.g., single-contact tag operations). No explicit exclusions or alternative references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_ai_search_agentA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds behavioral context such as the GET endpoint, OAuth scopes, and pagination behavior, which are not covered by annotations.

  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 concise with four sentences covering purpose, endpoint, scopes, and pagination. It is front-loaded with the main action, though the first line 'Search Agents' is redundant with the annotation title.

  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 search tool with pagination and no output schema, the description adequately covers the endpoint, scopes, and pagination. However, it does not explain what the response looks like, error conditions, or that the query parameter is optional.

  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 clear descriptions for each parameter. The description adds pagination grouping and mentions 'status and configuration' as search criteria, though these are not present in the schema. This adds slight confusion but overall adds some value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Searches for AI agents based on various criteria' and provides a specific verb-resource pair. It distinguishes itself from sibling tools like ghl_conversation_ai_get_agent and ghl_conversation_search by focusing on search with filtering and full-text capabilities.

  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 explains when to use the tool (searching agents by criteria) and includes pagination guidance with startAfter and limit. However, it does not explicitly mention when not to use it or suggest alternatives like get_agent for a single agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_download_message_transcriptionA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, etc. The description adds that the response is a file download (text/plain) with Content-Disposition header, which is beyond the annotations. No contradictions.

  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 somewhat verbose with repetitive phrases ('Download transcription by Message ID' and 'Download the recording transcription...'), and includes technical endpoint details that may not be needed. It could be more 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 no output schema, the description adequately explains the response format (text/plain file download), provides the endpoint and required scopes. It does not explain prerequisites like needing an existing transcription, but for a simple download tool it is fairly 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 input schema has 100% description coverage for both parameters. The description does not add new meaning beyond what the schema provides (just 'messageId' and 'locationId'). 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 tool downloads a transcription file (text/plain) for a given message ID, and explicitly distinguishes it from the sibling tool that returns JSON. The verb 'download' and resource 'transcription by message ID' are specific and actionable.

  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 explains when to use this tool (to download a transcription as a file) versus the alternative GET /transcription endpoint, and lists required OAuth scopes. While it does not explicitly state when not to use it, the distinction is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_get_messageA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which already convey the tool's safe, read-only nature. The description adds valuable context about the inferred `id` parameter due to a spec gap, the endpoint method (GET), and required OAuth scopes. No contradictions with annotations.

  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 somewhat verbose, including a technical note about the spec gap and source details. The purpose statement is repeated twice. While not excessively long, it could be more streamlined by removing the repetition and focusing on essential information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has a single parameter, rich annotations, and no output schema, the description adequately covers the endpoint, auth requirements, and the spec issue. However, it does not describe the response shape or return value, which would be helpful since there is no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for the single `id` parameter, describing it as a required path parameter. The description adds context beyond the schema by explaining that the official spec omitted the `id` declaration and that it is inferred from the URL template, which clarifies the parameter's origin and necessity.

  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 explicitly states 'Get message by message id', clearly indicating the verb (get) and resource (message by ID). This distinguishes it from sibling tools like ghl_conversation_get_messages (which retrieves multiple messages) and ghl_conversation_get (which gets a conversation rather than a message).

  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 mentions OAuth scopes and the requirement for the `id` parameter, but it does not provide guidance on when to use this tool versus alternatives (e.g., listing messages vs. getting a single message). It lacks explicit 'when to use' or 'when not to use' statements.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_send_messageA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds context about PHI-adjacent data and required fields. However, it does not disclose side effects like triggering notifications or updating conversation state. No contradiction with annotations.

  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 front-loaded with critical warnings (PHI-adjacent, required fields) and is mostly concise. A few extra details could be trimmed, but overall 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?

  Given the complexity (nested object, many optional fields) and no output schema, the description covers usage well but omits return value details. It could be more complete about what the response looks like.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but the description adds value by noting that 'status' is unusual for outbound sends yet required, and instructs to populate type-appropriate fields (message/html/subject for Email, fromNumber/toNumber for SMS, attachments as URLs). This goes beyond what the schema defines.

  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 'sends a message on a real conversation thread' and 'Send a new message', specifying the verb (send) and resource (message). It distinguishes from sibling tools like ghl_conversation_add_inbound_message by emphasizing the real conversation thread 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 provides explicit guidance that all four required fields must be supplied or the API returns 400, and advises to populate type-appropriate fields. However, it does not explicitly state when to avoid this tool versus alternatives like ghl_conversation_add_inbound_message.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_custom_field_updateA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds critical context: locationId and showInForms are required on every update, and options replacement behavior (must include all existing options). No contradiction.

  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 contains redundant text ('Update Custom Field By Id' repeated) and a technical first sentence. Could be more streamlined, though the info callout and critical details are well-placed.

  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?

  Covers supported objects, required fields, and options replacement behavior. No output schema exists, so return values are not expected. Adequate for a nested-parameter update 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 emphasizes that locationId and showInForms are required on every update, reinforcing the schema. However, the 'id' parameter lacks description in both schema and description. Overall, moderate added 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?

  The description clearly states 'Update Custom Field By Id' and specifies it supports only Custom Objects and Company, distinguishing it from siblings like ghl_custom_field_create, ghl_custom_field_delete, etc.

  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 when-not guidance by stating the tool only supports Custom Objects and Company, helping the agent avoid misuse. It lacks explicit alternatives but the scope limitation is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_custom_menu_deleteA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true; the description reinforces this. The additional disclosure about agency-level token requirement adds behavioral context beyond annotations. No contradictions.

  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 has some redundancy (title appears twice) and could be more compact. The security note is important but interrupts flow. Still, it is reasonably clear and not overly long.

  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 delete operation with one parameter and no output schema, the description covers the essential: action, required parameter, and token requirement. It does not detail error cases or success response, but it is adequate for an AI agent to use 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?

  Schema description coverage is 100%, so the description adds little beyond restating that the custom menu is identified by its ID. The example in the schema provides format detail, but the description does not enhance parameter 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 verb ('Delete Custom Menu Link') and resource, and explains that it removes a specific custom menu identified by its ID. It effectively distinguishes from siblings like create, get, list, and update.

  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 explicit guidance that only agency-level (Company) tokens are allowed, which is a critical usage constraint. However, it does not elaborate on when to use vs. alternatives, though the deletion purpose is clear relative to siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_email_builder_template_getA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds behavioral details: endpoint method (GET), required API version header (2021-07-28), OAuth scopes, and pagination mechanics (limit, offset). This enriches the agent's understanding of how the tool operates. No contradiction with 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 concise, with five sentences that each add value. It front-loads the legacy context, then covers endpoint, scopes, and pagination. No redundant or verbose language.

  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 complexity (11 parameters, no output schema), the description adequately covers purpose, legacy context, endpoint, auth, and pagination. However, it omits explanations for most parameters and does not describe the return format, leaving gaps for a complete understanding.

  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?

  With 0% schema description coverage, the description must compensate but only explains locationId implicitly and pagination parameters (limit, offset). The other 9 parameters (name, search, archived, originId, parentId, sortByDate, templatesOnly, builderVersion) are not described. The agent would have no guidance on their semantics beyond default values.

  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 fetches email templates from a legacy API, explicitly distinguishing it from the v3 template family. The verb 'Fetch' and resource 'email templates' are specific, and the legacy context differentiates it from sibling tools like ghl_email_template_get.

  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 contrasts this legacy API with the v3 template family, noting they are not interchangeable. This provides clear guidance on when to use this tool (legacy builder templates) versus alternatives. It does not explicitly list when not to use it, but the distinction implies the exclusion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_invoice_getA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context such as the endpoint, OAuth scopes (invoices.readonly), and version header, which are not in annotations. No contradictions 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 concise (4 lines) and front-loaded with the core purpose. Every sentence adds value: purpose, endpoint, version, OAuth scopes. No redundant or irrelevant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple nature of a get-by-ID operation, the description provides sufficient context including endpoint, OAuth scopes, and version. No output schema exists, but that is acceptable. It covers key aspects for a developer to use 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?

  Input schema covers all 3 parameters with descriptions and examples (100% coverage). The description adds no meaning beyond what the schema provides; it only mentions 'by invoice id' which is already in the schema's invoiceId 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 clearly states 'Get invoice' and 'API to get invoice by invoice id', using a specific verb ('get') and resource ('invoice'). Among siblings like ghl_invoice_create, ghl_invoice_delete, etc., the purpose is distinct 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 usage (get an invoice by ID) but provides no explicit guidance on when to use this tool over alternatives, prerequisites, or exclusions. Usage is implied by the naming convention, but not stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_oauth_get_access_tokenA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations, the description discloses that the operation has no security scheme (credentials in body), defaults to form-encoded body but accepts JSON, and references the spec. No contradictions with annotations.

  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 relatively concise with key information front-loaded, though some redundancy exists (e.g., 'Get Access Token' appears in title and description). Overall, it is 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 description covers purpose, grant types, content type, and security, but lacks details about the expected response format and error scenarios. Given the absence of an output schema, more detail on the response would improve completeness.

  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 has 100% coverage with descriptions for all parameters. The description adds value by explaining the content type handling and that client credentials go in the body, which is not obvious from the schema 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 clearly states the tool performs OAuth2 token exchange for authorization_code and refresh_token grants to obtain access tokens for accessing CRM resources. It distinguishes itself from sibling tools by specifying the grant types and content type handling.

  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 explains when to use the tool ('to access CRM resources') and provides some context on content type defaults, but does not explicitly state when not to use it or compare with sibling OAuth tools like ghl_oauth_get_location_access_token.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_object_get_schema_by_keyA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds meaningful context: the returned data includes all fields and properties, supported objects, the endpoint URL, version header, source file, and OAuth scopes. No contradictions with annotations. Some details like error handling are omitted.

  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 includes useful information but is somewhat verbose, with URL, endpoint, version, source, and OAuth scopes. This content could be moved to metadata or annotations. The first sentence is clear but the long paragraph could be more 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?

  No output schema exists, so the description's statement that it returns 'the schema of the custom object, including all its fields and properties' provides sufficient completeness. It also lists supported object types. Lacks error handling or performance notes, but overall adequate for a read-only, idempotent schema retrieval.

  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 descriptions already document each parameter. The description mentions 'key or ID' but the input schema only has a 'key' parameter, causing slight confusion. It does not add significant meaning beyond the schema. 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 'Get Object Schema by key / id' and elaborates that it retrieves the schema of a custom object including all fields and properties. It specifies supported objects (contact, opportunity, business, custom objects) and distinguishes itself from sibling tools like ghl_object_get_record_by_id which operate on records rather than schema.

  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 indicates this tool is for schema retrieval, not record manipulation. It lists supported object types and provides a documentation link. While it does not explicitly contrast with alternatives, the context of sibling tools (mostly unrelated) makes the tool's role clear. A more explicit when-to-use/not-use statement would improve clarity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_object_listA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description reinforces read-only nature with OAuth scopes objects/schema.readonly and provides endpoint and version info. No contradictions; description adds useful context beyond annotations.

  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?

  Description is somewhat verbose with renaming explanation and documentation link. The first sentence is clear, but the meta-commentary about renaming could be distilled. OAuth scopes line is useful but front-loading could be better.

  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 list tool with one parameter and no output schema, the description covers purpose, scope, standard vs custom objects, and provides a documentation link. Lacks return format details but is adequate for agent decision-making.

  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 one parameter locationId described as 'location id' and an example. Description mentions 'for a location' but adds no additional semantic detail or format guidance 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?

  Description clearly states the verb 'lists' and resource 'all objects (standard: contact/opportunity/business, plus custom) for a location'. It distinguishes from sibling tools like ghl_object_get_schema_by_key by mentioning the renaming and contrast with single-object 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?

  Description provides context by contrasting with the ambiguous auto-generated name and noting it follows list/get_by_id naming. However, it does not explicitly state when to use this tool vs alternatives like ghl_object_search_records or ghl_object_get_record_by_id.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_payment_custom_provider_disconnect_configA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds context beyond annotations by noting the potential interruption of live payment collection. Annotations (destructiveHint=false) are consistent since disconnection disrupts but does not destroy data. Includes OAuth scopes and endpoint details.

  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 contains redundancy ('Disconnect existing provider config' repeats the purpose) and is not as concise as it could be. It still conveys the necessary information but could be tightened.

  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?

  Reasonably complete given no output schema: covers the effect, parameters, endpoint, and auth. Could mention recovery but the interruption warning suffices. The tool's role among many siblings is clear.

  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 both parameters (locationId, body.liveMode) are already well-described in the schema. The description does not add additional semantic meaning or usage details for 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 disconnects the custom payment provider's live/test config with a specific verb and resource. It distinguishes itself from sibling tools like create, delete, and get_config by explicitly stating it's a disconnect 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 on when to use: to disconnect an existing payment config. Includes a warning about interrupting live payment collection. However, it does not explicitly state when not to use or mention alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_payment_transaction_getA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the HTTP method (GET), endpoint path, and OAuth scopes, which are consistent with annotations and provide useful implementation details.

  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 concise and front-loaded with the title. It includes necessary details (endpoint, scopes) without unnecessary fluff, though it could be slightly more compact.

  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 lacks information about the return format or response structure. Since there is no output schema, the agent needs to know what fields are returned, but this is omitted. The description covers the purpose and usage but not the output, which is a gap for a retrieval 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?

  Schema coverage is 100% with descriptions for all parameters. The description does not add extra parameter semantics beyond noting that transactionId is the path parameter, but since the schema is comprehensive, 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.

  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 information for a specific transaction by its unique ID, using phrases like 'Get Transaction by ID' and 'fetch details for a single transaction.' It differentiates from listing tools by focusing on a single resource.

  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 explains when to use the tool (to fetch details for a single transaction) and includes OAuth scopes. It does not explicitly mention alternatives or when not to use it, but the context of siblings (e.g., ghl_payment_transaction_list) provides implicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_payment_transaction_listA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, confirming safe read behavior. The description adds value beyond annotations by explaining pagination (limit, offset), filtering capabilities, and OAuth scopes, which inform the agent of important behavioral aspects.

  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 front-loaded with the core purpose and contains four sentences. It includes technical details like endpoint and OAuth scopes which, while not strictly necessary, add context without excessive verbosity. Slightly less concise than ideal but 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 many parameters and no output schema. The description covers filtering and pagination adequately but omits details on response structure, sorting, or total count. Given the complexity and absence of output schema, more completeness would be beneficial.

  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?

  Input schema has 100% description coverage, providing baseline value. The description adds semantic grouping of filter options (name, alt type, date range, etc.) and explicitly mentions pagination parameters, helping the agent understand which filters are available and how to page 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 it retrieves a paginated list of transactions with filtering options. The verb 'List' matches the resource 'Transactions', distinguishing it from sibling tools like `ghl_payment_transaction_get` (single transaction) and `ghl_payment_subscription_list`.

  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 explains what the tool does but provides no explicit guidance on when to use it versus other list tools (e.g., `ghl_payment_order_list`). Usage context is implied through the resource name, but no exclusion or alternative recommendations are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_pipeline_listA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the endpoint details and OAuth scopes, and mentions that stages are included. However, it does not describe the return structure or pagination, which would be helpful given no output 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 very concise, consisting of two sentences plus endpoint details. It front-loads the core functionality and avoids unnecessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple nature of the tool (one required param, read-only) and annotations covering safety, the description is mostly complete. It lacks details about the response structure (e.g., shape of pipelines and stages), but the core purpose is well-conveyed.

  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?

  Only one parameter (locationId) with full schema coverage. The description does not add any additional meaning beyond what the schema already provides, so 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 it 'lists pipelines (and their stages) for a location,' specifying the verb and resource. It also distinguishes itself by noting it's named as a pipeline tool per convention despite living under the opportunities path.

  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 guidance on when to use this tool versus alternatives, but it is the only pipeline list tool among siblings, reducing confusion. The endpoint and OAuth scopes are provided but do not specify usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_product_price_getA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey readOnlyHint=true and destructiveHint=false, so the description adds minimal extra behavioral context (endpoint, scopes). It doesn't disclose traits like performance or rate limits.

  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 brief: a title, a sentence explaining functionality, and three lines of metadata. No redundant information. Front-loaded with the purpose.

  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 tool with annotations, the description covers what it does, endpoint, and auth. It doesn't specify return format, but that's acceptable. Overall sufficient for an agent to select and 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?

  All three parameters have descriptions in the input schema (100% coverage). The description adds no further details beyond mentioning 'using its unique identifier', which is already implied.

  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 Price by ID for a Product' and explains it retrieves information for a specific price using a unique identifier. It distinguishes from sibling tools like list, create, update, delete by focusing on a single resource.

  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 indicates when to use: to fetch details for a single price. It provides endpoint and OAuth scopes. However, it does not explicitly state when not to use or compare with alternatives like ghl_product_price_list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_proposal_list_templatesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds pagination behavior and endpoint details. No contradictions, but no additional behavioral traits (auth, rate limits, return format) are 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 concise with three sentences: a title line, a brief explanation of what the tool does, and endpoint/pagination info. No fluff 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 good annotations and full schema coverage, the description is mostly complete. It mentions pagination but lacks description of the output structure (no output schema). Still adequate for typical usage.

  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 all 9 parameters documented. The description does not add any extra meaning beyond what the schema already provides, so 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 states 'List document contract templates for a location', which is a specific verb+resource. It distinguishes from the sibling 'ghl_proposal_list_documents' which likely lists actual documents rather than 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 mentions pagination parameters (limit, skip) and explains how to use them to page through results. However, it does not explicitly state when to use this tool versus alternatives like ghl_proposal_list_documents, nor does it provide exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_pause_location_deprecatedA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Description mentions auth requirement and deprecation but adds little beyond annotations. Annotations already indicate mutation (readOnlyHint=false) and non-destructive nature (destructiveHint=false). No contradiction.

  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?

  Description is functional but repetitive (deprecation notice appears twice). Could be more concise, but core information is present and accessible.

  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?

  Covers deprecation, authentication level, endpoint details, and required parameters. Lacks explanation of pausing effects, but given the tool's simplicity and annotations, 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 100%, so baseline 3. Description restates the parameters (locationId, body) without adding new meaning or constraints 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?

  Clearly states the tool pauses a location/subaccount, includes verb and resource. Deprecation and replacement are explicitly noted, distinguishing it from the newer ghl_saas_pause_location sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states DEPRECATED and superseded by a specific endpoint, guiding agents to prefer the replacement. Also requires agency-level token, providing clear usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_category_listA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it is safe and non-destructive. The description adds behavioral context: the endpoint (GET), OAuth scopes, and pagination mechanism. No contradictions with 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 concise with three sentences and endpoint details, no fluff. The main purpose is front-loaded in the first sentence, followed by endpoint and OAuth info, then pagination guidance.

  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 no output schema, the description omits details about the return type (list of categories) but covers pagination and required locatioparameter. The tool is straightforward, so the description is mostly complete. Could briefly mention the response structure.

  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 descriptions for each parameter. The description adds meaning by grouping limit and skip as pagination params and mentioning 'optional search', but does not provide additional semantics beyond the schema for locationId or searchText. 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 'Get categories by location id' and 'Retrieve all categories for a specific location with optional search and pagination', providing a specific verb and resource. It distinguishes from sibling tools like ghl_social_category_get (singular) and ghl_social_fetch_available_categories by focusing on location-based listing with pagination.

  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 categories filtered by location with optional search and pagination, but does not explicitly state when not to use or compare to alternatives like ghl_social_category_get or ghl_social_fetch_available_categories. The guidance on pagination params (limit, skip) is helpful but lacks exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_clone_queue_itemA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the requirement for an active edit session beyond the annotations (readOnlyHint=false, destructiveHint=false), which is valuable. However, it does not detail side effects or output behavior, nor does it contradict annotations.

  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 brief and front-loaded with the action, but includes endpoint and OAuth scope details that are likely redundant for an AI agent. Still, it is efficient and under two sentences.

  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 covers the key prerequisite (active edit session) but lacks information about the return value or output, which is not compensated by an output schema. Given the tool complexity and no output schema, more detail would be beneficial.

  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 descriptions for nested properties like order, sessionId, and locationId, but the top-level description for body is generic. The tool description does not add additional semantic meaning beyond what the schema already provides, resulting in minimal added 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?

  The description clearly states the verb 'Clone' and the resource 'queue item', and specifying 'Duplicates an existing queue item at a specified order position' distinguishes it from sibling tools like create, update, or delete queue items.

  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 notes the prerequisite of an active edit session, providing important usage context, but does not explicitly compare to alternatives or state when not to use this tool versus other duplication methods.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_get_tags_location_idA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by detailing pagination behavior (limit, skip parameters) and the endpoint, which goes beyond the annotation hints. No contradiction with annotations.

  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 three sentences, front-loading the main purpose. The first sentence repeats the title, introducing slight redundancy, but overall it is concise and well-structured. Each sentence adds meaningful information.

  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, the description could explain the return format (list of tag objects). It covers pagination and search but lacks details on what the tags contain or how they relate to other social tools. Annotations provide behavioral context, but completeness is adequate rather than thorough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% but descriptions are minimal. The description adds meaning by explaining pagination parameters (limit, skip) for paging through results and mentions optional search, clarifying the searchText parameter's purpose. This adds useful context 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 it retrieves tags by location ID, with specific verb 'get' and resource 'tags by location id'. It distinguishes itself from sibling tools like ghl_social_get_tags_by_ids by emphasizing the location-based retrieval.

  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 explains the basic use case (retrieve tags for a specific location with optional search and pagination) but provides no explicit guidance on when to use this tool versus alternatives like ghl_social_get_tags_by_ids. No when-not or context exclusions are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_voice_ai_get_actionA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate read-only, idempotent, and non-destructive behavior. Description adds useful context: endpoint, version header, OAuth scopes, and that it returns action configuration including actionParameters. Does not discuss error handling or rate limits, but is satisfactory beyond 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?

  Description is concise with purposeful sentences: a clear title, a one-sentence purpose, then technical details. No redundant information; each line adds value.

  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?

  No output schema, but description mentions return of 'action configuration including actionParameters'. Provides endpoint, version, and OAuth scopes. Does not list error conditions but is adequate for a simple GET-by-ID 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 coverage is 100% with parameter descriptions in the schema. Description does not add significant extra meaning for parameters beyond what schema already provides. Baseline score 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?

  Description clearly states 'Retrieve details of a specific action by its ID' and 'Get Agent Action', providing a specific verb and resource. It distinguishes itself from sibling tools like create, delete, and update actions by focusing on retrieval.

  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 guidance on when to use this tool versus alternatives (e.g., list agents or list actions). The description implies usage when an action ID is known, but lacks when-not conditions or alternative tool mentions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_google_targeting_searchA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by specifying the HTTP method (GET), API endpoint, version, and required OAuth scopes, providing behavioral context beyond annotations without contradiction.

  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?

  Description is extremely concise: two lines of purpose, followed by endpoint and scopes. No wasted words; essential 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description does not specify return format. While the tool is simple and annotations cover safety traits, a mention of typical response structure (e.g., list of locations) would improve completeness for agent usage.

  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 and example. The description adds minimal extra meaning, only implying the search target via 'geo-locations' without explaining how parameters like locationId relate to the query or type.

  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 explicitly states 'Search Google geo-locations for ad targeting', combining a specific verb (Search) and resource (Google geo-locations). This clearly distinguishes it from sibling tools like ghl_ad_fb_targeting_search and ghl_ad_li_targeting_search, which target different ad platforms.

  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 for use (Google ad targeting, requires adPublishing.readonly scope). However, no explicit 'when not to use' or direct comparison to sibling tools; the differentiation relies on the tool name and implicit platform specificity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_affiliate_getA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false. The description adds behavioral context: the endpoint, version header, source, and required OAuth scopes. This information aids the agent in understanding invocation requirements beyond the 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 extremely concise: a title, one sentence summarizing purpose, then endpoint and OAuth details. No redundant information, and all content is front-loaded.

  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 read-by-ID tool with full annotations and complete parameter schema, the description provides all necessary context (purpose, endpoint, authentication). No output schema is needed for this straightforward 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?

  Input schema has 100% coverage with descriptions for both required parameters (locationId, affiliateId). The description does not add any additional parameter semantics beyond what the schema provides, 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 'Get Affiliate' and 'Retrieve a single affiliate by id for a location.' It specifies the verb (retrieve) and resource (affiliate by ID and location), distinguishing it from sibling tools like ghl_affiliate_list which lists multiple affiliates.

  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 guidance on when to use this tool vs alternatives. While the name and description imply single-affiliate retrieval, it doesn't mention contexts where ghl_affiliate_list would be more appropriate or provide exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_appointment_getA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds endpoint details (HTTP GET, version header, OAuth scopes) which provide additional behavioral context without contradicting annotations.

  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 concise with three sentences: title, short description, then technical details. It is front-loaded with the core purpose.

  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 single parameter with schema description, annotations, and no output schema, the description provides sufficient context including endpoint, API version, and OAuth scopes.

  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 a detailed description of eventId. The tool description adds no further parameter semantics, so baseline is 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and resource 'Appointment by ID'. It distinguishes from sibling tools like create, update, delete, and list by focusing on retrieval by ID.

  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 for fetching a specific appointment by ID. While it doesn't explicitly exclude alternatives, the context is clear enough for an agent to infer when to use this tool over others.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_appointment_note_listA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, non-destructive. Description adds endpoint, OAuth scope, and pagination details (limit/offset for full results). Does not contradict 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?

  Three sentences front-loaded with purpose ('Get Notes', 'Get Appointment Notes'), followed by endpoint, scopes, and pagination. 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?

  Covers purpose, parameters, and pagination well. Missing description of return value structure (no output schema exists), which would help agent understand the response format.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema already describes each parameter (100% coverage). Description adds context that limit and offset are for pagination to get full result sets, which is not in 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?

  Description explicitly states 'Get Appointment Notes', uses verb 'Get' and resource 'Notes'. Distinguishes from siblings like create/delete/update and contact notes 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?

  No explicit guidance on when to use vs alternatives (e.g., contact notes). OAuth scope implies read-only calendar usage, but no when-not or alternative references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_resource_getA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context such as the specific API version to use, deprecation status, and OAuth scopes, which go beyond the structured annotations.

  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 reasonably concise, front-loading the main purpose. The deprecation warning and version details, while important, add some wordiness. Still, most sentences serve a clear purpose.

  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 operation, the description covers version, deprecation, scopes, and endpoint. No output schema exists, but the response is standard for a resource get. Annotations cover safety. Slightly incomplete due to lack of return value description.

  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 descriptions for both parameters. The description clarifies how parameters map to the URL path (resourceType, id) but adds no additional meaning beyond the schema. 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 'Get Calendar Resource' and 'Get calendar resource by ID (Services V1)', using a specific verb+resource pattern. It is easily distinguishable from siblings like create, delete, list, and update.

  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 warns against using Version: v3 for resource endpoints and notes deprecation, which guides correct usage. It also specifies the endpoint and OAuth scopes, but does not explicitly contrast with alternative tools beyond noting the deprecated variant.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_ai_get_agentA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context beyond annotations by detailing the returned fields (name, status, actions, settings) and specifying OAuth scope (conversation-ai.readonly), which is useful for authorization understanding.

  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 compact with no fluff: a title line, one sentence on retrieval purpose, one on return contents, and then endpoint and scopes. It is front-loaded with the most important action first.

  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 read tool with one parameter and no output schema, the description sufficiently covers purpose, return value, endpoint, and authorization. Annotations confirm safe behavior, making it complete for its 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?

  Schema coverage is 100% with a clear description and example for agentId. The description does not add additional meaning beyond what the schema provides, meeting baseline expectations.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it retrieves a specific AI agent by ID and returns the complete configuration including name, status, actions, and settings. This distinguishes it from sibling tools like get_action_by_id and get_generation by focusing on agents.

  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 guidance on when to use this tool versus alternatives like search_agent or list_actions. The description implies usage for retrieving a known agent by ID, but does not provide when-not to use or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_export_messages_by_locationA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: cursor-based pagination, default channel behavior (all non-email types including activity messages), OAuth scopes, and endpoint details. This goes well beyond annotations without contradiction.

  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 well-structured. It front-loads the main purpose, followed by pagination details, channel behavior, and then technical metadata (endpoint, OAuth scopes). Every sentence serves a purpose without 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?

  Given 10 parameters and no output schema, the description covers the core functionality and pagination but only partially describes the response structure (lists only three fields: messageType, source, subType). It does not mention pagination response fields or the full set of return values. The agent may need to infer additional response structure from the pagination mention.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the channel parameter's default behavior (returns all non-email types including activity messages unless channel=Email is set) and that limit/cursor are for pagination. This provides context that the schema alone does not.

  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 purpose: export messages by location ID. It specifies the verb (export), resource (messages by location), and provides additional scope details such as cursor-based pagination, response fields, and channel behavior. This distinguishes it from other conversation tools like ghl_conversation_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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides context for when to use the tool (e.g., for exporting messages with pagination, channel behavior). However, it does not explicitly state when not to use it or provide direct comparisons to sibling tools such as ghl_conversation_get_messages. Implicit guidance is present but not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_update_custom_subtypeA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds that it can update or archive (with archived=true), which is a behavioral nuance. It also discloses the admin role requirement and endpoint. No contradictions with annotations.

  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 concise at three sentences, but the first line ('Update Custom Subtype') is redundant with the title from annotations. The essential info (update/archive, role, endpoint) is present and well-structured. Slightly front-loaded but could be more 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?

  Given no output schema and moderate complexity (nested body), the description covers the tool's purpose, role requirement, and endpoint. It does not explain return values or error handling, but the schema handles parameter details. Adequate for the 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 has 100% coverage with descriptions for all properties. The description adds no additional parameter meaning beyond what is already in the schema. According to the rubric, baseline is 3 when schema coverage is high and description adds no param info.

  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 updates or archives a custom subtype, which is a specific verb-resource pair. It distinguishes from sibling tools like create and list by implying modification of existing subtypes. The role requirement adds specificity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description mentions the required role (agency or account admin), implying who can use it. However, it does not explicitly guide when to use this tool versus create or list tools, leaving the agent to infer from context. The usage context is clear but lacks explicit alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_email_legacy_campaign_listA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and no destructive effects. The description adds valuable behavioral context: it mentions pagination (limit/offset), filters (status, emailStatus), endpoint version, and OAuth scopes. This is more than what annotations provide.

  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 structured well with front-loaded differentiation and endpoint details. However, the last sentence about pagination parameters is somewhat redundant given the schema, making it slightly less 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?

  The description covers key aspects: legacy status, endpoint, auth scopes, pagination, and filters. It does not describe the response format, but given no output schema and the tool's simplicity, this is acceptable. Annotations fill in safety details.

  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 clear parameter descriptions. The description only summarizes that pagination and filters are supported, which adds minimal new meaning. 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 it is a 'Legacy schedule/campaign listing' from 2021-era, distinctly different from the v3 campaign family. It specifies the endpoint, OAuth scopes, and pagination parameters, making the purpose very clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly distinguishes this legacy tool from the v3 campaign family, providing context on when to use it. However, it does not directly compare with sibling tools like 'ghl_campaign_list' or 'ghl_email_list_campaigns', leaving some ambiguity for exact selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_email_list_workflow_campaignsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, ensuring safety. The description adds pagination behavior (limit, offset) and the endpoint details, which go beyond annotations without contradiction.

  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 concise (5 lines) and front-loaded with the title and action. It includes endpoint, scopes, and pagination info, but could be more 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?

  For a read-only list tool with no output schema, the description covers endpoint, required location ID, pagination, and OAuth scopes. Annotations handle safety. It is sufficiently complete, though return format is not mentioned.

  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 parameters described. The description only mentions pagination params (limit, offset) without adding new meaning beyond what the schema provides, 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 states 'List Workflow Campaigns' and 'Get list of workflow campaigns for a location', providing a specific verb (list) and resource (workflow campaigns) with scope. It distinguishes from sibling tools like ghl_email_get_workflow_campaign (singular) and ghl_email_list_campaigns (general campaigns).

  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 context by specifying it's for workflow campaigns, but does not explicitly state when to use this tool versus alternatives or when not to use it. Pagination and OAuth scopes are mentioned, which helps understand usage but without exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_link_deleteA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint: true, describing the destructive nature. The description adds OAuth scopes and endpoint details, which are useful beyond the 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 extremely concise with three lines, front-loading the purpose. Every sentence adds value 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?

  For a simple delete operation with one parameter and no output schema, the description adequately covers purpose, endpoint, auth scopes, and parameter usage. No gaps remain.

  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 linkId parameter with an example. The description does not add extra semantic information about the parameter 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 'Delete Link,' matching the tool name and endpoint. It distinguishes from sibling tools like create, get, list, and update by specifying the HTTP DELETE method and endpoint path.

  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 guidance on when to use or not use this tool is provided. The description only indicates deletion, but does not mention alternatives or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_oauth_exchange_location_tokenA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are sparse (readOnlyHint=false, etc.). The description adds significant behavioral context beyond annotations: security requirement (Agency-Access-Only), encoding format (form-urlencoded), and that it is the 'standard way' to obtain a location token.

  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 relatively concise and well-structured, starting with the critical requirement in bold. A few extraneous details (e.g., endpoint URL, OAuth scopes) could be trimmed, but overall 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?

  Given the tool's moderate complexity and lack of output schema, the description provides sufficient context: security, encoding, endpoint. Missing return value details, but not critical for a token exchange 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?

  Schema coverage is 100% with descriptions for companyId and locationId. The description redundantly mentions them as form fields but adds little new meaning. 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 tool's purpose: 'mint a location-scoped token from an agency token.' It uses specific verbs ('get', 'mint') and resources ('location access token'). Distinguishes from siblings by explicitly requiring an agency-level token.

  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 specifies that the tool requires an agency-level token and that the body must be application/x-www-form-urlencoded. It does not explicitly mention when not to use it or list alternatives, but provides critical usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_payment_order_list_fulfillmentsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds OAuth scopes and endpoint info, providing useful behavioral context beyond annotations.

  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 short and to the point, with three meaningful lines. The first line repeats the title, but overall it is concise and well-structured without fluff.

  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 list operation, the description covers purpose, endpoint, and auth. It lacks mention of pagination or return structure, but given the annotations and schema, 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?

  Schema coverage is 67% (2 of 3 parameters described). The description does not add any parameter details, but the schema descriptions for altId and orderId are sufficient, and altType is self-explanatory via its enum.

  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 'List all fulfillment history of an order' with a specific verb and resource. It distinguishes itself from sibling tools like ghl_payment_order_create_fulfillment by being the read-only counterpart.

  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 the endpoint and OAuth scopes, implying it is for reading fulfillments. No explicit when-not-to-use or alternatives, but the context from the name and annotations (readOnlyHint) makes usage clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_product_listA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds endpoint and OAuth scope details, which is useful but not deep. No contradictions.

  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 concise and front-loaded with the core purpose. The parenthetical about the name artifact is slightly tangential but valuable. Could be slightly more structured, but no fluff.

  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 12 parameters, 1 required, and no output schema, the description provides enough to use the tool: required locationId, optional filters, and pagination. It doesn't describe the return format, but that's acceptable for a list 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?

  Schema coverage is 100%, so baseline is 3. The description highlights important parameters (search, limit, offset) and their purpose, adding context beyond the schema. It doesn't explain all 12 parameters but covers the key ones.

  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 products for a location. It differentiates from sibling tools like product_create, product_get, and product_update by focusing on listing. The note about the corrected original name removes confusion.

  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 explains pagination and filtering by name, and mentions OAuth scopes. However, it doesn't explicitly state when to use this tool over alternatives like ghl_product_search or ghl_product_get, though this is a straightforward list operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_product_review_bulk_updateA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds behavioral context beyond annotations: it is a bulk mutation operation, requires careful ID review, and includes OAuth scopes. This disclosure helps agents understand potential side effects and authorization needs.

  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 relatively concise with key information front-loaded: purpose, then caution, then technical details. However, there is some redundancy with the title and endpoint info that could be trimmed. Overall 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?

  Given the tool's complexity (nested parameters, no output schema), the description combined with the schema provides sufficient context to use the tool. It covers purpose, required scopes, and a critical caution. Missing details like return format are compensated by the schema and 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?

  Schema coverage is 100% with descriptions already present for all parameters. The description mentions 'status, reply, etc.' which aligns with the schema but does not add significant new meaning beyond what the schema provides. 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 'Bulk-mutates' and the resource 'multiple reviews in one call', explicitly distinguishing it from sibling tools like ghl_product_review_update for single updates. The phrase 'approve/reject in batch' further clarifies the specific use case.

  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 for bulk operations and includes a caution to 'review the target reviewIds carefully before sending'. While it doesn't explicitly list when not to use it or name alternatives, the bulk nature is implicit, and the warning guides safe usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_get_locations_deprecatedA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint false. Description adds deprecation context and auth requirement, which are beyond the annotations. No contradictions.

  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?

  Description is somewhat messy with repeated brackets and redundant deprecation notice. While relatively short, it could be more streamlined 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?

  Given the absence of an output schema, description does not explain the response structure or what fields are returned. While annotations cover safety, the description leaves the output format unspecified, which is a gap.

  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 description mostly repeats schema info ('Pagination params: page — pass them to page through full result sets'). Does not add new semantic 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?

  Description clearly states 'Get SaaS Locations' and 'Fetch all SaaS-activated locations for a company with pagination', identifying the specific verb and resource. It also distinguishes from siblings by marking itself as deprecated and noting the superseding endpoint.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states deprecation status ('DEPRECATED per spec — superseded by...') and the requirement for an agency-level token ('REQUIRES AN AGENCY-LEVEL (Company) TOKEN'). Provides clear guidance to prefer the replacement and mentions pagination usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_create_likeA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate a non-idempotent mutation (readOnlyHint=false, destructiveHint=false). The description adds that it's a POST endpoint, supports only specific platforms, and that Instagram returns a 400 error. This provides valuable behavioral context beyond the 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 concise and front-loaded with the main action. It uses two short paragraphs with no extraneous information, efficiently conveying the tool's purpose and key constraints.

  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 no output schema, and the description does not explain return values, error handling, rate limits, or authentication requirements. For a simple mutation, missing return info is acceptable, but more context on what happens on success/failure 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 coverage is 100%, so the baseline is 3. The tool description adds nuance about the 'id' parameter (must be Highlevel comment ID), but this is also detailed in the schema property description. No significant 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 clearly states 'Like a comment' and specifies that it uses Highlevel comment ID, supports multiple platforms, and explicitly excludes Instagram. This distinguishes it from siblings like ghl_social_delete_like.

  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 explains when to use the tool (to like a comment at any level) and notes that Instagram is not supported. It could be more explicit about alternatives (e.g., using ghl_social_delete_like for unliking), but the platform enumeration in the schema provides clear boundaries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_fetch_slotsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false, openWorldHint=true, etc. The description adds endpoint and OAuth scopes but doesn't disclose potential side effects or beyond what annotations provide. No contradiction.

  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 focused sentences plus endpoint info. Front-loaded with purpose, then key usage. No redundant information.

  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?

  Covers purpose, parameters, and basic return fields (scheduledDateTime, isSkipped). Lacks details on pagination metadata, error handling, or full response structure, which is significant given no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 50%, but the description adds meaning to sessionId (draft vs live) and advises calling after mutations. This supplements the schema's parameter descriptions effectively.

  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 'fetch' and the resource 'slot information for queue items'. It specifies the return fields (scheduledDateTime, isSkipped) and distinguishes itself from sibling tools like ghl_social_fetch_queue_items by focusing on slots.

  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 explicit guidance on when to pass sessionId (draft items) vs omit (live items) and recommends calling after mutations to refresh data. Lacks exclusion or alternative tools, but the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_get_oauth_accountsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavior details: it's a GET endpoint, returns platform-specific listings, and includes the URL path. No contradictions; the description enriches understanding beyond annotations.

  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 well-structured with headings, a table, and flow steps. Each part adds value, though it is slightly verbose. The endpoint line and OAuth flow details are concise and informative.

  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?

  No output schema is provided, but the description compensates with a table explaining return values per platform and the endpoint path. It covers the OAuth flow context and accountId dependency. Adequate for a read-only list 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?

  Schema coverage is 100% with clear parameter descriptions. The description mentions accountId is from Step 1 but does not add significant new semantic value beyond the schema. Baseline 3 is appropriate as schema fully documents 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 'Get Available Accounts (Step 2 of 3)' and explicitly describes the tool as retrieving a list of available pages, channels, or locations for connection after OAuth. It distinguishes itself within the OAuth flow and per-platform return tables, leaving no ambiguity about its purpose.

  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 guidance by positioning the tool as Step 2 of a three-step OAuth flow, instructing the agent to use it after Step 1 authentication. It does not explicitly list alternative tools, but the step-based context makes when-to-use clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_fb_campaign_publishing_progress_getA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the description's job is to add context. It does so by explaining the data source (Redis-backed) and the purpose (polling during publishing). This goes beyond just restating annotations and gives practical 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 concise and front-loaded: a clear first line, a second line with key behavior, and a third line with endpoint and auth. No wasted words; every sentence adds value.

  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 return type (publish progress step counts and completion state), data source (Redis-backed), and usage (validation funnel UI). However, it does not detail the output structure, which would be helpful given no output schema. Still, the core information is sufficient for a simple polling 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?

  Schema description coverage is 100%, so each of the three parameters has a description. The tool description does not add additional meaning to parameters 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get campaign publishing progress' and explains it returns Redis-backed progress for a campaign publishing to Meta. It distinguishes itself from sibling tools like campaign_get (details) and campaign_reporting_get (reporting) by specifying it polls step counts and completion state during publishing.

  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 says it is 'Used by the validation funnel UI to poll step counts and completion state,' which gives clear context for when to use. However, it does not explicitly list alternatives or situations where other tools would be preferred, though the use case is well-defined.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_ad_google_audience_getA
  4.2/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by specifying the exact endpoint, API version, and OAuth scope (adPublishing.readonly), which are not in annotations and provide key 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 very concise: a title, a one-sentence action, and technical details (endpoint, version, OAuth). Every sentence is necessary and front-loaded. No fluff.

  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 read-only nature, good annotations, and no output schema, the description is largely sufficient. It includes endpoint and auth scope. Minor gap: it doesn't explicitly state that it returns the full audience object, but that is implied.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description does not add any parameter-specific meaning beyond the schema; it only mentions 'by ID' which is already in the schema. No extra 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?

  The description clearly states 'Get audience by ID' and 'Retrieve a specific Google Ads combined audience by ID', using a specific verb and resource. It distinguishes itself from siblings like list (returns many) and upsert (creates/updates) by focusing on retrieval by ID.

  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 an audience ID and need a single audience, but it lacks explicit guidance on when not to use this tool or mention of alternatives like list or upsert. No exclusions or context are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_group_listA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds the endpoint and required OAuth scopes, providing useful behavioral context beyond the annotations. It does not contradict any 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 extremely concise with three short lines, front-loading the purpose and then providing endpoint and scopes. Every sentence is informative 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?

  The description sufficiently covers purpose, required parameter, and authorization. While there is no output schema, the operation is straightforward; however, a note on return format (e.g., array of groups) 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 coverage is 100% with the single parameter 'locationId' fully described (example and text). The description adds no additional meaning beyond what the schema provides, so it meets the 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 states 'Get all calendar groups in a location' using a specific verb and resource, clearly distinguishing it from sibling tools like ghl_calendar_group_create or ghl_calendar_group_delete.

  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 indicates when to use this tool (to retrieve all calendar groups for a location). It does not explicitly mention alternatives or when not to use it, but the context from sibling tools makes the use case obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_chat_widget_listA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark readOnlyHint, idempotentHint, destructiveHint. Description adds OAuth scope ('chat-widget.readonly') and endpoint details, which are useful beyond annotations. No contradictions.

  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?

  Description is concise (4 lines), front-loads purpose, and includes all key details without 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 a simple list tool with no output schema, the description covers key aspects: resource, pagination, filters, auth, and endpoint. Could mention required locationId but it's in 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?

  Schema coverage is 100%, so baseline is 3. Description mentions pagination params and optional filters but does not add significant extra semantics for individual parameters 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?

  Title and description clearly state 'List Chat Widgets' and 'Returns chat widgets for the sub-account with pagination and optional filters.' This distinguishes it from sibling tools like get, create, delete for the same resource.

  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?

  Description explains when to use it (listing with pagination/filters) and mentions pagination params. However, it does not explicitly state when not to use it (e.g., for a single widget use get). Still clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_contact_get_by_idA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the exact endpoint, version header, and OAuth scopes beyond the annotations' safety hints. It does not contradict annotations and provides meaningful 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is somewhat verbose including renaming history, but the endpoint and auth details earn their place. Could be more front-loaded but remains clear.

  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?

  Missing description of the return value (full contact object). Given no output schema, this omission reduces completeness. Otherwise covers endpoint, auth, and naming.

  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 parameter contactId is fully covered by the input schema with example and description. The description adds no extra semantic detail beyond 'by ID', so 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 states it fetches a single contact by ID and explicitly distinguishes from sibling tools ghl_contact_list and ghl_contact_search_advanced by method and purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly contrasts with ghl_contact_list (deprecated list) and ghl_contact_search_advanced (filtered search), guiding the agent on when to use each alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_contact_update_taskA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds value beyond annotations by noting the regression verification for assignedTo, partial update behavior, and OAuth scopes. Annotations already indicate idempotent and non-destructive, so the description provides additional context without contradiction.

  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?

  Concise at 3-4 sentences, front-loaded with key points (regression verification, partial updates). Could be slightly streamlined (e.g., regression note could be secondary), but overall efficient and 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?

  With no output schema, the description does not explain the response format or content. It also does not mention error conditions or prerequisites (e.g., contact existence). The complexity of nested parameters partially mitigated by schema, but more context would improve completeness.

  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 already covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds explicit detail that all body properties are optional partial updates, which reinforces the schema and clarifies intended use.

  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 updates a task for a contact, distinguishes from the create sibling by noting all fields are optional on update, and provides the HTTP method and endpoint. This gives the agent a precise understanding of 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Contrasts with create by highlighting partial updates, but does not explicitly state when not to use this tool or suggest alternatives beyond the create tool. The guidance is implicit and helpful but not exhaustive.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_contact_upsertA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses behavioral traits beyond annotations, such as the dedup behavior adhering to location-level settings, the effect of createNewIfDuplicateAllowed, and that tags overwrite all current tags. No annotation contradictions (readOnlyHint=false is consistent with mutation).

  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 front-loaded with key information but is somewhat lengthy and includes HTML formatting and truncation. It could be more concise without losing essential details.

  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 complexity (nested objects, custom fields, DND settings), the description covers important behavioral aspects like dedup control and tags overwriting. It includes endpoint and OAuth scopes but lacks details on return values or error cases. No output schema exists, so the description carries the burden.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with parameter descriptions. The description adds value by explaining the createNewIfDuplicateAllowed scenarios in detail, but much of the parameter information is already in the schema. The description provides additional context on dedup logic.

  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 'Upsert Contact' and explains that it requires locationId, uses the same field set as ghl_contact_create, and controls dedup via createNewIfDuplicateAllowed. It distinguishes from sibling tools like ghl_contact_create and ghl_contact_update by its upsert behavior.

  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 explicit usage context: requires locationId, same field set as create, and provides scenarios for createNewIfDuplicateAllowed. However, it does not explicitly state when not to use this tool or mention alternatives beyond ghl_contact_create.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_add_message_attachmentsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Disclosed that attachments are replaced (not appended), max 5 URLs, and the operation is for specific message types. Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds contextual constraints. No contradiction.

  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, front-loaded with the core action, and efficiently covers purpose, constraints, and related endpoints in a few sentences without 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 tool with 2 parameters and no output schema, the description covers the operation, constraints, supported message types, and OAuth scopes. Missing return value details but acceptable given no 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?

  Schema coverage is 100% with clear descriptions for both parameters. The description repeats some schema info (e.g., max 5 URLs) and adds the upload distinction, but adds limited new semantic 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 clearly states the tool replaces/adds attachment URLs on an existing message, using specific verbs and resource. It distinguishes from the file-binary upload endpoint, 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 explicitly contrasts with the upload tool and specifies supported message types (TYPE_CUSTOM_CALL, TYPE_CALL with subType EXTERNAL_CALL). However, it does not differentiate from other conversation sibling tools like add inbound/outbound message, which could lead to confusion about when to use this vs those.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_ai_delete_agentA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint=true. The description adds value by clarifying permanence and scope (configurations and conversation history removed). OAuth scopes are also provided. No contradiction with 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?

  Description is extremely concise and front-loaded. Title is repeated briefly, then key consequences, endpoint, and scopes. No superfluous sentences.

  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 delete tool with annotations providing destructive hint, the description covers permanence, scope, and auth requirements. It does not mention error cases or response format, but output schema is absent and annotations already indicate safe usage. Slightly more detail on prerequisites could elevate it.

  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% (single parameter with description and example). The description does not add further meaning or context beyond what the schema provides. Baseline score 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 (Delete Agent) and resource (AI agent), and explicitly mentions permanence and removal of configurations/history. This distinguishes it from sibling tools like update or get.

  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 warns that the action cannot be undone and removes all associated data, helping the agent decide when to use it. However, it does not explicitly state when not to use it or suggest alternatives like update.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_update_email_message_statusA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate mutation (readOnlyHint=false) and idempotency (idempotentHint=true). The description adds behavioral context: requires OAuth scope, provider ownership, and explains additive event merging and recipient status upserting. It does not contradict annotations.

  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 verbose with multiple paragraphs covering authorization, field details, and inference rules. While well-structured with sections, it could be more concise; the first sentence effectively summarizes the purpose.

  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 complexity (two parameters, nested objects, no output schema), the description is thorough: it covers authorization, field semantics, provider restrictions, and update behavior (additive/upsert). It is nearly complete for an agent to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with good descriptions, but the description adds extra value by explaining inference rules, additive merging, and the distinction between events and recipients. This goes beyond the schema to clarify parameter 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 title and description clearly state the tool updates email message status, including delivery events, per-recipient statuses, and overall status for custom conversation provider emails. It is distinct from sibling tools like ghl_conversation_update_message_status due to the 'email' specificity.

  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 specifies that the tool is for emails sent via a custom conversation provider and warns that attempts on LC Email or Mailgun emails return 403. This provides when-to-use and when-not-to-use guidance, though it does not explicitly name alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_custom_menu_createA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate non-read-only and non-destructive. Description adds security context (agency token, OAuth scopes, endpoint details) beyond annotations. However, it does not describe the response or side effects (e.g., what is returned on success).

  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?

  Description is relatively concise but includes redundant information (repeats title 'Create Custom Menu Link') and is slightly verbose with endpoint and OAuth details. Front-loads the critical token requirement. Could be tighter.

  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 no output schema and a complex nested input, the description should at least hint at the return value (e.g., the created custom menu object). It does not do so. Missing this context limits completeness for an AI agent.

  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?

  Input schema has 100% description coverage, so the description is not required to explain parameters. It adds value by providing an external link for icon usage details, which supplements the icon parameter. Baseline 3, plus link → 4.

  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 'Create Custom Menu Link' and 'Creates a new custom menu for a company,' using specific verb and resource. It distinguishes from sibling tools (delete, get, list, update) by being the create variant.

  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?

  Explicitly states a critical security prerequisite: 'REQUIRES AN AGENCY-LEVEL (Company) TOKEN' and that operations are agency-access-only. Also mentions authentication and OAuth scopes. However, it does not compare to alternatives like update or delete.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_object_create_custom_objectA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds that it creates a schema (not a record) and provides OAuth scopes, but does not disclose additional behavioral traits like side effects or rate limits. The description adds some value but is not rich beyond 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 concise, front-loaded with the core purpose (creating a schema, not a record), followed by necessary context (rename, sibling differentiation, endpoint, scopes). No superfluous sentences.

  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 complexity of the tool (nested objects), the schema fully documents parameters, and the description covers purpose, naming, and OAuth scopes. It links to documentation. Without an output schema, the description is sufficiently complete for an AI to decide when and how to use it, though response format details are missing.

  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%, and the schema already includes detailed descriptions, examples, and constraints for all parameters. The description does not add parameter-specific information, 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?

  Description explicitly states it creates a custom object schema, not a record, and distinguishes from sibling tools that operate on existing objects (update_schema, get_schema_by_key). The verb 'creates' and resource 'custom object schema' are clear and specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit differentiation from sibling tools ghl_object_update_schema and ghl_object_get_schema_by_key, explaining they operate on already-created objects. Also mentions the endpoint and OAuth scopes, giving clear context for when 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.

• ghl_payment_coupon_deleteA
  4.2/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructive=true and idempotent=true. The description reinforces permanence ('Permanently deletes', 'cannot be undone') and explains downstream effects (checkout links stop working). No contradictions with annotations.

  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 somewhat verbose, repeating the tool name and including technical endpoint details (URL, version header, OAuth scopes) that could be shortened. The key information is front-loaded but could be more 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?

  For a delete tool without output schema, the description adequately covers the action's irreversibility and impact on checkout links. It also includes OAuth scope requirements. However, it could mention potential error cases or prerequisites.

  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 the nested parameters (id, altId, altType), so the description does not need to add much. It does not provide extra context beyond what the schema already describes.

  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 is for permanently deleting a coupon and explains the effect on checkout links. It distinguishes from sibling tools like create, get, list, and update by focusing on deletion.

  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 usage scenarios: discontinuing promotional offers or cleaning up unused coupons. It also warns that the action cannot be undone. However, it does not explicitly state when not to use or suggest alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_payment_coupon_getA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying the HTTP method (GET), OAuth scope, and the ability to retrieve by either ID or code. No contradictions.

  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: it begins with the purpose, lists the API details, and includes scopes. No unnecessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single retrieval tool without an output schema, the description effectively communicates what the endpoint returns (coupon parameters, usage stats, validity periods). It could briefly mention the response format, but the current level is 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?

  Schema coverage is 100% and the description mentions the two key identifiers (id and code). While the description adds a bit of context on how to use them, the schema already documents all parameters adequately, so the description's added value is minimal.

  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 comprehensive information about a specific coupon using ID or code. It lists the kind of data returned (parameters, usage stats, validity periods) and distinguishes itself from sibling tools like create/delete/list by being a retrieval endpoint.

  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 tells the agent to use this endpoint to view coupon details, which implies it's for individual coupon lookups. However, it does not explicitly contrast with the list tool or state when not to use it, but the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_payment_coupon_listA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond annotations by specifying the HTTP method (GET), OAuth scopes, and pagination details. Annotations already indicate read-only and idempotent, so no contradiction.

  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 four sentences, front-loading the key operation and avoiding unnecessary details.

  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 schema coverage and annotations, the description is fairly complete, covering purpose, endpoint, auth scopes, and pagination. It could mention response structure but no output schema exists.

  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?

  With 100% schema description coverage, the description does not significantly enhance parameter meaning. It only reiterates limit and offset for pagination, which are already documented 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 clearly states it retrieves a list of all coupons in a location using a specific verb ('retrieve') and resource ('coupons'). It distinguishes from sibling tools like create, delete, get, and update.

  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 for viewing all coupons and mentions pagination. However, it lacks explicit 'when to use vs alternatives' or exclusions, such as when to use the 'get' tool for a single coupon.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_payment_coupon_updateA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true. Description adds that it modifies existing coupon details with specific fields and mentions OAuth scopes. No contradictions.

  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?

  Description is concise (few sentences), front-loaded with tool purpose, and every sentence adds value. No redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers purpose, usage, and behavioral traits well. Missing return value details, but for a standard update tool with rich schema and annotations, it's reasonably 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 detailed descriptions for all parameters. Description adds no additional meaning beyond the schema, maintaining 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 title 'Update Coupon' and description clearly state the verb 'update' and resource 'coupon'. Among siblings like create, delete, get, list, it is well-differentiated.

  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 says 'Use this endpoint to adjust or extend promotional offers for your customers', providing clear context. It does not explicitly mention when not to use, but sibling tools cover other operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_payment_order_getA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the endpoint path, version header, and OAuth scopes, providing useful context beyond annotations. No contradictions.

  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, front-loaded with the title, followed by a clear sentence, and then technical details. 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?

  No output schema is provided, but the tool is simple (get by ID). The description is sufficient for basic use, though additional details about return structure 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 coverage is 100%, so parameters are already well-described. The description mentions orderId and endpoint, but does not add significant meaning beyond the schema. 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 'Get Order by ID' and explains it retrieves information for a specific order using its unique identifier. It distinguishes from sibling tools like ghl_payment_order_list by focusing on single order retrieval.

  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 tells when to use it ('fetch details for a single order') and mentions OAuth scopes. However, it does not explicitly exclude use cases or mention alternatives, though context from siblings provides some guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_get_locations_by_stripe_id_deprecatedA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds important context about deprecation, required token type, and endpoint version, which is beyond what annotations provide. No contradictions.

  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 has some redundancy (e.g., deprecation stated twice, similar sentences repeated). Although clear, it could be more concise by merging the first two lines.

  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 output schema and the openWorldHint annotation, the description does not mention what the response contains (e.g., fields, pagination). This leaves the agent uncertain about the return structure, which is a significant gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage. The description adds value by clarifying that customerId and subscriptionId are Stripe-specific and that they are used in conjunction with companyId, reinforcing the schema's meaning without redundancy.

  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 is deprecated and superseded, specifies it retrieves locations by stripe ID or customer/subscription ID, and provides the endpoint URL. The sibling tool ghl_saas_get_locations likely serves as the replacement, making the differentiation explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly marks the tool as deprecated and names the superseding endpoint ('GET /saas/locations'). Also states the required token level ('AGENCY-LEVEL (Company) TOKEN'), giving clear guidance on when to avoid using this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_get_plan_deprecatedA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds value by disclosing deprecation status and the required token type. No contradictions with annotations. It does not detail response format, but that is acceptable given the simple read 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 somewhat verbose with repeated deprecation warnings ('DEPRECATED per spec' and bracketed note). It could be more concise by combining these. However, it is structured with deprecation, auth, and then purpose, making it readable.

  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 operation with two required params and no output schema, the description covers deprecation, auth, endpoint, and version. It lacks clarification on the relationship between planId and companyId, but overall it is fairly complete for an agent to use or avoid this 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?

  Schema coverage is 100% with both parameters described. The description restates 'by plan ID' and 'filter SaaS plan', but adds no new semantic information beyond what the schema already provides. 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 'Get SaaS Plan' and 'Fetch a specific SaaS plan by plan ID', providing a specific verb and resource. It also explicitly marks the tool as deprecated and identifies the superseding endpoint, distinguishing it from siblings like ghl_saas_get_plan.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states that the tool is deprecated and superseded by a specific endpoint, guiding the agent to prefer the replacement. It also notes the required authentication level ('REQUIRES AN AGENCY-LEVEL (Company) TOKEN'), which is critical for correct usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_calendar_service_location_deleteA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructive and idempotent hints. The description adds OAuth scopes ('calendars.write') and endpoint details, providing useful behavioral context beyond 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 concise with no wasted words; it states purpose, endpoint, and OAuth scopes efficiently.

  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 delete-by-ID tool, the description covers what it does, the HTTP method, auth scope, and source reference. No output schema needed.

  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 one parameter fully described. Description does not add additional parameter meaning beyond what 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 'Delete a service location by ID', using a specific verb and resource. It distinguishes from sibling tools like create, get, list, and update.

  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 directly states the use case: delete by ID. No explicit when-not-to-use or alternatives, but the tool's simplicity makes guidelines implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_contact_remove_from_all_campaigns_legacyA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already signal destructive and idempotent hints. The description adds value by revealing the legacy status, OAuth scopes, and endpoint details (DELETE /contacts/{contactId}/campaigns/removeAll). No contradiction with annotations.

  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 slightly verbose but front-loads critical information: legacy nature, equivalence, and preferred alternative. Every sentence contributes to disambiguation and usage guidance.

  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 single-parameter tool with good annotations, the description is fairly complete. It explains the tool's purpose, alternative, and usage context. Missing details like return values are acceptable since no output schema exists.

  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 a description and example for contactId. The description does not add further semantic meaning beyond what the schema provides, 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 tool removes a contact from every campaign and distinguishes it from the v3 equivalent. The legacy nature and exact endpoint are specified, providing a specific verb+resource that differentiates it from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states 'prefer the v3 tool for new integrations,' giving clear usage guidance. It also mentions functional equivalence, helping the agent choose correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_get_message_recordingA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnly, idempotent, non-destructive. The description goes beyond by specifying the exact response format (audio/x-wav, Content-Disposition), that it is not JSON, and the required scopes. No contradictions.

  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 well-structured with the critical warning first, then title,restatement, and technical details. It has minor redundancy (e.g., repeating 'Get Recording by Message ID' in both the first line and later) but is otherwise 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 no output schema, the description covers the response format and binary nature well. It also includes endpoint and OAuth scopes. It lacks error handling or size limits, but is sufficient for a simple retrieval 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?

  Schema coverage is 100% with both parameters described ('Message ID as string', 'Location ID as string'). The description does not add additional semantics beyond what the schema provides, so baseline score 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 that it gets a recording (audio) for a message, distinguishing it from other conversation/get message tools that return JSON. The title 'Get Recording by Message ID' and the phrase 'Get the recording for a message' specify the verb and resource.

  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 warns that the response is NOT JSON and is binary audio, telling callers to handle a binary/audio body. It also provides the endpoint and OAuth scopes. However, it does not explicitly state when not to use this tool or list alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_kb_listA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds pagination behavior, endpoint path, and version header, which go beyond annotations.

  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?

  Multiple sentences each add value: purpose, sibling distinction, endpoint details. Slightly verbose but well-structured and front-loaded.

  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?

  Covers purpose, pagination, and differentiation. No output schema needed for a list tool. Adequate given annotations and schema richness.

  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%; description reinforces pagination context (limit, lastKnowledgeBaseId) but does not add significant new meaning beyond 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?

  Clearly states it lists knowledge bases for a location, with pagination via limit/lastKnowledgeBaseId. Explicitly distinguishes itself from sibling ghl_kb_faq_list, which lists FAQ entries inside a knowledge base.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly explains when to use this tool vs the alternative ghl_kb_faq_list, and mentions pagination parameters for iterative retrieval.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_marketplace_uninstall_applicationA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Description confirms destructive behavior (removes access, stops functionality) consistent with annotations. Adds OAuth scope detail. No contradictions.

  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 plus endpoint and scopes; front-loaded with action and effect, no wasted words.

  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?

  Provides all needed information for a simple destructive operation, including auth scopes and parameter roles, given no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema already covers all 2 parameters with descriptions; description adds value by noting that 'reason' is required for developer uninstalls, beyond what schema 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?

  The description clearly states 'Uninstall an application' and explains that it removes access and stops functionality, distinguishing it from other marketplace tools like charge-related ones.

  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?

  Provides context on company vs location scoping but lacks explicit guidance on when to use this tool versus other marketplace tools 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.

• ghl_oauth_get_installed_locationsA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds significant behavioral context beyond annotations: it specifies the required token type (agency-level), the endpoint, OAuth scopes, and pagination details. This complements the readOnlyHint, openWorldHint, and idempotentHint annotations well without contradiction.

  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 well-structured with critical security info first, followed by purpose, endpoint, scopes, and pagination. It is not overly verbose but contains necessary details. A few sentences could be streamlined, but overall it is 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?

  Given 11 parameters, no output schema, and no nested objects, the description covers security, endpoint, scopes, and pagination. It lacks explanation of the response structure, which would be helpful, but the annotations and schema already provide substantial context. Overall, it is reasonably 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 description coverage is 100% for all 11 parameters, so the description adds minimal extra meaning. It mentions pagination parameters (pageSize, pageToken) but the schema already describes them thoroughly. Baseline score of 3 is appropriate given full 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 'Get Location where app is installed' and uses a specific verb-resource combination ('Get Location'). It distinguishes from siblings like 'ghl_oauth_get_installed_location' (singular) by indicating it fetches installed locations (plural). The scope is well-defined.

  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 requires an agency-level token and notes 'no Location-Access alternative', providing a critical usage constraint. It mentions pagination parameters but does not explicitly state when not to use this tool or compare with alternatives beyond the token requirement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_saas_get_location_wallet_balanceA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behavioral context beyond annotations: it requires agency-level token and specifies the OAuth scope. It also states the return value is a 'resource object with balance details.' No contradiction with annotations, which declare readOnlyHint and idempotentHint.

  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 concise with five sentences, front-loaded with the crucial security requirement. Minor redundancy (repeating 'Get Location Wallet Balance' in title and first sentence) but overall 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?

  For a simple read-only tool with full annotation coverage, the description explains the security context and return type. It does not detail the structure of the balance details, but without an output schema, this is 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 covers both parameters with descriptions, and the description adds no further parameter-level semantics. Baseline 3 is appropriate given full 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: 'Get Location Wallet Balance' and 'Fetch the wallet balance for a specific location.' It effectively distinguishes itself from its sibling tool 'ghl_saas_update_location_wallet_balance' by specifying the read-only nature.

  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 mentions the requirement for an Agency-Level token and OAuth scopes, providing strong usage constraints. It implies that this tool is for reading the balance, contrasting with the update sibling, but does not state explicit when-not-to-use or list all alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_attach_twitter_profileA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false and destructiveHint=false, but the description adds critical deprecation context beyond annotations, revealing the tool is obsolete and likely non-functional. It does not detail what happens if invoked, but the deprecation warning suffices for 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 front-loaded with the deprecation warning and endpoint, which is effective. However, it includes verbose HTML formatting for the warning, making it longer than necessary. The structure is good but slightly verbose.

  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 is deprecated and has a nested input schema with no output schema, the description provides essential deprecation context and the endpoint. It lacks parameter explanations, but for a deprecated tool, the selection guidance is complete enough.

  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 (all parameters have a description), but those descriptions are minimal (e.g., 'Account Id', 'Request body...'). The description adds no additional semantic meaning for parameters. Baseline 3 is appropriate since schema does the heavy lifting but with weak semantics.

  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 attaches a Twitter profile and immediately flags it as deprecated, making the purpose unambiguous. The sibling tools are other social attachment tools, which it distinguishes itself from by the specific platform (Twitter). The deprecation warning is upfront.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states 'DEPRECATED per official docs — prefer the documented replacement if one exists' and includes a red box confirming X is no longer supported. This provides clear when-not-to-use guidance and suggests an alternative, which is ideal for a deprecated tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_voice_ai_delete_actionA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (destructiveHint=true), the description explains 'permanently removes the action and its configuration', provides the HTTP endpoint, version header, and required OAuth scopes, adding significant 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 concise with two sentences plus endpoint/scope details. No redundant information; every sentence serves a purpose.

  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 delete operation, the description covers the action, permanence, authentication, and endpoint details. Complete enough for an agent to invoke correctly without needing an 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?

  Input schema already has 100% coverage with descriptions for all three required parameters. The description does not add extra meaning beyond what the schema provides, so 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 'Delete an existing action from a voice AI agent' and emphasizes permanent removal, distinguishing it from sibling tools like create, get, and update actions.

  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 does not explicitly state when to use this tool versus alternatives, but the tool name and context imply it is for deletion. No guidance on when not to use or about prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_voice_ai_get_call_logsA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark it as read-only, idempotent, and non-destructive. The description adds valuable context: OAuth scopes (readonly), 1-based pagination, date range interpreted in IANA timezone, and the endpoint header/version. All behaviors are consistent with no contradictions.

  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 well-structured with a brief title, clear purpose statement, and a list of supported operations. It is front-loaded and easy to read. However, it includes endpoint and OAuth scope details that might be considered extra, slightly reducing 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 tool's complexity (11 parameters, many enums, no output schema) and rich annotations, the description provides a good overview of filtering, sorting, pagination, and timezone handling. It doesn't describe the return format in detail, but the schema already defines inputs well, so the gap is minor.

  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 11 parameters. The description only groups them into 'filtering by agent, contact, call type, action types, and date range' and mentions pagination params. This adds minimal new meaning beyond what the schema already provides, so a 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 'List Call Logs' and explains it returns call logs for Voice AI agents scoped to a location. It lists specific filters (agent, contact, call type, action types, date range) and mentions pagination and sorting, distinguishing it from sibling tools like the single call log getter.

  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 when to use this tool (for listing call logs with various filters and pagination). However, it does not explicitly state when not to use it or contrast with the similar sibling 'ghl_voice_ai_get_call_log' for single logs, so it misses explicit exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_agent_studio_execute_deprecatedA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description reveals that the tool is a write operation (OAuth scope agent-studio.write), returns non-streaming JSON, and manages sessions via executionId. These go beyond the minimal annotations (readOnlyHint false, etc.). No contradictions with annotations.

  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 unnecessarily verbose, with the deprecation warning repeated three times. Session management details are included but could be more structured. A more concise and organized description would improve readability.

  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 complexity of the nested input schema and lack of output schema, the description covers core behavior (execution, session handling, required fields) and deprecation. It omits error handling and response structure, but is adequate for a deprecated 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?

  The description adds value beyond the 33% schema coverage by explaining the purpose of executionId for session continuity, noting that versionId defaults to latest production version, and emphasizing that locationId is required. This compensates for the schema's lack of detail.

  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 that the tool executes an agent and returns a non-streaming JSON response. It specifies the verb 'Executes' and the resource 'agent', and distinguishes itself by noting deprecation and directing to an alternative sibling tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly recommends using the non-deprecated sibling tool 'ghl_agent_studio_execute' instead. It also provides conditions (agent must be active, locationId required) and detailed session management instructions for first and subsequent messages.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_custom_field_get_by_idA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by disclosing that the tool returns folders as well as fields, lists supported object types, and provides endpoint details and OAuth scopes. It does not contradict annotations. Some minor behavioral details (e.g., rate limits) are absent, but it is sufficiently transparent.

  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 contains unnecessary HTML tags (e.g., <div>, <p>) and repeats the title 'Get Custom Field / Folder By Id' twice. While the core information is present, the formatting issues and redundancy reduce conciseness. The important details are front-loaded, but the HTML clutter is detrimental.

  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 retrieval tool with one parameter and no output schema, the description provides adequate context: it explains the dual nature, supported objects, and OAuth scopes. It could mention response structure or error scenarios, but overall it is complete enough for an agent to understand and use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema only defines a required 'id' string parameter with no description. The description compensates by explaining that the 'id' can be for either a custom field or a folder, and advises checking the response shape to determine which. This adds significant meaning beyond the schema, though it lacks examples or format hints.

  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 that the tool retrieves both custom fields and folders by ID, explicitly differentiating it from sibling tools like create, delete, and update operations. It includes the phrase 'Get Custom Field / Folder By Id' and advises checking the response shape to distinguish the two.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states that the tool only supports Custom Objects and Company (Business) today, with future support for other Standard Objects. This provides clear guidance on when to use the tool and when not to. It also advises checking the response shape, which helps the agent interpret results correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_oauth_get_location_access_tokenA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses that it generates a locationAccessToken from AgencyAccessToken, requires agency-level token, and uses form-urlencoded body. Annotations do not cover these details, so the description adds significant behavioral context beyond annotations.

  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?

  Front-loads critical info (requires agency token, form-urlencoded) in bold. Slightly verbose with version/source details, but every sentence adds value. No unnecessary repetition.

  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?

  Covers required parameters, authentication, and body format, but does not describe the response structure (expected token fields). For a simple token exchange, this is a notable omission. Without output schema, the description should clarify 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?

  Schema already covers both parameters (companyId, locationId) with descriptions (100% coverage). The description adds that they are form fields and not JSON, which is valuable beyond the schema. Baseline 3 plus extra context justifies 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it gets a location access token from an agency token, specifies the endpoint, and distinguishes itself as the legacy twin of a v3 operation. The verb 'Get' and resource 'Location Access Token' are precise.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly requires an agency-level token, specifies the request body format (application/x-www-form-urlencoded), and advises to prefer the v3 operation for new integrations. Provides clear when-to-use and 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.

• ghl_phone_list_number_poolsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds that it's a GET request, requires locationId, and provides OAuth scopes. It also mentions the absence of a Version header, which is extra behavioral context beyond annotations.

  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 front-loaded with the key action and resource. The note about the Version header is somewhat verbose but does not harm clarity. Overall, it is efficient and well-structured, though it could be slightly more concise.

  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 list tool with one parameter and no output schema, the description adequately states the purpose, required parameter, and endpoint details. It provides sufficient context for an agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for the only parameter (locationId) with description and example. The description confirms it's a query parameter, which adds a small but valuable clarification beyond the schema (which doesn't specify query vs path).

  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 number pools for a location, using the verb 'List' and specifying the resource 'number pools'. It distinguishes from sibling tools like ghl_phone_list_active_numbers and ghl_phone_list_available_numbers by focusing on number pools.

  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 specifies that the tool requires a locationId as a query parameter, providing clear context for usage. However, it does not explicitly mention when not to use it or provide alternatives among siblings, but the name and context make it clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_social_create_commentA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate non-read-only, non-destructive, non-idempotent. Description adds value by detailing platform-specific behaviors (attachments ignored on most platforms, max lengths) and endpoint info, going beyond annotations.

  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?

  Description is well-structured with sections and bullet points, front-loading core action. Slightly long but each part serves a purpose; no wasted sentences.

  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?

  Covers two modes, parameter usage, platform limitations, and endpoint info. Lacks response format but given complexity and no output schema, it is fairly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%. Description adds platform-specific max lengths, supported fields for attachments and mentions, and detailed parentId explanation, providing 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?

  Description clearly states 'Create a comment or reply' and details the two modes (top-level comment vs reply) using isParentThread and parentId. It is distinct from sibling tools like ghl_social_create_like or ghl_social_delete_post.

  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 explicit guidance on when to use isParentThread: true vs false and how to set parentId for each case. Does not mention alternatives or when not to use, but context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ghl_conversation_upload_file_attachmentsA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses that the binary file is not represented in the JSON schema, lists allowed file types, mentions OAuth scopes, and specifies the endpoint and version. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

  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 relatively long but well-structured, starting with the key point ('multipart/form-data upload'), then explaining schema limitations, listing file types, and providing endpoint/OAuth info. Efficient use of text, slightly verbose but each part adds value.

  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?

  Covers input format, required fields, allowed file types, authentication, endpoint, and return value ('object with URLs'). No output schema, but description compensates. Complete for a file upload tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions, but the description adds critical information: the need to attach a separate multipart part 'fileAttachment' (buffer) which is not in the schema. Also lists allowed file types. This significantly enhances understanding 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 is for uploading file attachments to a conversation, specifying multipart/form-data format, required fields, and allowed file types. It distinguishes itself from sibling tools by emphasizing the upload aspect and the constraints of the API.

  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 context on when to use this tool (for uploading files as multipart) and lists allowed file types, but does not explicitly contrast with sibling tools like ghl_conversation_add_message_attachments or ghl_conversation_add_outbound_message. Usage guidance 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.

• ghl_media_upload_fileA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only indicate non-readOnly, non-idempotent, etc. The description adds rich behavioral details: it does not construct multipart payloads, size limits (25MB/500MB), OAuth scopes (medias.write), and endpoint info. It fully discloses the conditional requirement and limitations, exceeding what annotations provide.

  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 well-structured, starting with the core concept (multipart/form-data) then detailing the conditional logic and constraints. It is slightly verbose but each sentence adds value. Could be tightened by merging some repeated information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity (two upload modes, size limits, no multipart construction), the description covers essential usage. Lacks details on error responses or result format, but no output schema is provided, so this is acceptable. OAuth scopes and endpoint are included for context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (all parameters named and typed), but the description adds critical semantics: the conditional mutual exclusivity of file vs fileUrl based on hosted. This goes beyond the schema's plain property listing. However, it does not elaborate on name or parentId, which remain minimally described.

  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 uploads files into media storage, specifies the multipart/form-data nature, and distinctively describes two modes (hosted vs binary). This differentiates it from sibling media tools like ghl_media_list_files or ghl_media_delete_file by focusing on upload and conditional logic.

  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 advises using the hosted:true + fileUrl path when the file already has a public URL, and warns that binary upload requires a pre-encoded multipart payload. It provides clear when-to and when-not guidance, though it does not compare to other upload tools (e.g., ghl_conversation_upload_file_attachments) which serve different contexts.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.