Start from the terminal, not the browser

Register the helper with your agent

webQsee hands you the line ready-made, token filled in and spelled for your agent: open your user area, the AI Analysis tab, From a terminal, and pick your MCP client. For Claude Code it looks like this:

claude mcp add --transport http wqs http://127.0.0.1:48620/mcp \
    --header "Authorization: Bearer <token>"

Run that once. From then on the agent can reach whatever this helper can reach. Away from webQsee, wqs-helper token prints the token and wqs-helper status the address.

Find the recording without leaving the terminal

> what webQsee recordings can you see?

The agent answers from three places at once: what is already parsed on this machine, what any open webQsee window has in its local gallery, and what your cloud gallery holds. It also says which of those it could not consult and why, so "you have no recordings" and "you are not signed in" never look the same.

> fetch the one called "checkout hangs on step 3" and tell me what went wrong

A recording in a browser window is streamed through the extension. A cloud recording is downloaded where it lies rather than routed through the browser.

Have the problem reproduced while you wait

This is the one that closes the loop that usually costs a day.

> I need to see this happen. Ask me to reproduce it and wait.

The agent waits. Someone records the problem in the browser, presses save, and the agent picks the recording up as soon as it exists. The person who can reproduce the bug and the person reading the code end up working on the same artefact within a minute of each other.

Analyze a file you already have

No browser involved at all:

wqs-helper overview  ~/Downloads/webQsee-behavior-report-2026-08-27.bar
wqs-helper moments   ~/Downloads/webQsee-behavior-report-2026-08-27.bar
wqs-helper analyze   ~/Downloads/webQsee-behavior-report-2026-08-27.bar \
    --ask "why does the cart total come back as null?" --project .

--project . is what lets the agent read the code as well as the recording, which is where most of the value is: the recording says what happened and the source says why.

--dry-run prints the exact command line and prompt without calling any model, which is the cheapest way to see what a profile actually does before you spend anything.

Reading a recording by hand

Sometimes you do not want an agent at all. The same model the agent reads is on the command line, and it is the fastest way to see what an archive holds:

wqs-helper overview  <file>     # what this recording is, and what to distrust about it
wqs-helper groups    <file>     # the shape of it, grouped the way the analyzer groups
wqs-helper moments   <file>     # a reading order, best first
wqs-helper events    <file> --problems
wqs-helper event     <file> 214 --headers --stack
wqs-helper related   <file> 214
wqs-helper search    <file> "Exception"

Bring your own error definitions

If your team has defined its own error-detection rules in webQsee, the analysis can use them, so a finding can say "this is an error by your definition" rather than by webQsee's. Export the rules and pass them alongside the archive, or drop them next to it as <archive>.wqs-rules.json and they are picked up automatically.

Whatever a reading cannot evaluate it names rather than skipping quietly, which is what keeps the result honest: while that list is non-empty, an event without a rule match is not proof that no rule applies to it.

Next