Connect your coding agent

If you already work with an AI coding assistant, it knows things Marriska can’t see on its own: your routes, field names, data-testids, and exactly what the current pull request changed. Connect it to Marriska and it turns that knowledge into real tests — authored from code, executed in our cloud, and readable by everyone on the team.

Why route it through Marriska

Your agent could write Playwright code directly. The difference is where the test lives afterwards:

The whole team owns it. A plain-English test is readable by QA, product, and support — not just whoever wrote it.
It runs without infrastructure. Cloud browsers, screenshots, visual regression, schedules, notifications, shareable reports.
It self-heals. Marriska resolves elements by visible text through a locator ladder, so a class rename doesn’t break the suite.
Your code stays yours. The agent reads your repo locally and sends only the finished plain-English steps.

Requirements

A Marriska API key — Settings → API Keys (every plan includes one; paid plans add more).
Node.js 18+ and an MCP-capable assistant (Claude Code, Claude Desktop, Cursor, Codex CLI, or any other MCP client).

Setup

Create an API key

In Marriska, open Settings → API Keys → Create API Key. Copy it — it’s shown once. Treat it like a password: it can create tests and start cloud runs in your organization.

Add the server to your agent

Claude Code:

claude mcp add marriska --env MARRISKA_API_KEY=ak_live_... -- npx -y @marriska/mcp

Any other MCP client (mcp.json, claude_desktop_config.json, Cursor’s MCP settings):

{
  "mcpServers": {
    "marriska": {
      "command": "npx",
      "args": ["-y", "@marriska/mcp"],
      "env": { "MARRISKA_API_KEY": "ak_live_..." }
    }
  }
}

Ask for a test

“Read the checkout flow in this repo, write a Marriska test for the happy path, run it, and show me the result.”

The agent authors the steps, creates the test in your workspace, queues a cloud run, and reports back with the outcome. The test is now in your Tests list like any other — editable, runnable, schedulable.

What the agent can do

Tool	What it does
`whoami`	The org, key and URL this server writes to
`list_projects`	Projects in your organization
`create_project`	Create a project — the same plan limit as in the app
`update_project`	Rename a project or change its description
`list_environments`	Where a project’s tests can be aimed
`create_environment`	Add staging, production… with a base URL
`update_environment`	Rename, re-point, change its allowlists, or make default
`delete_environment`	Delete one; refused while a schedule uses it
`project_variables`	Which variable names this project’s tests need, and which environments supply them
`list_variables`	An environment’s variables; a secret’s value is never returned
`set_variable`	Set a value on an environment; mark it secret to encrypt and mask it
`delete_variable`	Remove one; a run still referencing it is refused
`set_descriptor`	Document a name and give it a default — never a secret
`list_folders`	Folders with their paths, optionally for one project
`create_folder`	Create a folder or a subfolder in a project
`list_tests`	Tests with their folder path and step counts
`list_test_sets`	Test sets with their test counts, for `run_test`
`create_test_set`	Group tests under a re-runnable name
`update_test_set`	Rename a set, or replace its membership
`delete_test_set`	Delete a set; its tests survive
`get_test`	One test with its full ordered steps
`create_test`	Create a test from explicit steps in a project (required — every test belongs to one), in a folder and at a viewport preset if you name them
`update_test_steps`	Replace a test’s steps after a code change
`rename_test`	Change a test’s name or description
`delete_test`	Delete a test, its steps and its baselines
`rename_folder`	Change a folder’s name
`delete_folder`	Delete a folder; its tests return to the project root
`run_test`	Queue a cloud run, optionally at one viewport preset, optionally with a session for that run
`get_run_result`	Status, per-test results, and every step with its error and screenshot path
`list_runs`	Runs newest first, by project, label or status
`wait_for_run`	Block until a run reaches a terminal status
`get_step_screenshot`	The image taken after one step, to see why it failed — and, when the step acted on or checked an element, where that element is in the image

The server also publishes the full step schema as an MCP resource (marriska://step-actions), so the agent learns the format — actions, assertions, wait semantics — without you pasting documentation.

Working well with it

Let it build the tree first. “Create a project for this repo with Smoke, Regression and In-trip folders, then file the tests.” Structure the agent creates is the structure QA inherits — the same projects and folders the team sees in the app.
Ask for assertions. “Make sure it verifies the total, not just that the page loads.” A test that only clicks can’t fail.
Say which screen size. “Write these as mobile tests” makes the agent set the mobile viewport (375 wide, iPhone user agent, touch) on each test, and run_test can render a whole run at one preset. A green run at desktop proves nothing about the phone layout most of your users see.
Point at a diff. “This PR changed the signup flow — update the tests that cover it” is where code-awareness pays off most.
Let it start signed in. Behind a login, the agent can pass a session with the run (run_test → session_cookies) — cookies your app already accepts, minted per run and never stored — or use the project’s stored session once an admin allows agent-created tests to. See Start a test signed in.
Let it read the failure. A run result carries every step with its error and a screenshot the agent can open, so “the checkout test failed — fix it” is a loop it can close on its own, and the report you get is the repaired test.
Let QA take it from there. Once the test exists, curating test sets, schedules, and failure triage happens in Marriska — that hand-off is the point.

Self-hosted or staging

Set MARRISKA_API_URL alongside the key (defaults to https://api.marriska.com/api/v1).

API keys — creating, scoping, and revoking keys
Step actions — the same schema the agent reads
Running tests — what happens after a run is queued