First MCP run

Use this workflow when a coding assistant is about to change product code, review a pull request or check a preview deployment. The assistant uses Autonomy MCP to write and run test cases; the agent reaches each outcome on Autonomy's runners and records the evidence.

1. Find the project

Everything lives in a project, so start there.

Use Autonomy MCP to list my projects and pick the one for this repository.
Then list its test cases, test plans, environments and the five most recent runs.
Tell me whether this change already has a recent run and which test cases cover it.

The assistant calls autonomy_project_list first, then autonomy_test_case_list, autonomy_test_plan_list, autonomy_environment_list and autonomy_run_list with that projectId. It can open the best match with autonomy_test_case_get.

2. Write a test case with outcome steps

If nothing covers the change, have the assistant write a test case. Each step is an outcome a person could check, not a list of clicks. Attachments give the agent what it needs: a fresh inbox, a generated password, a saved sign-in, or a value it must use as written (Exact).

Create one Autonomy test case in this project for the acceptance criteria below.
Write each step as an outcome in plain words, not as clicks.
Attach a fresh inbox for any email, a data attachment with an intent for any password the agent should choose,
and an account attachment for any saved sign-in. Mark a value Exact only if the product must accept that exact value.
Use {{env.NAME}} for values that differ between environments. Never put a password in the step text.

Acceptance criteria:
- <paste criteria here>

The assistant calls autonomy_test_case_create with the projectId, a name, the platforms and the steps. It needs the "Create and edit test cases" permission. A step it writes looks like this:

1{2  "id": "sign-up",3  "text": "A new grower account exists for a fresh email address",4  "attachments": [5    {6      "id": "inbox",7      "kind": "inbox",8      "exact": false9    },10    {11      "id": "password",12      "kind": "data",13      "label": "Password",14      "intent": "A strong password",15      "exact": false16    }17  ]18}

See Outcome steps for every attachment, and Authoring for how to write good outcomes.

3. Start the run

Use a saved environment when the target is already set up in Autonomy. Use explicit targets for a fresh preview URL, API base URL or mobile build.

Run the new test case against this preview URL:
https://preview.example.com

Use branch feature/sign-up-copy and PR 128, with your own idempotencyKey. Return the run id, then follow the run.

The assistant calls autonomy_run_trigger with the testCaseId and either an environmentSlug or targets (for web, targets.web.baseUrl). It needs the "Start runs" permission.

4. Follow the run

The assistant calls autonomy_run_get with the runId and saves the cursor. While next is wait, it calls again with that cursor and waitMs: 25000. A response with timedOut: true only means nothing changed, so it calls again.

Use autonomy_run_get to follow this run until it ends.
Reuse each returned cursor with waitMs 25000. A timeout isn't an error.
While it runs, tell me which step it's on.

5. Read the Step Actions and the evidence

When the run ends, the assistant reads what the agent did and what it saw:

For this Autonomy run, call autonomy_run_step_actions and autonomy_run_evidence.
For each step, give its result, the explanation, whether the Final check agrees, and a media link.
If the run failed, tell me why each failed step failed, and whether its outcome wasn't reached or couldn't be shown.
Don't propose a code change until the evidence supports it.

• autonomy_run_step_actions lists every action the agent took for each step, including the Final check.
• autonomy_run_evidence gives each step's outcome, result, explanation, Final check and media links. Links expire after 15 minutes.

A run ends Passed, Failed, Couldn't start or Cancelled. A failed step's explanation says why: read it before deciding the app is broken.

6. Check the issues

Issues are problems the run noticed along the way, such as a console error, kept apart from the result. A passing run can still report one.

List the Autonomy issues for this run with autonomy_issue_list and its runId.
Summarize each one: Bug or Risk, what was expected and what happened.

The assistant can file one with autonomy_issue_create and mark one resolved with autonomy_issue_set_status after a run shows the fix. Both need the "File and update issues" permission.

7. Fix and rerun

After the code change, run the same test case against the same target and compare.

Rerun the same Autonomy test case against the same preview target.
Follow it to the end, compare its evidence with the earlier run, and tell me whether the fix is confirmed.

What this is not

MCP doesn't turn the coding assistant into a browser driver. The assistant asks Autonomy to run a test case, then reads the results and evidence. The agent does the testing, and every action it takes is shown as a Step Action.