HighLevel Agency & Builder MCP

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds value by naming the specific checks performed (Safe-Writes Policy preset, progressive discovery, doctor check), but doesn't disclose the return shape or what 'health' means when degraded.

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, front-loaded sentences: the capability first, then a concrete example. No filler. The example is compact and clarifying rather than verbose.

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 carries some burden to explain what a health check returns, and it only partially does so by enumerating the checked areas. How failures or degraded states are reported is left unspecified, which is a meaningful gap for a diagnostic 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 description coverage is 100%, so all three parameters (company, context, includeDoctor) are already documented, and the example demonstrates context plus includeDoctor. The description adds no meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Check') and names concrete resources: connection health, active Safe-Writes Policy preset, and progressive discovery status. This tells an agent exactly what the tool inspects. It falls short of a 5 because it doesn't distinguish itself from the sibling ghl_agency_doctor, which plausibly overlaps.

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 included example invocation implies a typical context, but there is no explicit statement of when to use this versus ghl_agency_doctor or ghl_agency_contexts. Usage is implied rather than stated, leaving the agent to infer the right selection.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so 'without mutating state' is largely a restatement. The phrase 'known sub-account locations' adds a small amount of information about what the call surfaces, but nothing is said about what happens when the context enum is omitted versus supplied.

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 the scope front-loaded and a compact, immediately usable example. Every element earns its place and nothing is padded.

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 must convey the shape of the response, and it only loosely does so ('configured contexts and known sub-account locations'). It is adequate for a single optional-parameter read tool, but leaves ambiguity about the relationship to the sibling locations tool and about what an omitted context returns.

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 optional enum parameter is documented in the schema. The description still adds value by showing a concrete populated example, which makes clear the context value is meant to be one of the enum identifiers rather than free 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 a specific verb+resource ('List configured HighLevel agency account contexts and known sub-account locations'), so the agent knows exactly what it returns. However, it overlaps with the sibling ghl_agency_locations by also claiming to return locations without explaining how the two differ.

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 example call ghl_agency_contexts({"context":"moosh-growth"}) implies how to use it and shows that inspection can be scoped, but there is no explicit when-to-use guidance, no exclusions, and no pointer to alternatives such as ghl_agency_locations or ghl_agency_connection_health.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the agent knows this is a safe, repeatable, non-mutating check. The description adds the useful scope detail that it checks four distinct things, but says nothing about what a failing check looks like or how results are reported. Adequate but thin beyond the annotations.

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

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

Two short sentences, front-loaded with the verification scope, followed by a compact example that costs little space. Nothing is wasted, though the example largely restates the 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 read-only audit tool with only two optional parameters this is close to sufficient, but with no output schema the description never indicates what the audit returns or how failures surface. An agent knows how to call it but not what to expect back.

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 enum values are already enumerated in the schema, so both parameters are fully documented structurally. The example call usefully shows that 'context' is the primary selector, but the description adds no meaning about how 'company' interacts with 'context' or whether it narrows the audit scope.

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 ("Verify") and enumerates exactly what is checked: PIT, CRM session, company, and seed location readiness. That is far more concrete than the title alone. It does not, however, distinguish itself from the closest sibling, ghl_agency_connection_health, which sounds like an overlapping readiness check.

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 statement of when to run this audit, when to prefer it over ghl_agency_connection_health, or what prerequisites must hold first. The only guidance is a sample invocation, which shows call shape rather than usage conditions.

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 idempotentHint=true and destructiveHint=false, and the description adds genuinely useful behavior: dry-run preview, read-back verification, and the two-phase apply pattern gated by the 'yes' flag. It does not clarify whether 'set' overwrites unspecified fields or how 'ensure' differs, which would complete the 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?

Two sentences, front-loaded with the verb and resource, with a compact example that anchors parameter usage. No padding, though the example slightly duplicates the schema's enum values.

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 5-parameter mutation-capable tool with no output schema, the description covers the safety workflow well, but the semantic difference between 'set' and 'ensure' — the core ambiguity an agent faces when picking an action — is left unexplained in both description and 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 100%, so the baseline is 3. The description reinforces the dry-run/apply semantics tied to the 'yes' parameter and shows 'action' and 'context' usage in the example, but adds no meaning for the 'set' vs 'ensure' actions or the optional 'company'/'location' fields beyond what the schema already says.

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 specific verbs (list, inspect, update) and a concrete resource (HighLevel sub-account locations), so an agent knows exactly what domain it operates on. It does not explicitly differentiate itself from siblings like ghl_agency_contexts or ghl_agency_doctor, leaving that distinction implicit.

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 worked example ({"action":"list","context":"moosh-growth"}) implies a typical listing use case, but there is no explicit guidance on when to choose this tool over ghl_agency_contexts or ghl_agency_connection_health. Usage is suggested rather than 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?

Annotations already declare this is a non-read-only, idempotent, non-destructive, closed-world operation, so safety is covered. The description adds that activation applies to the current Progressive Discovery session, but does not say whether enabling replaces or augments the current tool set, whether 'pack' and 'tools' can be combined, or whether the change persists past the session.

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 action and scope in one sentence, followed by a compact example. The example partly restates an enum value already visible in the schema, so it is slightly redundant but still cheap.

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 only two optional, fully documented parameters and a complete annotation set, this is close to sufficient. However, the key interaction — pack vs. tools, additive vs. replacing, and effect duration — is left unstated for a state-mutating session 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% with enum values and bounds already documented, so the baseline is 3. The description demonstrates the 'pack' parameter with a concrete value ('onboarding') and mentions 'specific tool names' for the tools array, but adds no semantics about precedence or combination between the two parameters.

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 (enable) and resource (a HighLevel MCP tool pack or named tools) scoped to the 'current Progressive Discovery session'. An agent can tell it apart from read-oriented siblings like ghl_agency_tools_search, though the contrast is only implicit.

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 example invocation shows the intended shape of a call and the session scope is named, but there is no explicit when-to-use/when-not guidance and no reference to the sibling ghl_agency_tools_search (which one would presumably use to discover names before enabling 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description usefully adds scale (55 tools) and the searchable surface (tool names and descriptions), but says nothing about result shape, result limits, or behavior when pack and query conflict.

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, no filler: the capability and its scope come first, followed by a concrete call example that doubles as usage guidance. Every element 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?

With only two optional params and no output schema, the description should say what a result looks like (tool identifier, description, pack) so the agent knows it can chain into ghl_agency_tools_enable. That return-shape guidance is missing, though the core search contract is adequately conveyed.

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 description adds a little beyond the schema by framing 'pack' as a domain pack filter and clarifying that the keyword matches tool names and descriptions, but it does not explain the eleven enum values or how pack='all' interacts with a query.

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 — searching across 55 native HighLevel Agency MCP tools and tool packs — and names the two search axes (keyword, domain pack). It is clearly distinct from siblings like ghl_agency_tools_enable or ghl_agency_doctor, though it never explicitly contrasts with 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 purpose implies discovery ('use this to find a tool'), and the inline example shows a realistic invocation with pack="all". However, it never says when this should be preferred over browsing siblings directly, or that the typical flow is search → enable via ghl_agency_tools_enable.

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=false, idempotentHint=true and destructiveHint=false, so safety is largely covered. The description adds useful context that syncing is batched and that the scan looks for broken merge tags and TBD placeholders. It still doesn't say whether sync overwrites existing custom values, whether validate/diff touch remote state, or what auth scope is needed.

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

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

Two tight sentences with the capability front-loaded and a concrete invocation example. Nothing is redundant, though the example sentence adds less value than a sentence describing the diff mode would.

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 multi-mode tool with a write path and no output schema, the description omits what each mode returns (e.g., a report of broken merge tags, a diff listing) and what sync actually changes. It is enough to start a call but not enough to interpret or safely sequence one.

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 and the action enum are documented structurally; baseline is 3. The description's example demonstrates a plausible parameter combination but adds no semantics for what 'diff' compares or what locationId defaults to when omitted (no required params).

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 specific verbs and resources: batch-sync Custom Values plus scan SMS/email templates for broken merge tags or TBD placeholders. It clearly reads as a sub-account custom-values tool, distinct from the agency-level siblings like ghl_agency_doctor and ghl_snapshot_diff_audit. However, the 'diff' mode is never explained, so the stated purpose covers only two of the three actions.

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 pick this tool over alternatives, and no explanation of when to choose validate vs diff vs sync. The example call only demonstrates syntax, not decision criteria. An agent must infer that 'sync' is the mutating path and validate/diff are read paths entirely from the enum 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 openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is partly covered. The description adds real context beyond that: it mutates external DNS records (CNAME/A/TXT) and performs SSL checks, and dryRun previews changes — telling the agent this reaches outside HighLevel's boundary. It stops short of stating reversibility, propagation wait times, or what a partial failure leaves behind.

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 action and scope, followed by a compact usage example that earns its place by demonstrating dryRun. No filler or repetition of the title.

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 open-world DNS mutation with no output schema, the description covers the workflow phases and the preview flag but omits what the tool returns (records to publish? propagation status?), how failures are surfaced, and the fact that no parameters are marked required yet the operation clearly needs domain + locationId.

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 all three parameters are already documented, making baseline 3 correct. The embedded example shows a plausible combination of domain/locationId/dryRun but adds no semantics about formats, constraints, or whether domain and locationId are effectively required despite required=[].

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 verbs (plan, verify, attach) against a concrete resource (HighLevel custom funnel domains, branded short-link DNS records with SSL). An agent immediately knows this is the domain/DNS onboarding tool. It does not name any sibling, but none of the listed siblings overlap this domain, so differentiation is implicit rather than stated.

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 three-phase framing (plan → verify → attach) and the dryRun example imply a preview-then-apply workflow, but there is no explicit statement of when to use this versus e.g. ghl_site_builder_sync, no prerequisites (agency vs. sub-account token), and no when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful domain context by listing exactly what is audited, including forwarding loops and unassigned monthly wallet drain, though it does not describe return format or omission 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 two focused sentences with the purpose front-loaded and a compact example. Every sentence earns its place and there is no unnecessary text.

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 one-optional-parameter tool with rich safety annotations and no output schema, the description gives enough context to understand the audit scope. The main minor gap is that it does not state what happens when the optional locationId is omitted.

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 single locationId parameter is already documented in the schema. The description provides an example invocation but adds no meaning beyond the schema, such as what happens when locationId is omitted.

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: "Read-only audit of sub-account LC Phone numbers, number pools, forwarding loops, and unassigned monthly wallet drain." It clearly distinguishes this tool from the sibling agency and governance tools by naming a concrete phone-wallet audit scope.

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 usage through "Read-only audit" and an example call, but it does not explicitly state when to use this tool versus alternatives or when not to use it. No prerequisites or exclusions are provided.

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

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

Annotations already declare non-read-only, idempotent, non-destructive, but the description adds genuinely new behavior: the operation preserves 2-step carts and 1-click upsells, which is the key safety promise for a layout sync. It stops short of stating required scopes, whether a live run is reversible, or what the diff output looks 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 short sentences: the capability sentence leads, the concrete example follows. No filler, and the most important behavioral promise (cart/upsell preservation) is front-loaded in the first sentence.

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 mutation tool with no output schema, the description should say something about what 'export' and 'diff' return or how a sync reports changes. It covers the risk of breaking carts/upsells but leaves the response shape and failure behavior undocumented, which is a clear gap for a no-output-schema mutation 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 all four parameters are already documented in the schema, establishing the baseline of 3. The description's example illustrates a valid combination (locationId + funnelId + dryRun) but adds no format or constraint detail beyond what the schema already says.

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 specific verbs (export, diff, update) and specific resources (HighLevel funnel steps and website layouts), so an agent can tell exactly what domain it operates on. It doesn't differentiate from any sibling, but the sibling list contains no comparable site/funnel tool, so that gap is minor.

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 only implied: the example shows dryRun=true for a preview, which suggests the inspect-before-mutate workflow, but the description never says when to use dryRun vs a live sync or what happens if neither funnelId nor stepId is given. No exclusions or alternatives are 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description reinforces this with 'without overwriting assets', but adds nothing about what the diff result contains or how large accounts are handled — meaningful given there is no output schema.

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

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

Two sentences, front-loaded with the core comparison and its non-destructive guarantee. The example call earns its place by showing the two IDs used together, though it is close to redundant with a 100%-covered 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 diff tool with no output schema, the description should say what the comparison returns (categories of drift, counts, per-asset detail). It also leaves the all-optional parameter contract unexplained, so an agent cannot tell what an empty-argument call does.

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; the example call only restates the parameter names with sample values. Neither the description nor the schema explains what happens when the optional parameters are omitted (required is empty), which is the one real semantic gap.

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 pair: compare a live sub-account against a reference Master Snapshot. The 'without overwriting assets' clause distinguishes it from any apply/sync operation, though it never names a sibling alternative explicitly.

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 'without overwriting assets' — this is the read-only diff path rather than a mutation — but there is no explicit when-to-use/when-not-to-use statement and no named alternative among the audit siblings (e.g. ghl_custom_values_audit, ghl_phone_wallet_audit).

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=false, idempotentHint=true and destructiveHint=false, so the safety profile is carried. The description adds the least-privilege framing and the offboarding intent, but never says what 'audit' returns, what permissions are required to assign/offboard, or that offboarding revokes access rather than deleting a user.

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, zero filler: the core capability is front-loaded and the example follows immediately. Nothing repeated from the title or 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 mutation tool with no output schema, the description leaves a critical hole: there is no parameter for identifying which user to assign or offboard, and the description never explains how a target user is specified or what an audit returns. An agent cannot reliably invoke 'assign' from this definition alone.

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 both parameters are enums, so the schema already documents them; baseline is 3. The description adds a concrete example pairing (audit + va-support) and names three of the four presets, but omits 'agency-admin' and does not explain action/preset combinations (e.g. preset is irrelevant for offboard).

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 ('Provision staff with least-privilege role presets', 'offboard sub-account access') and enumerates concrete presets. The 'audit' action appears only inside the example, so the tool's full action surface isn't fully surfaced in prose, keeping it below 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 example shows one invocation path ({"action":"audit","preset":"va-support"}), which implies how the tool is used, but there is no explicit when-to-use/when-not guidance, no prerequisites, and no mention of how this differs from the other ghl_* agency tools.

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=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is carried by structured data. The description adds 'publish' and a dryRun preview example, but says nothing about permissions required, what publishing changes, or reversibility beyond what annotations imply.

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

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

Two sentences plus a compact example, with the purpose front-loaded and zero filler. Every element 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?

With no output schema, the description should ideally say what a compile/publish returns or what the dryRun diff contains. For a publishing tool with zero required params, this leaves the agent guessing about side effects and 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?

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description's example illustrates locationId/preset/dryRun together, which adds a little contextual meaning but no syntax 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?

States specific verbs (synthesize, publish) and three concrete resource types (workflows, LeadShield form guards, call-screening IVRs). These are clearly distinct from the audit/governance siblings, so an agent can route to it confidently.

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 example invocation implies a preview-then-publish usage pattern and the dryRun parameter hints at safe testing, but there is no explicit statement of when to use this tool versus alternatives or when it should not be used.

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