Skip to main content
Glama
brunoboto96

SceneScout

by brunoboto96
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

scout_lane_brief

Split an app's crawled routes across parallel audit lanes after the first crawl, assigning each lane a session name, objective, and non-overlapping routes so every area is covered once.

Instructions

For a run split across parallel agents (lanes). Divides the app's known routes between N lanes and returns each lane's session name, the objective to attach it with, and the routes it owns — whole modules per lane, balanced by route count, so no two lanes audit the same area and none is left unopened. Call it after the first crawl, when route knowledge is complete. Touches no browser; pass the briefs to your lane agents, then use scout_lane_report for what they hand back.

Input Schema

NameRequiredDescriptionDefault
goalNoWhat the whole run is for; each lane's objective is written against it
lanesYesHow many lanes to split across (1–8)
routesNoRoutes to split. Omit to split every route this project knows about.
fromRunNoStart from an earlier run's record: a ci.json, or a project directory (relative to this project). With fromRunMode continue, the lanes take the routes it never worked on first, then the ones it left work on with what to do first, then the rest; with replay, one lane per session it had, following its routes and steps in order. Default SCENESCOUT_FROM_RUN, else none (the stable split).
sessionNoTarget this session directly instead of the active one — pass it explicitly when dispatching to MULTIPLE sessions in one turn (e.g. two scout_click calls with different `session`), which then run CONCURRENTLY rather than queueing. Omit for single-session sequential use.
runMinutesNoHow long the lanes will run, in minutes (default 60). When they attach by a saved role, the brief is refused if that login will not last this long plus the margin.
fromRunModeNoWith fromRun: continue (default) or replay. Default SCENESCOUT_FROM_RUN_MODE, else continue.
expiryMarginMinutesNoHow long past the run a saved role's login must still last, in minutes (default 10).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.31.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed2 schema fields changedv3.25.0
    • addedInput schema / properties / fromRun
      Added value: +{
+  "description": "Start from an earlier run's record: a ci.json, or a project directory (relative to this project). With fromRunMode continue, the lanes take the routes it never worked on first, then the ones it left work on with what to do first, then the rest; with replay, one lane per session it had, following its routes and steps in order. Default SCENESCOUT_FROM_RUN, else none (the stable split).",
+  "maxLength": 1024,
+  "type": "string"
+}
    • addedInput schema / properties / fromRunMode
      Added value: +{
+  "description": "With fromRun: continue (default) or replay. Default SCENESCOUT_FROM_RUN_MODE, else continue.",
+  "enum": [
+    "continue",
+    "replay"
+  ],
+  "type": "string"
+}
  3. Changed2 schema fields changedv3.14.1
    • addedInput schema / properties / expiryMarginMinutes
      Added value: +{
+  "description": "How long past the run a saved role's login must still last, in minutes (default 10).",
+  "maximum": 240,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / runMinutes
      Added value: +{
+  "description": "How long the lanes will run, in minutes (default 60). When they attach by a saved role, the brief is refused if that login will not last this long plus the margin.",
+  "maximum": 1440,
+  "minimum": 1,
+  "type": "integer"
+}
  4. Addedv3.4.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose the important traits: it touches no browser, the split is whole-modules balanced by route count, and the split guarantees no overlapping lanes and no unopened routes. It does not cover failure modes such as the saved-role login-expiry refusal, which only appears in the schema.

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 core action and the lane-isolation guarantee are front-loaded, and the sequencing guidance follows without filler. The opening fragment ("For a run split across parallel agents (lanes).") is slightly abrupt, but no sentence is wasted.

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 coordination tool with 8 parameters and no output schema, the description usefully describes the return payload (session name, objective, owned routes) and the no-browser contract. Minor gaps around refusal/error behavior are acceptable since the schema documents the triggering parameters.

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 including fromRun, fromRunMode, runMinutes, and expiryMarginMinutes is already documented in structured data. The description only reinforces the meaning of `lanes` (N lanes) and the default route set. This is the expected baseline when the schema does the heavy lifting.

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 concrete verb and resource: divides the app's known routes between N lanes and returns each lane's session name, objective, and owned routes. It also explicitly separates itself from scout_lane_report, which handles what the lanes hand back, so an agent can pick between them without opening either 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?

"Call it after the first crawl, when route knowledge is complete" gives the precondition, and the closing sentence routes the agent to scout_lane_report for the reverse direction. It also tells the agent what to do with the output (pass the briefs to lane agents) rather than call this tool itself for browsing.

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