Scan a project directory to uncover frontend workspace, framework, routes, dev command, Playwright auth states, and testid conventions. Run this first to prepare for UI testing.
Scan a project directory to discover the frontend workspace, framework, routes, dev command, Playwright auth storage states, and testid conventions. Run this first.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path to the project root |
Changes observed during successful MCP inspections.
v1.1.0Does 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.