Hoot Lens

Preview a settings change

preview_settings_change

Read-only

Previews a change to the site's Hoot Lens setup without making it. Returns the exact diff (one sentence per change), the effects from the site's own data (for example which recorded pages would stop being recorded, or how many visits a page goal would have matched last week), warnings, and a change token valid for 10 minutes. Nothing is changed. Settings changes are two steps: a preview returns a change token, and applying that token commits the change. Agent credentials can make capture stricter or add things to measure, not looser: removing a mask or block selector, unmasking an input, keeping query strings, moving to a less strict privacy preset and removing or loosening a path preset are refused (403, privacy_weakening_refused). Areas: targeting (addInclude, removeInclude, addExclude, removeExclude: page path globs such as /champions or /blog/*; with no include rule every page is recorded, and adding one narrows capture to the listed pages, which the warnings state), goals (add, update by id, remove by id; click goals match by selector, hootId or label, page goals match a path glob), funnels (add with 2 to 8 steps, each a goal id or exact goal name, including a goal added in the same change; remove by id), privacy (stricter only: preset, addMaskTextSelectors, addBlockSelectors, removeUnmaskInputSelectors, captureQueryStrings false) and pathPresets (set: [{match, preset}] where preset is safe-form, balanced or strict; safe-form records clicks and steps on application and contact forms but no field values, even when the site preset is full, and ignores the site's unmasked-input allowlist and query strings there). Owners can change every area; editors can change goals and funnels. Needs the configure scope.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>",
      "changes": "<changes>"
    },
    "name": "preview_settings_change"
  }
}

Input Schema

Name	Required	Description	Default
`changes`	Yes	The settings areas to change; areas left out are unchanged.
`projectId`	Yes	The project ID

Output Schema

Name	Required	Description	Default
`diff`	No
`token`	No
`changed`	No
`effects`	No
`message`	No
`warnings`	No
`expiresAt`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces 'Nothing is changed' consistently. Beyond that it discloses the return contents (diff, effects, warnings, token), a 10-minute token TTL, the 403 privacy_weakening_refused failure mode, and the role/scope requirements — rich context annotations do not cover. Deduction only because it does not state rate limits or what happens when the token expires.

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

Conciseness4/5

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

Front-loading is strong — purpose, return shape, and the two-step workflow precede the caveats, and nearly every sentence carries information. It is, however, a single dense paragraph whose area-by-area detail would parse far better as a list, costing some readability.

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

Completeness5/5

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

For a tool with a deeply nested five-area schema, an output schema, and privacy-sensitive mutation semantics, the description still covers permissions, scope, the refused-change list, and per-area semantics. Nothing an agent needs in order 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.

Parameters5/5

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

Although schema coverage is 100%, the description adds substantial meaning the schema cannot convey: glob syntax examples (/champions, /blog/*), the fact that adding an include rule narrows capture, how click goals match (selector/hootId/label) versus page goals (path glob), that funnel steps may reference a goal added in the same request, and what safe-form actually records. This goes well past the structural constraints in the schema.

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

Purpose5/5

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

States a specific verb (previews) and resource (a change to the site's Hoot Lens setup) and immediately contrasts with the commit step, so it is clearly distinguished from apply_settings_change and get_site_settings. An agent knows exactly what this does 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.

Usage Guidelines5/5

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

'Settings changes are two steps: a preview returns a change token, and applying that token commits the change' explicitly routes the agent to the counterpart tool and the condition that selects it. It further constrains usage by role (owners vs editors) and scope (configure), and enumerates which changes are refused, leaving little to inference.

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

All Hoot Lens tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.