Inspect coverage, trigger a Run, wait for completion, retrieve External Evidence, and rerun after a fix.

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 for Test Cases, Test Plans, Runs, Environments, and External Evidence, while Autonomy still owns browser, API, and mobile execution.

1. Inspect coverage first

Ask the agent to look for existing Test Cases, Test Plans, and recent Runs before it creates or triggers anything.

Coverage prompttext

Use Autonomy MCP before editing code.
List relevant Test Cases and Test Plans, then list the most recent Runs.
Tell me whether this change already has fresh QA evidence and which existing coverage should be reused.

The expected tool path starts with autonomy_test_case_list, autonomy_test_plan_list, and autonomy_run_list. The agent can use autonomy_test_case_get or autonomy_test_plan_get to inspect the best match.

2. Create missing coverage

If no Test Case covers the change, have the agent create one from explicit steps. A Test Plan is only needed when several Test Cases should be selected and run together.

Test Case prompttext

Create one focused Autonomy Test Case for the acceptance criteria below.
Write explicit steps and assertions. Reuse an Environment value for credentials or deployment-specific inputs instead of embedding a secret.

Acceptance criteria:
- <paste criteria here>

This uses autonomy_test_case_create and requires the autonomy:test_cases:write OAuth scope. Creating a Test Plan uses autonomy_test_plan_create and autonomy:test_plans:write.

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.

Preview Run prompttext

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

Use branch feature/checkout-copy and PR 128. Return the Run id, then wait for it to finish.

Call autonomy_run_trigger with exactly one of testCaseId or testPlanId. 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. Wait for completion

Call autonomy_run_get with the returned runId. Save its cursor; when next is wait, call the tool again with that cursor and waitMs: 25000. A response with timedOut: true only means nothing changed during that wait, so it is safe to repeat with the same cursor.

Wait prompttext

Use autonomy_run_get to wait for this Run.
Reuse each returned cursor with waitMs 25000 until the Run finishes. A timeout is not a failure.

5. Diagnose with External Evidence

When a Run fails, make the agent call autonomy_run_evidence before it proposes a product fix.

Failure diagnosis prompttext

Fetch the failed Autonomy Run and its External Evidence.
Cite the failing step, observed and expected outcomes, diagnosis, and a fresh media link.
Do not propose a code change until the evidence supports the conclusion.

External Evidence contains customer-meaningful outcomes and short-lived media links. It deliberately excludes model, prompt, token, cost, runner, and raw UI-tree internals.

6. Fix and rerun

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

Rerun prompttext

Rerun the same Autonomy Test Case against the same preview target.
Wait for completion, compare the new External Evidence 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 state and evidence. That separation keeps execution evidence-backed and organization-scoped.

First MCP Run