Connect Claude Code, or any MCP client, to ReTibe. It writes scenarios, validates them before a browser ever opens, runs them on the platform, and reads back exactly which step failed and why.
$ claude mcp add --transport http retibe \ https://retibe.com/mcp \ --header "Authorization: Bearer $TOKEN" > retibe_whoami you@example.com · professional 168/200 web tests · 41/600 inspections > retibe_inspect_page {{params.base}}/cart form#checkout · button[data-testid="pay"] · 4 links selectors verified unique at capture time > retibe_validate_scenario warn: step-3 web_assert reads no expected value use data.contains, or this step passes on anything > retibe_run_result webtest-4417 failed · step-4 web_click selector .submit not found after 30s > retibe_compare_runs webtest-4417 vs last green: step-4 pass → fail, error is new step-2 1.9s slower · nothing else moved
In your profile, under API tokens. It is shown once and cannot be recovered. Revoking it there takes effect immediately.
One claude mcp add command over HTTP, with the token in an Authorization header. No local install, no Playwright download.
Ask the agent to call retibe_whoami. It should return your email, your plan and the quota you have left.
Everything the engine will not tell it by itself: which checks cannot fail, how the storyboard reads, how to name scenarios and how many to keep. Drop the file into the thread, or link to it.
Playwright MCP drives a live browser: open the page, click around, see what is there. ReTibe does its own reconnaissance now — a page outline with selectors verified unique, and a crawl that maps the site — but that is only the first five minutes. The rest is locking it down: this path must always work, check it on every release.
| Playwright MCP | ReTibe MCP | |
|---|---|---|
| Working model | Drives a live browser | Writes a scenario, runs it, reads the analysis |
| Reconnaissance before writing | Its whole job | Page outline and site crawl, on a separate cheaper quota |
| Sees the page while the test runs | Yes | No |
| Left after the session | Nothing | A saved scenario, a report, run history |
| Running it again | Explain it all over again | One call by id |
| Where it runs | Locally | On the platform, in its browsers |
Twenty-six of them over the HTTP connector. retibe_doctor and retibe_publish_run appear only when the server runs on your own machine, because that is the only place they mean anything.
Look at the page before writing a selector for it. Neither one spends a run.
retibe_inspect_pageoutline and verified selectorsretibe_crawlwhich pages exist at allWhat exists, what a step must look like, and whether yours is valid.
retibe_doctorpreflight checkretibe_actionsaction catalogueretibe_referencecross-cutting mechanicsretibe_validate_scenariomilliseconds, no browserretibe_docsauthoring handbookretibe_examplesworking scenariosStart, poll, read the verdict. Calls never block on a long run.
retibe_run_scenariovalidates firstretibe_run_statusbounded waitretibe_run_resultwhat failed, where, whyretibe_list_runsrecent runsretibe_stop_runcancelYour account, environments, saved scenarios and their history.
retibe_whoamiplan and quotaretibe_envparameter keys onlyretibe_paramwrites a key, never reads one backretibe_scenariossaved scenarios, and their revisionsretibe_save_scenariowith diff, and revertretibe_visual_reviewapprove under confirmretibe_auditwhat an agent changedTwo runs side by side, and what each step has done over the last ten.
retibe_compare_runswhat changed since the last green runretibe_historystability and flakesretibe_publish_runexplicit, shareable linkWhat is still tested by hand, and what runs on its own tomorrow morning.
retibe_checklistswhat is still manualretibe_checklistcreate one with its casesretibe_checklist_itemadd, edit, link a caseretibe_calendarschedules and past runsretibe_schedulecreate, pause, run now/authorWrite a scenario from a description.
/debugTake a failed run apart and propose a fix.
/hardenFind the checks that never actually check anything.
The engine accepts almost anything, so a broken scenario does not fail, it passes while verifying nothing. Validation runs in milliseconds before a browser opens, and every warning comes with the replacement.
api_test, security, seo_analysis and others record findings and still report passed. A 500 response leaves the test green. If the step should block a release, follow it with a real assertion.
Forty warnings still will not tell you whether the test would notice your site breaking. view:'storyboard' does: it lists every step with a verdict — can fail, asserts nothing, always green, may not run — and then says how many can go red at all. If the answer is none, the scenario is decoration.
It checks visibility and a substring, and only through data.contains. Fields like expected or attribute are never read, so the step passes on any visible element.
visible: false looks like "it is gone" and means the opposite: the element must be in the DOM, just hidden. Absence is absent: true, which passes once the element is removed or hidden, and the validator warns when the flag is written as a string and would quietly check the opposite.
Validation, view:'storyboard' and the refusal retibe_run_scenario makes before it launches a browser cost nothing at all. Reconnaissance comes off its own counter, not the run quota: 60 page inspections a month on Free, 600 on Professional. The only thing that spends a web test is a web test.
The action catalogue is extracted from the engine's own dispatcher by AST, and a drift test fails the build when they diverge. Actions the model made up are rejected with a suggested replacement.
Buyer and seller, caller and callee, admin and user. Declare the participants once, put an actor on each step, and the run drives a separate browser for each — separate session, separate cookies, one scenario. It is how you test what happens between two people.
The storyboard gains an actor column, the step timeline says which browser each step ran in, and the result breaks pass/fail down per participant. "Whose side failed?" is answered without opening a screenshot.
A scenario that declares two participants but misses one flag runs both of them in a single browser — green, and meaningless. Validation calls that an error before you spend a run on it, and flags a mistyped participant id, which otherwise passes while testing the wrong person.
Steps run in scenario order: while one participant acts, the other waits. To make one wait for the other, assert on what the other's action produced — that assertion is the synchronisation, and it is a real check rather than a sleep.
Step six is not optional. The platform does not validate scenarios; it will happily run a broken one.
retibe_inspect_pageThe page as the run will see it, with selectors that resolveretibe_envEnvironments and parameter keysretibe_actionsThe contract of every action it plans to useretibe_referenceTemplates, conditions, fixturesretibe_validate_scenarioBefore any browser opensrun → result → compareStart, poll, read the analysis, diff it against the last green runTwo runs compared step by step, an outcome history per step, the failing frame with the console errors that came with it, the same verdict in a format CI already reads — and a record of every change an agent made.
retibe_compare_runs takes two finished runs of the same scenario and says which steps flipped pass↔fail, whether the error is the same one or a new one — compared after stripping numbers, paths and Playwright call logs — which steps got markedly slower, and which exist in only one run. Leave the baseline out and it finds the last passed run itself.
retibe_history detail:'steps' prints each step's pass/fail string across the last ten runs. ✓✓✗✓✗✓ is a flaky step. ✓✓✓✓✗✗ is something you broke on Tuesday. One run cannot tell you which; ten can.
A frame after the last failed attempt, by default, without the scenario spelling the field out. The step also carries the browser console errors and the failed or 4xx/5xx requests from around the moment it died, so "selector not found" arrives next to the 500 that explains it.
detail:'markdown' is a block sized for a pull request comment. detail:'junit' is the XML itself, not a link a CI job cannot open without arranging a token first. And uses: retibe/gate@v1 runs one stored scenario and fails the job on its verdict — curl and jq, no browser in your runner.
Every save snapshots the scenario as it stood before it — the last twenty, each with who saved it and which steps that save added, changed or removed. {op:'revert', id:47, revision:4, confirm:true} puts one back, and the state the revert replaces is snapshotted in turn, so the revert is itself revertable.
retibe_audit lists every non-GET call made with an API token, newest first: scenarios saved, schedules changed, params written, runs started or stopped. Identifiers only — it says what was touched, never what it was changed to. Edits made from the browser are not in it, and the answer says so rather than reading as "nothing changed".
The agent can see which cases your team still checks by hand, wire the scenario it just wrote to one of them, put it on a schedule, and follow the run step by step — without leaving the thread.
Keep your manual checklist where it is. retibe_checklists only:'unlinked' answers "what is still manual?", and after the scenario is saved, one call ties a case to the step that now proves it. Coverage stops being a guess.
Daily, weekly, monthly or once — with the next firing time computed by the platform and handed straight back, so a wrong schedule is obvious now rather than tomorrow. Pause, resume, or fire one immediately and poll the run it started.
Say what you are waiting for, not how long: wait_for:'failure' comes back the moment something breaks instead of spending the whole budget. Each reply carries a step timeline and a cursor, so the next poll costs only what is new.
Every number that is an estimate says so. Step timings are intervals between log lines, not measurements, and the reply says which. A checklist link is a plain string the platform never validates, so there is a call that checks whether yours still points at anything. Where the platform reports one figure three different ways, you get the raw counts and the formula beside them.
Scenarios can be written and validated here, but running one needs a session created by an interactive login with SMS. Start those from the platform.
Per account. Web tests and bot tests block each other, and runs started here spend the same monthly quota as runs started in the web interface. Page inspections come off a separate counter — 60 a month on Free, 600 on Professional — and one account inspects one page at a time.
A web test usually takes about a minute, the longest around ten. Starting returns a run id and the agent polls, so a long run never blocks the tool call.
infra_error means the scenario never ran. unknown is not "passed". Step counts are an estimate; only the state is a verdict.
Issue a token, add one MCP server, and the paths your agent explored today become the regression suite that runs tomorrow morning.