SceneScout

Overview Schema Source Related Servers Discussions Admin

Plan a re-check after a fix

scout_recheck_plan

Read-only

Build a guided plan to re-check previously open UI problems, showing which are resolved, still present, or changed within the same care level.

Instructions

Build a guided plan that checks again the problems earlier checks left open, and says which are gone, still there or changed. It runs in the care level the problems were found in, never a looser one: problems found in a looser care level are left for a re-check of their own, and problems on another site for a re-check of that site. It is a new plan: where its care level needs the person's confirmation, scout_guided_confirm asks them again, whatever an earlier check was given. Follow it as you would scout_guided_plan's: attach with its planId, then scout_verify. By default every open problem but those the person marked not a bug, worst route first, at most 25; pass ids for exactly those. Touches no browser.

Input Schema

Name	Required	Description
`ids`	No	Re-check exactly these finding ids. Default: every open one but those marked not a bug
`signIn`	No	How the person signs in to the site, as in the check that found them (default none). Never a password
`address`	No	The site, when no check has run in this conversation: its problems are read from the folder SceneScout keeps for it, and only those on it are re-checked

Output Schema

Name	Required	Description	Default
`mode`	Yes
`areas`	Yes
`calls`	Yes
`level`	Yes
`budget`	Yes
`planId`	Yes
`choices`	Yes
`confirm`	Yes
`recheck`	No
`objective`	Yes
`tellPerson`	Yes
`signInHealth`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv3.31.0Oct 26, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedOutput schema / properties / calls / items / properties / args / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
Addedv3.28.0Oct 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds behavior beyond the annotations: each call yields a NEW plan so prior confirmations do not carry over and scout_guided_confirm must ask again, and the tool touches no browser (consistent with readOnlyHint). That non-idempotent, no-side-effect-on-site profile is exactly what annotations alone could not convey.

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?

Purpose is front-loaded in the first sentence and every clause carries information (scope limits, confirmation semantics, follow-up flow, defaults). It is dense and runs long as a single paragraph, which slightly hurts scannability.

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?

With an output schema, full param coverage and annotations already present, the description supplies the remaining decision-critical context: care-level scoping, cross-site exclusion, confirmation reset, and sequencing with scout_attach/scout_verify. Nothing needed to invoke it correctly is missing.

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 coverage is 100%, so the schema already documents ids, signIn and address, and the description's default rule largely restates the ids default. It does add one thing the schema lacks: ordering ('worst route first', at most 25) and the site-scoping effect of address, but that is marginal against a fully documented schema.

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 artifact: build a guided re-check plan over problems earlier checks left open, classifying them as gone, still there or changed. This is clearly separable from scout_guided_plan (fresh check) and from per-site or looser-care-level re-checks it explicitly excludes.

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?

Explicitly scopes the call to the care level where problems were found and says what is NOT handled here ('problems found in a looser care level are left for a re-check of their own, and problems on another site for a re-check of that site'). It also prescribes the follow-up flow (attach with planId, then scout_verify) and names scout_guided_confirm as the confirmation path.

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