Skip to main content
Glama

HighLevel Agency & Builder MCP

Diff Sub-Account Against Master Snapshot

ghl_snapshot_diff_audit
Read-onlyIdempotent

Compare a live HighLevel client sub-account against a reference Master Snapshot without overwriting assets. Example: ghl_snapshot_diff_audit({"locationId":"loc_123","snapshotId":"snap_456"})

Input Schema

NameRequiredDescriptionDefault
locationIdNoLive HighLevel sub-account location ID to audit.
snapshotIdNoReference Master Snapshot ID to compare against.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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

Schema description coverage is 100%, so both parameters are 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.

Purpose4/5

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.

Usage Guidelines3/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.