Skip to main content
Glama

scout_journey

Measure real-task ease by walking a first-time user's click path, then report interaction cost, screens visited, and backtracks that signal discoverability problems.

Instructions

Measure how EASY a real task is, not just whether it works — the question pass/fail e2e suites never answer. Wrap one user goal: scout_journey {action:'start', goal:'Create an order'}, perform it the way a first-time user would (navigate by CLICKING through the UI, not by jumping to a known deep URL — a shortcut invalidates the measurement), then scout_journey {action:'end', completed:true|false}. Returns interaction cost (clicks, navigations, distinct screens, elapsed), the actual path taken, and friction signals: BACKTRACKS (returning to a screen already left — the clearest sign the next step wasn't discoverable), screen count, and over-interaction. Run it on each module's primary journey; an abandoned journey is a high-severity finding.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalNoFor start: the user-facing task, e.g. 'Create an order and assign it'
noteNoFor end: what made it hard or easy, in one line
actionYes'start' before attempting the task, 'end' when done or blocked
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.
completedNoFor end: did the user actually achieve the goal? false is a strong finding.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.