Skip to main content
Glama
brunoboto96

SceneScout

by brunoboto96
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

scout_session

Manage live browser sessions: list them, set the default for sequential calls, or adjust their action speed mid-run.

Instructions

List live sessions, or set which one is the DEFAULT (used by any tool call that omits session). Prefer passing session directly on each tool call for multi-role work — that's what lets concurrent dispatch happen; scout_session is for sequential convenience (skip repeating session on every call) and for checking what's live. Both browsers stay live and authenticated regardless of which is default — re-snapshot a session after a break to see what changed while it was away.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoSession to make the default; omit to list sessions
paceMsNoChange how fast this session acts, mid-run: a floor between actions in milliseconds, for when a person is watching and needs to keep up. 0 restores full speed. With `name`, applies to that session; without, to every live session — which is what 'slow everything down so I can follow' means.
sessionNoAlias for `name`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.4.0
    • addedInput schema / properties / paceMs
      Added value: +{
+  "description": "Change how fast this session acts, mid-run: a floor between actions in milliseconds, for when a person is watching and needs to keep up. 0 restores full speed. With `name`, applies to that session; without, to every live session — which is what 'slow everything down so I can follow' means.",
+  "maximum": 60000,
+  "minimum": 0,
+  "type": "integer"
+}
  2. Addedv1.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations supplied, the description carries full behavioral burden and meets it: it discloses default-session persistence, that switching default does not deauthenticate other sessions ('Both browsers stay live and authenticated'), and the effect of paceMs on live sessions. It also hints at re-snapshotting after a break, adding operational behavior beyond 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences, front-loaded with the core action, then usage guidance, then behavioral caveats. Every sentence earns its place and no tautology or padding.

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 3-optional-parameter tool with no output schema, this is nearly complete: purpose, default behavior, persistence, and speed control are covered. It does not describe the shape of the listing result or edge cases like unknown session names, but the stated behavior is enough for an agent to decide confidently.

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?

Schema coverage is 100% so the schema already documents each parameter. The description still adds value by explaining that the default is what is used when a tool call omits session, and by contrasting direct session passing with default-based convenience. Minor: it could restate paceMs semantics, but schema already covers 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?

Description opens with a precise dual function: 'List live sessions, or set which one is the DEFAULT' and explains what DEFAULT means. This distinguishes scout_session from sibling action tools like scout_snapshot or scout_navigate while making its resource ('sessions') explicit.

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 explicit decision guidance: prefer passing session on each call for multi-role/concurrent work, and use scout_session for sequential convenience or checking what's live. It names the context that should steer an agent away from this tool, which is exactly what a usage guideline should do.

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