Skip to main content
Glama
brunoboto96

SceneScout

by brunoboto96
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

scout_note

Read or add durable, human-readable learnings about a tested app between sessions, so every test run builds on past understanding rather than starting from scratch.

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

TableJSON 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.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"
+]
  2. Addedv1.1.0

TDQS

A4.6/5.0
Behavior4/5

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

With zero annotations, the description carries the full burden and discloses the cumulative/persistent nature ('every run starts smarter than the last'), the file location, and the side effects of adds: 'Notes are dated, attributed to the acting role, and deduplicated.' It stops short of exhaustive because edge cases like first-run behavior when ASSUMPTIONS.md does not yet exist, and the exact shape of the read response, are left implicit.

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?

Every sentence earns its place and the purpose is front-loaded, but the whole description is one dense paragraph with a ~70-word parenthetical section list and a dangling clause about engine read-back at the end. The length is proportionate to the tool's conceptual richness (7 sections, 2 actions, content policy), but the lack of structural breaks makes it harder for an agent to scan.

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?

Given no annotations and no output schema, the description alone must cover purpose, storage location, usage timing, section semantics, content policy, and behavioral traits — and it covers all of these with concrete examples. Nothing an agent needs to invoke read/add correctly is missing; the only minor gaps (exact read return shape, first-run file creation) are self-evident for this kind of tool.

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 baseline is 3; the description adds real value by giving a concrete example for every section enum — e.g., roles: 'qa-role = reviewer: approves orders, cannot administer' and constraints: 'an order can only ship once approved.' It also reinforces note-format guidance and session concurrency semantics, meaningfully elevating what the schema states.

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 opening sentence states the resource and function precisely: 'Cumulative WRITTEN knowledge about the tested app — .scenescout/ASSUMPTIONS.md.' It further disambiguates from coverage tracking with 'memory.json stores coverage; this stores UNDERSTANDING,' and the twin actions read/add are made explicit. An agent can distinguish this from scout_coverage or scout_finding 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 direct operational directives: 'READ it at the start of every session' and 'ADD durable learnings as you go,' plus an explicit when-not rule: 'Do NOT record session-specific facts (ids, counts) — only durable knowledge.' It also names the storage-state trigger ('reads back to you the next time a storage state has expired') and explains the alternative store for coverage, so an agent knows exactly when this tool is the right one.

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