Skip to main content
Glama

scout_report

Generate a markdown report with findings, page scores, role matrix, oracle rollup, and a gap ledger of untested items. Enforce coverage gates and return a bounded summary.

Instructions

Generate the final markdown report — findings, page quality scores (worst first), role capability matrix, oracle rollup, and the GAP LEDGER (an explicit list of what was NOT tested). Writes the full document to .scenescout/report.md and returns a bounded SUMMARY (full reports exceed client token limits). Gates by level: 'minimal' needs all routes visited + ≥1 design audit; 'medium' additionally needs several routes audited; 'extensive' REFUSES while the gap ledger is non-empty — that refusal is the completeness guarantee: an extensive report only generates when nothing known is left untested. force=true overrides (only when the user capped the budget).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoGenerate even though gates are unmet (only when the user capped the budget)
levelNoWhich completion contract to enforce — match the level the run was asked formedium
sessionNoTarget this session directly instead of the active one — pass it explicitly when dispatching to MULTIPLE sessions in one turn (e.g. two scout_click calls with different `session`), which then run CONCURRENTLY rather than queueing. Omit for single-session sequential use.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden, and it delivers: it states the file write to .scenescout/report.md, the bounded summary return due to token limits, and the refusal behavior for 'extensive' when the gap ledger is non-empty. This transparency is unusually strong for a tool with no structured annotation safety hints.

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

Conciseness5/5

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

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

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

Completeness5/5

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

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

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

Parameters4/5

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

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

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

Purpose5/5

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

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

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

Usage Guidelines5/5

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

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

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