MCP connector

Give your coding agent
a real test runner

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 code
$ claude mcp add --transport http retibe \
    https://retibe.com/mcp \
    --header "Authorization: Bearer $TOKEN"

> retibe_whoami
you@example.com · professional
quota 168/200 web tests this month

> 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
Setup

Two minutes to connect

STEP 01

Issue a token

In your profile, under API tokens. It is shown once and cannot be recovered. Revoking it there takes effect immediately.

STEP 02

Add the server

One claude mcp add command over HTTP, with the token in an Authorization header. No local install, no Playwright download.

STEP 03

Verify

Ask the agent to call retibe_whoami. It should return your email, your plan and the quota you have left.

Then hand the agent the guide

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.

Guide — English Инструкция — русский
Positioning

Not a browser driver

Playwright MCP is for reconnaissance: look at the page, click around. ReTibe is for locking it down: this path must always work, check it on every release. Scout with one, pin it with the other.

Playwright MCPReTibe MCP
Working modelDrives a live browserWrites a scenario, runs it, reads the analysis
Sees the page between stepsYesNo
Left after the sessionNothingA saved scenario, a report, run history
Running it againExplain it all over againOne call by id
Where it runsLocallyOn the platform, in its browsers
Tools

Twenty-two tools and three prompts

Reference and checks

What exists, what a step must look like, and whether yours is valid.

retibe_doctorpreflight check
retibe_actionsaction catalogue
retibe_referencecross-cutting mechanics
retibe_validate_scenariomilliseconds, no browser
retibe_docsauthoring handbook
retibe_examplesworking scenarios

Running

Start, poll, read the verdict. Calls never block on a long run.

retibe_run_scenariovalidates first
retibe_run_statusbounded wait
retibe_run_resultwhat failed, where, why
retibe_list_runsrecent runs
retibe_stop_runcancel

Platform

Your account, environments, saved scenarios and their history.

retibe_whoamiplan and quota
retibe_envparameter keys only
retibe_scenariossaved scenarios
retibe_save_scenariowith diff
retibe_historystability and flakes
retibe_visual_reviewapprove under confirm
retibe_publish_runexplicit, shareable link

Coverage and schedule

What is still tested by hand, and what runs on its own tomorrow morning.

retibe_checklistswhat is still manual
retibe_checklist_itemlink a case to a scenario
retibe_calendarschedules and past runs
retibe_schedulecreate, pause, run now

/author

Write a scenario from a description.

/debug

Take a failed run apart and propose a fix.

/harden

Find the checks that never actually check anything.

Why the validator exists

A green test that checks nothing is worse than no test

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.

Checks that cannot fail

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.

And one question the warnings do not answer

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.

web_assert does less than it looks

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.

You cannot assert absence

visible: false looks like "it is gone" and means the opposite: the element must be in the DOM, just hidden. There is no absence check in the engine at all.

Invented actions get caught

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.

The order the tools expect

Step five is not optional. The platform does not validate scenarios; it will happily run a broken one.

01retibe_envEnvironments and parameter keys
02retibe_actionsThe contract of every action it plans to use
03retibe_referenceTemplates, conditions, fixtures
04Write the scenario
05retibe_validate_scenarioBefore any browser opens
06run → resultStart, poll, read the analysis
Beyond one run

A test that only runs when you ask is half a test

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.

Coverage, not a pile of files

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.

On a schedule, in your timezone

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.

Watch it, don't wait blindly

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.

It tells you what it cannot promise

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.

Know before you start

Limits, stated plainly

Telegram is authoring only

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.

One test at a time

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.

Runs are asynchronous

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.

Read the state, not the counter

infra_error means the scenario never ran. unknown is not "passed". Step counts are an estimate; only the state is a verdict.

Scout with Playwright. Pin it with ReTibe.

Issue a token, add one MCP server, and the paths your agent explored today become the regression suite that runs tomorrow morning.