Build TestDriver tests iteratively using MCP tools with visual feedback
npx skills add https://github.com/testdriverai/testdriverai --skill testdriver:mcp-workflow
Build automated tests by directly controlling a sandbox through MCP tools. Every action returns a screenshot AND the generated code to add to your test file.
Use this skill when:
session_start, find, click, etc.)Use MCP tools to:
session_start({ type: "chrome", url: "https://your-app.com" })
This provisions a sandbox with Chrome and navigates to your URL. You'll see a screenshot and the provision code:
Add to test file:
await testdriver.provision.chrome({ url: "https://your-app.com" });
For local development (pointing to a custom API endpoint):
session_start({
type: "chrome",
url: "https://your-app.com",
apiRoot: "https://your-ngrok-url.ngrok.io"
})
For self-hosted AWS instances (your own Windows EC2):
session_start({
type: "chrome",
url: "https://your-app.com",
os: "windows",
ip: "1.2.3.4" // IP from your AWS instance
})
See AWS Setup Guide to deploy your own infrastructure.
Find elements and interact with them. Each action returns a screenshot AND generated code:
find_and_click({ description: "Sign In button" })
→ Returns: screenshot with element highlighted
→ Add to test file: await testdriver.find("Sign In button").click();
type({ text: "[email protected]" })
→ Returns: screenshot showing typed text
→ Add to test file: await testdriver.type("[email protected]");
After performing actions, use check to verify they worked:
check({ task: "Was the text entered into the field?" })
→ Returns: AI analysis of whether the task completed, with screenshot
check({ task: "Did the button click navigate to a new page?" })
→ Returns: AI compares previous screenshot to current state
Use assert for boolean pass/fail conditions that get recorded in test files:
assert({ assertion: "the login form is visible" })
→ Returns: pass/fail with screenshot
→ Add to test file:
const assertResult = await testdriver.assert("the login form is visible");
expect(assertResult).toBeTruthy();
As you perform actions, append the generated code to your test file:
/**
* Login Flow test
*/
import { describe, expect, it } from "vitest";
import { TestDriver } from "testdriverai/lib/vitest/hooks.mjs";
describe("Login Flow", () => {
it("should complete login", async (context) => {
const testdriver = TestDriver(context);
// Append generated code here as you go:
await testdriver.provision.chrome({ url: "https://app.example.com" });
await testdriver.find("email input field").click();
await testdriver.type("[email protected]");
// ... more code as you perform actions
});
});
Run the test from scratch to validate it works:
verify({ testFile: "tests/login.test.mjs" })
| Tool | Description |
|------|-------------|
| session_start | Start sandbox with browser/app, returns screenshot + provision code |
| session_status | Check session health and time remaining |
| session_extend | Add more time before session expires |
Each tool returns a screenshot AND the generated code to add to your test file.
| Tool | Description |
|------|-------------|
| find | Locate element by description, returns ref for later use |
| click | Click on element ref |
| find_and_click | Find and click in one action |
| type | Type text into focused field |
| press_keys | Press keyboard shortcuts (e.g., ["ctrl", "a"]) |
| scroll | Scroll page (up/down/left/right) |
| Tool | Description |
|------|-------------|
| check | For AI to understand screen state. Analyzes current screen and tells you (the AI) whether a task/condition is met. Use this after actions to verify they worked. |
| assert | AI-powered boolean assertion for test files (pass/fail for CI). Returns generated code. |
| screenshot | For showing the user the screen. Captures and displays a screenshot. Does NOT return analysis to you (the AI). |
| exec | Execute JavaScript, shell, or PowerShell in sandbox. Returns generated code. |
| Tool | Description |
|------|-------------|
| verify | Run test file from scratch to validate it works |
Every tool returns a screenshot showing:
Don't try to build the entire test at once:
# Step 1: Get to login page
session_start({ url: "https://app.com" })
→ Add to test: await testdriver.provision.chrome({ url: "https://app.com" });
# Step 2: Verify you're on the right page
check({ task: "Is this the login page?" })
# Step 3: Fill in email
find_and_click({ description: "email input field" })
→ Add to test: await testdriver.find("email input field").click();
type({ text: "[email protected]" })
→ Add to test: await testdriver.type("[email protected]");
# Step 4: Check if email was entered
check({ task: "Was the email entered correctly?" })
# Step 5: Continue with password...
After each action, use check to verify it worked:
find_and_click({ description: "Submit button" })
check({ task: "Was the form submitted?" })
The check tool compares the previous screenshot (from before your action) with the current state, giving you AI analysis of what changed and whether the action succeeded.
For AI understanding: Use check to analyze the screen:
check({ task: "Did the form submit successfully?" })
→ Returns AI analysis you can read and understand
For user visibility: Use screenshot to show the user:
screenshot()
→ Displays to user, no analysis returned to you
Action tools (find, click, find_and_click) return screenshots automatically, which the user can see. But if you need to understand the state, use check.
If elements take time to appear, use find with timeout:
find({ description: "Loading complete indicator", timeout: 30000 })
Sessions expire after 5 minutes by default. Use session_status to check time remaining and session_extend to add more time:
session_status()
→ "Time remaining: 45s"
session_extend({ additionalMs: 60000 })
→ "New expiry: 105s"
After each successful action, append the generated code to your test file. This ensures you don't lose progress and makes the test easier to debug.
If find fails:
find({ description: "...", timeout: 10000 })scroll({ direction: "down" })If the session expires:
session_start again with the same URLverify to get back to last stateIf verify fails:
When creating a new test project, use these exact dependencies:
package.json:
{
"type": "module",
"devDependencies": {
"testdriverai": "canary",
"vitest": "^4.0.0"
},
"scripts": {
"test": "vitest"
}
}
Important: The package is testdriverai (NOT @testdriverai/sdk). Always install from the canary tag.
Create test files using this standard format. Append generated code inside the test function:
/**
* Login Flow test
*/
import { describe, expect, it } from "vitest";
import { TestDriver } from "testdriverai/lib/vitest/hooks.mjs";
describe("Login Flow", () => {
it("should complete Login Flow", async (context) => {
const testdriver = TestDriver(context);
// Append generated code from each action here:
await testdriver.provision.chrome({ url: "https://app.example.com" });
await testdriver.find("email input field").click();
await testdriver.type("[email protected]");
await testdriver.find("password field").click();
await testdriver.type("secret123");
await testdriver.find("Sign In button").click();
const assertResult = await testdriver.assert("dashboard is visible");
expect(assertResult).toBeTruthy();
});
});
You can use your own AWS-hosted Windows instances instead of TestDriver cloud. This gives you:
AWS_REGION=us-east-2 \
AMI_ID=ami-0504bf50fad62f312 \
AWS_LAUNCH_TEMPLATE_ID=lt-xxx \
bash setup/aws/spawn-runner.sh
Output: PUBLIC_IP=1.2.3.4
session_start({
type: "chrome",
url: "https://example.com",
os: "windows",
ip: "1.2.3.4"
})
aws ec2 terminate-instances --instance-ids i-xxx --region us-east-2
You can also set TD_IP environment variable in your MCP config instead of passing ip to each session:
{
"mcpServers": {
"testdriver": {
"env": {
"TD_API_KEY": "your-key",
"TD_IP": "1.2.3.4"
}
}
}
}
check to understand the screen - This is how you (the AI) see and analyze the current statescreenshot to show the user - This displays the screen to the user, but does NOT return analysis to youcheck after every action - Verify your actions succeeded before moving oncheck for verification, assert for test files - check gives detailed AI analysis, assert gives boolean pass/fail for CIGuide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
Intelligently organizes your files and folders across your computer by understanding context, finding duplicates, suggesting better structures, and automating cleanup tasks. Reduces cognitive load and keeps your digital workspace tidy without manual effort.
Generates creative domain name ideas for your project and checks availability across multiple TLDs (.com, .io, .dev, .ai, etc.). Saves hours of brainstorming and manual checking.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Implements Manus-style file-based planning for complex tasks. Creates task_plan.md, findings.md, and progress.md. Use when starting complex multi-step tasks, research projects, or any task requiring >5 tool calls.
Creative research ideation and exploration. Use for open-ended brainstorming sessions, exploring interdisciplinary connections, challenging assumptions, or identifying research gaps. Best for early-stage research planning when you do not have specific observations yet. For formulating testable hypotheses from data use hypothesis-generation.
Comprehensive GitHub project management with swarm-coordinated issue tracking, project board automation, and sprint planning
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Take testdriverai/testdriver:mcp-workflow from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.