Skip to main content
Glama

update_scan_settings

Change a client's AI-visibility scan settings: answer language, market/country, the engines scanned, passes per prompt, cadence (incl. day/hour/timezone), and GEO-audit frequency. Only the fields you pass are changed, with one exception: a changed scheduleDay or scheduleHour also writes scheduleTz (the one you pass, else the project's timezone, else the workspace's), so the hour keeps its meaning. Passing the values the project already has changes nothing (changed:false). Requires MCP write actions; without confirm:true it returns a preview. Market / language / engine changes rebase the metrics, so an internal timeline note is written.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
marketNoMarket/country, ISO 3166-1 alpha-2 (e.g. "de", "us"). Pass null to clear (worldwide).
modelsNoEngines to scan, by id — REPLACES the current selection.
confirmNoSet true to apply. Omit for a preview. With confirm:true, also pass the preview's previewToken.
clientIdNoClient id — alternative to projectId.
languageNoAnswer language, ISO 639-1 (e.g. "de", "en", "fr").
scheduleNoScan cadence (daily may be plan-gated).
projectIdNoAI-visibility project id.
scheduleTzNoIANA timezone for the schedule (e.g. "Europe/Berlin"). Null → UTC. Omitted: a changed day or hour keeps the project's timezone, or takes the workspace's when the project has none (as in the app).
scheduleDayNoWeekly cadence: day of week the scan runs (0 = Sunday … 6 = Saturday).
previewTokenNoWith confirm:true: the previewToken from this tool's preview (valid 15 minutes, once, for exactly the previewed arguments).
scheduleHourNoHour the scheduled scan runs (0–23, local to scheduleTz).
runsPerPromptNoPasses per prompt per scan (sample size). Clamped to your plan's ceiling.
scheduleMarketNoGive ONE market of the project its own scan schedule, as a locale ("de-DE", "en-US", "de"; list_prompts lists the markets with their schedules). With it, only schedule, scheduleDay, scheduleHour, scheduleTz and scheduleIntervalDays apply, to that market alone; its prompts then leave the project's scan. A schedule equal to the project's is stored as "with the project". Not the same as market, which sets the project's own country.
geoAuditFrequencyNoHow often the technical GEO audit re-runs.
resetMarketScheduleNoWith scheduleMarket: true puts that market back on the project's schedule.
scheduleIntervalDaysNoWith schedule "everyN": run every N days (1–90).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Goes well past the annotations (which only say readOnly=false, destructive=false, openWorld=false): it discloses the scheduleTz side-effect with its precedence chain, the no-op/changed:false path, the timeline note written on market/language/engine changes, and the 15-minute single-use previewToken contract. None of this contradicts 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.

Conciseness4/5

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

Front-loads the changeable fields and pushes the exception and preview mechanics into ordered clauses, so a reader can stop early. The heavy parentheticals around scheduleTz and the previewToken make sentences run long, costing it a point on tightness.

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 16-parameter, zero-required mutation tool with no output schema, it covers the essentials: what is mutated, what is left untouched, side effects, authorization/preview requirements, and a hint at the return (preview vs changed:false). No output schema means it must not explain return shapes, and it doesn't need to.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

Schema description coverage is already 100%, so the baseline is 3; the description earns above baseline by explaining cross-parameter behavior the schema states only locally (a changed scheduleDay/scheduleHour also writes scheduleTz, with the timezone fallback order) and by framing the whole call as a sparse patch.

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 specific verb and resource ("Change a client's AI-visibility scan settings") and enumerates the exact field families it can change, making it easy to tell apart from update_project_settings or run_scan. It never names a sibling tool explicitly, so differentiation is inferred 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.

Usage Guidelines4/5

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

Clearly frames the invocation context: partial-update semantics, the write-actions requirement, and the preview-then-confirm flow via confirm:true + previewToken. It stops short of saying when NOT to use it or which sibling to prefer for related settings changes.

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.

Resources