Skip to main content
Glama
brunoboto96

SceneScout

by brunoboto96
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

scout_attach

Launch a browser and attach to a running web app to begin exploratory UI testing. Choose a write mode—observe, read-only, safe-write, or destructive—to match real data versus disposable environments.

Instructions

Launch a browser and attach to a running web app. First attach in this conversation and you have read neither the SceneScout skill nor scout_playbook? Call scout_playbook before this. Write policy is enforced at the NETWORK layer: mode='observe' blocks EVERY request that is not a GET (login and token refresh excepted) — choose it for a target that holds real data, where even an ordinary form submission would create a record; mode='read-only' (default) blocks destructive-labeled elements AND all PUT/PATCH/DELETE + destructive POSTs, but lets ordinary form POSTs through; mode='safe-write' allows creating data and permits updates/deletes ONLY on resources this session created (use when the user wants create/edit flows tested); mode='destructive' allows everything — ONLY when the user explicitly confirmed a disposable/seeded environment. Pass a Playwright storage-state JSON to explore as an authenticated role. Pass session to keep MULTIPLE roles alive at once (one browser each, genuinely concurrent) for collaboration testing — target each directly with every tool's session param, or use scout_session to set which one is the default; coverage and findings merge into one project memory.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesBase URL of the running app, e.g. http://localhost:3000
modeNoWrite policy (see tool description). Never choose 'destructive' yourself — user opt-in only.read-only
headedNoShow the browser window
browserNoBrowser to drive. Default: the SCENESCOUT_BROWSER environment variable, else chromium. firefox and webkit must be downloaded first (scenescout install --browser-only --browsers firefox). Use them for a cross-browser pass; stay on chromium otherwise.
sessionNoSession name for multi-role runs (e.g. 'admin', 'qa'). Creates/replaces that session's browser and makes it the default. Default: 'default'.
projectPathYesAbsolute path to the project (memory + report live in .scenescout/ here)
viewportWidthNoViewport width (default 1280); use e.g. 390 for a mobile pass
viewportHeightNoViewport height (default 900)
storageStatePathNoOptional Playwright storage-state JSON path for authenticated exploration

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • addedInput schema / properties / browser
      Added value: +{
+  "description": "Browser to drive. Default: the SCENESCOUT_BROWSER environment variable, else chromium. firefox and webkit must be downloaded first (scenescout install --browser-only --browsers firefox). Use them for a cross-browser pass; stay on chromium otherwise.",
+  "enum": [
+    "chromium",
+    "firefox",
+    "webkit"
+  ],
+  "type": "string"
+}
  2. Addedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden, and it does so thoroughly. It discloses network-layer write enforcement for each mode, clarifies what destructive mode permits, and explains multi-session concurrency and project-memory merging. This goes well beyond a simple 'launch browser' statement.

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 description is long, but it is dense and front-loaded with the core action, then the prerequisite, then mode semantics, then session/auth guidance. Each section earns its place given the tool's complexity and nine parameters. It loses a point for being a somewhat run-on wall of text rather than a more structured breakdown, but it is not padded.

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?

Given no annotations, no output schema, and a nine-parameter tool, the description is nearly complete: it covers prerequisites, safety modes, authentication, and multi-session behavior. The main gap is that it never hints at what the agent should expect after a successful attach (e.g., a connection status or a browser session handle), which would be more important without an output schema. Still, everything needed to invoke the tool correctly is present.

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?

The schema already covers 100% of parameters, establishing a baseline of 3, but the description adds substantial meaning for mode, session, browser, and storageStatePath. It explains the real-world implications of each mode and how session enables multi-role collaboration, which the enum/type definitions alone do not convey. The description doesn't need to restate url/projectPath since the schema already documents them.

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?

The description opens with a specific verb and resource: 'Launch a browser and attach to a running web app.' This clearly identifies the tool as the browser-attachment entry point and distinguishes it from the navigation, clicking, and scanning sibling tools. It also frames the tool's role in the conversation with the 'First attach in this conversation' prerequisite.

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?

The description gives explicit preconditions: call scout_playbook first if the skill/playbook hasn't been read. It also provides mode-selection guidance tied to real scenarios, such as choosing observe for real data and safe-write for create/edit flow testing, and states that destructive mode requires user confirmation. This is strong when-to-use and when-not-to-use guidance.

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