Skip to main content
Glama
brunoboto96

SceneScout

by brunoboto96
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

scout_note

Read and add durable app knowledge across test sessions to retain roles, UI conventions, constraints, and setup steps for smarter exploratory UI testing.

Instructions

Cumulative WRITTEN knowledge about the tested app — .scenescout/ASSUMPTIONS.md, in prose a human can read and correct. memory.json stores coverage; this stores UNDERSTANDING, so every run starts smarter than the last. READ it at the start of every session ({action:'read'}). ADD durable learnings as you go ({action:'add', section, note}): what the app is for (app-model), who each role is and what they're FOR — infer the persona from what the role can see and do, e.g. 'qa-role = reviewer: approves orders, cannot administer' (roles), UI patterns the app follows (conventions), rules discovered the hard way like 'an order can only ship once approved' (constraints), fragile areas worth re-testing every run (risks), domain terms (glossary), and how to get the app testable at all — the command that regenerates an expired login state, what has to be running (setup), which the engine reads back to you the next time a storage state has expired. Notes are dated, attributed to the acting role, and deduplicated. Do NOT record session-specific facts (ids, counts) — only durable knowledge.

Input Schema

NameRequiredDescriptionDefault
noteNoFor add: the learning, one or two sentences, written for a future reader with no context
actionYes'read' the accumulated knowledge, or 'add' one durable learning
sectionNoFor add: which knowledge section this belongs to
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.31.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed1 schema field changedv3.4.0
    • changedInput schema / properties / section / enum
      Previous value: -[
-  "app-model",
-  "roles",
-  "conventions",
-  "constraints",
-  "risks",
-  "glossary"
-]New value: +[
+  "app-model",
+  "roles",
+  "conventions",
+  "constraints",
+  "risks",
+  "glossary",
+  "setup"
+]
  3. Addedv1.1.0

TDQS

A4/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 much of it: notes are dated, attributed to the acting role, deduplicated, persisted across runs, and the setup section is read back by the engine on storage-state expiry. It omits whether notes can be edited or removed once written, and whether read returns the whole file or one section.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Purpose is front-loaded in the first two sentences, but the rest is a single dense run-on paragraph with nested em-dash asides and inline JSON examples that duplicate the schema. Every claim is relevant, yet the readability cost is real compared with a short bulleted section list.

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?

There is no output schema, so the description must carry return expectations; it conveys that read yields human-readable prose and enumerates the section taxonomy, which is enough to call it correctly. What read actually returns (whole file vs. a section) is left implicit.

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 both enums already document their values, so the baseline is 3. The description goes somewhat beyond the schema by explaining what belongs in each section in prose (persona inference for roles, examples for constraints), but the note format and session parameter behavior are largely restated from the schema.

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?

Names a specific resource (.scenescout/ASSUMPTIONS.md), its content type (cumulative written knowledge about the tested app) and explicitly contrasts it with memory.json ('memory.json stores coverage; this stores UNDERSTANDING'). It does not distinguish itself from the nearest sibling, scout_playbook, which is the one an agent could plausibly confuse it with.

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 when-to-use ('READ it at the start of every session'), when-to-add ('ADD durable learnings as you go'), and an explicit exclusion ('Do NOT record session-specific facts (ids, counts) — only durable knowledge'). Each of the seven sections is named with the condition that selects it.

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