First MCP Run

Use this workflow when an IDE agent is about to change product code, review a pull request, or validate a preview deployment. Autonomy MCP gives the agent a QA control plane: it can ask for plans, runs, environments, traces, and evidence, while Autonomy still owns the browser, API, and mobile execution.

1. Inspect coverage first

Ask the agent to look for existing plans and recent runs before it generates anything new.

Use Autonomy MCP before editing code.
List relevant test plans for this project, then list the most recent runs.
Tell me whether this change already has fresh QA evidence and which plan should be reused.

The expected tool path is autonomy_list_test_plans, then autonomy_list_runs, and usually autonomy_get_test_plan for the plan the agent wants to reuse.

2. Generate missing coverage

If no plan covers the change, have the agent generate one from the PR summary, acceptance criteria, or ticket text.

Generate an Autonomy test plan for this change.
Use the acceptance criteria below, keep the plan focused on one user journey, and include web plus API checks if the UI state depends on backend state.

Acceptance criteria:
- <paste criteria here>

This uses autonomy_generate_test_plan and requires the autonomy:plans:write OAuth scope.

3. Trigger the run

Prefer a saved environment when the target is already configured in Autonomy. Use explicit targets when the agent or CI job has a fresh preview URL, API base URL, or mobile artifact.

Trigger the checkout smoke plan against this preview URL:
https://preview.example.com

Use branch feature/checkout-copy and PR 128. When the run is queued, return the run id and what evidence I should expect.

For web, pass targets.web.baseUrl. For API, pass targets.api.baseUrl. For mobile, pass a saved environmentSlug or explicit targets.ios / targets.android with artifactUrl or a scanned storageId.

4. Diagnose with evidence

When a run fails, make the agent fetch the run and traces before it proposes a product fix.

Fetch the failed Autonomy run and its traces.
Summarize the likely root cause with evidence links or trace ids.
Do not propose a code change until you cite the failing step and observed behavior.

The expected tool path is autonomy_get_run, then autonomy_get_run_traces. Good answers cite the failing step, trace detail, screenshot or evidence link, and the smallest code area likely responsible.

5. Fix and rerun

After the code change, rerun the same plan against the same target. Keep the rerun scoped unless the failure suggests a broader regression.

Rerun the same Autonomy plan against the same preview target.
Compare the new result with the failed run and tell me whether the fix is verified.

What this is not

MCP is not a local browser automation package and it does not turn the IDE agent into Playwright. The agent asks Autonomy to run QA, then reads structured results and evidence. That separation is intentional: it keeps execution deterministic, evidence-backed, and organization-scoped.