Skip to main content
Glama
Sign In

CrunchJunkie

by io.crunchjunkie.app
OverviewDiscussionsAdmin

update_scan_settings

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

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "update_scan_settings"
  }
}

Input Schema

NameRequiredDescriptionDefault
marketNoMarket/country, ISO 3166-1 alpha-2 (e.g. "de", "us"). null clears it (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 the plan's ceiling.
scheduleMarketNoOne market of the project gets its own scan schedule, given 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. Changed3 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / runsPerPrompt / maximum
      Added value: +9007199254740991
  2. Changed3 schema fields changed
    • changedInput schema / properties / market / description
      Previous value: -"Market/country, ISO 3166-1 alpha-2 (e.g. \"de\", \"us\"). Pass null to clear (worldwide)."New value: +"Market/country, ISO 3166-1 alpha-2 (e.g. \"de\", \"us\"). null clears it (worldwide)."
    • changedInput schema / properties / runsPerPrompt / description
      Previous value: -"Passes per prompt per scan (sample size). Clamped to your plan's ceiling."New value: +"Passes per prompt per scan (sample size). Clamped to the plan's ceiling."
    • changedInput schema / properties / scheduleMarket / description
      Previous value: -"Give 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."New value: +"One market of the project gets its own scan schedule, given 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."
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the annotations: it discloses cascading writes (scheduleDay/scheduleHour also write scheduleTz), idempotent no-ops returning changed:false, metric rebasing with an internal timeline note on market/language/engine change, and the Peec-import exception. Nothing here contradicts destructiveHint=false, since a settings rebase is disclosed rather than contradicted.

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-loaded with the scope, then the exceptions and side effects in descending order of importance. Six dense sentences is reasonable for a 16-parameter tool, though a couple of the parenthetical clauses ('including day, hour and timezone') could be trimmed without loss.

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 mutation with no output schema and only safety annotations, the description carries its weight: it covers the confirm/preview cycle, the changed:false return signal, partial-update semantics, and every non-obvious side effect. An agent has what it needs to call this correctly and safely.

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 coverage is 100%, so the baseline is 3, but the description adds real cross-parameter semantics the schema cannot express: partial updates ('only the fields passed are changed'), the one exception where a field triggers a sibling field, and the interaction between settings that rebase metrics. It stops short of explaining previewToken lifetime details, which the schema already covers.

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?

A precise verb ('Change') plus a precisely scoped resource ('a client's AI-visibility scan settings'), followed by an enumeration of the exact settings covered (language, market, engines, passes, cadence, GEO-audit frequency). That enumeration separates it from the adjacent update_project_settings and run_scan siblings without naming 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?

It spells out the invocation flow (preview when confirm is omitted, confirm plus previewToken to apply), the prerequisite ('Requires MCP write actions'), and the edge case where the tool is pointless for Peec AI-imported projects. It does not explicitly name which sibling to use for non-scan settings (update_project_settings), so the boundary is inferred rather than stated.

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

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