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

No annotations are provided, so the description carries the full burden and does so unusually well: it discloses that write policy is enforced at the NETWORK layer, exactly what each mode blocks and permits, the auth failure behavior (attach refused, command named, user must sign in), that multiple sessions mean genuinely concurrent browsers, and that coverage/findings merge into one project memory.

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?

Purpose is front-loaded and the long paragraph is held together with dashes and semicolons, so a reader can scan to the mode they need. The opening sentence about the scout_playbook gate is contorted ('First attach in this conversation and you have read neither...'), which costs a little clarity in a description that is heavy by necessity for 17 parameters.

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 17-parameter tool with no annotations and no output schema, the description covers the decisions that matter: write policy, authentication, multi-session orchestration, and prerequisites. It stops short of describing what a successful attach returns or how long it takes, though most remaining knobs (timeouts, pace, recording) are self-documented in the schema.

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 real semantic depth beyond the schema — the four-way mode taxonomy and its consequences, the role/session interplay, and how session targeting works across every other tool. It meaningfully reduces the chance of a wrong mode or auth choice.

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?

States a specific verb and resource ('Launch a browser and attach to a running web app'), and immediately positions itself relative to siblings by gating on scout_playbook and explaining session/role handling versus scout_session. An agent can distinguish this from scout_navigate or scout_scan without opening a schema.

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?

Explicit when-to-use for every mode ('choose observe for a target that holds real data', 'safe-write when the user wants create/edit flows tested', 'destructive ONLY when the user explicitly confirmed a disposable/seeded environment'), plus a prerequisite rule (call scout_playbook first) and when to pass role vs storageStatePath vs session.

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 exist, so the description carries the full burden. It fully states the behavior (browser history navigation) and the testing intent (back-button resilience). For a simple navigation action, this is adequate disclosure; no hidden side effects are suggested.

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 entire description is one short sentence with no filler. The core behavior comes first and the testing rationale follows in a parenthetical, preserving structure and brevity.

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 zero-required-parameter navigation action with fully documented optional parameters and no output schema, the description is complete enough to invoke. It would benefit from explicit sibling routing, but that gap is minor for such a simple 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% and the parameter descriptions are rich, so the baseline is 3. The tool description itself adds no parameter-level meaning, but it does not need to because the schema already explains task, session, and objective.

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 ('Go back in browser history') and attaches a clear test purpose ('tests back-button resilience'). This makes it immediately distinguishable from siblings like scout_navigate or scout_crawl without needing their 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 parenthetical implies the tool should be used when exercising back-button behavior, but it does not explicitly state when not to use it or name alternatives. The usage context is inferable, not spelled out.

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 output format (PNG), content (element bounds plus margin), and write location (.scenescout/captures/), but does not address permissions, error cases, overwrite behavior, or what is returned.

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 output path. The ref-sourcing instruction and the design-audit exclusion each earn their place, with no wasted wording.

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-output-schema, no-annotation tool with five parameters, the description covers purpose, element selection, output location, and sibling routing well. It does not state what the tool returns (e.g., a capture key), though the schema's key parameter implies a return artifact.

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 all five parameters are already documented in the schema. The description reinforces that ref comes from the latest scout_snapshot and adds conceptual meaning to margin, but does not add syntax or constraints beyond what the schema 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?

States a specific verb and resource: save a PNG of ONE element from a real screenshot, with scope (bounds plus margin) and output location (.scenescout/captures/). It distinguishes itself from the full-page sibling scout_screenshot by emphasizing 'ONE element' and from scout_design_audit by name.

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?

Tells the agent to supply the element's ref from the latest scout_snapshot, and explicitly routes design judgment to scout_design_audit. It implies the contrast with full-page scout_screenshot via 'ONE element' but does not name that alternative directly.

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 exist, so the description must carry behavior disclosure. It explains that repeated clicks can fire the same state-changing request twice and that the result reports whether duplicates occurred, plus oracle violations. It does not warn that a click can navigate away or trigger irreversible side effects, but it does characterize the tool as state-changing and outcome-reporting.

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 first sentence states purpose, the second summarizes output, and the remaining clause explains the non-obvious clicks behavior. It is dense but every element is informative; the long clicks explanation earns its place because it conveys a testing strategy rather than restating the schema.

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, the description at least explains that the response includes an outcome and oracle violations, and it covers the key usage twist (double-click probing). It leaves the exact result shape and handling of task/session parameters to the schema, which is acceptable for a relatively simple interaction tool, though a bit more on failure modes would help.

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 all parameters, but the description adds real value: ref is tied to the latest scout_snapshot, and clicks is explained as a deliberate double-submit probe with interpretation guidance. This goes beyond the schema's generic '1 = normal; 2-3 = rapid repeated clicks'.

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 first sentence names a concrete action and resource: click an element identified by a ref from the latest scout_snapshot. It also states the return content, distinguishing it from sibling actions like hover, type, or navigate without relying on the tool name alone.

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?

Gives explicit operational guidance: use clicks=2/3 on every important submit/create button as a double-submit probe. It does not name alternatives or exclusions, but the 'latest scout_snapshot' constraint and button-specific recommendation provide adequate context for when to invoke 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, and it delivers: it discloses persistence, default/all behavior, lane-close refusal, and the destructive consequence of force. It also mentions that refusal names every such lane, so the agent knows what to expect. No contradictions.

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 default behavior. The lane sentence is long but carries necessary exception logic; no filler or repeated 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?

For a state-changing tool with no annotations and no output schema, it covers the main behaviors, including edge cases (lanes, force). It doesn't describe return values or error handling beyond the refusal, but that's a minor gap for a close operation.

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 already documents all three parameters at 100% coverage, so the baseline is 3. The description adds operational context: when to use all, what force destroys, and the default session behavior. This is meaningful added value, though the schema itself already covers force well.

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: 'Close a session's browser.' It also states the key side effect (memory persists on disk) and distinguishes default, specific, and all sessions, which separates it from sibling tools like scout_session or 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?

It gives explicit operational guidance: default session, session parameter for a specific one, and all=true for multi-role runs. It also explains when not to close—lane sessions awaiting acceptance—and directs the agent to scout_lane_report for folding. It doesn't enumerate all alternatives, but the key routing is present.

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 clearly implies a read-only analysis operation ('show', 'use to decide') and details the specific data it surfaces. However, it does not explicitly state that it is non-destructive, nor does it mention permissions, rate limits, or any side effects—gaps that matter for a tool with zero annotation coverage.

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 fluff. The first sentence front-loads the purpose with a comprehensive list of coverage dimensions, and the second sentence provides actionable guidance. Every phrase earns its place, making it easy to scan and parse.

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 simplicity (one optional param, no output schema), the description adequately explains what the tool reports and when to use it. The only gap is the lack of information about the output format (e.g., text, table, JSON), but since the tool is clearly a reporting utility, an agent can infer the response type. This is a minor omission rather than a critical one.

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 covers the single optional parameter `session` with a detailed explanation of when to pass it explicitly. Since schema description coverage is 100%, the baseline is 3. The tool description itself adds little beyond the schema's parameter documentation, only referencing 'across all runs' without elaborating on the session parameter's behavior.

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') and a clear resource ('exploration coverage'), then enumerates exactly what is covered: visited states, unexercised elements, unchosen dropdown options, and blank-submitted forms. It also states its decision-making purpose, distinguishing it from sibling tools like scout_scan or scout_screenshot.

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 'Use to decide where to explore next and when the level's budget is satisfied,' giving clear when-to-use context. However, it does not mention when NOT to use it or name alternative tools, so it stops short of the explicit exclusion and alternative guidance that would merit a 5.

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?

With no annotations, the description carries the full burden and does well: it discloses deduplication across runs, automatic capture of the recent action trace as the repro, and the distinction between a real defect and a convention-dependent 'worth a look' finding. It never covers permissions, whether findings can be edited/deleted, or how the record surfaces in reports, which keeps it short of a 5.

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?

Two sentences, front-loaded with the core action, no filler. The second sentence is a long run-on enumeration of reportable categories, which is information-dense but slightly bloated rather than wasteful.

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 7-parameter ingestion tool with no output schema, the description covers the key behavioral contracts (dedup, auto-trace capture, convention handling) plus usage triggers. It is complete enough to call confidently; only return behavior and lifecycle of the record are unaddressed.

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 86%, so the schema already documents nearly all parameters, and the baseline is 3. The description adds some conceptual framing (ux-polish needs 'concrete measurements', oracle violations must be 'confirmed') but never maps to specific fields like evidence's dedup-signature format or the session concurrency parameter, which the schema already handles.

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?

Starts with a specific verb+resource ('Record a structured finding') and immediately scopes it to bugs, UX issues, or improvements, which distinguishes it from sibling tools like scout_note or scout_report. It also names concrete artifact types (crashes, permission leaks, missing testids), so the agent knows exactly what kind of object this tool produces.

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 enumerates when to use it ('anything worth reporting: crashes, oracle violations you confirmed, dead ends, confusing UX...'), which gives strong context. It even routes a common edge case ('I could not tell') away from filing, but it never names a concrete alternative tool (e.g. scout_note) for lighter-weight capture, so it stops short of full when/when-not 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 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 and does well: it discloses that the tool 'touches no browser' and that the caller must pass the briefs to lane agents itself. It also explains the balancing guarantee (no overlap, none left unopened) and the return shape, which is needed since there is no output schema. It doesn't cover failure modes or what happens if lanes exceed available routes.

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 sentences, purpose front-loaded, zero filler. It is dense but every clause adds routing or behavioral information. Slightly long, and the return-value clause could be trimmed, but nothing is wasted.

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 6-param tool with no annotations and no output schema, the description supplies the missing pieces: what it returns, that it has no browser side effects, and the ordering constraint relative to the crawl. Remaining gaps are minor — no explicit mention of what a refused brief looks like or how to handle lane counts exceeding route counts.

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 genuine meaning beyond the schema by explaining the splitting algorithm ('whole modules per lane, balanced by route count'), which tells the agent how the `lanes` and `routes` inputs actually partition work rather than merely restating their types.

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?

States a specific verb and resource — it divides an app's known routes across N parallel lanes and returns each lane's session name, objective, and owned routes. The scope ('whole modules per lane, balanced by route count, no two lanes audit the same area') is precise enough to separate it from scout_crawl or scout_lane_report without opening any schema.

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?

Explicit timing: 'Call it after the first crawl, when route knowledge is complete.' It also routes the agent forward, naming scout_lane_report as the counterpart for what lanes hand back. It stops short of stating when not to use it (e.g. a single-agent run with no parallel split).

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 adds a helpful trait ('Touches no browser') and explains the two output behaviors, including the failure case ('reason it was refused'). However, it does not explicitly state whether it has any state-changing side effects or mention permissions/rate limits, leaving some ambiguity for a tool with no annotations.

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 information-dense and well-structured: it opens with the run context, then branches into the two modes with concrete outcomes, and closes with a safety note. Every sentence earns its place, though the density requires careful reading. It is slightly long but not wasteful.

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?

There is no output schema, so the description must explain return values, and it does: it details the paragraph content for the no-reply mode and the one-line fold or refusal reason for the reply mode. It also explains the input contract for the lane. Missing are details like pagination or error semantics, but for a tool of this complexity it is reasonably complete.

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 baseline is 3. The description adds value beyond the schema by explicitly linking the two parameters: omitting `reply` yields the instruction, while providing it triggers parsing. This conditional relationship is not obvious from the schema alone, so the description enhances parameter understanding.

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+resource pair: it returns a lane prompt paragraph when `reply` is omitted and parses a lane's reply when `reply` is provided. The opening context 'For a run split across parallel agents (lanes)' clearly frames this as a lane-specific tool, distinguishing it from sibling tools like scout_report or scout_lane_brief.

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: use it when a run is split across lanes, and it precisely states the two modes based on whether `reply` is omitted or provided. It does not name alternatives or exclusions, but the context is clear enough that an agent can decide when to invoke this tool over siblings.

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?

There are no annotations, so the description alone must disclose behavior. It only says 'Navigate' and mentions an 'attached base URL' without explaining side effects, page-load waiting, session/state changes, auth requirements, or return value. For a tool that changes the current page, this is a significant behavioral 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?

Two short sentences with no fluff. The core action is front-loaded, and the back-navigation note is a useful addition. Every word 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 tool with no annotations and no output schema, the description is too thin. It does not explain what 'attached base URL' means, what happens after navigation, or what the agent should expect in return. With 28 siblings, it also lacks guidance on when this tool is the right choice compared to other navigation or action tools.

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 the concept of an attached base URL and a '/orders' example, which slightly enriches the `target` parameter meaning. However, it adds nothing about `task`, `session`, or `objective` 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 uses a specific verb ('Navigate') and a precise resource ('a URL or a path relative to the attached base URL'), with a concrete example. It also distinguishes itself from the sibling scout_back by explicitly routing 'back' navigation to that tool. An agent can clearly tell what this tool does and how it differs from at least one close 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?

It gives a clear exclusion by stating that 'back' should go via scout_back. However, it does not mention when to prefer this over other navigation-related siblings like scout_crawl or scout_scroll. The intended use is implied (direct URL/path navigation) but not explicitly contrasted with alternatives beyond the back case.

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 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.

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.

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.

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.

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.

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.

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?

With no annotations provided, the description carries the full burden. It states the core behavior and even hints at consequences (modal dismissal, keyboard navigation), but it does not disclose details such as whether the press targets the active page, whether it dispatches keydown/keyup, or how unsupported keys are handled. This is acceptable for a simple action 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?

The description is a single front-loaded sentence with no filler. It immediately states the action, gives examples, and then explains when it is useful — every word 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 key-press tool with a well-described parameter schema, the description is largely sufficient. It covers what the tool does and typical use cases. The only gap is an explicit relationship to sibling tools like scout_type, but this is minor given the overall clarity.

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 75%, and the tool description adds essential meaning to the undocumented `key` parameter by providing valid examples. The other parameters already have detailed schema descriptions, so the description's contribution is focused and useful for the one parameter that needs it.

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 action: 'Press a keyboard key' with concrete examples (Escape, Tab, Enter) and signals the intended resource (keyboard). It differentiates the tool from close/click/type siblings by focusing on key-based interaction rather than mouse or text entry, making intent unmistakable.

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 clear use cases: 'closing modals and testing keyboard navigation.' It does not explicitly mention when to avoid this tool or name alternatives like scout_type, but the context is clear enough for an agent to choose it appropriately for key-press 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, the description carries the full burden. It discloses that the tool writes a file to .scenescout/report.md, returns a bounded summary because full reports exceed token limits, can refuse based on gates, and that extensive mode's refusal is intentional as a completeness guarantee. This is unusually 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?

Every clause carries operational information and the critical output behavior is front-loaded. The length is justified by the number of gates and modes, though a later reference to 'oracle rollup'/role capability matrix relies on domain jargon.

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 supplies the needed return behavior (bounded summary) and side effect (full doc at .scenescout/report.md). Gate logic, force semantics, history modes, and multi-session behavior are all covered, leaving no obvious gap for calling 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?

All four parameters are already fully described in the schema (100% coverage), so the baseline is 3. The tool description adds meaningful context beyond the schema: it expands level into concrete gate requirements, explains why force should only be used on a budget cap, gives a concrete size example for history='full', and notes that separate session values run concurrently instead of queueing.

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?

Clearly names the deliverable ('final markdown report'), enumerates its contents (findings, page quality scores worst-first, capability matrix, oracle rollup, gap ledger), and pinpoints the exact write target `.scenescout/report.md`. This is distinguishable from siblings like `scout_lane_report` because it is the aggregate final report, not a lane or coverage view.

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 level-dependent gate conditions ('minimal' needs all routes visited + ≥1 design audit; 'medium' adds several routes audited; 'extensive' refuses on a non-empty gap ledger) and a strict condition for force=true (only when the user capped the budget). It does not name alternatives such as scout_lane_report, so it stops short of a full when-not-to-use comparison.

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 delivers richly: it discloses in-page execution carrying session cookies and replaying the app's last Authorization header, passage through the write-policy interception layer, the interpretation of safe-write refusals as a safety net rather than a finding, the exact response composition (status line, timing, identity-determining headers, body), run-trail recording, and origin fencing. This goes well beyond what annotations would normally convey.

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 (~180 words) but densely packed: every sentence earns its place, from the front-loaded purpose through the safety-net clarification, the return-value specification, and the trail-signature guidance. It is structured with the core purpose first and operational caveats following. Slightly verbose, but the tool's complexity — arbitrary methods including DELETE, write-policy interaction, and findings-grade evidence — justifies nearly every clause.

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 high-complexity tool with no annotations and no output schema, the description covers the critical bases: purpose, authentication context, write-policy interception, response shape, run-trail recording, and scope restriction. Minor gaps remain — no mention of rate limits, network-error behavior, or side effects of mutation methods beyond the safe-write note — but an agent has what it needs to invoke this tool correctly and interpret results.

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 structured fields already document all seven parameters and the baseline is 3. The description adds some contextual enrichment — e.g., "Paths are fenced to the attached origin" clarifies the `path` parameter's bounds, and the Authorization-header replay explains what `headers` overrides — but most of its content concerns tool behavior, not parameter-level semantics. The schema does the heavy lifting.

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 — "Call the app's own API as this session, with the UI bypassed" — and immediately establishes its distinct role among the scout_* siblings. It explicitly contrasts its proof value with UI actions: "A button that is not shown proves nothing; the same action refused by the server does," which differentiates it from scout_click and scout_navigate without ambiguity.

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 a clear when-to-use rationale (verify server-side refusal when a control is hidden or disabled), contrasts with shell calls ("Unlike a shell call, every request is recorded in the run's trail"), and provides when-not guidance: safe-write refusals are "the engine's safety net, not a finding," and paths are fenced to the attached origin ("use another session to reach another host"). It stops short of explicitly naming sibling alternatives such as scout_click as the preferred path when a control is visible.

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 provided, the description carries the full burden—and it delivers. It discloses execution-time target resolution, the prohibition on snapshot refs, the persistence and replay behavior, the upload semantics, the abort condition on new oracle violations/policy refusals/failed steps, the non-abort on repeated violations, and the transcript return. This is comprehensive behavioral 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 well organized: purpose, locator semantics, replay behavior, upload specifics, and abort semantics each get a sentence. No filler is present, though the length is substantial; a short example or a tighter split would make it even easier to scan.

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 tool is complex, but the description covers the execution model, target resolution, replay purpose, upload behavior, and failure semantics, and it states that a transcript is returned. With no output schema, a bit more detail on the transcript's structure would help, but the core context an agent needs 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?

Schema coverage is 75%, and the description adds meaning beyond the schema for key parameters: target locator syntax ('testid=…', 'text=…', 'label=…', 'role=button[name=Save]') and upload value semantics (fixture kind or project-relative path). It does not dwell on parameters already well described in the schema, like replace, pressEnter, and session, which 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 opens with a specific verb and resource: 'Execute up to 20 actions in ONE call.' It clearly identifies the intended use case (mechanical sequences like filling a form or walking a wizard) and distinguishes itself from the individual scout_* sibling tools by emphasizing batching and the round-trip cost saving. The upload-step comparison to scout_upload further differentiates it.

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 this tool: 'use for mechanical sequences (fill a form, walk a wizard) so each step doesn't cost a round-trip.' It also explains the replay workflow with scenescout check. It does not explicitly list exclusions or name alternative tools beyond scout_upload, so it falls short of a full 5.

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?

No annotations are provided, so the description carries the full burden. It does not disclose any behaviors beyond the literal act of selecting, such as whether it waits for options to load, how it handles missing values, or any side effects. It also does not mention that it may navigate or change application state.

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?

Extremely concise, single sentence, front-loaded with the primary action. Only one sentence, but it is not verbose. However, it might be too sparse given the tool's complexity.

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 minimal for a tool that manipulates a UI element. It lacks essential context such as how to identify the select, how values are matched, and any error conditions. Given there is no output schema and no annotations, the agent is left with too much uncertainty.

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 80%, so most parameters are described in the schema. However, the description adds nothing about parameter meanings. 'ref' is ambiguous, and 'value' could be either an option value or label, which is already in the schema but not elaborated in the description. With partial coverage, the description should compensate but does not.

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 ('Select') and resource ('an option in a <select>') but is very terse. It does not distinguish itself clearly from siblings like scout_click or scout_press, and 'by ref' is vague without explaining what 'ref' refers to.

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?

No guidance on when to use this tool versus alternatives like scout_click or scout_type. The description lacks any context about use cases, prerequisites, or exclusions. An agent would not know when to choose this over sibling tools.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 disclosure burden and exceeds it. It details append semantics, the separating-space rule, empty-text clearing, replace behavior, the exact event side effects (input fires, keydown does not), and the fact that the result reports pre-existing content. This is exemplary behavioral documentation.

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, append behavior, replace semantics, clearing rule, event caveat, and usage scope. It is front-loaded with the core action and then systematically covers edge cases. Length is justified by the behavioral complexity.

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 and no output schema, the description covers the full operational surface: how content is entered, when it is cleared, what side effects occur, and what the result reports. Nothing an agent needs to invoke it correctly or anticipate its behavior 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 meaningful context beyond the schema by explaining the interaction between textValue, replace, and empty-string clearing, and by clarifying which event behaviors apply. It enriches the parameters without restating 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 names a specific verb ('Type') and resource ('text input/textarea/composer by ref'), and immediately distinguishes the tool's core behavior — appending vs. replacing — which separates it from sibling input tools like scout_click or scout_press. The purpose is unambiguous and action-oriented.

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 states a broad use case ('valid values and boundary/fuzz values') and gives a critical constraint (keydown-driven triggers won't react to appended text), which effectively tells the agent when behavior may not match expectations. It does not name a sibling alternative (e.g., 'use scout_press for keydown-sensitive actions'), but the guidance is sufficiently clear for selection.

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 succeeds remarkably. It discloses the chooser interception, in-memory fixture generation, project-fencing of `filePath`, accept-violation flagging, warning if the input is cleared, and detection of state-changing requests. This goes far beyond a simple 'uploads a file' summary.

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 dense with operationally relevant detail; nearly every clause adds value. It is front-loaded with the core purpose and then proceeds from ref targeting to fixture/file selection to post-selection behavior. A few parentheticals could be trimmed, but the length is justified by the tool's complexity.

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, zero annotations, and no output schema, the description is remarkably complete. It covers the input-targeting strategy, file source options, validation behavior, state-change detection, and necessary follow-up actions. An agent has enough context to invoke the tool correctly and interpret its result without additional structured metadata.

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%, but the description adds substantial meaning beyond the schema: `ref` resolution through styled controls, fixture kind inference from the accept attribute, project-fencing semantics for `filePath`, and `name` use for boundary tests. It also explains the result fields tied to these parameters, making parameter behavior concrete.

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: 'Attach a file to an upload control the way a user does.' It clearly distinguishes the tool's scope from general file operations by detailing `ref` targeting of file inputs, hidden inputs, and chooser-opening controls. The distinctive behavior of intercepting the chooser makes it unambiguous among 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 description gives extensive usage context: when to omit `ref`, how to distinguish fixture-based uploads from `filePath` uploads, and what to do after a selection that fires no state-changing request. It does not explicitly name alternative sibling tools or state when not to use this tool, but the parameter-level guidance is clear enough for 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?

With no annotations, the description carries the full behavioral burden, and it delivers: it discloses ordering (worst route first), grouping, returned content (evidence and repro steps), and the state effects of each verdict—'gone' resolves, 'present' confirms, 'changed' keeps open. This is unusually transparent about side effects.

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?

Every sentence earns its place: the tool's action, the worklist behavior, narrowing, verdict recording, and usage timing. The information is front-loaded with the core purpose and flows logically without repetition or fluff.

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 five parameters, no annotations, and no output schema, the description is remarkably complete. It covers what the worklist returns, how to narrow it, how to record verdicts, and what each verdict means, leaving no critical gap for an agent trying 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 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the interaction between id, ids, and verdict—including that a verdict is recorded by calling again with id and verdict—and clarifies what the verdict values do to report state.

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: re-test findings left open by previous runs and record verdicts. It distinguishes itself from siblings like scout_scan or scout_resolve by describing a specific verification workflow with 'gone', 'present', and 'changed' outcomes.

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 when-to-use context: 'Use after a fix wave, or at the start of a run against an app this project has tested before.' It also explains the call pattern for listing, narrowing, and recording verdicts. It does not mention alternatives or when-not-to-use, so it stops short of a 5.

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