CrunchJunkie

update_site_audit_settings

Change a client's SEO audit settings: pages per crawl (10 to the workspace's per-crawl cap), the crawler's device (mobile or desktop), the start URL (an https page of the client's own website; null resets it to the website), URL Inspection (inspectTop: pages per crawl, 0 to 100, on the client's Search Console quota), the key-page monitor (keyPages, monitor off / daily / hourly, acceptChecks: the checks a month the call states, off by default), the parameters to ignore (ignoreParams: up to 100 query parameter names removed from every URL found, so /contact/?topic=a is crawled once as /contact/; the start URL is kept as entered; [] clears it; free, from the next crawl; a changed list is another comparison scope) and the schedule (off, weekly with scheduleDay 0-6, monthly with scheduleDay 1-28; scheduleHour UTC, default 3). A schedule is off by default and switched on only with acceptPages: the pages per crawl it will request, as the call's own answer states it (call once without acceptPages to see the cap and the most a month of it can use). The preview shows each change, before and after. Without confirm:true it returns a preview.

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": {
      "clientId": "<clientId>"
    },
    "name": "update_site_audit_settings"
  }
}

Input Schema

Name	Required	Description
`device`	No	The crawler's device (Google indexes mobile first).
`confirm`	No	true saves. Omit to preview. With confirm:true, also pass the preview's previewToken.
`monitor`	No	The key-page monitor's cadence. Hourly needs Pro or higher.
`clientId`	Yes	Client id (from list_clients).
`keyPages`	No	Key pages of the client's own website the monitor checks; at most the plan's number.
`maxPages`	No	Pages per crawl.
`schedule`	No	The crawl schedule.
`startUrl`	No	https URL on the client's website; null = the website itself.
`inspectTop`	No	Pages per crawl read through Search Console's URL Inspection; 0 = off.
`acceptPages`	No	Switching a schedule on: the pages per crawl the user accepted (the cap the call states).
`scheduleDay`	No	weekly: 0 (Sunday) to 6; monthly: 1 to 28.
`acceptChecks`	No	Switching the monitor on or changing it: the checks a month the user accepted (the figure the call states).
`ignoreParams`	No	The whole list of query parameter names to ignore (replaces the saved list; [] = none). Names only (letters, digits and _ - . ~ [ ]), no "=" or value, compared case-insensitively, at most 100. A URL carrying one is crawled without it. Common tracking parameters: utm_source, utm_medium, utm_campaign, utm_term, utm_content, gclid, fbclid, msclkid.
`previewToken`	No	With confirm:true: the previewToken from this tool's preview (valid 15 minutes, once, for exactly the previewed arguments).
`scheduleHour`	No	Hour of the day, UTC (default 3).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations declare this is a non-destructive write, and the description adds the two-step preview/confirm contract plus previewToken lifetime (15 minutes, single use, bound to the previewed arguments). It also discloses side effects of ignoreParams ("free, from the next crawl; a changed list is another comparison scope") and that the start URL is kept as entered. That is meaningful context beyond the annotations, though nothing is said about permissions, who may change quota-consuming settings, or what the preview payload contains.

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

Conciseness2/5

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

The content is dense but delivered as one enormous run-on sentence with nested parentheticals covering seven unrelated settings, so an agent cannot quickly locate the preview/confirm rule or the schedule-enabling rule. Front-loading is good and little is truly redundant, yet the structure actively impedes scanning and would be far better as short grouped sentences.

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

Completeness4/5

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

For a 15-parameter mutation with no output schema, the description covers the critical gaps: preview versus save, defaults, quota-costing settings, and the side effects of changing ignoreParams. Authorization requirements and the shape of the preview response are the notable omissions.

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 the schema already carries the per-parameter documentation and a baseline of 3 applies. The description adds genuine semantics on top – that acceptPages/acceptChecks must match the figure the call itself states, that monitor is off by default, and the URL-collapsing effect of ignoreParams – but it mostly restates the same field meanings rather than adding format or interaction rules the schema lacks.

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?

Opens with a concrete verb+resource ("Change a client's SEO audit settings") and then enumerates the exact settings under its control, so an agent knows this mutates audit configuration rather than crawling, scanning or reporting. It does not explicitly distinguish itself from nearby siblings such as update_scan_settings, update_project_settings or create_site_audit_task, so the differentiation is left to the reader.

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

Usage Guidelines4/5

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

Gives unusually concrete operating procedure: without confirm:true it previews, confirm:true saves, and a schedule is enabled only by passing acceptPages, with the instruction to "call once without acceptPages to see the cap". That is real when-to-use guidance, but no exclusions or alternative tools are named for cases where this is the wrong choice.

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

All CrunchJunkie 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.

Resources

Need Help?