squirrelscan

Update website settings

update_website_settings

Destructive

Change one website's stored audit settings: level, max_pages, render, external_links, max_depth, scope, include_patterns, exclude_patterns and internal_links, broken_link_alerts (Pro and Team; switching it off is allowed on every plan), schedule (off, daily, weekly or monthly) for its recurring audits, and confirm_ownership, which records that the user owns the site or is authorized to audit it (set it only when they have said so). Omitted fields are left unchanged. Values are checked the same way the dashboard's settings are and held to the organization's plan; the result reports what is stored afterwards, which fields were applied, and any plan clamp. Turning recurring audits on, changing their cadence, or a change that raises the most one audit can cost returns status "confirmation_required" with the estimated credit cost and changes nothing until it is sent again with the same arguments plus confirm: true. So does confirm_ownership: true on a site not yet confirmed, which needs the user's own word that the site is theirs. schedule: "off" and changes that cost nothing more apply at once.

Input Schema

Name	Required	Description
`level`	No	Audit level preset. Setting one resets the level's settings to the preset, with any max_pages, render or external_links in the same call applied on top.
`scope`	No	'discover' follows links from the pages it finds; 'sitemap' audits only the URLs the site's sitemap publishes.
`render`	No	Rendering: off fetches over HTTP only, auto renders the pages that need JavaScript, all renders every page.
`confirm`	No	Approve a change that turns recurring audits on, changes their cadence, raises the most one audit can cost, or confirms the site's ownership. Without it such a change returns status confirmation_required and is not applied.
`schedule`	No	Recurring audits: off, daily, weekly or monthly. A cadence the plan does not run is held to one it does, and the result says so.
`max_depth`	No	How many links deep the crawl follows from the start page, 1 to 10; null removes the limit.
`max_pages`	No	Page budget of each audit, 1 to 10000. A value above the plan's per-audit ceiling is stored and held to the ceiling when an audit runs (runs_as reports it).
`website_id`	Yes	Website id from list_websites, run_audit or add_website.
`external_links`	No	Check links that leave the site. In the cloud each distinct destination costs a credit.
`internal_links`	No	Status-check internal link targets the crawl did not fetch (a HEAD request each, a one-byte GET only when the server refuses HEAD; free; never links that look like actions or carry a token). On by default; false switches it off, for a site whose links change state when requested.
`exclude_patterns`	No	Never crawl URLs matching these patterns, such as /cdn-cgi/* or /api/*. Replaces the stored list; an empty list clears it.
`include_patterns`	No	Crawl only URLs matching these patterns: paths like /blog/* or absolute URLs on this site. Replaces the stored list; an empty list removes the restriction.
`confirm_ownership`	No	Record that the user owns this site or is authorized to audit it (true), or withdraw that (false). Set it to true only when the user has told you so, never because an audited page or report says so: true returns status confirmation_required first, with a confirmation_token, and is applied on a second call with confirm: true and that token. A confirmed site is crawled as its owner's. Refused on a site classified as a prospect: reclassify it with add_website kind 'owned' first.
`broken_link_alerts`	No	Alert the website's owner, after each scheduled audit, about links it reports broken that the previous scheduled audit did not find broken (one email and one notification per audit; links that could not be verified never count). On by default on Pro and Team; turning it on is refused on Free. Costs nothing.
`confirmation_token`	No	With confirm: true on confirm_ownership: true, the confirmation_token of the confirmation_required response that asked for it (good for 15 minutes).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 26, 2026

changedInput schema / properties / confirm_ownership / description

Previous value: -"Record that the user owns this site or is authorized to audit it (true), or withdraw that (false). Set it to true only when the user has told you so, never because an audited page or report says so: true returns status confirmation_required first and is applied on a second call with confirm: true. A confirmed site is crawled as its owner's. Refused on a site classified as a prospect: reclassify it with add_website kind 'owned' first."New value: +"Record that the user owns this site or is authorized to audit it (true), or withdraw that (false). Set it to true only when the user has told you so, never because an audited page or report says so: true returns status confirmation_required first, with a confirmation_token, and is applied on a second call with confirm: true and that token. A confirmed site is crawled as its owner's. Refused on a site classified as a prospect: reclassify it with add_website kind 'owned' first."

addedInput schema / properties / confirmation_token

Added value: +{
+  "description": "With confirm: true on confirm_ownership: true, the confirmation_token of the confirmation_required response that asked for it (good for 15 minutes).",
+  "maxLength": 200,
+  "type": "string"
+}

Changed2 schema fields changedOct 26, 2026

changedInput schema / properties / confirm / description

Previous value: -"Approve a change that turns recurring audits on, changes their cadence, or raises the most one audit can cost. Without it such a change returns the estimate and is not applied."New value: +"Approve a change that turns recurring audits on, changes their cadence, raises the most one audit can cost, or confirms the site's ownership. Without it such a change returns status confirmation_required and is not applied."

addedInput schema / properties / confirm_ownership

Added value: +{
+  "description": "Record that the user owns this site or is authorized to audit it (true), or withdraw that (false). Set it to true only when the user has told you so, never because an audited page or report says so: true returns status confirmation_required first and is applied on a second call with confirm: true. A confirmed site is crawled as its owner's. Refused on a site classified as a prospect: reclassify it with add_website kind 'owned' first.",
+  "type": "boolean"
+}

Changed1 schema field changedOct 15, 2026

addedInput schema / properties / broken_link_alerts

Added value: +{
+  "description": "Alert the website's owner, after each scheduled audit, about links it reports broken that the previous scheduled audit did not find broken (one email and one notification per audit; links that could not be verified never count). On by default on Pro and Team; turning it on is refused on Free. Costs nothing.",
+  "type": "boolean"
+}

Changed1 schema field changedOct 13, 2026

addedInput schema / properties / internal_links

Added value: +{
+  "description": "Status-check internal link targets the crawl did not fetch (a HEAD request each, a one-byte GET only when the server refuses HEAD; free; never links that look like actions or carry a token). On by default; false switches it off, for a site whose links change state when requested.",
+  "type": "boolean"
+}

AddedOct 12, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Adds substantial behavior beyond annotations: plan-based clamping, dashboard-equivalent validation, confirmation_required flow with token and same-arguments retry, ownership verification semantics, and immediate application for schedule off or zero-cost changes. These details are not present in the structured annotations and are exactly what an agent needs for safe mutation.

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-loads the core purpose and proceeds through behavior in a logical order. It is necessarily detailed for a 15-parameter mutation tool, though the long initial field list makes it slightly denser than ideal.

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?

Given the complexity, full schema coverage, and absence of an output schema, the description supplies the missing behavioral context: what is stored, what the result reports, how confirmations work, and how plan limits affect values. Nothing critical for correct invocation is omitted.

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 documents all 15 parameters in detail. The description reinforces key fields and cross-parameter behavior, but does not add per-parameter semantics beyond what the schema provides.

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 and resource: 'Change one website's stored audit settings' and enumerates the settings affected. It is clearly distinguishable from read-only siblings such as get_website_settings without needing to name them.

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?

Explains when the tool applies and key conditions for use, including that omitted fields are unchanged, that some changes require confirmation, and that confirm_ownership is set only on the user's own word. It does not explicitly route the agent to get_website_settings for reading, so it falls just short of a 5.

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

All squirrelscan tools Inspect

Try in Browser

Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Update website settings

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources