Skip to main content
Glama

Re-run a saved test, "Scan again"

rerun_target_scan

Re-run a saved test, "Scan again" (permission: edit)

Re-runs the saved target, from the target's own country. journeyId selects which journey to replay (without url only with a journey scanType, otherwise 400 field_not_applicable); omitted, it defaults to the target's journey with the lowest run_order (previously documented as "oldest journey" — the same journey for every existing customer, now deterministic). A journeyId that is over the plan quota is refused with 409 journey_sleeping, one with more steps than the plan allows with 402 step_cap_exceeded. Supply a url to scan a per-PR preview deploy as a dry-run (no baseline mutation); preview runs require the Professional plan or higher (403 plan_required otherwise). An omitted scanType is inferred from the target type, so on a website target a url without scanType runs web_compliance, a compliance audit of the preview, not a dataLayer journey replay. Only with scanType:"web_journey" is the resolved journey (journeyId, or the default above) replayed against the preview for a dataLayer diff gate. Every url request resolves that journey first, whatever the scanType, so each can return 400 journey_required (no runnable journey, issue on journeyId), journey_mismatch, journey_sleeping or step_cap_exceeded. Set journeys:"all" (which REQUIRES url and FORBIDS journeyId) to fan the preview out across EVERY active journey of the target and receive a 202 FanOutAccepted with one ScanRef per journey plus any per-journey dispatch failures (failed[].error { code, message }). maxJourneys (1..50, journeys:"all" only; otherwise a 400 field_not_applicable) caps how many journeys the fan-out runs — applied AFTER the plan quota cut, in run_order — so a CI gate on a target with many journeys can bound its scanner cost. Preview dispatches also derive their scan ids from the Idempotency-Key, so a retry after a lost slot re-derives the same scans. A replay reports each scan's current status. url is an absolute http(s) URL. idempotencyKey (sent as the Idempotency-Key header): retrying the same call with the same value replays the original answer; the same value with different arguments is 422 idempotency_conflict, and 409 idempotent_in_progress means wait error.meta.retryAfter seconds and retry.

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": {
      "id": "<id>"
    },
    "name": "rerun_target_scan"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesSaved test id: from GET /targets or the POST /targets answer.
urlNoAbsolute http(s) URL of a preview deploy to scan as a dry run (no baseline change).
journeysNo`all` replays every active journey of the target against `url` (requires `url`, not with `journeyId`).
scanTypeNoThe scan type to run; omitted, it is inferred from the target's type.
journeyIdNoThe target's journey to replay; omitted, the first runnable journey in run order. Without `url` only with a journey scanType.
maxJourneysNoWith journeys `all`: run at most this many journeys (1-50), in run order after the quota cut.
idempotencyKeyNoOptional Idempotency-Key: reuse the same value when retrying this exact call so it is applied once.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / id / description
      Added value: +"Saved test id: from GET /targets or the POST /targets answer."
    • addedInput schema / properties / journeyId / description
      Added value: +"The target's journey to replay; omitted, the first runnable journey in run order. Without `url` only with a journey scanType."
    • addedInput schema / properties / journeys / description
      Added value: +"`all` replays every active journey of the target against `url` (requires `url`, not with `journeyId`)."
    • addedInput schema / properties / maxJourneys / description
      Added value: +"With journeys `all`: run at most this many journeys (1-50), in run order after the quota cut."
    • addedInput schema / properties / scanType / description
      Added value: +"The scan type to run; omitted, it is inferred from the target's type."
    • addedInput schema / properties / url / description
      Added value: +"Absolute http(s) URL of a preview deploy to scan as a dry run (no baseline change)."
  2. First observed

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false; the description goes well beyond them by disclosing that url runs are dry-runs with no baseline mutation, the exact error taxonomy (400 field_not_applicable/journey_required, 402 step_cap_exceeded, 403 plan_required, 409 journey_sleeping/idempotent_in_progress, 422 idempotency_conflict), and the 202 FanOutAccepted shape. It also correctly reconciles the idempotentHint=false annotation by describing idempotencyKey as an opt-in retry-replay rather than default behavior.

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

Conciseness3/5

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

The first sentence is front-loaded and clean, but the body is a single ~250-word paragraph dense with nested parentheticals and stacked error codes that would read far better as a bulleted list. Nearly every clause carries information, but the packaging makes it easy to miss a constraint such as the journeys/journeyId mutual exclusion.

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 7-parameter mutation tool with no output schema, the description covers modes, prerequisites, error semantics, and even the return shape for fan-out (202 FanOutAccepted with one ScanRef per journey plus failed[].error). The 'replay reports each scan's current status' line is thin regarding the normal synchronous response, but nothing critical for correct invocation 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?

Schema coverage is already 100%, yet the description adds real meaning: scanType is inferred from target type (so url alone on a website runs web_compliance, not a journey replay), journeyId without url is only valid on journey scan types, and maxJourneys is applied after the plan quota cut in run_order. These interaction rules between parameters are not expressible in the flat schema and materially change how the call is composed.

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: re-runs a saved target, branded as "Scan again", and states the required permission (edit). It makes the replay semantics concrete (from the target's own country, journey replay vs preview dry-run), but never explicitly names the sibling that starts a fresh scan (trigger_scan), so the agent must infer the boundary from the tool names alone.

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?

Explicit conditions are given for every mode: omit journeyId to get the lowest run_order journey, supply url for a per-PR dry-run, add scanType:"web_journey" for a dataLayer diff gate, and use journeys:"all" (requires url, forbids journeyId) for fan-out. Plan-tier prerequisites (Professional+), maxJourneys scoping for CI cost control, and per-condition error outcomes are all spelled out, so an agent can pick the right call shape without guessing.

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