Skip to main content
Glama

Trigger Test Run Execution on HyperExecute

tm.trigger_testRunExecution

Triggers actual execution of prepared test cases on HyperExecute cloud infrastructure using a test run template and returns a new execution test run ID.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNo
regionNo
tunnelNo
timezoneNo
ios_app_idNo
concurrencyNo
console_logNo
geolocationNo
max_retriesNo
performanceNo
test_run_idYes
network_logsNo
replaced_urlNo
accessibilityNo
app_profilingNo
mobile_regionNo
android_app_idNo
environment_idNo
report_enabledNo
dedicated_proxyNo
report_email_toNo
network_full_harNo
network_throttleNo
retry_on_failureNo
extent_report_enabledNo
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses resource consumption, template behavior (returns different ID), and filtering based on is_auteur_generated, with no annotations to cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Structured with clear intro, parameter list, and warnings, but slightly verbose; still well-organized and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 25 parameters, no output schema, and complexity, it covers all parameters, execution behavior, and warnings comprehensively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 25 parameters are described in prose with defaults, enums, and constraints (e.g., mutually exclusive group), compensating for 0% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it dispatches test cases to HyperExecute for real execution, distinguishing from preparation tools like tm.create_testRun and tm.add_testCasesToTestRun.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises not to call speculatively, suggests confirming with tm.get_testRunById, and explains the template behavior and execution constraints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/prakhar-gahlot/TestMu-AI-Test-Manager-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server