MCP and your testing suite

How the pieces fit

1. Tests run — Playwright, Appium, or Maestro executes in CI or on your machine.
2. SDK reporter — Sends structured run data to the TestRelic cloud (when configured). See the Playwright, Appium, and Maestro installation guides once the SDK section migrates.
3. Cloud — Stores runs, sessions, journeys, and org integrations. See the Cloud Platform quickstart once it migrates.
4. MCP — Runs inside your AI-capable editor or MCP client. It reads from the same cloud (with your MCP token) so the assistant can list runs, analyze gaps, suggest tests, or propose heals while you work on the repo.

The MCP does not replace your test runner or reporter. It is the bridge between TestRelic cloud data and your assistant.

Typical workflows

• After a red CI run — Use triage/healing tools to pull diagnostics and patch hints into the thread instead of copying logs.
• Before a large change — Use impact tools to rank tests from a diff against user-impacting journeys.
• Coverage planning — Use coverage tools to list top journeys missing tests, then creation tools to draft a plan or code.

Mock mode in the suite

Use --mock-mode when you want teammates or CI to verify the MCP binary and config without touching production data. It uses local fixtures instead of the cloud.

CI note

Most teams run the MCP in the IDE on developer machines. Running an MCP server in shared CI is possible (HTTP transport or programmatic startup) but is an advanced setup; start with local IDE wiring, then extend if your organization needs it.

Related docs

• Playwright E2E example (SDK section, migrating in a later phase)
• GitHub Actions integration
• Ask AI