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.

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.

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.

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.

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.

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.

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

No annotations are provided, so the description carries the full burden. It accurately discloses the core behavior and its testing intent, but it does not mention whether it waits for page load, how it handles missing history, or any operational side effects. For a simple non-destructive action this is acceptable, but not richly transparent.

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

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

One short sentence with a purposeful parenthetical. It is front-loaded, free of filler, and every word contributes to understanding the tool's action and intent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a low-complexity tool: no required parameters, no output schema, and the one optional parameter is fully explained in the schema. The description plus schema is sufficient for an agent to invoke it correctly, with only minor operational details unmentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single optional `session` parameter is fully documented in the input schema, including guidance on concurrent multi-session use. The description itself adds no parameter semantics, but with 100% schema coverage, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'go back in browser history.' It also adds a distinct purpose, 'tests back-button resilience,' which clearly separates it from navigation, crawling, and other sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use case is clear: use this tool to go back in browser history and exercise back-button behavior. It does not explicitly name alternatives or exclusions, so it falls just short of a 5, but the context is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It does a good job explaining the double-submit probe mechanism and that the result states whether duplicates fired. However, it fails to disclose general click side effects (navigation, form submission, waiting behavior, failure modes when ref is invalid) for a mutating action, leaving notable gaps.

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

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

The content is valuable but poorly structured — it is a single long run-on sentence cramming purpose, return value, and a detailed behavioral explanation together. It would benefit from breaking the probe explanation into separate sentences and front-loading the core click purpose. Every idea earns its place, but the formatting hurts readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should fully explain return values and post-click behavior. It vaguely says 'Returns the outcome plus any oracle violations triggered' but doesn't specify what the outcome looks like, whether it waits for page loads, or what happens after navigation. The clicks probe guidance is thorough, but general click behavior is under-specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 meaningful value beyond the schema by explaining WHY the clicks probe matters ('fires the same state-changing request twice means the control is not guarded against double submission') and giving concrete usage guidance. This elaboration justifies a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource: 'Click an element by its ref from the latest scout_snapshot.' It clearly distinguishes from siblings like scout_hover and scout_type by anchoring to snapshot element refs. However, it does not explicitly differentiate from scout_press, leaving slight ambiguity about boundary cases, which keeps it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance for the clicks probe: 'use it on every important submit/create button once.' It also explains the double-submit detection rationale. But it offers no when-not guidance or explicit alternatives among the 25 siblings for a basic click, so it misses the top score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full burden of exposing side effects. It directly discloses that memory persists on disk after closing, and that all=true only affects live sessions. This goes well beyond the schema's parameter descriptions and helps the agent predict the tool's impact.

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

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

The description is one compact sentence that front-loads the core function and persistence caveat, then covers all invocation modes without redundancy. Every clause contributes useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two optional parameters, no output schema, and no annotations, the description is complete: it states what is closed, the persistence behavior, the default behavior, how to target one session, and how to close all sessions. Nothing material is missing for correct selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers both parameters with 100% description coverage, so the baseline is 3. The description adds useful semantic context: session targets one browser, all=true is intended for multi-role run cleanup, and omitting both closes the DEFAULT session. This extra guidance justifies a slightly higher score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Close a session's browser') and clearly distinguishes this teardown action from the other scout_* tools, which are about scanning, navigating, clicking, or reporting. It also communicates the key scope variants (default session, specific session, all sessions).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage conditions: no session argument closes the DEFAULT session, session closes a named session, and all=true closes every live session at the end of a multi-role run. It does not explicitly mention when not to use this tool or name an alternative, but no sibling tool performs closing, so the guidance is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations present, the description carries the behavioral disclosure burden. It clearly indicates a read-only reporting operation via 'Show' and scopes the behavior to 'all runs' and unexercised elements. It does not mention output formatting or staleness, but for a simple coverage-reporting tool, the transparency is reasonably complete.

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

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

The description is two sentences with no wasted words. It front-loads the core output definition, then immediately gives the intended decision-making use case. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description provides enough context to invoke it correctly: it defines what coverage means and when to use it. It could add output shape or formatting details, but those are not essential for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the single `session` parameter is already well-documented in the schema, including concurrent versus sequential usage. The tool description adds no parameter-level detail, but the schema fully compensates, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Show') with a concrete resource ('exploration coverage') and defines what that means: states visited across all runs and which elements remain unexercised. This clearly distinguishes the tool from the scout_* siblings like scout_scan, scout_snapshot, or scout_navigate by focusing on aggregate coverage rather than a single action or snapshot.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use it: 'Use to decide where to explore next and when the level's budget is satisfied.' This gives clear decision context, but it does not name alternatives or state when not to use it, so it falls just short of a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden and largely succeeds: it discloses the mutation profile ('Navigation-only — safe in read-only mode'), a side effect (records into coverage memory), and the return contents. It does not cover rate limits, auth requirements, or whether the crawl runs synchronously, which would be useful but are not critical for safe invocation.

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

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

Three dense sentences with zero filler: capability and outcome are front-loaded, safety follows, then usage strategy. Every clause earns its place, and the key differentiator ('Use this FIRST') is placed at the end as actionable guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description compensates by enumerating the per-route health summary fields. Combined with full schema descriptions for both parameters and explicit usage guidance, almost everything an agent needs to invoke it correctly is present. Minor omissions: behavior when no unvisited routes exist and any timing/asynchronicity expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters. The description adds mild conceptual context (e.g., default behavior of visiting unvisited routes, purpose of recording into coverage memory), but does not substantially extend beyond the schema's own parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Engine-side route sweep... visits each path'), enumerates concrete outcomes (records states into coverage memory, returns per-route health summary with HTTP status, element count, oracle violations, dead-ends, auth-redirects). It differentiates from siblings like scout_scan and scout_navigate by being a broad one-call sweep versus interactive exploration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs 'Use this FIRST for broad coverage; explore interactively only where it flags problems or where journeys matter.' This gives both a when-to-use and a when-not-to-use, with the alternative approach (interactive exploration) implied, so an agent can sequence its actions correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden and does a good job: it declares the audit is computed-style without screenshots, samples keyboard focus with 'real Tab presses', and lists both measurable defects and craft suggestions. It does not address side effects or permissions, but as a read-only audit the implied behavior is clear.

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

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

The description is long but densely informative, with clear structure: purpose, defect types, suggestion types, summary, and usage note. It front-loads the core identity and every subsequent clause adds practical detail. A little trimming would be possible, but the length serves the complexity of the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema and no annotations, the description compensates well by enumerating what the audit detects, the structure (defects vs. suggestions vs. system summary), and how to use the results. It does not specify the exact return format, but the content coverage is sufficient for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, session, is already fully documented in the input schema with clear guidance on when to pass it explicitly. The description adds no additional parameter semantics, which is acceptable because schema coverage is 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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: a 'computed-style design audit of the current page', and explicitly distinguishes itself with 'WITHOUT screenshots'. It enumerates distinct audit categories (WCAG contrast, tiny targets, clipped text, etc.), making its purpose unmistakable compared to siblings like scout_screenshot or scout_scan.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: 'Run once per representative page' and instructs that improvement-tier findings should be filed as ux-polish findings with concrete numbers rather than just as defects. It does not explicitly name alternative tools or exclusion criteria, but the context is specific enough to guide correct invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Since no annotations are provided, the description carries the full burden. It discloses two key behaviors: deduplication across runs and automatic capture of the recent action trace as the repro. These are significant behavioral traits that go beyond what the schema conveys. It does not contradict anything (there are no annotations) and adds valuable context.

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

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

The description is two sentences, front-loaded with purpose and key behaviors in the first sentence, and a list of use cases in the second. Every sentence earns its place, and there is no redundancy or fluff. It is concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and moderate complexity (6 params, 4 required), the description covers purpose, usage, and behavioral traits. It does not mention return values or errors, but that is not required when no output schema exists. The session parameter has detailed guidance in the schema, so the description does not need to repeat it. The description is complete enough for an agent to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 83% (5 of 6 parameters have descriptions). The description does not add much about parameters beyond what the schema already provides. The evidence parameter's purpose for dedup is already in the schema. The description mentions 'concrete measurements' for ux-polish, which relates to detail, but this is marginal. Severity lacks a description but its enum values are self-explanatory. Baseline 3 is appropriate given the high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Record' and the resource 'structured finding', and enumerates the types of findings (bug, UX issue, improvement). It also distinguishes itself from the sibling action tools by positioning it as the reporting tool, and lists specific use cases like crashes, oracle violations, dead ends, and ux-polish. This is explicit and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use for anything worth reporting' and gives a comprehensive list of scenarios. It does not mention alternatives or exclusions, but the tool's purpose is clear enough that an agent would know to use it for recording findings rather than executing actions. The guidance is strong but lacks explicit when-not-to-use instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries full behavioral disclosure responsibility. It explains that results are diffed against pre-hover state, unrelated text may be labelled, items are truncated to 300 characters, and hover does not count as exercising the element. This gives a clear and honest model of the tool's behavior.

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

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

Three dense sentences with no filler: the first defines behavior and outputs, the second states a key caveat, and the third provides usage guidance. The most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema and no annotations, the description explains the result composition, truncation, and possible noise. Combined with complete parameter schema and explicit usage conditions, an agent has everything it needs to invoke and interpret the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: both ref and session already have full descriptions, including the concurrency behavior of session. The tool description adds little per-parameter detail, but that is acceptable because the schema already handles parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: hover an element by ref and report what it reveals. It enumerates concrete outputs (tooltips, new text, title attribute, aria-describedby) that clearly distinguish it from sibling tools like scout_click and scout_snapshot.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use it on badges, icons, truncated text, and error indicators before concluding an element 'does nothing', which is strong when-to-use guidance. It also notes that hovering does not count as exercising the element, implying it is not a substitute for interaction, though it does not name scout_click as the explicit alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries full behavioral burden and does so well: it discloses that the tool actually performs the journey by clicking, that shortcuts invalidate the measurement, what metrics are returned, and how to interpret abandonment. The live side-effect potential is implied by the 'Create an order' example, but the 'perform it' wording makes the behavior clear.

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

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

Four dense sentences cover purpose, lifecycle, execution rule, return metrics, and usage guidance. There is no filler; the opening contrast with pass/fail e2e orients the agent, and the lifecycle example is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even without an output schema, the description enumerates the returned interaction metrics and friction signals, defines the invalidating shortcut, and states the severity of an abandoned journey. Session handling is covered by the schema's detailed session parameter, so an agent has enough to invoke and interpret the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds a concrete usage template pairing action:'start' with goal and action:'end' with completed, plus a real example goal. It doesn't add separate semantics for session/note, but those are already well documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific measurement goal — task ease rather than pass/fail — and defines a clear start/end journey lifecycle with concrete signals (backtracks, interaction cost, over-interaction). This clearly distinguishes scout_journey from execution-oriented siblings like scout_click or scout_navigate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use it: wrap a user goal with start/end and run it on each module's primary journey. It also emphasizes the correct execution method (clicking through UI, no deep-link shortcuts) and treats abandoned journeys as high-severity. However, it doesn't name alternative tools or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds useful behavior: path resolution is relative to the attached base URL, and back navigation is delegated to scout_back. However, it is silent on whether navigation waits for page load, how it affects the current session, or what errors may occur.

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

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

The description is two sentences with no wasted words. The main action is front-loaded, and the back-navigation alternative is a useful, compact addition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity tool with one required parameter and fully documented schema fields, the description covers the essential invocation knowledge: target semantics, relative-path behavior, and the scout_back alternative. It omits return/wait behavior, but this is not critical for selecting or invoking this simple navigation command.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters. The description adds value beyond the schema by clarifying that paths are relative to the attached base URL and giving a concrete example ('/orders'). The session parameter is fully described in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Navigate to a URL or a path relative to the attached base URL.' It also distinguishes this tool from the sibling scout_back by explicitly routing back-navigation there. The scope is immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states when to use the tool: for a URL or a path relative to the base URL. It also gives an explicit exclusion for the 'back' action by naming scout_back. It does not enumerate other alternatives like scout_click, but the core usage context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that notes are dated, attributed to the acting role, and deduplicated, and that the file is human-readable and correctable. It also states that it stores understanding so every run starts smarter, implying persistence across sessions. No contradictions with annotations (none exist), and the description fully explains the tool's behavior.

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

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

The description is densely informative yet well-organized. It front-loads the core purpose and file path, then explains actions with examples, lists the sections inline, and closes with a clear exclusion rule. Every sentence earns its place; there is no fluff or repetition. The use of parentheses and examples makes it scannable without losing depth.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters, 2 enums, and no output schema, the description covers all necessary aspects: what it does, when to use it, how to use each parameter, what content to store, and what to avoid. It even explains the file location and the distinction from memory.json. An agent could confidently call this tool correctly after reading the description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (all parameters have descriptions), but the description adds significant meaning beyond the schema. It explains the action enum (read/add) and how to combine with section and note, gives concrete examples of section values, and clarifies the session parameter's concurrency behavior. This enriches the agent's understanding of how to construct valid calls, far exceeding the bare schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: it stores cumulative WRITTEN knowledge about the tested app in ASSUMPTIONS.md, and supports reading and adding durable learnings. It distinguishes itself from memory.json (coverage) and from sibling tools like scout_finding by focusing on durable understanding rather than session-specific events. The verb 'read' and 'add' are explicit, and the resource (knowledge store) is named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs to READ at the start of every session and to ADD durable learnings as you go, with concrete examples of what to record (app-model, roles, conventions, constraints, risks, glossary) and what NOT to record (session-specific facts like ids and counts). This gives clear when-to-use guidance and even defines the exact action pattern. It implicitly differentiates from other scout tools by focusing on knowledge accumulation rather than immediate actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden, and it states 'Takes no input and touches no browser,' making the read-only, side-effect-free nature clear. It also warns that calling it again is unnecessary and that it duplicates the skill text.

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

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

Three tightly packed sentences: content, usage timing/alternative, and input/side-effect constraints. No filler, and the most decision-relevant information appears first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-input, no-output-schema tool, the description fully covers what the tool returns, when to invoke it, how it relates to the skill alternative, and that it has no browser side effects. Nothing an agent needs to call or follow it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema already says nothing is needed. The description adds the explicit confirmation 'Takes no input,' which aligns with the empty schema, earning the zero-parameter baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Return the SceneScout testing method' and enumerates its contents (setup order, write modes, exploration, done criteria, reporting). This clearly distinguishes it from the sibling execution tools like scout_attach and scout_report.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to call it: 'ONCE before the first scout_attach in a conversation, then follow it.' It also names an alternative and provides a rule: if a SceneScout skill is offered, load that instead and 'never read both.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full burden. It discloses the action (press a key) and a common use case, but doesn't mention whether the key press is sent to the active element, whether it waits for effects, whether it can fail (e.g., no focused element), or any side effects. For a tool that sends input, this is a notable gap.

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

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

The description is a single sentence that front-loads the action and examples, then gives a use case. It's concise and readable, though it could add a brief note on key format without bloating.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple input tool with no annotations and no output schema, the description is minimal. It doesn't explain what happens after the key press, whether a page/session must be active, or how the key should be specified (e.g., exact key names). The session parameter guidance is good, but the core behavior is under-specified for an agent to invoke reliably.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50%: the 'key' parameter has no description in the schema, and the description only gives examples (Escape, Tab, Enter) without specifying format (e.g., 'Escape' vs 'Esc' vs key codes). The 'session' parameter is well-described in the schema, so the description adds little there. The description partially compensates for the undocumented 'key' parameter but doesn't fully specify accepted values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool presses a keyboard key and gives examples (Escape, Tab, Enter) plus a use case (closing modals, testing keyboard navigation). It distinguishes from siblings like scout_click and scout_type by focusing on key presses, though it doesn't explicitly name a sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (closing modals, keyboard navigation testing) but doesn't explicitly contrast with alternatives like scout_type or scout_click. The session parameter description provides some guidance on when to pass session explicitly, but the main description lacks clear 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.

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 delivers: it states the file write to .scenescout/report.md, the bounded summary return due to token limits, and the refusal behavior for 'extensive' when the gap ledger is non-empty. This transparency is unusually strong for a tool with no structured annotation safety hints.

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

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

The description is dense but every clause earns its place: purpose, report contents, output location, return behavior, gating semantics, and override conditions. It is front-loaded with the core purpose and then layers the necessary nuance without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema or annotations, the description fully covers what the report contains, where it is written, what the tool returns, and the exact conditions under which it will or will not generate. An agent has enough context to know when to call it and what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes all three parameters with 100% coverage, so the baseline is 3. The description adds value by defining what each gate level actually requires ('minimal' needs all routes visited + audit, etc.) and by clarifying that force overrides should only occur under a user-budget cap, enriching the level and force parameters beyond their schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Generate') and resource ('final markdown report'), and enumerates the exact contents: findings, page quality scores, role capability matrix, oracle rollup, and gap ledger. This clearly distinguishes the tool from sibling action tools like scout_scan or scout_snapshot because it produces the terminal, comprehensive report artifact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit gating preconditions for each level ('minimal' needs all routes visited, 'medium' needs more audits, 'extensive' refuses while the gap ledger is non-empty), effectively saying when the tool should and should not be invoked. It also explains when force=true is appropriate: only when the user capped the budget, which is a clear when-not condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden and meets it by disclosing behavioral consequences: resolved findings move to the green Resolved section and reopen automatically as REGRESSIONS if re-found later. This adds meaningful context beyond the schema, though it does not address potential side effects like irreversibility or permissions.

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

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

The description is three concise sentences with no filler. It front-loads the core action, then explains behavior and usage conditions. Every sentence contributes useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, usage triggers, and behavioral outcomes, which is sufficient for a simple action tool with no output schema and no required parameters. It does not explicitly explain the return value, but given the tool's simplicity and the strong schema coverage, the remaining gap is minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are already well-documented. The description adds minor value by hinting where to find the id ('shown when recorded and in the report'), but it does not elaborate on parameter formats beyond the schema, hence a baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-resource pair ('Mark a finding as resolved') and clearly identifies the target (by id). It distinguishes itself from sibling tools by explaining the outcome (moving to the Resolved section and auto-reopening as REGRESSIONS), which is unique to this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use it: when the user says a bug is fixed, or when re-testing shows the evidence no longer reproduces. It does not provide when-not-to-use guidance or name alternatives, but the usage context is clear and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden. It discloses the abort-on-new-violation/failure behavior, else it returns a transcript of how far it got, and specifies that repeated violations do not abort. It also explains semantic locator resolution at execution time and upload step specifics—all beyond schema and highly valuable for an agent.

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

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

The description starts with purpose, then flows to target resolution, upload exception, and abort behavior—logical and front-loaded. Every sentence earns its place, though the density of technical details makes it slightly heavy to parse. Could benefit from bullet points, but it remains concise for the information conveyed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex multi-step tool with no annotations and no output schema, the description covers essential operational semantics: execution limits, target resolution, upload steps, and abort conditions. It lacks detail on the transcript format and domain terms like 'oracle violation', but enough is provided for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (session described well, steps not). The description compensates by explaining the steps' target syntax ('testid=…', 'text=…', 'label=…'), upload behavior, and the abort semantics. This adds meaning beyond the schema's bare enum, though not every action type is individually expanded.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Execute up to 20 actions in ONE call' and specifies the use case ('mechanical sequences (fill a form, walk a wizard)'), clearly distinguishing this from single-action siblings like scout_click and scout_type. It names the resource and action explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use this tool: for mechanical sequences to avoid round-trip cost. It does not explicitly name alternatives or state when not to use it, but the context makes it clear that individual single actions belong to the sibling tools. This is strong guidance but lacks formal exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the burden of behavioral disclosure. It conveys a read-only reconnaissance behavior by saying 'scan a project directory to discover...' but does not mention whether state is persisted, what the return shape looks like, or if any environmental prerequisites exist. This leaves some behavioral ambiguity.

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

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

The description is a single efficient sentence plus the useful sequencing directive 'Run this first.' It frontloads the action and follows with a concrete list of discovery targets, containing no filler or redundant repetition of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with no annotations and no output schema, the description provides the essential call context: what to pass, what will be discovered, and that it should be invoked first. It does not explicitly describe the return format, but the enumerated discovery targets partially compensate and make the tool callable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, projectPath, is already fully documented in the schema as 'Absolute path to the project root,' and the description adds no additional constraints, defaults, or format details. The discovered artifacts listed in the description concern tool output rather than parameter semantics, so the schema remains the primary source of parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('scan') and object ('project directory') and enumerates the concrete artifacts it uncovers: frontend workspace, framework, routes, dev command, Playwright auth storage states, and testid conventions. This makes its role as a project discovery tool unmistakable and distinguishes it from execution-oriented siblings. The directive 'Run this first' also makes its purpose immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs the agent to run this tool first, establishing clear sequencing relative to the many scout_* sibling tools. It does not name specific alternatives or conditions for choosing another tool, but the 'first' directive gives the agent enough contextual guidance for initial invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the burden, and it does well by disclosing the JPEG format, viewport scope, and the 'LAST RESORT' nature of the tool. It could be slightly more explicit about side effects or what the caller receives, but the core behavior is transparent.

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

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

The description is one dense, front-loaded sentence with no filler. It packs the main action first and the routing caveats after, though the long em-dash chain is slightly less scannable than a short two-sentence structure would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete enough for selecting and invoking the tool: it says what is captured, in what format, and when not to use it. With no output schema, it slightly underspecifies the result format or delivery mechanism, but that is a minor gap for a simple screenshot tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the sole optional `session` parameter is fully documented in the schema. The description adds no parameter-specific detail, but none is required beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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: 'Take a JPEG screenshot of the current viewport.' It also clearly distinguishes itself from siblings by naming what belongs in scout_snapshot and scout_design_audit instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

This is exemplary routing guidance. It tells the agent to use this tool only for pixel-native content that computed data cannot capture, and explicitly directs geometry issues to scout_snapshot, style/contrast/spacing issues to scout_design_audit, and broken-image checks to the BROKEN IMAGES section of scout_snapshot.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full behavioral burden, and it is unusually rich: it discloses the fallback to the largest scrollable pane on app-shell layouts, that smaller regions beside it never move, that it reports SCROLL LOCKED, and that scrolling triggers lazy-loaded content. This goes well beyond what the schema alone reveals.

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

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

The description is long and dense, but nearly every clause carries behavioral or workflow value, and it is front-loaded with the core action. Some rhetorical framing ('real apps hide their bugs below the fold') could be trimmed, and the parenthetical caveats make it a wall of text rather than a scannable definition, but it is efficient for the complexity it documents.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 optional parameters, no output schema, and no annotations, the description covers the essential missing context: result format (px and %), SCROLL LOCKED detection, fallback behavior, target-region semantics, and why scrolling matters for audits and lazy-loaded content. The schema handles the remaining parameter details, so nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds real value on top by explaining the target semantics in depth — single region, nearest scrollable ancestor, and the 'smaller region beside it' trap. It does not redundantly restate by/to/session, leaving the schema to cover those.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific behavior ('Scroll like a user'), the resource acted on (page or one target region), and the outcome (reports position in px and %, flags SCROLL LOCKED when scroll is blocked). It clearly differentiates itself from sibling tools like scout_snapshot and scout_design_audit by being the scroll-position-changing action that precedes them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit workflow guidance: use before judging a long page, then re-snapshot/re-audit deep sections, because the design audit measures at the current scroll position. It also warns against calling a nav item missing without scrolling its own container first, which is a concrete when-to-use versus when-to-target instruction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description must carry the behavioral transparency burden. It only says 'Select an option in a <select> by ref' and does not disclose whether the action triggers change events, waits for navigation, requires visibility, or what happens when the value/label is not found. These are meaningful gaps for an interaction tool.

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

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

The description is a single sentence with no filler and the core action is front-loaded. It loses a point only because the brevity edges into under-specification, particularly around the meaning of 'ref'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations, no output schema, and a minimally described ref parameter, the description is not complete enough. An agent would still need to infer where ref comes from, what 'value' matching entails, and what side effects or errors to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67%, with value and session already documented. The description adds some interpretive value by indicating that ref is a reference to the select element, but it does not explain how ref is obtained or formatted, leaving the most opaque parameter only partially clarified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Select') and a specific resource ('an option in a <select>'), refined by 'by ref'. This makes the tool's core purpose clear and distinguishable from names like scout_click, though it does not explicitly name a sibling alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: whenever an option needs to be selected in a <select> element. However, it gives no exclusions, no guidance on how it compares to sibling tools like scout_click, and no mention of when the session parameter should be used, which lives only in the schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries full behavioral burden. It discloses that both browsers remain live and authenticated regardless of default choice, and that re-snapshotting after a break reveals changes. This adds meaningful state-lifecycle context beyond the basic action.

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

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

Three sentences, front-loaded with the core action, and every sentence earns its place: the first states purpose, the second gives usage guidance, the third clarifies persistent browser state. No filler or repetition of schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given only two simple parameters, no annotations, and no output schema, the description covers purpose, default behavior, concurrency trade-offs, and persistence of browser sessions. It does not spell out return format or conflict behavior if both `name` and `session` are supplied, but these are minor for this tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 extra meaning by explaining the default selection applies to any tool call that omits `session`, and why that matters for concurrent dispatch. This goes beyond the schema's parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'List live sessions, or set which one is the DEFAULT.' It clearly distinguishes this tool from the broader scout_* family by centering on session default management and live-session listing, so an agent can tell what it does without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage direction: prefer passing `session` directly for multi-role/concurrent work, and use scout_session for sequential convenience and checking live sessions. This is exactly the when-to-use versus when-not-to-use guidance needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly discloses the diff behavior, stable refs, cheapness, and the 'since the last action' scope. It does not explicitly state whether the operation is read-only or discuss failure modes, but 'capture' implies non-mutation and the disclosed traits cover the most important behaviors.

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

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

The description is compact and front-loaded, with the primary purpose stated in the first sentence and useful behavioral details following. Each sentence adds distinct value—purpose, diff behavior, and cost/alternative—with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers what the snapshot contains, the diff behavior, the temporal scope ('since the last action'), and the important recommendation against screenshots. No output schema is present, so the listed content items serve as a sufficient description of what the agent will receive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the input schema already documents both parameters in detail, including the full-diff toggle and session targeting semantics. The description itself adds no parameter-level meaning, which is acceptable given the schema's thoroughness; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a strong verb and resource: 'Capture the current page state' and lists concrete outputs (URL, state fingerprint, interactable elements, refs, geometry issues, coverage, oracle violations). It also distinguishes itself from the screenshot sibling by stating it is cheaper and preferred, making the tool's identity clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent to prefer this over screenshots and explains that re-snapshotting the same route returns a diff, which guides when to call it again. It does not enumerate exclusions relative to other scout_* siblings, but the guidance it gives is actionable and sufficient for the main decision.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses append-with-preservation behavior, separating-space logic, replace/clear semantics, the fact that input events fire but keydown does not, and edge-case handling for empty values. This is far beyond minimal disclosure.

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

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

The description is dense but purposeful, with behavioral facts and edge cases packed into a compact block. It is somewhat long and could be broken into clearer sentences, but every sentence earns its place by adding operational detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given six parameters, no annotations, and no output schema, the description is remarkably complete. It covers core behavior, parameter-level semantics, event caveats, replace/clear logic, and boundary-value use cases. The only minor omission is the exact result format, but the description does mention what the result reports.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: it explains what appending does to existing content, when replace is appropriate, and that empty textValue clears. This enriches the raw parameter definitions with behavioral context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Type'), resource ('text input/textarea/composer'), and method ('by ref'). It also clarifies the core behavioral distinction between appending and replacing, making it easy to tell apart from sibling input tools like scout_click or scout_press.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly explains when to use replace=true vs default appending, notes that empty textValue clears the field, and gives an explicit use case ('valid values and boundary/fuzz values'). It also warns that keydown-driven menus won't react to appended text, which helps an agent decide between this tool and alternatives. It does not explicitly name alternative sibling tools, but the guidance is otherwise strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers thoroughly. It explains the interception of the file chooser, the generation of valid fixtures in memory, the fencing of filePath to the project, and the detailed result content (input name, violation flags, cleared-input warning, state-changing request detection). It also hints at side effects (state-changing requests) and provides follow-up guidance, making behavior fully transparent.

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

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

The description is dense and front-loaded with the core action, but it is a single long paragraph without section breaks. Every sentence adds value, and the structure flows from purpose to parameters to result, so it is well-organized. It could be slightly more scannable with bullet points, but the content justifies the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the absence of an output schema, and no annotations, the description is remarkably complete. It explains the return value in detail (input name, method, accept violations, cleared-input warning, state-change detection) and offers concrete next steps. It also covers edge cases like hidden inputs, multiple sessions, and fixture types. Nothing essential for an agent to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds substantial meaning beyond the schema. For `ref`, it explains the two acceptable target types and the hidden-input scenario. For `fixture`, it clarifies the inference logic and default. For `filePath`, it adds the project-fencing constraint. For `name`, it explains boundary-test use cases. This is far beyond the schema's terse descriptions, so it deserves a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear, specific verb and resource: 'Attach a file to an upload control the way a user does.' It immediately distinguishes the tool from siblings like scout_click or scout_type by describing the upload interaction and the mechanism for reaching hidden inputs. The purpose is unambiguous and not a tautology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides rich usage context: when to omit `ref`, when to use `fixture` vs `filePath`, how to target hidden inputs, and what to do after upload (click submit if no state-changing request). It does not explicitly name alternative tools for exclusion, but the guidance is clear enough to select this tool for uploads. A small gap is the lack of an explicit 'use this instead of X' statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.