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

The readOnlyHint already tells the agent this is a safe read. The description adds genuine behavioral context beyond that: it enumerates the reference types scanned, states the validation source (location data), and describes the shape of the result (valid, broken, suggested replacements). It does not mention size limits or performance cost on large 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?

Three tight sentences with no filler: purpose first, then scope of the scan, then the return shape. Nothing restates the tool name or wastes space.

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?

With no output schema and a single fully documented parameter, the description carries the return-value burden well by naming valid/broken classifications and replacement suggestions. It is essentially complete, only slightly short on edge-case behavior such as empty results.

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?

With one parameter at 100% schema description coverage, the schema already documents workflowId fully, including its UUID format and origin from list_workflows. The description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

The description states a specific verb and resource (audit a workflow for broken entity references) and details exactly what is scanned (actions, triggers, pipeline/stage/user/custom field/custom value IDs). That is far more specific than the sibling get_workflow or read_workflow_outline, though no sibling is named explicitly to force the distinction.

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 use case is implied by 'audit a workflow for broken entity references,' which tells the agent the trigger condition is suspected stale references. However, there is no explicit when-to-use/when-not guidance and no mention of how this relates to siblings like get_workflow or read_workflow_outline.

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?

Annotations supply only destructiveHint=true, so the description carries most of the burden and does well: it discloses server-side UUID remapping and action-chain rewiring, the default copy naming, and that the full cloned object is returned. It does not reconcile why a clone is flagged destructive (e.g., whether it consumes quota or creates side effects), which keeps it out of 5 territory.

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 tight sentences, front-loaded with the core action, then server-side behavior, then the naming default and return value. No filler or repetition.

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?

With no output schema, the description usefully states it returns the full cloned workflow object, and it covers naming and server-side wiring for a 2-parameter tool. The missing piece is any acknowledgement of the destructiveFlag/side-effect profile, which an agent would want before invoking a mutation.

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 100%, and the description's naming detail ('Copy - {original name}' unless overridden) simply restates what the schema already documents for the name parameter. Baseline 3 applies since the schema does the heavy lifting.

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 (clone) and resource (workflow), and adds the scope detail 'independent copy on the same location'. It is distinguishable from create_workflow by intent, but the description never names any sibling to sharpen that contrast, so it falls short of a 5.

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

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

Usage is only implied by the verb; there is no explicit when-to-clone-vs-create guidance or any stated prerequisite beyond the workflowId source hint in the schema. Adequate but with clear gaps against the create_workflow/update_workflow siblings.

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?

The annotations declare destructiveHint=true, which is unusual for a create operation, and the description does not reconcile or explain that (e.g., whether the write is irreversible). The description does add one piece of behavioral value beyond annotations by stating it returns the created folder object, which matters since no output schema exists.

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, front-loaded with the action and scoped location, followed immediately by the return behavior. 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 single-parameter create tool the description covers the essentials and proactively notes the return value, compensating for the absent output schema. It omits failure modes such as duplicate names or permission requirements, which is a minor gap given the tool's simplicity.

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 100% and there is only one parameter, already documented as 'Name for the new folder' with minLength 1. The description adds no constraint information (uniqueness, character limits, collisions) 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.

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

Specific verb + resource ('Create a new workflow folder') with scope ('in the current GHL location'). The resource is distinguishable from overlapping siblings like create_tag, create_workflow, and rename_folder/delete_folder. It stops short of explicitly contrasting itself with those siblings, so it is clear but not maximally differentiated.

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 on when to create a folder versus creating a workflow directly, no prerequisites (permissions, location context), and no mention of the folder-nesting or naming rules. The agent is told what the tool does but not when to reach for it over alternatives.

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?

Annotations declare destructiveHint=true, which for a creation tool is a notable behavioral claim the description never addresses — it says nothing about duplicate-name behavior, overwriting, permissions, or reversibility. The description adds only the location scoping, so it neither explains nor contradicts the destructive hint, leaving the agent with an unresolved ambiguity.

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?

A single front-loaded sentence with no filler; nothing redundant. It is not padded, though it is also too spare to earn a 5 on structure alone.

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 one-parameter create tool with no output schema, the essentials are covered and the parameter is documented. However, given the destructiveHint annotation, the definition is incomplete about what the destructive behavior actually is and whether re-creating a name collides.

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?

Only one parameter exists and the schema describes it fully at 100% coverage ('Name for the new tag'), so the schema does the heavy lifting. The description adds no format, length, or uniqueness semantics beyond what the schema already states.

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+resource ('Create a new tag') and adds scope ('in the current GoHighLevel location'), so the action is unambiguous. It does not differentiate itself from any sibling (e.g., list_tags for checking existing tags) or clarify whether tag creation is idempotent, so it stops short of a 5.

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

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

There is no when-to-use, when-not-to-use, or alternative guidance. The only hint of context is the 'current location' scoping, which an agent must infer places the tag in the active sub-account rather than anywhere else.

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?

Annotations only supply destructiveHint=true, so the description carries most of the disclosure burden and it does so well: it explains that salvage decisions surface in skippedActions[] (HARD drops) and warnings[] (advisory), and that a HARD drop forces status to draft. It stops short of saying what causes a HARD drop or whether a call can partially succeed while still returning 2xx.

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?

Front-loaded with the verb+resource, then a sequence of dense, non-redundant sentences; every clause carries information (enum constraint, scaffold guidance, drop semantics, docs pointer). It is slightly crammed with disparate topics for a short description, but 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?

With 10 parameters, nested action/trigger objects, and no output schema, the description does what an agent needs: it explains the salvage/warning return surface and the status-fallback rule, and it delegates deep field documentation to a named companion MCP. The lack of detail on what triggers a HARD drop is the remaining 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning on top: the enum constraint on action/trigger types and the then/else vs three-sibling accepted forms for if_else conditions are structural facts the schema does not express. It leaves the per-field semantics to the external docs MCP rather than restating them.

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 opening sentence states a specific verb and resource ('Create a new workflow'), which is enough to separate it from publish_workflow, clone_workflow, and update_workflow by name alone. It stops short of explicitly scripting the distinction from clone_workflow, which is the nearest overlapping sibling.

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 gives concrete construction directives — action/trigger types must come from the schema enums, use the then/else scaffold for if_else — and routes the agent to the GHL Workflow Docs MCP for per-step-type field meanings. It does not state when to prefer create_workflow over clone_workflow or update_workflow, so it is clear context without exclusions.

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?

destructiveHint=true already declares the operation is destructive, but the description adds genuinely non-obvious behavior: contained workflows are relocated to root level rather than deleted, and the action is irreversible. It does not cover permissions or any partial-failure behavior, keeping it just short of 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?

Three short sentences that are front-loaded with the core action, followed by the cascade side effect and the irreversibility warning. 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?

For a single-parameter destructive tool with a complete schema and a destructive annotation, the description supplies everything needed: what it deletes, what happens to contents, and that it cannot be undone. No output schema is required for a delete operation.

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% and folderId is fully documented in the schema (including its provenance from list_folders). The description adds nothing about the parameter, so baseline 3 applies.

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 and resource ('Delete a workflow folder'), which cleanly distinguishes it from the sibling delete_workflow (which deletes the workflow itself, not a container). The scope is unambiguous without opening the schema.

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 purpose implies when it applies, but there is no explicit when-to-use/when-not guidance or reference to alternatives such as rename_folder, move_workflow, or create_folder. An agent can infer usage but is given no routing rules.

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?

Annotations already declare destructiveHint=true, so the safety profile is known; the description usefully adds that the deletion is permanent, irreversible ('no undo'), applied immediately in GHL, and that the deleted workflow name is echoed back for confirmation. It does not mention auth/permission requirements or any failure modes, but it meaningfully enriches the behavioral picture.

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 sentences, zero filler, with the destructive nature and the confirmation return value both front-loaded. Every sentence 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 one-parameter destructive tool with annotations covering the safety profile and no output schema, the description covers permanence, immediacy, irreversibility, and the return value. Nothing an agent needs to call it correctly is missing.

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 100% and the single parameter already documents itself, including the hint that the ID comes from list_workflows. The description adds nothing beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Delete a workflow') and adds the scope qualifier 'permanently'. The action is clearly distinct from siblings like clone_workflow, move_workflow, or update_workflow, though it does not explicitly name them.

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 gives no when-to-use or when-not-to-use guidance and names no alternatives (e.g., audit_workflow first, or move_workflow to relocate instead). The 'No undo' line is a warning about consequences, not usage direction.

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?

Annotations provide readOnlyHint=true, so safety is already covered. The description adds meaningful behavioral context beyond that: default compact summary with action names/types/ordering, and a warning that includeActionDetails=true can produce very large responses. It does not cover auth or rate limits, but for a read tool this is solid disclosure.

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 tightly written sentences, front-loaded with purpose, then default behavior, then the size warning and prerequisite. Every sentence carries information 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?

Given no output schema and moderate complexity, the description adequately explains the return shape (summary of action names, types, ordering) and flags the large-response risk. It falls short only in not distinguishing this tool from sibling read tools like read_workflow_outline and read_workflow_step.

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%, and the description largely repeats what the schema already states: workflowId comes from list_workflows, includeActionDetails defaults to false, and large responses are possible. It adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource: get a GoHighLevel workflow's structure including actions and triggers. This clearly distinguishes it from list/create/update workflow siblings, but it does not differentiate from other read-oriented siblings like read_workflow_outline or read_workflow_step, which an agent might reasonably confuse it with.

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 gives a useful prerequisite ('Call list_workflows first to find workflow IDs') and frames the default versus detailed mode. However, it does not say when to choose get_workflow over read_workflow_outline, read_workflow_step, or audit_workflow, leaving the agent to infer the right granularity.

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 load and does disclose the two-phase confirmation behavior that governs side effects, which is genuinely useful. It does not mention persistent side effects such as profile creation or window lifetime, leaving a minor gap.

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 sentences, front-loaded with the action, then the trigger, then the confirm protocol. No filler and every sentence contributes to correct invocation.

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-parameter tool with no output schema, the description covers the essential flow and even indicates the first call returns instructions rather than launching. Missing only minor detail on what state the subsequent launch leaves behind.

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 100% and the single confirm parameter is already documented in the schema as 'Set to true to actually launch Chrome.' The description restates this without adding new format or default detail, so the baseline of 3 applies.

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 ('Launch a dedicated Chrome window with GoHighLevel') and clearly separates this tool from its sibling test_connection by naming the failure condition that selects it. An agent can identify this tool without opening the schema.

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 an explicit trigger ('Call this when test_connection fails because Chrome is not running') and a precise two-step protocol: first call without confirm to get instructions, then confirm=true after user agreement. Both when-to-use and the sequencing are spelled out.

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?

readOnlyHint=true already covers the safety profile, so the description earns credit for going further: it discloses the return payload (association types and cardinality) and that results are implicitly scoped to the current location's contacts. Given there is no output schema, this return-shape disclosure is genuinely additive; only pagination/volume behavior is unaddressed.

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 tight sentences, zero filler, with the core purpose front-loaded and the return content immediately after. Every clause 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 no-parameter list tool without an output schema, the description covers scope (current location, contacts) and return content (association types, cardinality), which is most of what an agent needs. It stops short of describing result volume, ordering, or how association types map to objects, so a small gap remains.

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 takes zero parameters and declares additionalProperties=false, so there is no parameter semantics for the description to explain. The baseline for a parameterless tool is 4, and nothing in the text misleads about 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?

States a specific verb (List) and resource (object associations) plus the scoping domain (contacts in the current GoHighLevel location) and what is returned (association types and cardinality). No sibling tool overlaps with associations, but the description never names or differentiates against alternatives, so this lands just short of a 5.

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

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

The description explains what the tool returns but gives no guidance on when to reach for it versus the many other list_* siblings. There are no prerequisites, exclusions, or alternative routes mentioned, leaving usage entirely to inference from the name.

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?

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds that it returns object metadata plus custom and standard fields, which is useful scope info, but says nothing about location/auth requirements despite referencing 'the current location'.

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 tight sentences with the listing action front-loaded. Minor redundancy between 'List ... fields' and 'all custom/standard fields', but no wasted clauses.

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?

With no output schema, no parameters, and a read-only annotation, the description adequately covers what the tool does and roughly what it returns. The missing piece is sibling differentiation, which is a minor gap for a zero-input read 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?

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to compensate for on the parameter side.

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 (List) and resource (business object definition and its fields) scoped to the current location. However, it does not distinguish itself from the very similar sibling list_custom_fields, which an agent could easily confuse it with.

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 on when to use this versus list_custom_fields or list_custom_values, despite those being obvious alternatives in the sibling set. The agent must infer selection criteria on its own.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered and the bar is lower. The description adds that contact and opportunity fields are served by different internal endpoints, which is extra context, but it says nothing about pagination, result size, or ordering for a list operation.

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

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

Two front-loaded sentences with no filler; the purpose comes first and the parameter constraint second. The closing note about internal API endpoints is mildly tangential but short enough to earn 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 one-parameter read-only list tool with no output schema, the description covers location scoping and the entity-type requirement adequately. Additional detail on return shape or pagination would help but is not critical given the annotations.

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% and the single parameter's enum and description are fully documented in the schema, so the schema does the heavy lifting. The description restates that model selects the entity type (contact or opportunity) without adding format or behavioral detail beyond the schema.

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

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

The description gives a specific verb (List) and resource (custom fields) scoped to the current GoHighLevel location, and names the two entity types it operates over. It is clear on its face, but does not explicitly differentiate itself from nearby siblings like list_custom_values or list_business_fields, so it stops short of a 5.

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

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

It states that a model parameter must be supplied and what that parameter selects, which implies the usage context (listing fields for contacts vs opportunities). There is no explicit when-to-use/when-not-to-use guidance and no routing to an alternative sibling for related data such as custom values.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely useful context by stating the location scoping and the two categories of returned values (system-defined static vs. location-specific custom), but says nothing about pagination, limits, or auth.

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 tight sentences, front-loaded with the action and resource, and the second sentence delivers return-shape information rather than 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?

For a zero-parameter read-only list with no output schema, the description usefully compensates by describing what comes back and the location scope. It leaves pagination behavior unstated, which is a minor gap for a list endpoint.

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 takes zero parameters, so there is nothing for the description to compensate for. Baseline 4 applies; the description correctly avoids inventing filter semantics.

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+resource ('List custom values') and disambiguates with the parenthetical '(template variables)', which separates it from the similarly named sibling list_custom_fields. It does not explicitly name which sibling to prefer, but the resource is unambiguous.

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 when-to-use guidance, no prerequisites, and no mention of the adjacent list_custom_fields sibling. The 'list' verb plus readOnlyHint implies a safe read, but the agent gets no routing signal.

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?

The readOnlyHint annotation already establishes this is a safe read, so the bar is lower. The description adds real value by disclosing the return payload ('template names and IDs') and the location scoping, both of which matter because no output schema exists to convey them.

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 with zero filler, and the core action and scope are front-loaded before the return-value detail. Every clause carries information.

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 no-argument read tool with no output schema, describing the returned fields and location scope covers what an agent needs. Minor gaps remain around volume/pagination behavior and whether results can be filtered, but nothing blocks 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 takes zero parameters, so there is no parameter semantics to describe; the baseline for a 0-param tool is 4. Nothing in the description contradicts or misrepresents the empty 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?

States a specific verb (List) and resource (email templates) with a scope qualifier ('in the current GoHighLevel location'). It is trivially distinguishable from siblings such as list_tags or list_pipelines, and it even names what it returns.

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 'for use in workflow email actions' implies the downstream context for the returned IDs, which hints at when this tool is useful. However, it gives no explicit when-to-use condition, no prerequisites, and names no alternative tool for retrieving templates by other means.

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?

The readOnlyHint already tells the agent this is a safe read. The description adds scope (location-bound) and the shape of the return (folder names and IDs), which is helpful since no output schema exists, but it says nothing about pagination, ordering, or behavior with an empty location.

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 sentences, front-loaded with the action and scope, then output, then downstream usage. No filler and nothing redundant.

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?

With no parameters, no nested objects, and no output schema, the description carries most of the burden and does so adequately by naming the returned fields and how to consume them. It stops short of documenting ordering or empty-result behavior, which is a minor gap for a simple lookup.

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 takes zero parameters, so there is no parameter semantics to document; baseline 4 applies. The only parameter-like detail mentioned (folderId) belongs to other tools and is correctly framed as a downstream input.

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 (List), resource (workflow folders), and scope (current GHL location), and previews the returned fields (names and IDs). It is clearly distinguishable from siblings like list_tags or list_pipelines by naming the exact resource.

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 tells the agent what to do with the result (use folder IDs with move_workflow or list_workflows), which is useful downstream routing, but it never states when this tool should or should not be chosen over siblings, nor any prerequisites. Usage is implied by the ID-consumption note rather than explicit selection 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?

readOnlyHint=true already declares this is a safe read, so the description only needs to add context. It does add the location scoping and the return shape ("form names and IDs"), which is valuable with no output schema, but says nothing about pagination, result limits, or auth/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.

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

Two short sentences, no filler. The scope is front-loaded in the first sentence and the return shape follows 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 zero-parameter read tool with no output schema, the description covers what is returned and where it is scoped, which is essentially everything needed to call it correctly. Only minor gaps remain, such as whether the result set can be large or truncated.

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 takes zero parameters and the schema is empty with additionalProperties=false, so there is nothing to document and no risk of misinterpretation. Baseline 4 applies since the description cannot add parameter meaning that does not exist.

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 and resource ("List all forms") plus the scope ("in the current GoHighLevel location"). The resource is unique among the many list_* siblings, so the agent can distinguish it without opening the schema, though it never explicitly contrasts itself with any alternative.

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 is only implied by the verb: an agent can infer this is the way to enumerate forms, but there is no statement of when to prefer it over other discovery tools (e.g. list_custom_fields, list_workflows) or any preconditions such as a required location context.

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?

Annotation already marks readOnlyHint=true, so the safety profile is clear. The description adds the return format ('pipeline names with their stages (name, position)'), which is useful context beyond the annotation. It does not mention pagination or whether all pipelines are always returned, but with annotations covering safety, this is a solid addition.

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 sentences, front-loaded with the purpose and then the return shape. No 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.

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

For a simple list tool with no parameters and no output schema, the description explains what it returns ('pipeline names with their stages (name, position)'), which is the main missing piece from structured data. It is complete enough for an agent to call 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?

The schema has zero parameters, so the baseline is 4 per the rubric. No parameter information is needed in 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?

States a specific verb ('List') and resource ('opportunity pipelines'), scoped to the current GoHighLevel location. Siblings are all different resources (tags, folders, workflows), so no direct alternative needs naming, but the description does not explicitly differentiate beyond the resource name.

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 when-to-use guidance, no alternatives, and no exclusions. It simply describes the action; the agent must infer that this tool is for enumerating pipelines.

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?

readOnlyHint=true already declares the safe-read profile, so the bar is lower. The description adds useful scope ('current GoHighLevel location') and the return shape (tag names and IDs) absent from the annotations, but says nothing about pagination or result limits for a list operation.

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

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

Two short sentences with zero filler, front-loading the action and scope before the return detail. Every clause 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 no-parameter, read-only list tool with the safety profile already covered by annotations, the description supplies scope and return fields. The main omission is any pagination or result-size behavior, which is minor for this weight class.

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?

There are zero parameters, so the baseline is 4; schema coverage is 100% and additionalProperties=false confirms no hidden inputs. No parameter explanation is needed or expected.

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 (List) and resource (tags) plus the scope ('current GoHighLevel location'), making it distinguishable from sibling create_tag by verb alone. It does not explicitly name an alternative, so it stops short of a 5.

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

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

The description gives no when-to-use guidance, prerequisites, or comparison to alternatives; the only cue is that the verb 'List' implies a read. An agent could reasonably infer usage, but nothing is stated.

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?

The readOnlyHint annotation already tells the agent this is a safe read, so the behavioral bar is lower. The description adds the useful scope constraint of 'current GoHighLevel location' and hints at the return content ('link names and IDs'), which is modest value beyond the annotation but not rich 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.

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

Two short sentences, front-loaded with the action and scope, and the parenthetical clarification earns its place. 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?

For a zero-param read tool with a readOnlyHint annotation and no output schema, the description is adequate. However, it offers no guidance on pagination, filtering, or when the location context matters, which an agent might need for a list operation.

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 takes zero parameters, so there is nothing for the description to explain beyond scope. Baseline 4 applies. It does clarify 'current location' as the implicit scope, which is a minor gain.

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 gives a specific verb and resource ('List all trigger links'), clarifies the concept with a parenthetical ('one-click action links'), and names the scope ('current GoHighLevel location'). It does not explicitly differentiate from siblings like list_tags, but the resource is specific enough that confusion is unlikely.

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 when-to-use guidance, no prerequisites, and no alternatives named. The description implies a read operation but says nothing about when an agent should reach for this tool versus any other list_* sibling.

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?

The annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context by specifying the scope ('current location') and the returned fields, but it does not disclose other behavioral traits such as pagination, rate limits, or authentication requirements beyond what a read-only list implies.

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 tightly written sentences with zero waste. The core purpose is front-loaded, and the second sentence efficiently describes the return values without an output schema.

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 parameterless list tool with annotations covering safety, the description is nearly complete: it states the scope and returned fields. It does not mention pagination or how the 'current location' is determined, but those are minor gaps for this level of complexity.

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, so the baseline is 4. The schema coverage is 100% but there is nothing for the description to compensate for; no parameter semantics are needed.

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 verb ('List') and resource ('all users') with a clear scope ('with access to the current GoHighLevel location'). This resource focus clearly distinguishes it from sibling list_* tools such as list_tags and list_pipelines, which target different entities.

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?

There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description merely states what it does; it does not help an agent decide between this and any other tool.

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?

Annotations declare readOnlyHint=true, so safety is covered. The description adds useful behavior beyond that: it auto-fetches all pages by default, which is non-obvious and important for an agent to know, and it describes what the summaries contain.

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 sentences, front-loaded with purpose, then return shape, then behavior and parameters. Efficient and no wasted phrasing, though the return-value detail is slightly redundant without an output schema.

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?

Complete enough for a read-only list tool: purpose, scope, return contents, and pagination behavior are all covered. No output schema exists, so explaining the summaries is helpful; only finer details like error or empty-result behavior are missing.

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 100%, so the schema already documents every parameter with defaults and semantics. The description restates the pagination and sorting intent but adds no syntax or format details 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.

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

States a specific verb+resource (list workflows) and scopes it to the current GoHighLevel location. It is distinguishable from siblings like get_workflow, audit_workflow, and list_folders because it describes a collection listing with summaries.

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?

Explains the default behavior (auto-fetch all pages) and when to override it with limit/offset, and mentions sorting. It does not explicitly name a sibling as an alternative or state when-not-to-use, 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.

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

No annotations are provided, so the description carries the full burden. Beyond the root-move mechanic it says nothing about whether the move requires folder permissions, what happens if folderId is invalid, whether the workflow's identity/steps are preserved, or whether the move is reversible — significant gaps for a mutation tool.

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

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

Two short sentences, front-loaded with the action and followed immediately by the non-obvious root-move rule. Every clause 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 two-parameter move with full schema coverage and no output schema, the description covers both invocation modes adequately. It falls short only on error/permission behavior, which is a modest gap at this complexity.

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 100%, so both parameters are already documented in the schema, including the 'omit or null for root' behavior the description also repeats. The description adds no meaning beyond that structured data, so the baseline of 3 applies.

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) and resource (workflow) plus both possible destinations (a folder, or root level). No sibling tool performs this operation, so an agent can route to it unambiguously.

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 explains the operational variant — omit folderId or pass null to move to root — which is genuine usage guidance, but there is no when-to-use vs. when-not guidance and no named alternatives among the folder/workflow siblings.

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?

Annotations only declare destructiveHint=true, yet the description discloses transactional semantics (all-or-nothing, aborts before any GHL write), optimistic-concurrency behavior (detects external workflow changes via the version field), and an explicit non-guarantee (rewire_step does not validate for cycles or orphaned downstream steps; the caller owns flow correctness). That 'you are responsible for' framing is exactly the kind of hazard disclosure a destructive tool needs.

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?

Front-loaded with the core purpose before diving into op taxonomy and semantics, and every clause carries information. It is dense to the point of terseness in the 'Param roles —' fragment, and some op-list detail duplicates the schema's const values, which slightly dilutes conciseness.

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 destructive, no-output-schema mutation tool with a highly polymorphic operations array, the description covers purpose, op semantics, parameter roles, failure semantics, concurrency, prerequisites, and the escape hatch to a sibling. Nothing an agent needs to call this safely appears missing.

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, but the description adds real semantic value the schema cannot express: the subject-vs-anchor distinction between step_id and after_step_id, the step_id alias accepted by insert_after, and that next is a scalar pointer overwrite rather than a splice. The only gap is that per-op required-field combinations are left to the schema's anyOf.

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 (apply an ordered list of patch operations) on a specific resource (a workflow) with a stated mechanism (deterministic server-side pointer rewiring). It enumerates the exact op set and explicitly distinguishes itself from the sibling update_workflow for whole-workflow rewrites. An agent can select this over update_workflow without opening either schema.

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?

Explicit prerequisites ('Use after read_workflow_outline + read_workflow_step'), an explicit exclusion boundary ('For whole-workflow rewrites or branched-step splices, fall back to update_workflow'), and a pointer to the docs MCP for field meanings. This is the when/when-not/alternatives pattern at full strength.

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?

The destructiveHint annotation already flags this as a significant state change, and the description adds real context beyond it: the workflow becomes active, will start processing contacts when triggered, and the full workflow object is returned. It stops short of stating whether publishing is reversible or what permissions are required.

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 sentences, front-loaded with the action and state change, followed by the operational consequence and the return value. No filler, and the return-value sentence is useful given there is no output schema.

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-parameter state-transition tool with only a destructiveHint annotation and no output schema, the description covers the action, the consequence, and the return shape. Missing only edge-case behavior such as what happens if the workflow is already published or lacks required steps.

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 100% and the single workflowId parameter is fully documented in the schema, including its source ('from list_workflows'). The description adds no parameter-level meaning, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Publish a draft workflow, changing its status to published') and names the state transition, so the agent knows exactly what the tool does. It does not explicitly differentiate itself from nearby siblings like update_workflow or patch_workflow, so it falls short of a 5.

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

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

Usage is implied by the precondition 'draft workflow' — use this when a workflow is in draft and should go live. There is no explicit when-not guidance, no mention of prerequisites or authorization, and no routing to alternatives such as update_workflow for non-status changes.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful context beyond that: it is free/cheap, it returns a reduced projection, and it explicitly excludes attributes — a real behavioral constraint an agent needs to know. It does not cover pagination or error behavior, keeping it short of 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?

Dense and front-loaded: cost signal first, then return shape, then routing advice. Every clause earns its place with 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?

With no output schema, the description compensates by enumerating what is returned and what is omitted (no attributes), which is exactly the information needed to decide between this and read_workflow_step. Nothing critical for correct invocation is missing.

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?

There is only one parameter and schema coverage is 100%, with the schema itself stating the ID comes from list_workflows. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (read) and resource (workflow outline), and precisely enumerates the returned fields: metadata plus step IDs/types/names/order/next/parentKey. It clearly distinguishes itself from get_workflow (full read) and read_workflow_step (per-step detail).

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?

Explicitly says to prefer this as the FIRST read when editing a workflow and to follow with read_workflow_step for steps to be mutated. Names the alternative and the condition that selects it, leaving nothing to inference.

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?

Annotations already establish readOnlyHint=true, so safety is covered. The description adds value beyond that: the '(FREE)' cost signal and the specific failure behavior ('structured step_not_found error with valid_step_ids') let the agent anticipate and handle the error path.

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 tight sentences with zero filler. The core action is front-loaded, followed by the usage ordering and the error contract, each earning 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 read-only tool with full schema coverage and annotations carrying the safety profile, the description covers action, sequencing, and the notable error case. It stops short of describing return structure or pagination, but no output schema exists and the 'full JSON' phrasing is sufficient for calling 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 100% – both workflowId and stepId are documented in the schema with their source references. The description only restates 'workflow + step ID', adding no format or syntax detail beyond the schema, so the baseline of 3 applies.

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

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

States a precise verb and resource ('Returns one step's full JSON for a given workflow + step ID') plus scope. It also differentiates itself from siblings by naming read_workflow_outline and the patching workflow, so an agent can place it without opening the schema.

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?

Explicitly sequences usage: 'Use after read_workflow_outline to inspect a specific step before patching it.' This names the predecessor tool and the downstream tool, giving the agent a clear when-to-use condition rather than leaving it to inference.

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, and it does disclose the key behavioral trait: this is a re-scan/switch operation that avoids a server restart, with dual list-vs-switch modes. It omits error behavior for an invalid targetId and any side effects, keeping 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?

Four short sentences, front-loaded with the primary action, with no filler. The last two sentences partially repeat what the schema already documents, preventing a perfect score.

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-parameter tool with no output schema, the description covers purpose, the two modes, and the practical benefit. Only return details and failure handling are unaddressed, which is a minor gap here.

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% and the schema description already explains that targetId comes from a prior listing call and that omitting it lists tabs. The description restates this rather than adding format or additional meaning, so the baseline 3 applies.

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 concrete verb and resource (re-scan Chrome for GoHighLevel tabs, then switch tab/location), which is clearly distinct from browser-lifecycle siblings like launch_chrome and the many read/list_* tools. It doesn't explicitly name those siblings, but the action is unambiguous.

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?

Gives a clear context for use ('change locations without restarting the server') and spells out the two invocation modes: omit targetId to list tabs, supply it to switch. It stops short of naming alternatives (e.g., launch_chrome/test_connection) 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.

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

No annotations provided, so the description must carry the behavioral burden. It indicates a mutation, but doesn't detail permissions, side effects, or return behavior. The description implies the operation targets an existing folder but lacks depth for a mutation tool.

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

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

A single, direct sentence that conveys the core action without any extraneous information.

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 no annotations and no output schema, the description is minimal. For a simple rename operation, it covers the basic action, but lacks comprehensive behavioral details that would be expected without structured support.

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%, and the schema fully describes both parameters. The description adds no additional parameter semantics, so the baseline would be 3, but the high coverage suggests the schema handles it completely, warranting a 4 for relying on schema without need for compensation.

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 (rename) and resource (workflow folder), clearly distinguishing it from siblings like create_folder, delete_folder, and move_workflow.

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?

Implies usage on an existing folder, but doesn't state when to use this vs alternatives or any prerequisites beyond the obvious requirement of an existing folder ID.

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?

readOnlyHint=true already establishes the safe read-only profile. The description adds substantive detail beyond that: the three specific preconditions it probes (Chrome reachability, GHL tab, Firebase token), which is real behavioral context. It omits what failure output or partial-failure states look like.

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 tight sentences with no filler; the verification targets come first and the call-ordering instruction follows. Every clause 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 three-dependency diagnostic with no output schema, the description covers what is checked and when to run it. It stops short of describing the result shape or the remediation path when a check fails, which is the only meaningful 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?

Zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter semantics are needed or missing.

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 ('Verify') and enumerates the exact resources checked: Chrome reachability, GHL tab presence, and Firebase token extraction. None of the siblings (reconnect, launch_chrome, list_*) do this, so an agent can identify it immediately.

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?

Explicitly says 'Call this first to confirm the MCP server can communicate with GoHighLevel,' giving clear sequencing context. It does not mention what to do on failure (e.g., fall back to launch_chrome or reconnect), which would have made the guidance complete.

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?

Goes well beyond the destructiveHint annotation by disclosing salvage behavior (skippedActions[], warnings[]) and a consequential side effect: any HARD drop forces status to draft. The schema also makes clear that omitted trigger IDs are DELETED. It does not mention auth requirements or reversibility, keeping it short of 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?

Front-loaded with the core action and constraint, then supporting behavior and a docs pointer. Six tight sentences with little waste, though the enum/scaffold sentence is dense and slightly harder to parse.

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 an 11-parameter mutation tool with no output schema, the description helpfully explains where salvage/warning information surfaces and the forced-draft consequence. It also points to external docs for step-type specifics, covering the main gap, though it leaves auth/reversibility unstated.

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 100%, so the baseline is 3, but the description adds real meaning: enum-sourcing requirement for types, the then/else scaffold for if_else, and the replace-not-merge semantics of the actions/triggers arrays. Minor caveat: it says action types 'must come from the enums in this schema,' yet no enum exists for action type in the schema.

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

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

States a specific verb and resource ('Update an existing workflow') and adds the key modifier 'with partial changes,' which tells the agent it is a merge-style operation. It does not, however, contrast itself with the sibling patch_workflow, which an agent could reasonably confuse with partial updates.

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?

Gives operational guidance ('Pass only fields you want to change') and routes the agent to the GHL Workflow Docs MCP for field-level detail. It never says when to prefer this over patch_workflow or create_workflow, so alternative selection is left to inference.

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