Skip to main content
Glama
brunoboto96

SceneScout

by brunoboto96
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

The person's saved checks

scout_saved_checks

List, save, run, or delete named guided checks to reuse UI test plan choices without storing passwords, codes, tokens, or cookies; run builds a new confirmable plan.

Instructions

List, save, run or delete the person's saved guided checks. A saved check keeps the choices of a guided plan under a name (the address, what to check, the journey, how they sign in, the care level and how thorough), never a password, code, token or cookie, in the project's .scenescout/guided/ folder, readable by its owner only. "save" takes a name and the planId of a plan built from choices (a re-check is not saved). "run" builds a new plan from a saved check, unaccepted: where its care level needs the person's confirmation, scout_guided_confirm asks them again. Follow that plan as scout_guided_plan's. "delete" removes one saved check's file and nothing else. With no check open in this conversation, pass the site's address so SceneScout finds its folder. Touches no browser.

Input Schema

NameRequiredDescriptionDefault
nameNoThe saved check's name: letters, digits, spaces and dashes
actionYes"list", "save" (name and planId), "run" (name) or "delete" (name)
planIdNoWith "save": the plan whose choices to keep
addressNoThe site, when no check has run in this conversation: its saved checks are in the folder SceneScout keeps for it

Output Schema

NameRequiredDescriptionDefault
planNo
savedYes
folderYes
refusedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv3.31.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedOutput schema / properties / plan / properties / calls / items / properties / args / propertyNames
      Added value: +{
+  "type": "string"
+}
    • removedOutput schema / properties / plan / properties / choices / $ref
      Removed value: -"#/properties/saved/items/properties/choices"
    • addedOutput schema / properties / plan / properties / choices / additionalProperties
      Added value: +false
    • addedOutput schema / properties / plan / properties / choices / properties
      Added value: +{
+  "address": {
+    "type": "string"
+  },
+  "areas": {
+    "items": {
+      "enum": [
+        "sign-in",
+        "forms",
+        "broken-pages",
+        "phone",
+        "journey",
+        "tickets"
+      ],
+      "type": "string"
+    },
+    "type": "array"
+  },
+  "care": {
+    "enum": [
+      "look-only",
+      "may-submit-forms",
+      "may-create-test-data"
+    ],
+    "type": "string"
+  },
+  "journey": {
+    "type": "string"
+  },
+  "signIn": {
+    "enum": [
+      "none",
+      "sso",
+      "password",
+      "one-time-code"
+    ],
+    "type": "string"
+  },
+  "thoroughness": {
+    "enum": [
+      "quick",
+      "normal",
+      "thorough"
+    ],
+    "type": "string"
+  },
+  "tickets": {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+}
    • addedOutput schema / properties / plan / properties / choices / required
      Added value: +[
+  "address",
+  "areas",
+  "signIn",
+  "care",
+  "thoroughness"
+]
    • addedOutput schema / properties / plan / properties / choices / type
      Added value: +"object"
  2. Addedv3.28.0

TDQS

A4.4/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: on-disk location (.scenescout/guided/), owner-only readability, an explicit guarantee that no password/code/token/cookie is stored, that delete touches one file and nothing else, that run produces an unaccepted plan, and that the tool "touches no browser." This makes the destructiveHint=false annotation coherent. A minor gap remains: nothing says what happens when "save" reuses an existing name, which matters given idempotentHint=false.

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 action set and the definition, then action-by-action behavior — no filler sentences. The parenthetical definition of a saved check is long, and the planning-flow sentences (run/confirm) are dense, but each carries distinct information an agent needs.

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 present and annotations covering the safety profile, the description supplies exactly what structured fields can't: storage/privacy semantics, per-action preconditions, the address fallback for folder resolution, and the handoff to scout_guided_confirm/scout_guided_plan. 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 every parameter is already documented in the schema, including the action enum and the address fallback. The description adds the cross-parameter coupling (name+planId only for save, address only when no check is open), but repeats rather than extends most per-parameter detail. Baseline 3 applies when the schema carries the load.

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 four specific verbs (list, save, run, delete) over a named resource (the person's saved guided checks) and immediately defines what a saved check is — the choices of a guided plan under a name. It also distinguishes this from the re-check path ("a re-check is not saved") and from scout_guided_plan, so an agent can route without opening the schema.

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?

Gives per-action conditions ("save" needs name+planId, "run"/"delete" take the name), names the alternative tools for the downstream flow (scout_guided_confirm asks for confirmation, then follow as scout_guided_plan), and states the prerequisite for resolving the folder via address when no check is open in the conversation. Explicit when-to-use and cross-tool routing.

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

Deploy Server

Other Tools