MCP tool reference

Parameters

Use it when

• First call of almost any session, because nothing else works without a project id.
• Confirming which project a request refers to when the user says "the checkout tests" and there are three projects.

Parameters

Use it when

• Finding the folder id needed to create a test.
• Understanding how a team organizes its library before adding to it.
• Deciding where a new test belongs, rather than dropping it in the first folder found.

Parameters

Use it when

• Setting up structure for a new feature area before writing its tests.
• Splitting a folder that has grown past the point of being navigable.

Parameters

Use it when

• Checking what conventions already exist before inventing a new tag.
• Finding the right tag name to scope a run to.
• Spotting tags with a count of one, usually a typo of a real tag.

Parameters

Use it when

• Introducing a genuinely new category, after checking list_tags for something equivalent.

Parameters

Use it when

• Finding a test by title before reading it in full.
• Surveying what is automated and what is not across an area.
• Locating an archived test so it can be restored.

Parameters

Use it when

• Reading the written steps before writing automation for them.
• Inspecting an existing automation plan before changing it.
• Checking which reusable preconditions are attached, and in what order.

Parameters

Use it when

• Turning a requirement or a bug report into a written test.
• Creating a test and its automation together, in one call.
• Bulk-creating a set of cases for a new feature.

Parameters

Use it when

• Attaching automation to a test that was written manually.
• Marking a test Broken after the UI changed under it.
• Adding tags in bulk when a new suite is defined.
• Moving a test to the folder it should have been in.

Parameters

Use it when

• Before writing any automation plan. It is the difference between knowing a command exists and knowing what to put in it.
• After a rejected save, to see what the command actually accepts instead of guessing again.

Parameters

Use it when

• Immediately after writing automation. This is the single most valuable tool for an agent, because it turns "looks right" into a checkable result.
• Auditing an existing suite to find the tests worth fixing first.
• Confirming a fix actually improved things rather than moving the problem.

Parameters

Use it when

• Retiring a test for a feature that no longer exists.
• Removing a duplicate, once you have confirmed which one to keep.

Parameters

Use it when

• Undoing an archive.
• Recovering a test after a folder was deleted. Find it first with list_tests and includeArchived: true.

Parameters

Use it when

• Checking whether a login block already exists before writing another one.
• Seeing the blast radius of a change before making it.
• Finding unused blocks worth deleting.

Parameters

Use it when

• Reading a block's steps before modifying them.
• Understanding what a precondition actually does when debugging a failing test.

Parameters

Use it when

• Extracting a sequence that has been copied into several tests.
• Defining login once, at the start of automating a project.

Parameters

Use it when

• Fixing every test at once after a login form changed.
• Making a block more robust, replacing a CSS selector with a role-and-name locator.

Parameters

Use it when

• Removing a block nothing uses any more.

Parameters

Use it when

• Giving a new test the standard login setup.
• Replacing steps that were inlined into a test with the shared block, usually right after analyze_test_quality flags the duplication.

Parameters

Use it when

• A test that no longer needs that setup.
• Clearing links before deleting a block.

Parameters

Use it when

• Fixing setup that runs in the wrong order: selecting an account before logging in, for instance.
• Putting a newly attached precondition in the right place instead of last.

Parameters

Use it when

• Reporting how tests will run, without guessing.
• Deciding whether to override the browser for one execution.

Parameters

Takes no parameters.

Use it when

• Getting the environmentId that every execution tool requires.
• Confirming which target the user means before running anything against it.

Parameters

Takes no parameters.

Use it when

• Discovering what is available to reference as {{orgVar.KEY}} before writing automation.
• Checking a base URL is defined before writing a test that depends on it.

Parameters

Use it when

• Finding what to reference as {{projectVar.KEY}}.
• Understanding which values are project-specific rather than shared.

Parameters

Use it when

• Checking what a test defines for itself as {{testVar.KEY}}.
• Diagnosing a test that fails only in one environment.

Parameters

Use it when

• Confirming a test will get the values it expects before running it.
• Working out why the same test passes against staging and fails against production. Usually it is a variable defined for one environment and not the other.

Parameters

Use it when

• Finding the run a user is referring to.
• Checking whether an open run already exists before creating another.
• Summarising recent testing activity.

Parameters

Use it when

• Reading what failed and why, in order to act on it.
• Watching results land while a runner executes.
• Producing a report from a completed run.

Parameters

Use it when

• Building a smoke run from a tag before a release.
• Creating a targeted run for the area a change touched.
• Setting up a run to hand straight to a runner.

Parameters

Use it when

• Recording the outcome of a test executed outside SmarTTest.
• Marking a test skipped, with the reason it was out of scope.
• Correcting a result after investigating a failure.

Parameters

Use it when

• Finishing a run once every test has a result.
• Closing a run so it starts counting toward the Health Dashboard.

Parameters

Use it when

• Getting the runnerId for run_on_runner.
• Checking one is online before queueing work, so the user is not left waiting on a stopped machine.

Parameters

Use it when

• The only way to execute tests from the remote connector.
• Running a full regression suite on a dedicated machine instead of your laptop.
• Re-running just the failures after a fix.

Parameters

Use it when

• Polling until execution finishes.
• Distinguishing "the runner never picked this up" from "the tests are failing". The job carries its own error separate from the results.

Parameters

Use it when

• Before asking anyone to execute a run. A locator that matches four elements fails the whole test, and this finds that out in one step instead of one execution.
• When a test fails and you cannot tell whether the element moved or the page did. The reply includes the final URL and title, which is how a redirect gives itself away.

Parameters

Use it when

• The develop-run-develop loop: write automation, run it, see the failure, fix it, without polluting any run with attempts.
• Reproducing a failure locally with a visible browser to see what is happening.
• Recording a real result, by passing runId.

Parameters

Use it when

• Polling a long execution.
• Reading which step failed, and the error it produced.

Parameters

Use it when

• Executing a whole suite locally, without setting up a runner.
• Re-running the failures from an earlier pass on your own machine.

Parameters

Use it when

• Polling until the suite finishes.
• Reporting progress while a long run is in flight.