Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@deploytest MCP server run the login-flow fixture against staging.example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A CLI tool for running Playwright test fixtures against live deployments, with optional MCP (Model Context Protocol) interface for AI agents"
✅ Run test fixtures against live deployments
✅ Capture screenshots, console errors, and network failures
✅ Support for parallel or sequential test execution
✅ Tag-based test filtering
✅ Structured test results with assertions
✅ Reusable test fixture interface
Related MCP server: Assert
When verifying a deployment, it's tempting to test things manually or write throwaway verification code. AI agents often try to create one-off bash scripts or Playwright commands to check if something works. This is inefficient for several reasons:
Wasteful: Every test requires re-discovering what to check and how to check it
Error-prone: Manual steps are forgotten, commands have typos
Not repeatable: Can't easily re-run the same verification later
Token-inefficient: Agents spend tokens re-figuring out the same verification logic
The same applies to humans doing manual testing in a browser.
Deploytest follows a better pattern:
Write test fixtures once - Codify your verification logic as reusable test fixtures
Run locally during development - Test against localhost as part of your normal workflow
Run against deployments - Use the same test code to verify staging/production deploys
Get structured results - Receive pass/fail, errors, screenshots, and assertions
Your test fixtures are proper code that lives in your repo and can be maintained over time.
Chrome DevTools MCP - For exploration and discovery
General-purpose browser inspection and DOM manipulation
Great for: Understanding a site, debugging issues, exploring unknown pages
Trade-off: Ad-hoc usage, requires many tokens to figure out what to check
Playwright MCP - For scripted browser automation
Low-level browser automation commands
Great for: One-off automation tasks, quick checks
Trade-off: Each verification requires writing/running commands from scratch
Deploytest - For deployment verification with reusable tests
Test fixtures that encode domain knowledge about your site
Great for: Verifying deployments, regression testing, CI/CD integration
Benefit: Write once, run many times; token-efficient; structured results
Use Chrome DevTools MCP or Playwright MCP to explore and understand what needs testing
Codify your findings into deploytest fixtures (proper test code in your repo)
Run those fixtures locally during development
Use deploytest (CLI or MCP) to verify staging/production deployments
Deploytest is primarily a CLI tool. Run deploytest mcp to start it as an MCP server for AI agents:
# Direct CLI usage
deploytest run-fixture --url https://staging.example.com --fixture login-flow
# MCP server mode (for Claude Desktop/Code)
deploytest mcpThe MCP mode simply makes it convenient for AI agents to run your existing test fixtures. The agent doesn't write ad-hoc test code - it runs your well-tested, reusable fixtures.
npm install
npm run buildOr with bun:
bun install
bun run buildnpx playwright install chromium# List all available fixtures
deploytest list-fixtures
# List fixtures with specific tags
deploytest list-fixtures --tags smoke,critical
# Run a specific fixture against a deployment
deploytest run-fixture --url https://staging.myapp.com --fixture basic-page-load
# Run all fixtures
deploytest run-all-fixtures --url https://staging.myapp.com
# Run tagged fixtures in parallel
deploytest run-all-fixtures --url https://staging.myapp.com --tags smoke --parallelAdd this to your MCP settings:
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"deploytest": {
"command": "deploytest",
"args": ["mcp"]
}
}
}Or if using npx (for published packages):
{
"mcpServers": {
"deploytest": {
"command": "npx",
"args": ["-y", "deploytest", "mcp"]
}
}
}list_fixturesList all available test fixtures, optionally filtered by tags.
Parameters:
tags (optional): Array of tags to filter by
Example:
// List all fixtures
await mcp.list_fixtures();
// List only smoke tests
await mcp.list_fixtures({ tags: ["smoke"] });run_fixtureRun a specific test fixture against a deployment URL.
Parameters:
baseUrl (required): URL of the deployment to test
fixtureName (required): Name of the fixture to run
headless (optional): Run in headless mode (default: true)
Example:
await mcp.run_fixture({
baseUrl: "https://staging.myapp.com",
fixtureName: "basic-page-load"
});run_all_fixturesRun all test fixtures (or filtered by tags) against a deployment URL.
Parameters:
baseUrl (required): URL of the deployment to test
tags (optional): Only run fixtures with these tags
parallel (optional): Run in parallel (default: false)
headless (optional): Run in headless mode (default: true)
Example:
// Run all smoke tests
await mcp.run_all_fixtures({
baseUrl: "https://staging.myapp.com",
tags: ["smoke"],
parallel: true
});Test fixtures are defined in src/fixtures.ts. Each fixture implements the TestFixture interface:
import type { TestFixture, TestResult } from './types.js';
export const myCustomTest: TestFixture = {
name: 'my-custom-test',
description: 'Description of what this tests',
tags: ['smoke', 'critical'],
timeout: 30000,
run: async (page, baseUrl) => {
const start = Date.now();
const consoleErrors: string[] = [];
page.on('console', msg => {
if (msg.type() === 'error') consoleErrors.push(msg.text());
});
try {
await page.goto(`${baseUrl}/my-page`);
// Your test logic here
const isVisible = await page.isVisible('[data-testid="my-element"]');
return {
passed: isVisible,
duration: Date.now() - start,
artifacts: {
screenshot: await page.screenshot({ encoding: 'base64' }),
consoleErrors
},
assertions: [
{
selector: '[data-testid="my-element"]',
expected: 'visible',
actual: isVisible,
passed: isVisible
}
]
};
} catch (error: any) {
return {
passed: false,
duration: Date.now() - start,
error: {
message: error.message,
stack: error.stack
},
artifacts: {
screenshot: await page.screenshot({ encoding: 'base64' }).catch(() => undefined),
consoleErrors
}
};
}
}
};
// Add to the exported array
export const testFixtures: TestFixture[] = [
// ... existing fixtures
myCustomTest
];To use this MCP with your own application's test fixtures:
Option 1: Direct Import (if fixtures are in same repo)
// src/fixtures.ts
import { myAppFixtures } from '../my-app/tests/fixtures.js';
export const testFixtures = [...myAppFixtures];Option 2: Symlink (if fixtures are in separate repo)
ln -s /path/to/my-app/tests/fixtures.ts src/app-fixtures.ts// src/fixtures.ts
import { testFixtures as appFixtures } from './app-fixtures.js';
export const testFixtures = appFixtures;Option 3: Dynamic Import (load at runtime)
// Configure path via environment variable
const fixturesPath = process.env.FIXTURES_PATH || './fixtures.js';
const { testFixtures } = await import(fixturesPath);Once configured, Claude Code can use this MCP to verify deployments:
User: "Test my staging deployment at https://staging.myapp.com"
Claude Code will:
1. Call list_fixtures to see available tests
2. Call run_all_fixtures with the URL
3. Analyze the results (screenshots, errors, assertions)
4. Report any issues and suggest fixes# Claude Code automatically uses the MCP like this:
1. User deploys to staging
2. Claude Code calls: run_all_fixtures({
baseUrl: "https://staging.myapp.com",
tags: ["smoke"]
})
3. Gets back:
- Test summary (10/12 passed)
- Failed test details with screenshots
- Console errors
- Network failures
4. Claude analyzes and reports:
"Deployment verification: 2 tests failed
- login-flow: Button selector changed
- checkout-flow: 404 on /api/cart"
5. Claude can fix the issues or alert you# Watch mode for development
npm run watch
# Run directly with tsx (for testing)
npm run dev
# Build for production
npm run buildYou can test the MCP using the MCP Inspector:
npx @modelcontextprotocol/inspector node dist/index.jsThe demo/ directory contains a complete example with working and broken demo sites that you can use to verify the tool works correctly.
Run the automated demo:
npm run demoThis will:
Start local servers for both working and broken example sites
Launch Chromium via Playwright
Run all test fixtures against both sites
Generate a comprehensive report showing detected issues
Manual exploration:
# Start working site on http://localhost:3000
npm run demo:working
# Start broken site on http://localhost:3001
npm run demo:brokenSee demo/README.md for detailed documentation.
MIT
To add new fixtures:
Create your fixture in src/fixtures.ts
Follow the TestFixture interface
Add it to the exported testFixtures array
Rebuild: npm run build
The fixture will automatically be available to Claude Code!
List all available test fixtures
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Filter fixtures by tags (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. 'List' implies a read-only operation, but the description adds no further context about return format, filtering behavior, or scope limitations. It is not misleading but lacks depth for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is appropriately sized for a simple list tool and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter and no output schema, the description is adequate. It clearly states what the tool does, and the schema covers the only parameter. Minor gap: it does not mention what the returned list contains (e.g., names, IDs), but this is likely inferred from 'fixtures'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the only parameter 'tags' has a clear description). The tool description adds no information about the parameter, so it does not enhance what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all available test fixtures' uses a specific verb ('List') and resource ('test fixtures'), clearly stating the tool's function. It distinguishes from sibling tools (run_fixture, run_all_fixtures) by focusing on listing rather than running.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (list fixtures when you need to see what's available) but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like run_fixture or run_all_fixtures, leaving the agent to infer based on sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run all test fixtures (or filtered by tags) against a deployment URL
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Only run fixtures with these tags (optional) | |
| baseUrl | Yes | The base URL of the deployment to test | |
| headless | No | Run browser in headless mode (default: true) | |
| parallel | No | Run fixtures in parallel (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only states the action (running fixtures) and provides no details about side effects, permissions, browser sessions, potential changes to the deployment, or the nature of the test execution. This is a significant gap for an execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the verb and object, with an optional modifier for tags. There is no redundant phrasing or filler; it is concise and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description should explain what happens when the tool runs (e.g., return values, exit codes, timeout behavior, or side effects). It only covers the action and filtering, leaving out operational context that an agent would need to reason about invocation and post-conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal semantic context by associating tags with filtering and baseUrl with the deployment URL, but it does not provide additional syntax, format, or behavioral details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Run all test fixtures', identifies the target resource (fixtures), and specifies the context ('against a deployment URL'). It also notes optional tag filtering, which distinguishes it from the sibling 'run_fixture' tool by indicating plural coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the description says it runs all fixtures or a tag-filtered subset, which suggests when to use it. However, it does not explicitly contrast with alternatives like 'run_fixture' (singular) or 'list_fixtures' (listing only), nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a specific test fixture against a deployment URL
| Name | Required | Description | Default |
|---|---|---|---|
| baseUrl | Yes | The base URL of the deployment to test | |
| headless | No | Run browser in headless mode (default: true) | |
| fixtureName | Yes | Name of the test fixture to run |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states 'Run' without revealing side effects (e.g., executing tests, launching browsers), requirements, or output behavior. The agent cannot infer safety or operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveying the core action and object with zero redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description leaves significant gaps: no indication of what happens when the fixture runs, how results are returned, or how this tool relates to run_all_fixtures. The simple schema covers parameters, but operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with every parameter described. The description adds no new meaning beyond mapping 'specific test fixture' to fixtureName and 'deployment URL' to baseUrl. It meets the baseline for high schema coverage but doesn't enrich the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Run'), a specific resource ('a specific test fixture'), and target ('deployment URL'). It implies distinction from 'run_all_fixtures' by emphasizing 'specific', but does not explicitly name sibling tools, so it doesn't fully achieve the 5-level differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for a single fixture rather than all (suggested by 'specific'), but provides no explicit when-to-use vs. alternatives, no exclusions, and no context about prerequisites. Usage is inferable but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0list_fixturesrun_all_fixturesrun_fixtureEach tool has a distinct purpose: listing fixtures, running a single fixture, and running all fixtures. No overlap or ambiguity exists.
All tool names follow a consistent verb_noun pattern with snake_case: list_fixtures, run_fixture, run_all_fixtures. The naming is predictable and uniform.
With only 3 tools, the server is tightly scoped to its purpose of running test fixtures. Each tool is essential and there is no bloat.
The tool set covers the full lifecycle for this domain: discovering fixtures, executing a specific fixture, and executing all fixtures. No critical operations are missing for a deployment test runner.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Browser-based QA for AI-built software. Test pages with real browsers via agents.
Direct access to Cypress tests results and accessibility reports in your AI workflow.
Agentic testing: HyperExecute jobs, test failure triage, SmartUI visual diffs, a11y audits
AI QA that runs your app in a browser on every pull request: projects, test targets, test cases.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/benhuckvale/deploytest'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
