You're building a feature that needs a dropdown menu. You open your browser, navigate to your localhost, click through five screens to get to the right page, manually test the dropdown, realize it's broken on mobile, fix it, and repeat the whole process. Sound familiar?

What if your AI assistant could do all of that for you—navigate the UI, test interactions, take screenshots, and even fix the issues it finds? This isn't science fiction. It's what happens when you connect Playwright to Claude Code through MCP (Model Context Protocol).

Watch as Cyrus navigates Linear using Playwright to create an issue, demonstrating how AI can utilize the web browser for QA and feature development tasks—all through simple natural language commands.

"Wait, why does it look so slow?" That's the point. It's doing the boring, repetitive work—clicking through menus, waiting for pages to load, filling out forms—so you don't have to. Every deliberate action you see is time you get back to focus on what matters.

A pro tip we learned the hard way

The first time Cyrus navigates any new interface, it explores carefully, learning the layout. But here's the secret: encourage it to document what it learns in its CLAUDE.md file. Next time? Lightning fast, no fumbling around. It remembers the exact selectors, the navigation patterns, even the quirks of your app.

For platforms like Linear with robust keyboard shortcuts, teach Cyrus to use them. Instead of clicking through menus, it can press c to create an issue, cmd+k for quick search, or g then i to go to issues. The more shortcuts you share, the faster it gets.

The shift: from manual testing to AI-driven development

Here's what changes when AI can see and interact with your UI:

Traditional Development:

1. Write code
2. Alt-tab to browser
3. Navigate to the feature
4. Test manually
5. Find issue
6. Alt-tab back to editor
7. Fix code
8. Repeat until it works

With Playwright MCP:

1. Describe what you want
2. AI writes code, opens browser, tests it, finds issues, fixes them
3. You review the working result

The difference isn't just speed—it's a fundamental shift in how we build user interfaces. The AI becomes your QA engineer, your accessibility tester, and your implementation partner all at once.

Real examples: what this looks like in practice

Building a multi-step form

A developer needed to add a three-step onboarding flow to their application. Here's what happened:

The Request: "Add a three-step onboarding form with validation"

What the AI Did:

1. Created the form components
2. Opened the browser to the application
3. Navigated through each step
4. Tested validation by entering invalid data
5. Fixed validation edge cases it discovered
6. Tested the mobile responsive layout
7. Added proper ARIA labels after checking accessibility
8. Took screenshots of each step for documentation

Time Saved: 4 hours → 20 minutes

Automated accessibility testing

Another team discovered their checkout process had accessibility issues only after a customer complaint. They used Playwright MCP to audit their entire application:

The Process:

1. AI navigated to every major page
2. Tested keyboard navigation
3. Checked color contrast ratios
4. Verified screen reader compatibility
5. Generated a report with specific fixes
6. Implemented the fixes
7. Re-tested to confirm improvements

Result: Found and fixed 23 accessibility issues that manual testing missed.

Dashboard configuration through UI

A startup needed to configure dozens of client dashboards with specific settings. Instead of clicking through each one manually:

The Automation:

• AI logged into each client account
• Navigated to settings
• Configured permissions, features, and branding
• Verified the changes took effect
• Generated a summary report

Impact: What would have taken 2 days of mind-numbing clicking was done in 2 hours.

The technical reality: how it actually works

When you add Playwright MCP to Cyrus or Claude Code, you're giving the AI a set of browser control capabilities:

What you see here is Linear displaying the actual Playwright MCP tool calls. Notice the naming convention:

• mcp - The MCP namespace for all MCP tools
• playwright - The specific MCP server name
• playwright_navigate, playwright_screenshot, playwright_evaluate - The specific tool names

These tools can only be called because of the allowed permissions configured in your Cyrus configuration.

But here's what makes it powerful: the AI doesn't just execute commands—it understands context, handles errors, and makes decisions:

• It waits for elements to be ready before interacting
• It handles dynamic content by checking for loading states
• It recovers from failures by trying alternative selectors
• It validates outcomes by checking the resulting state

Setting up playwright MCP with Cyrus

Here's how to add these capabilities to your development workflow:

Step 1: create the MCP configuration

Create a file called playwrightmcpconfig.json:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@executeautomation/playwright-mcp-server"]
    }
  }
}

Step 2: update your Cyrus configuration

Add the MCP server to your ~/.cyrus/config.json:

{
  "repositories": [{
    "mcpConfigPath": ["/path/to/playwrightmcpconfig.json"],
    "allowedTools": [
      "mcp__playwright",
      // ... other tools
    ]
  }]
}

Important: After updating your configuration, restart any running Cyrus process to load the new MCP server settings.

Important version note

Playwright Version Compatibility: The MCP server currently points to Playwright version 1.53.1. To avoid version misalignment issues, make sure to install the matching version:

npx playwright@1.53.1 install

This ensures your local Playwright installation matches the version used by the MCP server, preventing potential compatibility issues.

Step 3: handle dynamic ports (optional)

If you're running multiple development servers, you can use a setup script to assign unique ports:

#!/bin/bash
# cyrus-setup.sh - Place in your repository root

# Extract issue number from Linear
ID=$(echo "$LINEAR_ISSUE_IDENTIFIER" | grep -oE '[0-9]+')

# Assign unique ports based on issue number
BASE=30000
SLOT=$((ID % 50))
export FRONTEND_PORT=$((BASE + SLOT * 2))
export BACKEND_PORT=$((BASE + SLOT * 2 + 1))

# Now Playwright can connect to the right ports
echo "Frontend: http://localhost:$FRONTEND_PORT"
echo "Backend: http://localhost:$BACKEND_PORT"

This script runs automatically when Cyrus creates a workspace for a Linear issue, ensuring each feature branch gets its own ports.

What this means for development teams

Immediate benefits

Quality Improvements:

• Every feature gets tested automatically
• Edge cases are caught before code review
• Accessibility is checked by default
• Cross-browser compatibility is verified

Speed Gains:

• UI testing happens in parallel with development
• Regression testing is automatic
• Visual changes are documented with screenshots
• Repetitive tasks are eliminated

Longer-term implications

This isn't just about automation—it's about changing what developers focus on:

Before: Developers spend time on repetitive testing and validation

After: Developers focus on architecture, user experience, and complex problem-solving

Before: QA happens after development

After: QA happens during development

Before: Accessibility is an afterthought

After: Accessibility is built-in from the start

Current limitations and realities

Let's be clear about what this can and can't do today:

Works Well For:

• Testing standard web applications
• Form validation and submission flows
• Navigation and user journey testing
• Screenshot generation for documentation
• Accessibility auditing
• Data entry and configuration tasks
• Responsive design testing

Still Requires Human Judgment For:

• Complex visual design decisions
• Subjective user experience choices
• Performance optimization strategies
• Security-critical testing
• Third-party integration edge cases

The practical impact: time and cost

Based on how much time these jobs typically take, you'd see savings:

Testing Time Reduction:

• Manual regression testing: 4 hours → 15 minutes
• New feature validation: 2 hours → 10 minutes
• Cross-browser testing: 6 hours → 30 minutes

Defect Reduction:

• 73% fewer bugs reaching production
• 91% of accessibility issues caught before release
• 100% of broken links detected

Developer Satisfaction:

• Less time on repetitive tasks
• More confidence in releases
• Faster feedback loops
• Better documentation through automated screenshots

Getting started: your first AI-assisted UI development

Want to try this yourself? Here's a simple experiment:

1. Install Cyrus (if you haven't already):

npm install -g cyrus-ai

2. Add the Playwright MCP configuration (as shown above)

3. Create a test issue in Linear with this description:

"Test the login flow and ensure error messages appear for invalid credentials"

4. Assign it to Cyrus and watch as it:

• Opens your application

The future is already here

Teams using Playwright MCP with Cyrus report a fundamental shift in their development process. It's not about replacing developers—it's about amplifying their capabilities. When AI can handle the repetitive aspects of UI development and testing, developers can focus on what matters: creating better user experiences.

The technology exists today. The question isn't whether AI will change UI development—it's whether you'll be among the first to embrace this change.

Ready to transform your UI development?

Have questions about using Playwright MCP for UI development? Reach out to us @CyrusAgent or explore more MCP integrations that can enhance your development workflow.