operative.sh Web Eval Agent MCP Server
Author: refreshdotdev
Description: An MCP server that autonomously evaluates and debugs web applications by driving a browser agent, capturing screenshots, console logs, and filtered network traffic, then returning a UX/debug report to your IDE (e.g., Cursor). Requires an Operative API key. NOTE: README indicates the project has been sunset/discontinued and the team is building something new at https://withrefresh.com.
Stars: 1.2k
Forks: 104
License: Apache License 2.0
Category: Enterprise
Overview
Installation
3. Restart your IDE to apply the changes.
4. In IDE chat, call the tool, e.g.:```bash
Test my app on http://localhost:3000. Use web-eval-agent.3. Source environment variables after installing uv:Mac:```bash
source ~/.zshrc4. Install Playwright:```bash
npm install -g chromium playwright && uvx --with playwright playwright install --with-depsweb_eval_agent
Automated UX evaluator that drives the browser to test a web app, captures screenshots plus console and network logs, and returns a rich UX report.
setup_browser_state
Opens an interactive (non-headless) browser session so you can sign in once; saves cookies/local-storage for reuse by subsequent web_eval_agent runs.
FAQs
How do I migrate from operative.sh Web Eval Agent to Browser-Use MCP or Playwright MCP?
Migration requires updating your MCP client configuration to point to the new server, then adjusting agent prompts based on architecture differences. For Browser-Use MCP, install via Docker and preserve the autonomous task-description pattern. For Playwright MCP, rewrite prompts into sequential navigation and assertion commands since it requires explicit step-by-step instructions rather than autonomous control.
How does Browser-Use MCP handle authenticated web app testing compared to operative.sh's setup_browser_state tool?
Browser-Use MCP persists authentication through container state preservation, maintaining session data across runs within the same Docker environment. Unlike operative.sh's dedicated setup_browser_state tool that explicitly separated one-time authentication from headless evaluation runs, Browser-Use MCP handles session persistence implicitly through its containerized architecture, requiring developers to manage authentication within the container lifecycle rather than through a specialized pre-authentication workflow.
Can Browser-Use MCP run in Docker, and how does its containerized setup compare to operative.sh's architecture?
Yes, Browser-Use MCP runs in Docker containers. The containerized architecture isolates browser dependencies and state management, whereas operative.sh ran locally with persistent storage for cookies and localStorage. Browser-Use MCP's Docker approach trades setup simplicity for stronger isolation and reproducibility across different development environments.
Can I use an MCP server with multiple AI assistants simultaneously?
Yes, MCP servers support multiple AI assistants simultaneously through standardized connections. Each assistant connects independently to the server, accessing shared tools and resources via the Model Context Protocol's client-server architecture. Enterprise deployments use centralized MCP instances with caching layers like Redis to handle concurrent requests, authentication controls to manage access, and Docker for stateless scaling across multiple assistant connections.
How does MCP improve the efficiency of AI systems?
MCP improves AI efficiency by enabling modular extensibility: new capabilities like browser automation or database access plug in through standardized servers without rebuilding the AI application, letting teams scale workflows from prototyping to production while maintaining consistent context quality across evolving toolsets and reducing technical debt from fragmented custom integrations.
What are the risks of using third-party MCP servers, and how can they be mitigated?
Third-party MCP servers expose systems to remote code execution, command injection, and credential theft because they connect AI to external tools with elevated privileges. Mitigate risks by enforcing per-client consent, sandboxing server execution, sanitizing all inputs, and cryptographically verifying server identity before deployment. Apply least-privilege access, maintain a verified tool registry, and continuously scan for shadow servers and chaining attacks.