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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read-only listing operation ('List') and surfaces important access constraints ('BYOK', 'PAID ONLY $39'). However, it does not disclose response shape, pagination, rate limits, or what happens when optional parameters are omitted, leaving meaningful behavioral gaps.

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

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

The first sentence is front-loaded and efficient: it states the core action and scope. The additional fragments 'BYOK' and 'PAID ONLY $39' are concise and convey real constraints, though their cryptic phrasing could be clearer. No meaningless filler is present.

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

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

For a relatively simple two-parameter read-only tool, the description is minimally viable: it names the operation, the resource, the account scope, and key access conditions. However, without an output schema or annotations, it should better explain what the returned calendars/appointments look like, how days_ahead applies, and whether a location/sub-account must already be selected.

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

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

Schema description coverage is 0%, so the description must compensate. It implicitly connects 'sub-account' to location_id and 'upcoming' to days_ahead, adding some meaning beyond the schema's bare field names and defaults. Yet it never explicitly documents how days_ahead behaves, whether location_id is required in practice, or the impact of omitting either parameter.

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

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

The description uses a specific verb and resource: 'List calendars and upcoming appointments for a sub-account.' This clearly distinguishes the tool from most siblings and avoids vague or tautological phrasing. However, it does not explicitly differentiate itself from any particular sibling tool, and the appended 'BYOK. PAID ONLY $39.' adds access/commercial context rather than sharpening the core purpose.

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

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

The description implies when to use the tool: whenever a user needs calendars or upcoming appointments for a sub-account. But it provides no explicit when-not-to-use guidance, no alternative tool references, and no conditions such as requiring a selected location or active GoHighLevel connection. The BYOK and paid-only notes hint at prerequisites but do not explain them.

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

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

With no annotations, the description carries the full burden. It does communicate that the tool uses a user-provided GHL API key and that upsert is a write operation, but it omits the confirm guard, the 50-item cap, default action, and any outcome/return behavior. The 'PAID ONLY $39' line adds cost noise rather than operational transparency.

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

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

The useful operations are front-loaded, but the middle clause about a 'dead 193-star repo' and the 'PAID ONLY $39' sentence do not help an agent invoke the tool correctly. The description could be half as long and lose only noise.

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

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

No annotations or output schema exist, and the tool has two modes plus a confirmation gate, yet the description does not explain the confirm requirement, default action, location override, or what a caller should expect back. The schema fills some gaps, but the description alone is not complete for a mutating dual-mode tool.

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

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

Schema coverage is 100%, so the baseline is 3. The phrase 'email key' adds a small bit of meaning by suggesting email is the identity key for upserts, but the description otherwise restates what parameter descriptions already cover.

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

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

The description names a concrete resource and two explicit operations: 'Search contacts by query' and 'bulk-upsert an array (email key) with tags.' It is specific enough for an agent to know what the tool does, though it does not explicitly contrast it with sibling tools like gold_ghl_tags_bulk_apply.

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

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

No guidance is given about when to choose search versus upsert_bulk, when to prefer a sibling tool, or what prerequisites exist beyond 'BYOK GHL_API_KEY.' The schema's action enum implies the two modes, but the description does not state decision criteria.

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

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

With no annotations, the description carries the burden, and it discloses useful behavior: BYOK key-dependent execution, fallback to a clean transcript, and a $39 paid condition. It also clearly indicates a read-style 'pull' rather than a mutation. It stops short of mentioning data-privacy side effects, errors, or rate limits, which keeps it from a 5.

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

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

The definition is short and front-loaded: the core action and outputs appear first, with key and pricing caveats following. The 'POWER:' prefix is marketing noise, and the BYOK/pricing sentence is dense, but no substantive information is wasted.

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

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

For a simple two-parameter read tool, the description covers the main output modes and key requirements, and it names the return contents. However, with no output schema and no annotation support, the absence of parameter semantics and alternative-tool guidance leaves a meaningful gap for an agent deciding how to invoke it correctly.

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

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

Schema description coverage is 0% and the description provides no parameter details. 'Conversation thread' hints at a conversation_id, but max_messages is entirely undocumented and its effect on the summary/transcript is not explained, so an agent cannot infer correct parameter semantics from the description.

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

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

The description states a specific action and outputs: 'pull a conversation thread and get a 5-line summary + sentiment + suggested next action.' This makes the function clear and non-tautological, but it does not explicitly distinguish it from sibling tools such as gold_ghl_conversations_list_reply_draft, so it 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.

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

It gives concrete conditional usage context: with the user's OpenAI key it summarizes; without the key it returns a clean transcript. It also notes the paid requirement. However, it never states when to prefer this tool over alternatives or when not to use it, so differentiation from siblings is left implied.

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

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

With no annotations, the description discloses useful traits: conversations come 'unread first,' and setting a conversation_id fetches one thread. It does not explicitly state read-only behavior, rate limits, authentication details, or failure modes, so the burden is only partially met.

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

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

Two short sentences carry the function, ordering behavior, thread mode, and key access constraints without wasted words. The most important information is front-loaded before the BYOK and pricing caveats.

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

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

There is no output schema and no documentation of return shape, so an agent does not know what list/thread responses look like. The description also omits the role of location_id and limit, which are needed to reliably call the tool.

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

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

Schema coverage is only 33% and the description does not compensate meaningfully: it implies conversation_id selects a thread, but limit and location_id are left unexplained. The phrase 'pull one thread's messages' adds no detail beyond the schema description already attached to conversation_id.

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

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

The description names a clear action and resource: 'List recent conversations' and 'pull one thread's messages to draft a reply,' with an explicit intent. It is specific enough to be understood, though it does not differentiate from siblings like gold_ghl_conversations_ai_summary.

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

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

It indicates the intended use ('to draft a reply') and access constraints (BYOK, paid), which helps an agent decide whether it can use it. It does not state when to prefer another tool or when not to use this one, leaving some inference to the agent.

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

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

No annotations are provided, so the description carries the full burden. It discloses important access traits (BYOK, paid only) and implies a read-only listing operation. However, it does not describe return shape, pagination, folder semantics, or any side effects, leaving notable behavioral gaps.

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

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

The description is exceptionally concise and front-loaded. The core action and purpose appear in the first sentence, while access constraints are packed efficiently into the second. Every word earns its place.

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

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

For a simple single-parameter listing tool, the description conveys the main function and even hints at return content (custom fields and folder). However, it lacks parameter guidance, requiredness clarity, and any output format details, which are meaningful gaps given there is no output schema.

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

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

Schema description coverage is 0%, and the sole parameter location_id has no schema description. The description mentions 'sub-account' but never maps it to location_id or clarifies whether it is required. With only one parameter, the description should have compensated for the schema gap but does not.

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

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

The description states a specific action and resource: 'List a sub-account's custom fields (+folder)'. It also clarifies the purpose—so AI fills fields correctly instead of guessing keys—which makes the tool's role immediately understandable and distinguishable 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.

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

The description implies when to use the tool: whenever custom field keys must be resolved before filling them. However, it does not explicitly mention alternatives, exclusions, or conditions beyond BYOK and paid access. The intended usage context is present but only implied.

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

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

With no annotations, the description carries the full disclosure burden, and it does add substantive context: 'Agency mode,' 'list every sub-account your key reaches,' 'BYOK,' and 'PAID ONLY $39.' The verbs 'list' and 'inspect' imply read-only behavior, though it never explicitly states whether the active location changes despite the 'switcher' name.

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

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

Three short fragments deliver mode, capability, auth model, and pricing without filler. The core behavior is front-loaded in the first clause, so an agent grasps the essential function immediately.

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

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

For a single-optional-parameter tool, the description covers invocation choice, key scope, auth requirement, and payment restriction, with return hints for the inspect case. The main remaining gap is the lack of explicit output details for the list case and no statement about whether switching/state changes occur, but overall it is enough for selection and basic invocation.

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

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

The single parameter location_id is already covered by the schema ('omit to list all reachable'), and the description reinforces that by contrasting 'list every sub-account' with 'inspect one.' It also adds what inspection returns — name/timezone/providers — which goes beyond the schema text.

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

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

The description uses specific verbs 'list' and 'inspect' against a clear resource: sub-accounts/locations reachable by the key. It names the return focus (name/timezone/providers) and is easily distinguished from sibling tools about conversations, workflows, contacts, appointments, tags, and pipelines.

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

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

The 'Agency mode' label and 'BYOK' clearly establish the intended context: use this when operating with an agency key and needing to enumerate or examine sub-accounts. It does not name alternative tools or explicitly state exclusions, so it falls just short of a 5.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It implies a mutating move but does not mention the required CONFIRM confirmation, side effects, reversibility, or permissions; BYOK and $39 are cryptic and do not explain execution behavior.

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

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

The operative sentence is front-loaded and there is no fluff. However, the cryptic 'BYOK. PAID ONLY $39.' adds little structural value, though it does not bloat the description.

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

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

For a 6-parameter mutation tool with no annotations and no output schema, this description is incomplete. It omits the confirmation requirement, required ID, optional parameters, and expected response shape, leaving an agent to discover critical invocation details only via the schema.

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

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

Schema coverage is only 17%, so the description must compensate. It vaguely maps to pipeline_stage_id and status ('pipeline stage or won/lost') but provides no meaning for confirm, opportunity_id, pipeline_id, or monetary_value.

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

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

States a specific verb ('Move'), resource ('opportunity'), and destination ('a pipeline stage or won/lost'), which clearly identifies the action. It does not explicitly distinguish from siblings, but none of the sibling names cover an opportunity stage-move operation, so it is reasonably distinct.

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

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

Provides no guidance on when to use this tool over alternatives or how it relates to sibling tools. The BYOK and paid phrases hint at prerequisites but not usage conditions; no alternative tool is named.

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

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

With no annotations, the description discloses key operational behaviors: BYOK (caller's own key), PAID ONLY $39 (cost), and 'one-call' (single invocation). The word 'report' implies a read-only operation. It doesn't cover rate limits or exact output shape, but the main behavioral constraints are surfaced.

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

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

Every phrase carries information: purpose, cadence, scope, auth, and cost. The primary purpose is front-loaded, and there is no filler.

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

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

Adequate for a simple optional-parameter report, but with no annotations and no output schema it leaves gaps: the return content is only implied by the report name, and the effect of omitting location_id is not stated. Complexity is low, so this is a moderate rather than severe gap.

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

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

The only parameter, location_id, has zero schema description coverage, but the description's 'across a sub-account' tells the agent that location_id selects the sub-account scope. This is a meaningful semantic addition beyond the bare schema.

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

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

Description names a specific artifact: a Monday snapshot report of pipeline open/won value per stage within a sub-account. This clearly distinguishes it from sibling tools, which are mostly actions (enroll, list, draft, apply, move) rather than reporting.

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

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

The phrase 'One-call Monday report' gives clear usage context: generate this report on Monday via a single call. It doesn't explicitly state when-not-to-use or name alternatives, but no sibling tool is a close alternative, so the missing exclusion is not a major gap.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose batching behavior ('25 ids/call') and upsert looping, and it flags the paid/BYOK requirement. Missing are details about idempotency, partial failures, return behavior, or what the 'confirm' flag actually guards against, which would be important for a mutating bulk operation.

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

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

The description is short and front-loaded with the primary action. Each fragment adds information, but the parenthetical 'loops upsert' is jargon that may confuse an agent, and the 'PAID ONLY $39' note is somewhat terse.

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

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

For a bulk tag mutation tool, the description provides the core action, batching limit, and cost/auth gate. The schema covers the required params and confirm constraint. Still, there is no output schema and no annotation, so the lack of guidance on location_id semantics and result/error behavior leaves the description only minimally complete.

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

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

Schema description coverage is 40%, so the description needs to compensate. It adds some semantic value: '25 ids/call' clarifies contact_ids, and 'Add or remove tags' maps to tags and the remove boolean. However, it does not explain location_id or elaborate on the tags parameter, leaving part of the compensation burden unmet.

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

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

The description clearly states the verb and resource: 'Add or remove tags on many contacts at once.' It also names the batch size ('25 ids/call') and the operation style ('loops upsert'), which distinguishes it from sibling tools focused on contact search/upsert or workflow enrollment.

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

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

Usage context is implied through 'on many contacts at once,' which signals this is for bulk tag operations. However, no alternatives are named and no explicit when-not-to-use guidance is given. The BYOK and PAID ONLY notes provide some prerequisite context, but not enough for strong usage routing.

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

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

With no annotations, the description carries the burden. It discloses that the tool loops the official add-to-workflow call, requires a BYOK GHL_API_KEY, and caps at 25 contacts. However, it does not disclose behavior around confirmation, idempotency, partial failures, or what happens if the workflow already contains a contact.

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

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

The description is compact and readable, but includes extraneous marketing elements like 'POWER' and 'PAID ONLY $39' that do not help an agent invoke the tool. The core behavioral sentence is front-loaded, but the fluff weakens the overall structure.

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

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

The description covers the core operation, the enrollment limit, the loop mechanism, and the auth requirement. However, for a write-like bulk operation with no annotations and no output schema, it omits important context such as confirmation handling, response format, error behavior, and whether enrollments are idempotent.

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

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

Schema coverage is 67%, and the description adds useful semantics: 'up to 25 contacts' clarifies contact_ids, 'enroll... into one workflow' clarifies workflow_id, and 'loops the official add-to-workflow call' explains how multiple contacts are processed. The confirm parameter is not addressed in the description, but the schema already documents its requirement.

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

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

The description states a clear verb (enroll) with a specific resource (contacts into one workflow) and includes a concrete limit (up to 25) and mechanism (loops the official add-to-workflow call). This distinguishes it from siblings such as workflows_list, which is a list-only operation.

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

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

It provides clear context by framing the tool as a way to run nurture blasts without CSV imports, which implies a bulk-enrollment use case. It does not explicitly name alternatives or when-not-to-use conditions, but the intended scenario is reasonably clear.

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

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

With no annotations provided, the description carries the full behavioral burden. The verb 'List' implies a read-only operation, and the description adds useful context about output fields and access prerequisites ('BYOK', 'PAID ONLY $39'). However, it does not mention potential errors, missing location_id behavior, or data scope beyond naming workflows.

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

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

The description is very compact and front-loaded: first sentence states the operation and its core use, and the following fragments add access constraints. Every part adds value with no redundant filler.

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

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

Given the tool's low complexity, the description covers purpose, return-content hints, and access prerequisites. However, it leaves the location_id parameter unexplained, does not clarify whether it is optional, and does not define what 'stats' means. This is adequate but not complete.

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

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

The schema has one location_id parameter with no description, and schema description coverage is 0%. The tool description never mentions location_id, how it should be used, or whether omitting it is allowed. The parameter name provides minimal self-evident meaning, but the description does not compensate for the schema's lack of documentation.

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

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

The description uses a specific verb and resource: 'List workflows (name/status/stats)'. It also states the purpose, helping the AI know what automation fires before touching contacts, which clearly separates this listing tool from action-oriented siblings like gold_ghl_workflow_bulk_enroll.

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

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

The description provides clear context for when to use the tool: before touching contacts, so the AI knows what automations may fire. It does not explicitly name sibling alternatives or state when not to use it, so it misses the full 'when/when-not' bar.

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

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

With no annotations provided, the description carries the full burden of behavior disclosure. It goes beyond stating the effect by explicitly constraining output to key names and 'never values', which is a meaningful privacy/security guarantee for agent decision-making. It also promises 'the exact next step', setting an expectation about the tool's advisory behavior.

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

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

The description is tight and front-loaded: the imperative 'run this FIRST' appears immediately, followed by a compact enumeration of the three kinds of outputs and the parenthetical safety guarantee. Every element earns its place with no filler or redundancy.

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

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

For a zero-parameter, no-output-schema diagnostic of low complexity, the description supplies everything an agent needs: when to run it, what it reports, what it deliberately withholds, and what it recommends next. There is no meaningful missing context for correct invocation.

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

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

The tool has zero parameters and schema coverage is vacuously 100%, so the baseline of 4 applies. The description appropriately focuses on output semantics instead of parameters, telling an agent what the check reveals rather than attempting to document nonexistent inputs.

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

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

The description clearly identifies this as the 'SETUP CHECK' diagnostic for GoHighLevel Gold and names its concrete outputs: license tier, API key presence, and the next step. This distinguishes it sharply from the operational sibling tools (conversations, workflows, contacts, appointments), which all perform domain actions rather than environment preflight.

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

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

The instruction 'run this FIRST' is an explicit temporal usage signal that establishes this tool as the entry point to the sibling suite. It does not name when-not-to-use conditions or direct alternatives, but as a zero-parameter first-run diagnostic, the ordering instruction is sufficient guidance for an agent.

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