Returns a short orientation for the TestMu AI Test Manager MCP server: what it wraps (Test Manager, HyperExecute, AI Insights/RCA) and a handful of rules that apply across many tools (mutating actions are real and persistent, RCA generation costs credits, manual vs. KaneAI incompatibility, ID types are not interchangeable). Useful to call first if unfamiliar with this server. Does not enumerate individual tools - see the tool catalog itself for that.

Retrieves a single LambdaTest Test Manager project's details by its exact project ID: name, description, test case count, tags, and created/updated timestamps. Use this when the project ID is already known - for example, to verify a project exists before creating test cases in it, or to show project metadata to the user. Do not use this to search for a project by name or to list all projects.

Creates a new LambdaTest Test Manager project with a name, an optional description, and any number of tags (zero or more). Use this when the user wants to start a new project to organize test cases in. Do not use this to update an existing project, and do not call it speculatively - creating a project is a real, persistent action.

Retrieves every folder in a LambdaTest Test Manager project, given the project's ID: each folder's name, ID, description, parent folder, created/updated timestamps, and test case counts (both direct and including subfolders). Use this to see how a project's test cases are organized, to find a folder's ID before adding test cases to it, or to spot folders whose direct and total test case counts differ (meaning subfolders hold more test cases than tm.get_testCasesByFolderId alone would show for that folder). Do not use this to fetch a single folder's details.

Creates a new folder inside a LambdaTest Test Manager project, to organize test cases. Requires the project's ID; optionally nest it under an existing folder by passing that folder's ID as parent_id, otherwise it's created at the project's root. Use this before adding test cases that need a home. Do not use this to update or move an existing folder, and do not call it speculatively - creating a folder is a real, persistent action.

Retrieves the test cases assigned DIRECTLY to a specific folder of a LambdaTest Test Manager project - it does not include test cases in that folder's subfolders. Each result has the test case's title, ID, description, priority, type, status, automation status, preconditions, estimated time, and tags. Requires both the project ID and the folder ID (use tm.get_foldersByProjectId first to find a folder's ID - it also shows each folder's direct vs. total test case count, so you can tell if subfolders hold more). Supports optional page, per_page, and sort parameters for folders with many test cases. Do not use this to fetch a single test case by its own ID, and do not expect it to include subfolder contents.

Retrieves every test case across an entire LambdaTest Test Manager project, regardless of which folder it's in: each test case's title, ID, folder ID, description, priority, type, status, automation status, estimated time, BDD scenarios, test steps, and tags. Use this for a project-wide view; use tm.get_foldersByProjectId + tm.get_testCasesByFolderId instead if you only need the test cases inside one specific folder. Supports optional page, per_page, and sort parameters for projects with many test cases.

Creates one or more test cases in a LambdaTest Test Manager project, in a single batch call. Each test case has a title (required), an optional description, optional preconditions, and any number of tags (zero or more). Requires the project ID; folder_id is optional - pass it (use tm.get_foldersByProjectId to find a folder's ID) to place the test cases in a specific folder, or omit it to let the API place them in the project's default 'Untitled' root folder. Use this when the user wants to add new test cases to a project. Do not use this to update an existing test case, and do not call it speculatively - creating test cases is a real, persistent action.

Retrieves the full details of a single LambdaTest Test Manager test case by its exact test case ID: title, description, priority, status, preconditions, tags, attachments (both the test case's own and each step's own, shown with their file_key for reuse with tm.update_testCase), test steps, BDD scenarios, dynamic fields, Jira links, folder path, and its current snapshot_id. Use this when the test case ID is already known, to inspect its full content, or as a required first step before updating it with tm.update_testCase - that endpoint requires the snapshot_id returned here, fetched fresh (not cached) immediately before the update. Do not use this to search or list test cases.

Updates a LambdaTest Test Manager test case's metadata (title, description, priority, status, automation_status, preconditions, external_id, tags, attachments) and/or appends new steps to it. Only the fields you provide are changed - everything else is left as-is. attachments (if provided) REPLACES the test case's whole attachment list - use tm.upload_attachment first to get a file_key, then pass one or more file_keys here; if omitted, existing attachments are left untouched. new_steps can each optionally carry their own attachments (same file_key values) for a fresh step. Only ADDING new steps is supported (appended after existing ones); this tool cannot modify or delete existing steps (including their attachments), edit BDD scenarios, or edit dynamic fields. Internally fetches the test case's current snapshot_id right before updating, as required by the API. Requires at least one field or new_steps entry to actually change. Do not call this speculatively - updating a test case is a real, persistent action.

Retrieves the execution history of a LambdaTest Test Manager test case by its exact test case ID: every recorded run's status (passed/failed/skipped/etc.), the test run it belonged to, start/end time, framework, test type (automation/manual), browser/OS/device environment, and automation test ID, plus overall executed/planned execution counts. Use this to inspect how a test case has performed over time. AUTOMATION TEST ID / RCA: for automation/KaneAI executions, automation_test_id is the ID LambdaTest's other services key off - a Test URL is shown (constructed from the same https://automation.lambdatest.com/test?testID={id} pattern this API itself uses elsewhere, since this endpoint does not return a URL field directly) and the same ID can be passed to LambdaTest's AI root-cause-analysis endpoint (https://api.lambdatest.com/insights/api/v3/rca/{automation_test_id}) for a failure's root cause, steps to fix, and error timeline. planned_executions_count is NOT scoped to any single test run - it aggregates across every run/schedule that has ever referenced this test case - so a gap versus executed_executions_count does not indicate anything about a specific run's own instances. Read-only; does not modify anything.

Retrieves the execution history of every LambdaTest Test Manager test case linked to a given Jira issue ID (e.g. 'PROJ-123'): each recorded run's status, which test case and test run it belongs to, start/end time, framework, test type (automation/manual), browser/OS/device environment, and automation test ID, plus overall executed/planned execution counts. Use this to see how all test cases tied to a Jira ticket have performed. If the Jira ID has no linked executions, returns an empty history rather than an error. Read-only; does not modify anything.

Links a Jira issue (e.g. 'PROJ-123') to a LambdaTest Test Manager test case, so the issue shows up in the test case's Jira links and the test case's runs appear in tm.get_testExecutionHistoryByJiraId for that issue. Requires the project ID and test case ID. The Jira issue must belong to the LambdaTest account/org configured via LT_ORG_ID in this server's config. Do not call this speculatively - linking is a real, persistent action.

Removes the link between a Jira issue (e.g. 'PROJ-123') and a LambdaTest Test Manager test case, reversing tm.link_jiraIssue. Requires the project ID, test case ID, and the Jira issue key. Unlike tm.link_jiraIssue, the issue key is passed as-is - no org_id prefix is needed here. Fails if the issue isn't actually linked to that test case. Do not call this speculatively - unlinking is a real, persistent action.

Retrieves a LambdaTest Test Manager test run by its exact ID: title, objective, status, type (Manual/Automation), build state, tags, and every test case included in the run along with the environment(s) (browser/OS/device/resolution) each one is set to run against. Note: this does not include per-execution pass/fail results - the status shown per test case is its own review status, not an execution outcome; use tm.get_testExecutionHistoryByTestCaseId for actual run history. TERMINOLOGY: a 'test case instance' is ONE (test case x environment) pairing, not one test case. If a single test case is assigned 2 environments in this run, that is 2 instances, not 1 - the count of unique test cases in a run is virtually always smaller than the instance count. KNOWN API QUIRK (already corrected in this tool's output, for awareness only): the LambdaTest API's own total_test_cases/total_environments/total_run_instances fields on this endpoint are ALL THE SAME underlying number (the instance count) despite their distinct-sounding names. This tool does NOT trust those fields - the 'Test Cases (distinct)' and 'Environments (distinct)' figures shown below are computed directly from the instance list instead, so they ARE genuinely correct. tm.get_testRunsByProjectId independently reports correct distinct figures too (via different, non-quirky fields), so the two tools' numbers should agree for the same run - if they ever don't, that's worth flagging as a bug, not expected behavior. Read-only; does not modify anything.

Retrieves the actual execution results for a LambdaTest Test Manager test run: a run-wide pass/failed/skipped/not-started breakdown, plus one entry per test case instance with its real execution status, assignee, remarks, and linked bug count. TERMINOLOGY: each entry is ONE (test case x environment) pairing, not one unique test case - a test case assigned 2 environments in this run produces 2 separate entries here, each with its own independent result. Unlike tm.get_testRunById (which shows planned composition only), this shows what actually happened. For automation/KaneAI instances, also surfaces the automation test's own ID (distinct from test_case_id and from this entry's own instance ID) and a direct link to that execution on the LambdaTest automation dashboard - the automation test ID is the key other LambdaTest services (e.g. AI root-cause-analysis, execution logs, video) use to look up that specific execution, not test_case_id or the instance ID. Supports pagination (page, per_page) and filtering by status ('Not Started', 'Passed', 'Failed', 'Skipped') and/or assignee (user ID). Read-only; does not modify anything.

Sets the overall status of a LambdaTest Test Manager test run to one of 'Skipped', 'In Progress', 'Failed', or 'Passed'. This is undocumented (sourced from the browser network inspector, not the official API docs), so treat it as best-effort. This changes the run's own status field - it does not touch per-instance execution results. Do not call this speculatively - it's a real, persistent action.

Retrieves full detail for ONE specific test case instance, identified by its own numeric test_instance_id (NOT the same as test_case_id - get it from tm.get_testCaseInstancesByTestRunId's 'Instance ID' field). TERMINOLOGY: a 'test case instance' is ONE (test case x environment) pairing within a run, not one test case - if a test case is assigned 2 environments in the same run, each environment has its own separate instance ID and its own separate result here. Includes the instance's own result (Passed/Failed/Skipped/Not Started), timing, remarks, environment, and per-step results (each step's own status/outcome/remarks, plus its own Step ID for use with tm.update_testCaseInstanceStep) - detail that tm.get_testCaseInstancesByTestRunId doesn't expose. Setting/inspecting this instance's result only affects its standing within this run - it does NOT change the underlying test case's own stored status in Test Manager. Read-only; does not modify anything.

Retrieves every test run in a LambdaTest Test Manager project: title, folder ID, status, type, build state, objective, tags, distinct test case/environment counts, total test case instances, percent complete, and a pass/failed/skipped/etc. breakdown. KANEAI RUNS: a run's top-level type field is ALWAYS 'Manual' regardless of whether it's a real manual run or a KaneAI-generated one - it does not distinguish them, despite the name. The actual signal is 'KaneAI-Generated' (the API's is_auteur_generated field) - true for a run KaneAI itself created. Manual and KaneAI test runs are not interchangeable (a manual test case cannot correctly run inside a KaneAI run and vice versa) regardless of the separate 'Editable'/schedule fields - use 'KaneAI-Generated' before calling tm.add_testCasesToTestRun, which refuses to modify any KaneAI-generated run. 'Editable: No' and a schedule name instead indicate the run's composition is currently owned/regenerated by an active KaneAI schedule - a related but separate concern from manual/KaneAI compatibility (a one-off, unscheduled KaneAI run can be 'Editable: Yes' and still be a KaneAI run). FOLDERS: test runs can be organized into their own folders/subfolders, entirely separate from the folder tree used for test cases (tm.get_foldersByProjectId) - a test run's folder and the folders its individual test cases live in are unrelated concepts and do not share IDs. This is currently the only tool that reliably reports a test run's OWN folder_id - tm.get_testRunById and tm.get_testCaseInstancesByTestRunId both return an empty folder_id for the same run. There is no known endpoint to browse/resolve the test-run folder tree itself (name, parent, path) - only this raw folder_id value is available so far. TERMINOLOGY: a 'test case instance' is ONE (test case x environment) pairing, not one test case - e.g. 1 test case assigned 2 environments contributes 2 to 'Total Test Case Instances' but only 1 to 'Test Cases'. 'Test Cases' and 'Environments (distinct)' below ARE correctly distinct counts on this endpoint (unlike tm.get_testRunById, where the API's equivalently-named raw fields are all just duplicates of the instance count - that tool works around it by computing its own distinct counts, so both tools' numbers should agree for the same run). Supports pagination (page, per_page) and filtering by status (e.g. 'Not Started', 'In Progress', 'Passed', 'Failed', 'Skipped'), build_state ('active' or 'archived'), and/or folder_id (the test run's OWN folder - see the Folder ID note above; this is NOT the folder_id of any test case inside the run). Use tm.get_testRunById or tm.get_testCaseInstancesByTestRunId for full detail on a specific run. Read-only; does not modify anything.

Creates just the SHELL of a new LambdaTest Test Manager test run in a project: a title (required), an optional objective, any number of tags (zero or more), and an optional folder_id to place it inside a test-run folder (from tm.get_testRunFoldersByProjectId - this is the test-run folder tree, separate from test case folders) instead of the project root. This always creates the run with ZERO test cases - test cases and their environment assignments are added to the run afterward via a separate PUT request, not this tool. DANGER: an invalid/nonexistent folder_id causes an unhandled server error (HTTP 500) rather than a clean validation error - no run is created in that case (safe to retry), but only pass a folder_id read from tm.get_testRunFoldersByProjectId. Use tm.get_testRunById afterward to confirm the run was created. Do not call this speculatively - creating a test run is a real, persistent action. KANEAI RUNS: set is_auteur_generated: true to create a one-off KaneAI-type run instead of a plain manual run. This only creates the KaneAI-type run shell - it does NOT create or link a KaneAI schedule (schedules are managed by KaneAI itself, not this API). Manual and KaneAI test cases are not interchangeable: once created, only add test cases whose own is_auteur_generated matches this run's, via tm.add_testCasesToTestRun.

Adds one or more test cases (each optionally with an environment_id, assignee user ID - see tm.get_organizationUsers to look one up - and priority) to an existing LambdaTest Test Manager test run, WITHOUT removing test cases already in the run. If a test case is already in the run with the same environment_id, this UPDATES its assignee/priority instead of adding a duplicate - so it's also how you reassign or reprioritize an existing test case instance, not just add new ones. Internally fetches the run's current test cases first and PUTs the complete merged list back, since the underlying API replaces the run's entire test case list on every update - calling this repeatedly is safe. A test case can be present multiple times with different environment_id values to run it against multiple environments. environment_id/assignee/priority are all optional per test case - omitting environment_id defaults to a placeholder 'No config selected' environment. Get a valid environment_id from tm.get_environments (or read one off an existing test-run instance via tm.get_testRunById). DANGER: only ever pass an environment_id from one of those two sources - a nonexistent environment_id does NOT return an error, it corrupts the run so badly that every subsequent read of it (tm.get_testRunById, tm.get_testCaseInstancesByTestRunId) starts failing with a 500 server error until repaired by another update. Do not call this speculatively - it's a real, persistent action. KANEAI RUNS: works on both manual and KaneAI test runs (see tm.create_testRun's is_auteur_generated input for creating one), but every test case passed in must match the run's own type - refuses the entire call (no partial changes) if any test case's own is_auteur_generated does not match the run's. Manual test cases cannot enter a KaneAI run and vice versa. This is NOT the same thing as the run's is_editable flag, which reflects KaneAI schedule ownership, not manual/KaneAI compatibility.

Updates MULTIPLE test case instances within one test run in a single call - each instance independently gets its own status (Not Started/Passed/Failed/Skipped) and/or assignee (user ID - see tm.get_organizationUsers to look one up), identified by its own numeric id (from tm.get_testCaseInstancesByTestRunId's 'Instance ID' field). Use this instead of calling tm.update_testCaseInstance repeatedly when updating several instances in the same run at once. Each instance needs at least one of status or assignee. environment_id and remarks are NOT supported here (confirmed silently ignored) even though tm.update_testCaseInstance supports both - use that tool instead for those fields. DANGER: including status on an instance resets ALL of that instance's steps to 'Skipped' - regardless of which status value is sent, even 'Passed' - discarding any real per-step results already recorded via tm.update_testCaseInstanceStep. If per-step results must be preserved, either omit status here (assignee-only) or re-apply per-step statuses afterward. Do not call this speculatively - it's a real, persistent action.

Dispatches a Test Manager test run's test cases to HyperExecute for REAL execution - this is what actually starts automation running (creating a test run and adding test cases to it only prepares the composition; nothing runs until this is called). Input: test_run_id (required). Everything else is optional: concurrency (parallel workers, default 1), title (build name), console_log (false/true/'error'/'warn'/'info'), network_logs, network_full_har, region ('eastus'/'centralindia', web only), mobile_region ('us'/'eu'/'ap', mobile only), tunnel/dedicated_proxy/geolocation (mutually exclusive - use at most one), environment_id, retry_on_failure (default true) with max_retries (default 1), timezone ({region}), app_profiling, performance (Lighthouse report), android_app_id/ios_app_id, accessibility, network_throttle, replaced_url (dynamic URL substitution), report_enabled/extent_report_enabled, and report_email_to (max 10 addresses). IMPORTANT: the test_run_id you submit is treated as a TEMPLATE - it stays 'Not Started' and unchanged. The response returns a DIFFERENT, freshly created test_run_id holding the actual execution - always use that one (not the one you submitted) to check results. Only test cases whose own is_auteur_generated matches the run's type will actually execute (see tm.add_testCasesToTestRun) - this endpoint does not validate that itself. DANGER: this is a real, resource-consuming action that spins up actual HyperExecute cloud infrastructure - do not call speculatively. Confirm the test run and its composition are correct first (tm.get_testRunById) before triggering.

Updates one or more of a single test case instance's own fields - status (Not Started/Passed/Failed/Skipped), assignee (user ID - see tm.get_organizationUsers to look one up), environment_id, and/or remarks - identified by its numeric test_instance_id (get it from tm.get_testCaseInstancesByTestRunId's 'Instance ID' field). Only the fields provided are changed; everything else about the instance, and every other instance in the run, is left untouched. Requires at least one field to change. Get a valid environment_id from tm.get_environments (or read one off an existing test-run instance via tm.get_testRunById). DANGER: only ever pass an environment_id from one of those two sources - a nonexistent environment_id does NOT return an error, it corrupts the run so badly that every subsequent read of it (tm.get_testRunById, tm.get_testCaseInstancesByTestRunId) starts failing with a 500 server error until repaired by another update. Do not call this speculatively - it's a real, persistent action.

Updates ONE step's own status (Not Started/Passed/Failed/Skipped), remarks, and/or attachment_urls within a single test case instance, identified by the step's own numeric test_run_step_id (get it from tm.get_testCaseInstanceById's 'Step ID' field on each step - NOT the instance ID itself). Only the fields provided are changed; every other step on the same instance is untouched. IMPORTANT: updating step statuses does NOT automatically roll up to the instance's own overall result - set that separately with tm.update_testCaseInstance if needed. attachment_urls, despite the name, must contain file_key values from tm.upload_attachment (upload the file first, then pass its file_key here) - a raw URL is silently accepted but has no effect. Requires at least one field to change. Do not call this speculatively - it's a real, persistent action.

Retrieves the folder/subfolder hierarchy used to organize TEST RUNS in a LambdaTest Test Manager project: each folder's name, ID, description, parent folder, timestamps, and test run counts (direct and including subfolders). This is a SEPARATE folder tree from test case folders (tm.get_foldersByProjectId) - the two do not share folder IDs. This tool only returns the folder structure and counts, not the runs themselves - use tm.get_testRunsByProjectId with its folder_id filter, passing a folder ID from here, to list the actual test runs inside a given folder. Read-only; does not modify anything.

Creates a new folder inside a LambdaTest Test Manager project, to organize TEST RUNS. This is a separate folder tree from test case folders (tm.create_folder) - the two do not share folder IDs. Requires the project's ID; optionally nest it under an existing test-run folder by passing that folder's ID (from tm.get_testRunFoldersByProjectId) as parent_id, otherwise it's created at the project's root. Do not use this to update or move an existing folder, and do not call it speculatively - creating a folder is a real, persistent action.

Lists environment configurations (browser/OS/device/resolution combinations) available in this LambdaTest organization, org-wide rather than scoped to a single project. Each entry's environment_id in this tool's output IS a valid value to pass as environment_id on tm.add_testCasesToTestRun/tm.update_testCaseInstance. Supports pagination (page, per_page), filtering by browser, os, platform, and/or resolution, and include_run_count to show how many test runs already use each config. This can be a large list, so use the filters to narrow it down rather than paging through everything. Read-only; does not modify anything.

Lists every user in the LambdaTest organization/account, with their numeric user ID, name, email, role, group, and whether they have Test Manager (TMS) access enabled. Use this to look up a user's ID before assigning them via the assignee field on tm.add_testCasesToTestRun or similar tools. This calls an undocumented endpoint on a different LambdaTest service (auth.lambdatest.com, not the Test Manager API) sourced from the browser network inspector. Read-only; does not modify anything.

Uploads a local file (given by its path on this machine) to Test Manager's attachment storage. Returns the uploaded file's file_key, file name, and a presigned URL. Use the file_key (not the URL) with tools that accept attachment_urls, e.g. tm.update_testCaseInstanceStep - despite that field's name, it expects file_key values. The returned URL is only useful for immediately previewing the upload; it's time-limited, not a permanent link. Do not call this speculatively - it performs a real upload.

Retrieves LambdaTest's AI-generated root cause analysis (RCA) for one or more automation/KaneAI test executions. Accepts any combination of test_ids (the same ID shown as 'Automation Test ID'/test_id by tm.get_testCaseInstancesByTestRunId, tm.get_testExecutionHistoryByTestCaseId, and tm.get_hyperExecuteJobSessions), job_ids (returns RCA for EVERY test execution in that HyperExecute job), task_ids (every execution on that Task), or stage_ids - at least one of the four is required, each as an array (multiple values batch-fetch in a single call). Optional page/limit for pagination over large result sets. Each record includes the RCA itself (category, severity-equivalent root cause/parent failure category, natural-language summary and analysis, a step-by-step error timeline with source logs and stack traces where available, and suggested steps to fix) AND that execution's own job_id/task_id/stage_id/build_id - useful even without needing tm.get_hyperExecuteTestDetails separately. IMPORTANT: RCA only exists for an execution that BOTH actually ran AND failed - a passed execution, an instance that never executed at all, and a wholly invalid ID of any type all return an empty result (not an error), so an empty result here does not necessarily mean an ID was wrong. Only query for executions already known to have failed (e.g. status FAILED on a test case instance that also has a non-empty Automation Test ID / Test URL, confirming it actually reached a session). Read-only; does not modify anything.

Dispatches AI-powered RCA generation for every failed test under the given scope: any combination of job_ids, stage_ids, task_ids, or test_ids (at least one required, each array capped at 100 IDs). Jobs/stages/tasks always route to the HyperExecute analyzer; test_ids route to the correct analyzer automatically per test, so a mixed batch is fine. A test whose RCA already exists or is currently generating is skipped automatically and not charged - only newly-dispatched tests cost credits, so it is safe to pass a broad scope (e.g. an entire job) without first checking which tests already have RCA. Returns how many were newly triggered vs. skipped (and why), and the estimated credits used. DANGER: this spends REAL organizational AI credits and cannot be undone - do not call speculatively or on a broad scope 'just to see'. Credits are all-or-nothing: if the organization's balance is insufficient for the whole scope, NOTHING is dispatched (a 402 is returned instead) rather than partially triggering. A scope resolving to more than 10,000 failed tests is rejected (413) - narrow it first. Use tm.get_testExecutionRCA beforehand to check whether RCA already exists for the tests you care about, and confirm with the user before calling this on anything but a small, deliberately-chosen scope.

Returns a progress summary (total/completed/in_progress/failed/pending counts) plus a paginated list of completed RCA results for a scope - the tool to poll with after calling tm.generate_testExecutionRCA, since generation is asynchronous. Accepts the same scope as tm.generate_testExecutionRCA/tm.get_testExecutionRCA: any combination of test_ids, job_ids, task_ids, or stage_ids (at least one required, each array capped at 100 IDs). Pass include_detail: true to hydrate each result with the full RCA detail (analysis, error timeline, steps to fix, stack traces - same content as tm.get_testExecutionRCA) - omitted by default to keep polling calls small. Supports limit/offset pagination over the results list (NOTE: offset-based, unlike tm.get_testExecutionRCA's page-based pagination - a real difference between these two otherwise-similar endpoints). A scope matching zero tests (wrong IDs, IDs with no failures, etc.) still returns a normal result with all-zero progress counts rather than an error - this tool surfaces the API's own explanatory message in that case. Read-only; does not modify anything (does NOT trigger generation itself - use tm.generate_testExecutionRCA for that).

Retrieves paginated test execution records enriched with AI insights: smart tags (always failing / new failure / flaky / performance anomaly), flakiness rate, a condensed RCA (category + summary - use tm.get_testExecutionRCA for the full detail), failure category, environment (browser/OS/device/resolution), test timing, and build/job/task/stage IDs. Filters: any combination of job_ids, task_ids, stage_ids, test_ids, build_ids (the TOTAL ID count across all five combined is capped at 100, unlike the RCA endpoints which cap each array separately). Defaults to the last 7 days if from_timestamp/to_timestamp are both omitted - THIS STILL APPLIES even when filtering by a specific test_id, so a real, valid test_id from more than 7 days ago returns an empty result unless the date range is widened explicitly (both timestamps must be RFC3339 UTC, supplied together - one alone is rejected - and span at most 31 days per call). Supports cursor-based pagination (cursor/limit, max 500) and sorting (sort_by: create_timestamp/duration/status, sort_order: asc/desc). Read-only; does not modify anything.

Retrieves the current status and full detail of a HyperExecute Job by its job ID: job-level info (status, job number, label, remark, job type, frameworks, org/user, tunnel, retry-on-failure setting, global/test-suite timeout, created/updated/start/end timestamps, total test count, execution time), a per-Task breakdown (each Task is one independent VM/parallel worker running its share of tests sequentially - a job using multiple parallels typically has multiple Tasks, each with its own status, OS, timing, and retry iteration), a numeric task-count summary, and a job summary (pre-run/post-run status breakdowns plus scenario-stage retry statistics). Input: job_id (the HyperExecute Job ID, e.g. a UUID like "11111111-1111-1111-1111-111111111111" - distinct from a Test Manager test_run_id or test_case_id; this tool does not discover a job_id from a Test Manager ID, it requires one already known). IMPORTANT: this is a snapshot at the moment of the call - for a still-queued/running job, call again later for updated status. The API's jobLabel field is a JSON-encoded string rather than a real array; parsed defensively into a readable label, falling back to the raw value if unparseable. Read-only; does not modify anything.

Lists scenario-level execution details for a HyperExecute Job: one entry per test execution attempt (across every Task in the job), each with its scenario ID, parent Task ID, name, iteration (retry number, 0 = first attempt), status, group number, and duration. Input: job_id (required, same ID used by tm.get_hyperExecuteJobById). Optional: limit (max 20, default 10), cursor (from a previous response's metadata, to fetch the next page - returns scenarios with an ID >= the cursor value), status (filter by execution status), search_text (filter by occurrence in the scenario name). IMPORTANT: a status/search_text filter that matches zero scenarios returns a 'not found' error here rather than an empty list - this tool distinguishes that case (reported as 'no scenarios match this filter') from a genuinely invalid/nonexistent job_id (reported as 'job not found') using the API's own error text, so the two are not confused. Read-only; does not modify anything.

Lists session-level execution details for a HyperExecute Job: one entry per test execution that reached an actual Selenium/Appium session (a retried test appears as a separate session entry, not an iteration counter - unlike tm.get_hyperExecuteJobScenarios, which lists every attempt including ones that never got a session). Each entry has its session/test ID (the same automation_test_id used by tm.get_testExecutionHistoryByTestCaseId, tm.get_testCaseInstancesByTestRunId, and tm.get_testExecutionRCA), parent Task ID, scenario name, status, group number, duration, and whether SmartUI was enabled. Input: job_id (required, same ID used by tm.get_hyperExecuteJobById). Optional: limit (max 20, default 10), cursor (from a previous response's metadata, to fetch the next page - returns sessions with an ID >= the cursor value), status (filter by execution status), search_text (filter by occurrence in the scenario name). IMPORTANT: a status/search_text filter that matches zero sessions returns a 'not found' error here rather than an empty list - this tool distinguishes that case (reported as 'no sessions match this filter') from a genuinely invalid/nonexistent job_id (reported as 'job not found') using the API's own error text. A test that never got a session at all (failed before one was created) will not appear here regardless of filters. Read-only; does not modify anything.

Lists every HyperExecute Job in the organization (not scoped to one specific job), newest first: job ID, job number, status, label, remark, task/test counts, who triggered it and how, timestamps, and execution time. When a job carries it, also shows its originating Test Manager test_run_id (from the job's meta.runId field) - the way to find which HyperExecute job corresponds to a known Test Manager test run. Not every job has this link (only KaneAI/Test-Manager-triggered jobs reliably do). Input: limit (page size, default 10, no documented hard maximum), cursor (a job_number to resume just below - from a previous response's 'Next Cursor' hint), show_test_summary (request the job_summary field - has returned null on every job observed so far, may not be populated for all job types). IMPORTANT: there is no way to filter or search directly by test_run_id/label server-side - finding a specific run's job means paging through results and checking each one's Test Manager Run ID. This can require checking many pages for an older run, since job numbers are not contiguous per organization. Read-only; does not modify anything.

Retrieves one specific automation test execution's HyperExecute routing details by its automation_test_id (the same ID shown as 'Automation Test ID'/test_id by tm.get_testCaseInstancesByTestRunId, tm.get_testExecutionHistoryByTestCaseId, tm.get_testExecutionRCA, and as sessionID/testID by tm.get_hyperExecuteJobSessions). Returns its status, Job ID, Task ID, Stage ID, step/retry number, and session ID. THIS IS THE RECOMMENDED WAY to find which HyperExecute Job (tm.get_hyperExecuteJobById) an execution belongs to, when you already have an automation_test_id - fast and reliable, including for scheduled Test Manager runs. It requires the automation_test_id to already be known (from one of the tools above), and that instance must have actually reached a session (an instance that failed before a session was created has no automation_test_id at all, so there is nothing to look up here). Read-only; does not modify anything.