SceneScout

Overview Schema Source Related Servers Discussions Admin

Build a guided plan

scout_guided_plan

Read-only

Builds a plain-language test plan from guided choices—care level, area actions, instructions, ordered calls, and limits—or reads an existing plan by ID.

Instructions

Turn a person's guided choices into a plan in plain words: the write mode its care level is, what each area does and holds back, what to tell the person, the calls to make in order, and its time and page limits. Pass choices to build a new plan, or planId to read one already built (a panel builds it and hands you only the id). A plan whose care level writes on a site that is not on this computer, or that creates test data anywhere, is built unaccepted: scout_guided_confirm asks the person, and until they accept, scout_attach above observe is refused. Once any plan is built, every scout_attach above observe must name an accepted plan's planId. A care level above the SceneScout config's maxMode is refused. Touches no browser.

Input Schema

Name	Required	Description	Default
`planId`	No	A plan already built, to read it back. Exactly one of choices or planId
`choices`	No	The person's choices. Exactly one of choices or planId

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.

Changed3 schema fields changedv3.31.0Oct 26, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- changedInput schema / properties / choices / additionalProperties
```
Previous value: -trueNew value: +{}
```
- addedOutput schema / properties / calls / items / properties / args / propertyNames
```
Added value: +{
+  "type": "string"
+}
```

Changed2 schema fields changedv3.28.0Oct 18, 2026

changedOutput schema / properties / calls / items / properties / tool / enum

Previous value: -[
-  "scout_login",
-  "scout_attach",
-  "scout_tickets",
-  "scout_session"
-]New value: +[
+  "scout_login",
+  "scout_attach",
+  "scout_tickets",
+  "scout_session",
+  "scout_verify"
+]

addedOutput schema / properties / recheck

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "foundIn": {
+      "enum": [
+        "look-only",
+        "may-submit-forms",
+        "may-create-test-data"
+      ],
+      "type": "string"
+    },
+    "ids": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "leftOut": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "care": {
+            "enum": [
+              "look-only",
+              "may-submit-forms",
+              "may-create-test-data"
+            ],
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "why": {
+            "enum": [
+              "looser-care",
+              "other-site"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "title",
+          "why",
+          "care"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "ids",
+    "foundIn",
+    "leftOut"
+  ],
+  "type": "object"
+}

Addedv3.25.0Oct 17, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond readOnlyHint=true, it discloses the acceptance state machine a plan may land in, why it happens (writing care level on a remote site, or creating test data anywhere), and the concrete consequence on scout_attach. It also confirms the tool touches no browser, which is the key behavioral fact for an agent deciding whether to call it.

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?

The build/read split is front-loaded and every sentence carries governance information that an agent needs. It is dense, with long compound sentences and several policy clauses stacked together, but nothing is filler.

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?

The annotations cover the safety profile, the schema covers all parameters, and an output schema exists, so the remaining burden on the description is behavioral and procedural. It covers that fully: build vs read mode, acceptance gating, the confirm handoff, and the maxMode ceiling.

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%, and enum-level detail (care, areas, signIn, thoroughness) already lives in the schema descriptions, so the schema does the heavy lifting. The description restates the exactly-one-of choices/planId rule, which the schema also says, and adds little new parameter-level semantics. Baseline 3 is appropriate.

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?

The description opens with a specific verb and resource: turns guided choices into a plan, and can also read back an existing plan by id. Both entry modes (choices vs planId) are stated explicitly. It does not differentiate itself from similar siblings such as scout_playbook, scout_run_plan, or scout_recheck_plan, so it stops short of a 5.

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?

It states exactly when to use each mode ('Pass choices to build a new plan, or planId to read one already built'), and notes the panel scenario where only an id is handed over. It also spells out downstream rules: unaccepted plans block scout_attach above observe, scout_guided_confirm asks the person, and a care level above the config's maxMode is refused.

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