How to fix: Use a ui:// URI and text/html;profile=mcp-app. For mcp-use v1, use widgetMetadata.metadata.widgetDescription; for v2, use the bound tool's view.description. The current description check reads _meta.ui.widgetDescription or _meta["openai/widgetDescription"] on resource contents or linked tools, not resource.description. Consequently, v2 view.description alone may leave this warning: report the checker compatibility gap instead of adding unsupported v1 fields or claiming the warning is fixed.
How to fix: For ChatGPT submission, set one exact HTTPS origin such as "https://app.example.com" on every view via _meta.ui.domain (or openai/widgetDomain). Paths are not valid and all views in one app must share the origin.
The title clearly communicates the tool’s action and subject. Keep it concise.
Description82/100
Generates a HyperExecute YAML configuration for running tests on LambdaTest's HyperExecute platform.
REQUIRED fields: project (language, framework) and testing (testDiscovery.command, testRunnerCommand)
All other fields are OPTIONAL.
Supports multiple languages and frameworks:
- JavaScript/TypeScript: Playwright, Cypress, WebDriverIO, Puppeteer, Taiko
- Python: Pytest, Behave, Robot Framework
- Java: TestNG, JUnit, Cucumber
- Ruby: RSpec, Capybara
- C#: NUnit, xUnit, MSTest
- Mobile (ONLY use appTesting for these): XCUI (iOS), Espresso (Android), Appium
Features:
- Smart framework defaults for common configurations
- Input validation with security checks
- Caching and artifact upload configuration
- Git integration via sourcePayload
- Mobile app testing support (via optional appTesting field)
The appTesting field applies to mobile app testing only; web automation (Selenium, Playwright, Cypress, etc.) leaves it out.
Describe the returned information so the agent knows whether it will answer the request.
Inputs91/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project › language
Programming language
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project › framework
Test framework
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project › buildTool
Build tool (optional, will be inferred)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
testing › testDiscovery › command
Command to discover tests (e.g., find tests -name '*.spec.ts')
Clear enough to supply this argument.
testing › testDiscovery › type
How tests are discovered: raw runs the command as given, automatic lets HyperExecute detect them
Clear enough to supply this argument.
testing › testDiscovery › mode
dynamic discovers tests on the runner at run time; static uses the list found before the run
Clear enough to supply this argument.
testing › testRunnerCommand
Command to run tests. Use $test placeholder for test identifier.
Clear enough to supply this argument.
execution › os
Runner operating system
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
execution › concurrency
Number of tests run in parallel
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
execution › autosplit
Spread the discovered tests across the parallel runners automatically
Clear enough to supply this argument.
execution › retryOnFailure
Retry failed tests
Clear enough to supply this argument.
execution › maxRetries
Retries per failed test when retryOnFailure is on
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
execution › globalTimeout
Global timeout in minutes
Explain what happens when this optional value is omitted.
execution › testSuiteTimeout
Test suite timeout in minutes
Clear enough to supply this argument.
execution › tunnel
Enable LambdaTest tunnel
Clear enough to supply this argument.
setup › preCommands
Commands to run before tests (e.g., npm install)
Clear enough to supply this argument.
setup › postCommands
Commands to run after tests
Clear enough to supply this argument.
setup › cacheKey
Cache key pattern
Explain the meaning of this value, not just its name.
setup › cacheDirectories
Directories to cache
Clear enough to supply this argument.
setup › env
Environment variables
Clear enough to supply this argument.
setup › runtime › language
Runtime to install on the runner, e.g. node, python, java
Clear enough to supply this argument.
setup › runtime › version
Runtime version, e.g. 20 or 3.11
Clear enough to supply this argument.
appTesting › framework
Mobile testing framework (required if appTesting is used)
Clear enough to supply this argument.
appTesting › appPath
Path to app file or lt:// URL
Clear enough to supply this argument.
appTesting › testSuitePath
Path to test suite
Clear enough to supply this argument.
appTesting › devices
Target devices (required if appTesting is used, e.g., 'iPhone 14 Pro-17')
Clear enough to supply this argument.
appTesting › video
Record a video of each test
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
appTesting › deviceLog
Capture device logs
Clear enough to supply this argument.
appTesting › networkLog
Capture network logs
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
sourcePayload › platform
Source platform; git is the only supported value
Clear enough to supply this argument.
sourcePayload › link
Repository URL
Clear enough to supply this argument.
sourcePayload › ref
Branch/tag/commit
Clear enough to supply this argument.
sourcePayload › accessToken
Reference to an environment variable that holds the Git token, e.g. ${GIT_TOKEN}; never the token itself
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
sourcePayload › gitProvider
Git host of the repository
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
artifacts › uploadPaths
Paths on the runner to upload as job artifacts, e.g. reports/ or screenshots/
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
artifacts › mergeArtifacts
Merge the artifacts from all parallel runners into one set
Clear enough to supply this argument.
artifacts › reports › items › type
Report FORMAT (not framework name). Use 'xml' for most frameworks (Playwright, Cypress, pytest, TestNG, JUnit generate XML reports). Use 'json' for Cucumber/BDD. Valid: html, json, xml, zip
Clear enough to supply this argument.
artifacts › reports › items › location
Path to report files
Clear enough to supply this argument.
artifacts › reports › items › frameworkName
Framework name for display (e.g., 'Playwright', 'pytest') - NOT the report format
Clear enough to supply this argument.
jobLabel
Labels for the job
Clear enough to supply this argument.
advanced
Advanced overrides (escape hatch for any HyperExecute field)
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
The title clearly communicates the tool’s action and subject. Keep it concise.
Description99/100
Runs an accessibility scan on the given URLs and returns the issues found. Pass urls to start a scan, or testId to re-read a scan that already ran; exactly one of the two. Results arrive in issueDetails: allIssues (most-severe-first, one page at a time), rules (name and reference link per rule id, listed once), pages (every scanned page with its score and issue count), failedRules (per-rule totals for the whole scan) and pagination. Each issue carries its own howToFix and criteria, measured for that element - two issues sharing a rule can have different causes and fixes. While pagination.nextOffset is not null the results are incomplete: call again with the testId from the response plus that offset, keeping the same filters, until it is null. Page with testId, never by passing urls again - that starts a new scan, costs another run, and can return a different set of issues whose offsets do not line up. a11yReportLink is the dashboard URL and needs a login; shareableLink is public and is only returned by the original scan.
The description explains the capability, when to use it, and what to expect.
Inputs88/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
urls
List of URLs to scan. Starts a new scan. Provide either urls or testId, not both.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
testId
Re-read an existing scan by its testId (as returned in a previous response) instead of running a new one. Use this to page through results with offset.
Clear enough to supply this argument.
severity
Only return issues of this impact level. Omit to get all severities.
Clear enough to supply this argument.
pageUrl
Only return issues found on this scanned page. Must exactly match one of the URLs in issueDetails.pages.
Clear enough to supply this argument.
limit
Maximum issues to return in this response (default 50, max 200).
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
offset
Index to start from within the filtered, severity-sorted issue list. Pass the nextOffset from a previous response, together with that response's testId, to page through results.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "getAccessibilityReport",
"title": "Get Accessibility Report",
"description": "Runs an accessibility scan on the given URLs and returns the issues found. Pass urls to start a scan, or testId to re-read a scan that already ran; exactly one of the two. Results arrive in issueDetails: allIssues (most-severe-first, one page at a time), rules (name and reference link per rule id, listed once), pages (every scanned page with its score and issue count), failedRules (per-rule totals for the whole scan) and pagination. Each issue carries its own howToFix and criteria, measured for that element - two issues sharing a rule can have different causes and fixes. While pagination.nextOffset is not null the results are incomplete: call again with the testId from the response plus that offset, keeping the same filters, until it is null. Page with testId, never by passing urls again - that starts a new scan, costs another run, and can return a different set of issues whose offsets do not line up. a11yReportLink is the dashboard URL and needs a login; shareableLink is public and is only returned by the original scan.",
"inputSchema": {
"type": "object",
"properties": {
"urls": {
"type": "array",
"items": {
"type": "string",
"description": "URL to analyze for accessibility issues"
},
"minItems": 1,
"description": "List of URLs to scan. Starts a new scan. Provide either urls or testId, not both."
},
"limit": {
"type": "number",
"maximum": 200,
"minimum": 1,
"description": "Maximum issues to return in this response (default 50, max 200)."
},
"offset": {
"type": "number",
"minimum": 0,
"description": "Index to start from within the filtered, severity-sorted issue list. Pass the nextOffset from a previous response, together with that response's testId, to page through results."
},
"testId": {
"type": "string",
"description": "Re-read an existing scan by its testId (as returned in a previous response) instead of running a new one. Use this to page through results with offset."
},
"pageUrl": {
"type": "string",
"description": "Only return issues found on this scanned page. Must exactly match one of the URLs in issueDetails.pages."
},
"severity": {
"enum": [
"critical",
"serious",
"moderate",
"minor"
],
"type": "string",
"description": "Only return issues of this impact level. Omit to get all severities."
}
},
"additionalProperties": false
},
"annotations": {
"title": "Get Accessibility Report",
"readOnlyHint": true,
"openWorldHint": true,
"destructiveHint": false
}
}
Align the title with the capability actually described by this tool.
Description96/100
Returns step-by-step instructions to build and serve a local web app and open a LambdaTest tunnel to it, so its accessibility can then be scanned with analyzeAppViaTunnel. It does not build, run or scan anything itself, and never includes the access key.
The description explains the capability, when to use it, and what to expect.
Inputs83/100
Explain what happens when this optional value is omitted.
codebasePath
Absolute path to the codebase directory
Clear enough to supply this argument.
customBuildCommand
Custom build command (optional, e.g., npm run build)
Explain what happens when this optional value is omitted.
port
Port to host the app locally
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "buildLocalAppForAnalysis",
"title": "Build and Analyze App",
"description": "Returns step-by-step instructions to build and serve a local web app and open a LambdaTest tunnel to it, so its accessibility can then be scanned with analyzeAppViaTunnel. It does not build, run or scan anything itself, and never includes the access key.",
"inputSchema": {
"type": "object",
"required": [
"codebasePath",
"port"
],
"properties": {
"port": {
"type": "number",
"maximum": 65535,
"minimum": 1024,
"description": "Port to host the app locally"
},
"codebasePath": {
"type": "string",
"description": "Absolute path to the codebase directory"
},
"customBuildCommand": {
"type": "string",
"description": "Custom build command (optional, e.g., npm run build)"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Build and Analyze App",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "getAutomationTestDetails",
"title": "Get Automation Test Details",
"description": "Fetches detailed information about an automation test by ID",
"inputSchema": {
"type": "object",
"required": [
"testId",
"platform"
],
"properties": {
"testId": {
"type": "string",
"description": "The ID of the automation test"
},
"platform": {
"enum": [
"web",
"app"
],
"type": "string",
"description": "Optional: set to \"app\" to fetch details from the mobile API"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Get Automation Test Details",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
Align the title with the capability actually described by this tool.
Description77/100
Fetches Selenium logs (web), Appium logs (mobile/Appium), or instrumentation logs (mobile/XCUI/Espresso) for a specific automation test. Automatically detects XCUI and Espresso tests and fetches the correct log type.
Describe the returned information so the agent knows whether it will answer the request.
Inputs75/100
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
testId
The ID of the automation test to fetch logs for
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
platform
The platform type: "web" for Selenium logs, "app" for Appium/instrumentation logs
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
sessionId
Required for app platform: the session_id of the app session, a UUID that listMobileSessions and getAutomationTestDetails return (not the test ID)
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "getAutomationTestSeleniumLogs",
"title": "Get Automation Test Selenium Logs",
"description": "Fetches Selenium logs (web), Appium logs (mobile/Appium), or instrumentation logs (mobile/XCUI/Espresso) for a specific automation test. Automatically detects XCUI and Espresso tests and fetches the correct log type.",
"inputSchema": {
"type": "object",
"required": [
"testId",
"platform"
],
"properties": {
"testId": {
"type": "string",
"description": "The ID of the automation test to fetch logs for"
},
"platform": {
"enum": [
"web",
"app"
],
"type": "string",
"description": "The platform type: \"web\" for Selenium logs, \"app\" for Appium/instrumentation logs"
},
"sessionId": {
"type": "string",
"description": "Required for app platform: the session_id of the app session, a UUID that listMobileSessions and getAutomationTestDetails return (not the test ID)"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Get Automation Test Selenium Logs",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description84/100
Read-only query of LambdaTest automation resources: list builds, get one build, list the sessions in a build, fetch test details, and retrieve test logs (command, network, console, selenium, instrumentation). Supported combinations: build with list or get (web), session with list (web), test with get (web or app), logs with get and a logType (web or app). logType "instrumentation" returns XCUI and Espresso test logs. Renaming, stopping and deleting builds are separate tools: updateBuild, stopBuild and deleteBuild.
The description explains the capability, when to use it, and what to expect.
Inputs80/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
resource
The resource type to query
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
action
The read to perform: list, or get one
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
platform
The platform type: "web" for browser automation, "app" for mobile app automation
Clear enough to supply this argument.
buildId
Build ID — required for build get, optional filter for session list
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
testId
Test ID — required for test get and logs get
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
logType
Log type — required when resource is "logs"
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
sessionId
Session ID — required for app platform log retrieval
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
status
Filter builds by status (e.g. "running", "passed", "failed")
Clear enough to supply this argument.
fromdate
Filter builds from this date (YYYY-MM-DD)
Clear enough to supply this argument.
todate
Filter builds to this date (YYYY-MM-DD)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
sort
Sort order for build listing (e.g. "asc", "desc")
Clear enough to supply this argument.
limit
Number of results to return (pagination)
Clear enough to supply this argument.
offset
Offset for pagination
Clear enough to supply this argument.
pageNumber
Page number for command log pagination
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "automationQuery",
"title": "Automation Query",
"description": "Read-only query of LambdaTest automation resources: list builds, get one build, list the sessions in a build, fetch test details, and retrieve test logs (command, network, console, selenium, instrumentation). Supported combinations: build with list or get (web), session with list (web), test with get (web or app), logs with get and a logType (web or app). logType \"instrumentation\" returns XCUI and Espresso test logs. Renaming, stopping and deleting builds are separate tools: updateBuild, stopBuild and deleteBuild.",
"inputSchema": {
"type": "object",
"required": [
"resource",
"action",
"platform"
],
"properties": {
"sort": {
"type": "string",
"description": "Sort order for build listing (e.g. \"asc\", \"desc\")"
},
"limit": {
"type": "number",
"description": "Number of results to return (pagination)"
},
"action": {
"enum": [
"list",
"get"
],
"type": "string",
"description": "The read to perform: list, or get one"
},
"offset": {
"type": "number",
"description": "Offset for pagination"
},
"status": {
"type": "string",
"description": "Filter builds by status (e.g. \"running\", \"passed\", \"failed\")"
},
"testId": {
"type": "string",
"description": "Test ID — required for test get and logs get"
},
"todate": {
"type": "string",
"description": "Filter builds to this date (YYYY-MM-DD)"
},
"buildId": {
"type": "number",
"description": "Build ID — required for build get, optional filter for session list"
},
"logType": {
"enum": [
"command",
"network",
"console",
"selenium",
"instrumentation"
],
"type": "string",
"description": "Log type — required when resource is \"logs\""
},
"fromdate": {
"type": "string",
"description": "Filter builds from this date (YYYY-MM-DD)"
},
"platform": {
"enum": [
"web",
"app"
],
"type": "string",
"description": "The platform type: \"web\" for browser automation, \"app\" for mobile app automation"
},
"resource": {
"enum": [
"build",
"session",
"test",
"logs"
],
"type": "string",
"description": "The resource type to query"
},
"sessionId": {
"type": "string",
"description": "Session ID — required for app platform log retrieval"
},
"pageNumber": {
"type": "number",
"description": "Page number for command log pagination"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Automation Query",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
{
"name": "triggerSuiteRun",
"title": "Trigger Suite Run",
"description": "Triggers a phone call test run for a specific suite. This will initiate phone calls for all scenarios configured in the suite.",
"inputSchema": {
"type": "object",
"required": [
"projectId",
"suiteName"
],
"properties": {
"projectId": {
"type": "string",
"description": "The project ID that contains the suite"
},
"suiteName": {
"type": "string",
"description": "The name of the suite to trigger"
}
},
"additionalProperties": false
},
"outputSchema": {
"type": "object",
"properties": {
"data": {
"type": "object",
"description": "Call initiation results"
},
"message": {
"type": "string",
"description": "Status message"
},
"success": {
"type": "boolean",
"description": "Whether the call initiation was successful"
}
}
},
"annotations": {
"title": "Trigger Suite Run",
"readOnlyHint": false,
"openWorldHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description98/100
Lists the OS, browser and device combinations LambdaTest supports, to find valid os, browser and version values for a test configuration. With no filters it returns a compact summary: each desktop OS with its browsers (version count, newest and oldest) and resolutions, and each mobile platform with its device count and OS versions. Set os (and optionally browser) for the full version list, or os=ios / os=android for device names.
The description explains the capability, when to use it, and what to expect.
Inputs83/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
type
Only desktop OSes or only mobile platforms
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
os
OS name to expand, matched case-insensitively as a substring, e.g. "Windows 11", "Sonoma", "android"
Clear enough to supply this argument.
browser
Browser to expand on desktop, e.g. "chrome", "firefox", "edge", "safari"
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "getSupportedPlatforms",
"title": "Get Supported Platforms",
"description": "Lists the OS, browser and device combinations LambdaTest supports, to find valid os, browser and version values for a test configuration. With no filters it returns a compact summary: each desktop OS with its browsers (version count, newest and oldest) and resolutions, and each mobile platform with its device count and OS versions. Set os (and optionally browser) for the full version list, or os=ios / os=android for device names.",
"inputSchema": {
"type": "object",
"properties": {
"os": {
"type": "string",
"description": "OS name to expand, matched case-insensitively as a substring, e.g. \"Windows 11\", \"Sonoma\", \"android\""
},
"type": {
"enum": [
"desktop",
"mobile"
],
"type": "string",
"description": "Only desktop OSes or only mobile platforms"
},
"browser": {
"type": "string",
"description": "Browser to expand on desktop, e.g. \"chrome\", \"firefox\", \"edge\", \"safari\""
}
},
"additionalProperties": false
},
"annotations": {
"title": "Get Supported Platforms",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description82/100
Retrieve all active LambdaTest tunnel connections for the account. Useful for checking which tunnels are running before starting a new one or debugging local testing connectivity.
Describe the returned information so the agent knows whether it will answer the request.
Inputs100/100
This tool declares no inputs, so argument descriptions are not needed.
No input fields.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "listTunnels",
"title": "List Tunnels",
"description": "Retrieve all active LambdaTest tunnel connections for the account. Useful for checking which tunnels are running before starting a new one or debugging local testing connectivity.",
"inputSchema": {
"type": "object",
"properties": {},
"additionalProperties": false
},
"annotations": {
"title": "List Tunnels",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "stopTunnel",
"title": "Stop Tunnel",
"description": "Terminate a specific active tunnel connection by tunnel ID. Use this to clean up tunnels that are no longer needed.",
"inputSchema": {
"type": "object",
"required": [
"tunnelId"
],
"properties": {
"tunnelId": {
"type": "string",
"description": "The ID of the tunnel to stop"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Stop Tunnel",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "updateSession",
"title": "Update Session",
"description": "Update the name or pass/fail status of a test session. Use status_ind to mark tests as passed, failed, error, or skipped from your test framework.",
"inputSchema": {
"type": "object",
"required": [
"sessionId"
],
"properties": {
"name": {
"type": "string",
"description": "New name for the session"
},
"sessionId": {
"type": "string",
"description": "The session ID to update"
},
"status_ind": {
"enum": [
"passed",
"failed",
"error",
"skipped"
],
"type": "string",
"description": "Test result status"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Update Session",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description84/100
Summarises automation test results in a date range: total tests, passed, failed, completed without a pass/fail mark, pass rate (over tests marked passed or failed), average duration and distinct builds, grouped by status, browser, os, build, device or day. Computed from test-level insights data (up to 2000 tests per call).
The description explains the capability, when to use it, and what to expect.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
fromDate
Start date, YYYY-MM-DD. Defaults to 30 days before toDate.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
toDate
End date, YYYY-MM-DD. Defaults to today.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
groupBy
Dimension to group by. Defaults to status.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
The title clearly communicates the tool’s action and subject. Keep it concise.
Description96/100
Lists tests that the insights engine marks as flaky (passing and failing intermittently) in a date range, with each test's flake rate, build and environment. Returns only flaky tests, plus how many tests were scanned.
The description explains the capability, when to use it, and what to expect.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
fromDate
Start date, YYYY-MM-DD. Defaults to 30 days before toDate.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
toDate
End date, YYYY-MM-DD. Defaults to today.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
limit
Maximum flaky tests to return, 1 to 200. Defaults to 50.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "getFlakyTests",
"title": "Get Flaky Tests",
"description": "Lists tests that the insights engine marks as flaky (passing and failing intermittently) in a date range, with each test's flake rate, build and environment. Returns only flaky tests, plus how many tests were scanned.",
"inputSchema": {
"type": "object",
"properties": {
"limit": {
"type": "number",
"description": "Maximum flaky tests to return, 1 to 200. Defaults to 50."
},
"toDate": {
"type": "string",
"description": "End date, YYYY-MM-DD. Defaults to today."
},
"fromDate": {
"type": "string",
"description": "Start date, YYYY-MM-DD. Defaults to 30 days before toDate."
}
},
"additionalProperties": false
},
"annotations": {
"title": "Get Flaky Tests",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description87/100
Daily trend of automation test results in a date range: for each day, total tests, passed, failed, completed without a pass/fail mark, pass rate (over tests marked passed or failed) and average duration.
The description explains the capability, when to use it, and what to expect.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
fromDate
Start date, YYYY-MM-DD. Defaults to 30 days before toDate.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
toDate
End date, YYYY-MM-DD. Defaults to today.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "getTestTrends",
"title": "Get Test Trends",
"description": "Daily trend of automation test results in a date range: for each day, total tests, passed, failed, completed without a pass/fail mark, pass rate (over tests marked passed or failed) and average duration.",
"inputSchema": {
"type": "object",
"properties": {
"toDate": {
"type": "string",
"description": "End date, YYYY-MM-DD. Defaults to today."
},
"fromDate": {
"type": "string",
"description": "Start date, YYYY-MM-DD. Defaults to 30 days before toDate."
}
},
"additionalProperties": false
},
"annotations": {
"title": "Get Test Trends",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description88/100
Summarises failed and errored automation tests in a date range: counts by failure category and by status, and the failing tests themselves with build and environment.
The description explains the capability, when to use it, and what to expect.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
fromDate
Start date, YYYY-MM-DD. Defaults to 30 days before toDate.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
toDate
End date, YYYY-MM-DD. Defaults to today.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
limit
Maximum failing tests to list, 1 to 200. Defaults to 20.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "deleteUserFile",
"title": "Delete User File",
"description": "Delete an uploaded user file by stored LambdaTest file path.",
"inputSchema": {
"type": "object",
"properties": {
"filePath": {
"type": "string",
"description": "Key of the stored user file, as uploadUserFile returns it (usually the file name)"
},
"file_path": {
"type": "string",
"description": "Key of the stored user file, as uploadUserFile returns it (usually the file name)"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Delete User File",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description97/100
Find test cases in a project by filters (folder, priority, automation status, type, tags) and/or search (matches test case ID like TC-123, or title; minimum 3 characters) — returns summaries. Filters combine (AND). Pass case_id instead to get one case's full detail (steps, BDD scenarios, field values).
The description explains the capability, when to use it, and what to expect.
Inputs86/100
Explain the meaning of this value, not just its name.
case_id
Test case ID (ULID). When given, returns that case's full detail and all other filters are ignored.
Clear enough to supply this argument.
project_id
Project ID (ULID). Required unless case_id is given.
Clear enough to supply this argument.
folder_id
Only cases in this folder
Clear enough to supply this argument.
priority
Filter by priority (e.g. Lowest, Low, Medium, High, Highest)
Clear enough to supply this argument.
automation_status
Filter by automation status (e.g. Automated, Not Automated, To Be Automated)
Clear enough to supply this argument.
type
Filter by test type (e.g. Functional, Regression, Smoke & Sanity)
Clear enough to supply this argument.
tags
Filter by tags
Explain the meaning of this value, not just its name.
search
Full-text keyword (min 3 chars)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
limit
Max results per page
Explain what happens when this optional value is omitted.
page
Page number (1-based)
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
{
"title": "Find / Get Test Cases",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
Output schema0/100
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_get_test_cases",
"title": "Find / Get Test Cases",
"description": "Find test cases in a project by filters (folder, priority, automation status, type, tags) and/or search (matches test case ID like TC-123, or title; minimum 3 characters) — returns summaries. Filters combine (AND). Pass case_id instead to get one case's full detail (steps, BDD scenarios, field values).",
"inputSchema": {
"type": "object",
"properties": {
"page": {
"type": "number",
"description": "Page number (1-based)"
},
"tags": {
"type": "array",
"items": {
"type": "string"
},
"description": "Filter by tags"
},
"type": {
"type": "string",
"description": "Filter by test type (e.g. Functional, Regression, Smoke & Sanity)"
},
"limit": {
"type": "number",
"description": "Max results per page"
},
"search": {
"type": "string",
"description": "Full-text keyword (min 3 chars)"
},
"case_id": {
"type": "string",
"description": "Test case ID (ULID). When given, returns that case's full detail and all other filters are ignored."
},
"priority": {
"type": "string",
"description": "Filter by priority (e.g. Lowest, Low, Medium, High, Highest)"
},
"folder_id": {
"type": "string",
"description": "Only cases in this folder"
},
"project_id": {
"type": "string",
"description": "Project ID (ULID). Required unless case_id is given."
},
"automation_status": {
"type": "string",
"description": "Filter by automation status (e.g. Automated, Not Automated, To Be Automated)"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Find / Get Test Cases",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description84/100
Get a folder tree. Test Manager keeps three folder types: Test Cases and Test Runs folders (per project — pass project_id) and Modules folders (organization-level, since modules are shared across projects — no project_id needed). Pick with the tree parameter (default: test-cases). New test-case/test-run folders can be created with tm_create_folder.
Describe the returned information so the agent knows whether it will answer the request.
Inputs88/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project_id
Project ID (ULID) — required for the test-cases and test-runs trees; not used for modules
Clear enough to supply this argument.
tree
Which folder tree to return (default test-cases). "modules" is organization-level.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_list_folders",
"title": "List Folders",
"description": "Get a folder tree. Test Manager keeps three folder types: Test Cases and Test Runs folders (per project — pass project_id) and Modules folders (organization-level, since modules are shared across projects — no project_id needed). Pick with the tree parameter (default: test-cases). New test-case/test-run folders can be created with tm_create_folder.",
"inputSchema": {
"type": "object",
"properties": {
"tree": {
"enum": [
"test-cases",
"test-runs",
"modules"
],
"type": "string",
"description": "Which folder tree to return (default test-cases). \"modules\" is organization-level."
},
"project_id": {
"type": "string",
"description": "Project ID (ULID) — required for the test-cases and test-runs trees; not used for modules"
}
},
"additionalProperties": false
},
"annotations": {
"title": "List Folders",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description86/100
List the organization's reusable step Modules (modules are org-level, shared across projects — the same list as the Modules page). Supports name search and pagination. Reference a module by id when creating or editing a test case to include its steps (the Module itself is never changed).
The description explains the capability, when to use it, and what to expect.
Inputs95/100
Input documentation gives an agent enough context to populate the arguments.
search
Filter modules by name keyword
Clear enough to supply this argument.
folder_id
Only modules in this Modules folder (folder ids from tm_list_folders with tree="modules")
Clear enough to supply this argument.
include_subfolders
With folder_id: also include modules from its subfolders
Clear enough to supply this argument.
limit
Max results per page (default 100)
Clear enough to supply this argument.
page
Page number (1-based)
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_list_modules",
"title": "List Step Modules",
"description": "List the organization's reusable step Modules (modules are org-level, shared across projects — the same list as the Modules page). Supports name search and pagination. Reference a module by id when creating or editing a test case to include its steps (the Module itself is never changed).",
"inputSchema": {
"type": "object",
"properties": {
"page": {
"type": "number",
"description": "Page number (1-based)"
},
"limit": {
"type": "number",
"description": "Max results per page (default 100)"
},
"search": {
"type": "string",
"description": "Filter modules by name keyword"
},
"folder_id": {
"type": "string",
"description": "Only modules in this Modules folder (folder ids from tm_list_folders with tree=\"modules\")"
},
"include_subfolders": {
"type": "boolean",
"description": "With folder_id: also include modules from its subfolders"
}
},
"additionalProperties": false
},
"annotations": {
"title": "List Step Modules",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description86/100
List saved run Configurations (reusable platform / browser / OS / device setups). To apply one to a run, pass the configuration's TOP-LEVEL id to tm_create_test_run or tm_update_test_run as configuration_id (NOT the nested environments[].environment_id). Pass run_type to see only the configurations usable for that run type (kaneai vs manual). Each test instance carries exactly one configuration. Configurations are created by humans in the Test Manager UI.
Describe the returned information so the agent knows whether it will answer the request.
Inputs75/100
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
project_id
Optionally scope to a project
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
run_type
Only configurations supporting this run type (kane-supported vs manual-supported)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
limit
Max results per page (default 10)
Clear enough to supply this argument.
page
Page number (1-based)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_list_configurations",
"title": "List Run Configurations",
"description": "List saved run Configurations (reusable platform / browser / OS / device setups). To apply one to a run, pass the configuration's TOP-LEVEL id to tm_create_test_run or tm_update_test_run as configuration_id (NOT the nested environments[].environment_id). Pass run_type to see only the configurations usable for that run type (kaneai vs manual). Each test instance carries exactly one configuration. Configurations are created by humans in the Test Manager UI.",
"inputSchema": {
"type": "object",
"properties": {
"page": {
"type": "number",
"description": "Page number (1-based)"
},
"limit": {
"type": "number",
"description": "Max results per page (default 10)"
},
"run_type": {
"enum": [
"manual",
"kaneai"
],
"type": "string",
"description": "Only configurations supporting this run type (kane-supported vs manual-supported)"
},
"project_id": {
"type": "string",
"description": "Optionally scope to a project"
}
},
"additionalProperties": false
},
"annotations": {
"title": "List Run Configurations",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description81/100
Pass run_id to get one test run's detail plus its result summary (instance counts by status — passed / failed / skipped / not started / in progress — and pass rate). Otherwise pass project_id to list runs with optional filters. Every returned run carries run_type ("kaneai" or "manual") identifying KaneAI runs — the backend stores KaneAI runs with type "Manual" (result-entry mode), so use run_type, not type, to tell them apart.
Resolve contradictions between the description, input schema, and annotations.
Inputs88/100
Input documentation gives an agent enough context to populate the arguments.
run_id
Test run ID (ULID). When given, returns detail + result summary.
Clear enough to supply this argument.
project_id
Project ID (ULID). Required when run_id is not given.
Clear enough to supply this argument.
status
Filter: Not Started, In Progress, Passed, Failed, Skipped
Clear enough to supply this argument.
run_type
Filter: "kaneai" (KaneAI runs), "manual" (human result-entry runs, KaneAI excluded), or "automation" (framework-uploaded runs). Buckets are disjoint.
Clear enough to supply this argument.
folder_id
Only runs in this folder
Clear enough to supply this argument.
search
Search runs by title
Clear enough to supply this argument.
limit
Max results per page
Clear enough to supply this argument.
page
Page number (1-based)
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_get_test_runs",
"title": "Get Test Runs",
"description": "Pass run_id to get one test run's detail plus its result summary (instance counts by status — passed / failed / skipped / not started / in progress — and pass rate). Otherwise pass project_id to list runs with optional filters. Every returned run carries run_type (\"kaneai\" or \"manual\") identifying KaneAI runs — the backend stores KaneAI runs with type \"Manual\" (result-entry mode), so use run_type, not type, to tell them apart.",
"inputSchema": {
"type": "object",
"properties": {
"page": {
"type": "number",
"description": "Page number (1-based)"
},
"limit": {
"type": "number",
"description": "Max results per page"
},
"run_id": {
"type": "string",
"description": "Test run ID (ULID). When given, returns detail + result summary."
},
"search": {
"type": "string",
"description": "Search runs by title"
},
"status": {
"type": "string",
"description": "Filter: Not Started, In Progress, Passed, Failed, Skipped"
},
"run_type": {
"type": "string",
"description": "Filter: \"kaneai\" (KaneAI runs), \"manual\" (human result-entry runs, KaneAI excluded), or \"automation\" (framework-uploaded runs). Buckets are disjoint."
},
"folder_id": {
"type": "string",
"description": "Only runs in this folder"
},
"project_id": {
"type": "string",
"description": "Project ID (ULID). Required when run_id is not given."
}
},
"additionalProperties": false
},
"annotations": {
"title": "Get Test Runs",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description85/100
Test coverage for a project — overall and per folder — computed live from the project's test cases (matches the Test Cases screen). Also answers requirement / traceability coverage: pass jira_id (any Jira issue key, e.g. TE-123 — a requirement, user story, epic, ticket or bug) to get that item's test coverage (the test cases linked to it and how many are automated; zero linked cases = uncovered). For a set of requirements, call once per Jira key. A scope with no test cases returns all zeros.
Describe the returned information so the agent knows whether it will answer the request.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project_id
Project ID (ULID)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
jira_id
Optional Jira issue key (e.g. TE-123) — scope coverage to the test cases linked to this requirement / user story / epic / ticket (traceability coverage)
Clear enough to supply this argument.
folder_id
Optional folder scope
Explain the meaning of this value, not just its name.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_get_coverage_summary",
"title": "Get Coverage Summary",
"description": "Test coverage for a project — overall and per folder — computed live from the project's test cases (matches the Test Cases screen). Also answers requirement / traceability coverage: pass jira_id (any Jira issue key, e.g. TE-123 — a requirement, user story, epic, ticket or bug) to get that item's test coverage (the test cases linked to it and how many are automated; zero linked cases = uncovered). For a set of requirements, call once per Jira key. A scope with no test cases returns all zeros.",
"inputSchema": {
"type": "object",
"required": [
"project_id"
],
"properties": {
"jira_id": {
"type": "string",
"description": "Optional Jira issue key (e.g. TE-123) — scope coverage to the test cases linked to this requirement / user story / epic / ticket (traceability coverage)"
},
"folder_id": {
"type": "string",
"description": "Optional folder scope"
},
"project_id": {
"type": "string",
"description": "Project ID (ULID)"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Get Coverage Summary",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description75/100
Create a new Test Manager project. Project & Org Instructions (Memory Layer) stay managed in the UI. Deleting projects is not available through this connection.
Explain mutations, irreversible effects, or prerequisites that matter before calling this tool.
Inputs73/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
name
Project name
Clear enough to supply this argument.
description
What the project covers
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
tags
Labels
Explain the meaning of this value, not just its name.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
The title clearly communicates the tool’s action and subject. Keep it concise.
Description84/100
Create a folder — in a project's Test Cases tree (default) or Test Runs tree (pass project_id), or in the organization-level Modules tree (no project_id needed; module folders are shared across projects). Optionally nest it under an existing parent folder to build folder trees. Deleting folders is not available through this connection.
The description explains the capability, when to use it, and what to expect.
Inputs80/100
Explain the meaning of this value, not just its name.
project_id
Project ID (ULID) — required for the test-cases and test-runs trees; not used for modules
Clear enough to supply this argument.
name
Folder name
Explain the meaning of this value, not just its name.
description
Optional description
Explain the meaning of this value, not just its name.
parent_folder_id
Nest under this existing folder (ULID); omit for top level
Clear enough to supply this argument.
tree
Which folder tree to create in (default test-cases). "modules" is organization-level.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_create_folder",
"title": "Create Folder",
"description": "Create a folder — in a project's Test Cases tree (default) or Test Runs tree (pass project_id), or in the organization-level Modules tree (no project_id needed; module folders are shared across projects). Optionally nest it under an existing parent folder to build folder trees. Deleting folders is not available through this connection.",
"inputSchema": {
"type": "object",
"required": [
"name"
],
"properties": {
"name": {
"type": "string",
"description": "Folder name"
},
"tree": {
"enum": [
"test-cases",
"test-runs",
"modules"
],
"type": "string",
"description": "Which folder tree to create in (default test-cases). \"modules\" is organization-level."
},
"project_id": {
"type": "string",
"description": "Project ID (ULID) — required for the test-cases and test-runs trees; not used for modules"
},
"description": {
"type": "string",
"description": "Optional description"
},
"parent_folder_id": {
"type": "string",
"description": "Nest under this existing folder (ULID); omit for top level"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Create Folder",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description83/100
Rename a folder, change its description, or move it under a different parent folder. Works on all three folder types: per-project Test Cases (default) and Test Runs trees, and the organization-level Modules tree. Moves of test-cases/test-runs folders require project_id; module folders need none.
Explain mutations, irreversible effects, or prerequisites that matter before calling this tool.
Inputs79/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
folder_id
Folder ID (ULID)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project_id
Project ID (ULID) — required when moving a test-cases or test-runs folder; not used for modules
Clear enough to supply this argument.
name
New name
Explain the meaning of this value, not just its name.
description
New description
Explain the meaning of this value, not just its name.
parent_folder_id
Move under this folder (ULID), or pass "root" to make it a top-level folder; cannot be the folder itself or one of its descendants
Clear enough to supply this argument.
tree
Which folder tree the folder belongs to (default test-cases). "modules" is organization-level.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_update_folder",
"title": "Update Folder",
"description": "Rename a folder, change its description, or move it under a different parent folder. Works on all three folder types: per-project Test Cases (default) and Test Runs trees, and the organization-level Modules tree. Moves of test-cases/test-runs folders require project_id; module folders need none.",
"inputSchema": {
"type": "object",
"required": [
"folder_id"
],
"properties": {
"name": {
"type": "string",
"description": "New name"
},
"tree": {
"enum": [
"test-cases",
"test-runs",
"modules"
],
"type": "string",
"description": "Which folder tree the folder belongs to (default test-cases). \"modules\" is organization-level."
},
"folder_id": {
"type": "string",
"description": "Folder ID (ULID)"
},
"project_id": {
"type": "string",
"description": "Project ID (ULID) — required when moving a test-cases or test-runs folder; not used for modules"
},
"description": {
"type": "string",
"description": "New description"
},
"parent_folder_id": {
"type": "string",
"description": "Move under this folder (ULID), or pass \"root\" to make it a top-level folder; cannot be the folder itself or one of its descendants"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Update Folder",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description99/100
Generate structured test cases from a requirement or prompt using the Test Manager AI generator (applies the project's Memory Layer — Project & Org Instructions — automatically) and file them into the chosen folder. Requirement documents, specs, spreadsheets or screenshots can be attached via files to ground the generation. Volume = test_scenario_limit × per_scenario_test_cases_limit, capped at 50 per call. By default all generated cases are saved into the folder (one sub-folder per scenario); pass auto_save=false to review before saving. The call returns FAST with a request_id (and a browser progress URL) — generation takes ~30-90s in the background; call this tool again with just request_id to check progress, fetch results, or save. Note: consumes AI generation credits.
The description explains the capability, when to use it, and what to expect.
Inputs90/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project_id
Project ID (ULID). Required when starting a new generation.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
folder_id
Folder to file generated cases into. Required when starting a new generation.
Clear enough to supply this argument.
prompt
The requirement / instructions to generate test cases from. Required when starting a new generation.
Clear enough to supply this argument.
jira_ids
Optional Jira issue keys to use as requirement context
Clear enough to supply this argument.
files › items › name
File name with extension, e.g. requirements.pdf
Clear enough to supply this argument.
files › items › content_base64
File content, base64-encoded
Clear enough to supply this argument.
test_scenario_limit
Max scenarios to generate (default 3)
Clear enough to supply this argument.
per_scenario_test_cases_limit
Max test cases per scenario (default 3)
Clear enough to supply this argument.
auto_save
Save all generated cases into the folder automatically (default true for a NEW generation). Set false to review first — that choice persists across request_id polls (a bare poll never saves it); to save after review, call again with request_id AND auto_save=true.
Clear enough to supply this argument.
request_id
Resume/act on an earlier generation: check progress, fetch results, or save them.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
{
"title": "Generate Test Cases with AI",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
Output schema0/100
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_generate_test_cases",
"title": "Generate Test Cases with AI",
"description": "Generate structured test cases from a requirement or prompt using the Test Manager AI generator (applies the project's Memory Layer — Project & Org Instructions — automatically) and file them into the chosen folder. Requirement documents, specs, spreadsheets or screenshots can be attached via files to ground the generation. Volume = test_scenario_limit × per_scenario_test_cases_limit, capped at 50 per call. By default all generated cases are saved into the folder (one sub-folder per scenario); pass auto_save=false to review before saving. The call returns FAST with a request_id (and a browser progress URL) — generation takes ~30-90s in the background; call this tool again with just request_id to check progress, fetch results, or save. Note: consumes AI generation credits.",
"inputSchema": {
"type": "object",
"properties": {
"files": {
"type": "array",
"items": {
"type": "object",
"required": [
"name",
"content_base64"
],
"properties": {
"name": {
"type": "string",
"description": "File name with extension, e.g. requirements.pdf"
},
"content_base64": {
"type": "string",
"description": "File content, base64-encoded"
}
},
"additionalProperties": false
},
"maxItems": 5,
"description": "Optional reference files to ground the generation (requirement docs, specs, data sheets, screenshots). Each item carries the file name and its raw bytes base64-encoded in content_base64. Supported: .pdf, .docx, .txt, .csv, .xlsx, .json, .xml, .jpg, .jpeg, .png, .gif, .bmp, .webp; max 5 files, 10 MB each. Large files are better uploaded in the Test Manager UI, since the base64 content travels in the request. Only used when starting a new generation."
},
"prompt": {
"type": "string",
"description": "The requirement / instructions to generate test cases from. Required when starting a new generation."
},
"jira_ids": {
"type": "array",
"items": {
"type": "string"
},
"description": "Optional Jira issue keys to use as requirement context"
},
"auto_save": {
"type": "boolean",
"description": "Save all generated cases into the folder automatically (default true for a NEW generation). Set false to review first — that choice persists across request_id polls (a bare poll never saves it); to save after review, call again with request_id AND auto_save=true."
},
"folder_id": {
"type": "string",
"description": "Folder to file generated cases into. Required when starting a new generation."
},
"project_id": {
"type": "string",
"description": "Project ID (ULID). Required when starting a new generation."
},
"request_id": {
"type": "number",
"description": "Resume/act on an earlier generation: check progress, fetch results, or save them."
},
"test_scenario_limit": {
"type": "number",
"description": "Max scenarios to generate (default 3)"
},
"per_scenario_test_cases_limit": {
"type": "number",
"description": "Max test cases per scenario (default 3)"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Generate Test Cases with AI",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description87/100
Create a single test case in a project folder, with optional steps and references to existing step Modules (module steps are included; the Module itself is unchanged). For creating many cases from a requirement, prefer tm_generate_test_cases.
The description explains the capability, when to use it, and what to expect.
Inputs81/100
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
project_id
Project ID (ULID)
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
folder_id
Folder to file the case into
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
title
Test case title
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
description
What the case verifies
Clear enough to supply this argument.
priority
Lowest, Low, Medium, High or Highest
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
type
e.g. Functional, Regression, Smoke & Sanity
Explain the meaning of this value, not just its name.
status
e.g. Live, Unverified, Ready (default per project settings)
Explain what happens when this optional value is omitted.
preconditions
Setup required before the steps
Clear enough to supply this argument.
estimated_time
Estimated execution time in minutes
Clear enough to supply this argument.
automation_status
Automated, Not Automated or To Be Automated
Clear enough to supply this argument.
tags
Labels
Explain the meaning of this value, not just its name.
test_steps › items › action
What to do
Clear enough to supply this argument.
test_steps › items › outcome
Expected result
Clear enough to supply this argument.
test_steps › items › description
Optional extra detail — stored as an additional paragraph of the step text
Clear enough to supply this argument.
module_ids
Existing step Module ids to include (appended as module steps after test_steps)
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
The title clearly communicates the tool’s action and subject. Keep it concise.
Description85/100
Edit an existing test case (fields are merged — only what you pass changes). test_steps, when given, REPLACE the case's steps; module_ids append module reference steps. Deleting test cases is not available through this connection.
Explain mutations, irreversible effects, or prerequisites that matter before calling this tool.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
case_id
Test case ID (ULID)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project_id
Project ID (ULID)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
title
New title
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
description
New description
Explain the meaning of this value, not just its name.
priority
Lowest, Low, Medium, High or Highest
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
type
Test type
Explain the meaning of this value, not just its name.
status
e.g. Live, Archived, Faulty, Ready
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
preconditions
New preconditions
Explain the meaning of this value, not just its name.
estimated_time
Estimated minutes
Clear enough to supply this argument.
automation_status
Automated, Not Automated or To Be Automated
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
folder_id
Move to this folder
Clear enough to supply this argument.
tags
Replace tags
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
test_steps › items › action
What to do
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
test_steps › items › outcome
Expected result
Clear enough to supply this argument.
test_steps › items › description
Optional extra detail — stored as an additional paragraph of the step text
Clear enough to supply this argument.
module_ids
Existing step Module ids to append as module steps
Explain the meaning of this value, not just its name.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
The title clearly communicates the tool’s action and subject. Keep it concise.
Description90/100
Create a test run from chosen test cases — manual (default) or KaneAI (run_type: "kaneai"). Each included test case becomes a TEST RUN INSTANCE — the executable copy of that test inside the run, which carries its own status, remarks and exactly one Configuration. The cases must match the run type: KaneAI runs only take KaneAI-authored cases with completed code generation; manual runs only take manual cases. Optionally attach existing milestones, file into a run folder, and apply a Configuration to all instances (KaneAI configurations must be compatible with each case's platform — web/mobile-app/mobile-browser and iOS/Android).
The description explains the capability, when to use it, and what to expect.
Inputs73/100
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
project_id
Project ID (ULID)
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
title
Run title
Explain the meaning of this value, not just its name.
objective
What this run verifies
Clear enough to supply this argument.
run_type
Run type (default manual). "kaneai" creates a KaneAI run: only KaneAI-authored test cases can be included, and configurations must be kane-supported and platform-compatible.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
is_sequential
KaneAI runs only: execute the instances sequentially (default false).
Clear enough to supply this argument.
test_case_ids
Test case ids to include
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
milestone_ids
Existing milestone ids to attach the run to
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
folder_id
Test-run folder to file the run into
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
configuration_id
Apply ONE Configuration to every included test case (the configuration's top-level id from tm_list_configurations)
Clear enough to supply this argument.
configuration_ids
Apply MULTIPLE Configurations: each included test case gets one test run instance per configuration (case × configuration), like the UI's Add Configuration checkboxes
Clear enough to supply this argument.
assignee
Assign every created instance to this organization member: email, username, or user id. Omit to leave the instances unassigned.
Clear enough to supply this argument.
tags
Labels
Explain the meaning of this value, not just its name.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_create_test_run",
"title": "Create Test Run",
"description": "Create a test run from chosen test cases — manual (default) or KaneAI (run_type: \"kaneai\"). Each included test case becomes a TEST RUN INSTANCE — the executable copy of that test inside the run, which carries its own status, remarks and exactly one Configuration. The cases must match the run type: KaneAI runs only take KaneAI-authored cases with completed code generation; manual runs only take manual cases. Optionally attach existing milestones, file into a run folder, and apply a Configuration to all instances (KaneAI configurations must be compatible with each case's platform — web/mobile-app/mobile-browser and iOS/Android).",
"inputSchema": {
"type": "object",
"required": [
"project_id",
"title"
],
"properties": {
"tags": {
"type": "array",
"items": {
"type": "string"
},
"description": "Labels"
},
"title": {
"type": "string",
"description": "Run title"
},
"assignee": {
"type": "string",
"description": "Assign every created instance to this organization member: email, username, or user id. Omit to leave the instances unassigned."
},
"run_type": {
"enum": [
"manual",
"kaneai"
],
"type": "string",
"description": "Run type (default manual). \"kaneai\" creates a KaneAI run: only KaneAI-authored test cases can be included, and configurations must be kane-supported and platform-compatible."
},
"folder_id": {
"type": "string",
"description": "Test-run folder to file the run into"
},
"objective": {
"type": "string",
"description": "What this run verifies"
},
"project_id": {
"type": "string",
"description": "Project ID (ULID)"
},
"is_sequential": {
"type": "boolean",
"description": "KaneAI runs only: execute the instances sequentially (default false)."
},
"milestone_ids": {
"type": "array",
"items": {
"type": "string"
},
"description": "Existing milestone ids to attach the run to"
},
"test_case_ids": {
"type": "array",
"items": {
"type": "string"
},
"description": "Test case ids to include"
},
"configuration_id": {
"type": "number",
"description": "Apply ONE Configuration to every included test case (the configuration's top-level id from tm_list_configurations)"
},
"configuration_ids": {
"type": "array",
"items": {
"type": "number"
},
"description": "Apply MULTIPLE Configurations: each included test case gets one test run instance per configuration (case × configuration), like the UI's Add Configuration checkboxes"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Create Test Run",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description89/100
Update an open test run — overall status (Passed / Failed / Skipped / In Progress), title, objective, milestones, folder, add test cases (each added case becomes a new test run instance; cases must match the run's type — KaneAI or manual), apply a Configuration to the run's instances (configuration_id; on KaneAI runs it must be kane-supported and platform-compatible with the targeted cases), toggle sequential execution (KaneAI runs), or archive it. Only open (active) runs can be updated; a closed/archived run returns a clear message. Adding cases/milestones appends, never replaces.
The description explains the capability, when to use it, and what to expect.
Inputs79/100
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
run_id
Test run ID (ULID)
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
status
Set the run's OVERALL status (independent of per-instance results). Manual runs only — KaneAI run status is managed by KaneAI executions.
Clear enough to supply this argument.
title
New title
Explain the meaning of this value, not just its name.
objective
New objective
Explain the meaning of this value, not just its name.
milestone_ids
Milestone ids to attach (appended)
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
folder_id
Move to this run folder
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
is_sequential
KaneAI runs only: execute the instances sequentially.
Explain what happens when this optional value is omitted.
add_test_case_ids
Test case ids to add to the run (appended)
Clear enough to supply this argument.
configuration_id
Set ONE Configuration on the run's instances (the configuration's top-level id from tm_list_configurations; each instance carries exactly one configuration)
Clear enough to supply this argument.
configuration_ids
APPEND multiple Configurations: each targeted test case gets an additional instance per configuration (case × configuration, like the UI); existing configured instances are untouched
Clear enough to supply this argument.
assignee
Assign the run's instances to this organization member: email, username, or user id ("none" clears). Scope with apply_to_test_case_ids. Omit to keep the current assignee.
Clear enough to supply this argument.
apply_to_test_case_ids
With configuration_id or configuration_ids: only apply to these test cases (default: all instances in the run)
Clear enough to supply this argument.
archive
Archive (close) the run
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_update_test_run",
"title": "Update Test Run",
"description": "Update an open test run — overall status (Passed / Failed / Skipped / In Progress), title, objective, milestones, folder, add test cases (each added case becomes a new test run instance; cases must match the run's type — KaneAI or manual), apply a Configuration to the run's instances (configuration_id; on KaneAI runs it must be kane-supported and platform-compatible with the targeted cases), toggle sequential execution (KaneAI runs), or archive it. Only open (active) runs can be updated; a closed/archived run returns a clear message. Adding cases/milestones appends, never replaces.",
"inputSchema": {
"type": "object",
"required": [
"run_id"
],
"properties": {
"title": {
"type": "string",
"description": "New title"
},
"run_id": {
"type": "string",
"description": "Test run ID (ULID)"
},
"status": {
"enum": [
"Passed",
"Failed",
"Skipped",
"In Progress"
],
"type": "string",
"description": "Set the run's OVERALL status (independent of per-instance results). Manual runs only — KaneAI run status is managed by KaneAI executions."
},
"archive": {
"type": "boolean",
"description": "Archive (close) the run"
},
"assignee": {
"type": "string",
"description": "Assign the run's instances to this organization member: email, username, or user id (\"none\" clears). Scope with apply_to_test_case_ids. Omit to keep the current assignee."
},
"folder_id": {
"type": "string",
"description": "Move to this run folder"
},
"objective": {
"type": "string",
"description": "New objective"
},
"is_sequential": {
"type": "boolean",
"description": "KaneAI runs only: execute the instances sequentially."
},
"milestone_ids": {
"type": "array",
"items": {
"type": "string"
},
"description": "Milestone ids to attach (appended)"
},
"configuration_id": {
"type": "number",
"description": "Set ONE Configuration on the run's instances (the configuration's top-level id from tm_list_configurations; each instance carries exactly one configuration)"
},
"add_test_case_ids": {
"type": "array",
"items": {
"type": "string"
},
"description": "Test case ids to add to the run (appended)"
},
"configuration_ids": {
"type": "array",
"items": {
"type": "number"
},
"description": "APPEND multiple Configurations: each targeted test case gets an additional instance per configuration (case × configuration, like the UI); existing configured instances are untouched"
},
"apply_to_test_case_ids": {
"type": "array",
"items": {
"type": "string"
},
"description": "With configuration_id or configuration_ids: only apply to these test cases (default: all instances in the run)"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Update Test Run",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description97/100
Record execution results on a MANUAL run's TEST RUN INSTANCES (the per-run copies of each test case) — max 500 per request, all-or-nothing (larger requests are rejected with nothing recorded). Manual runs only: KaneAI run results are recorded by KaneAI executions, so manual entry on a KaneAI run is rejected. Target an instance by instance_id, or just pass test_case_id and the instance is resolved automatically. Valid statuses: Passed, Failed, Skipped, Not Started (terminal — run-level "In Progress" is set via tm_update_test_run). Re-recording a step status replaces its result: an omitted step remark is cleared; response echoes per-step outcomes. Optional remarks and assignee per result, and per-step results via steps[] (mark individual test steps / BDD scenario rows Passed/Failed/Skipped with remarks, like the UI's per-step Mark Status). Note: this sets INSTANCE statuses; the run's overall status is set separately via tm_update_test_run.
The description explains the capability, when to use it, and what to expect.
Inputs89/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
run_id
Test run ID (ULID)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
results › items › instance_id
Run-instance id (from tm_get_test_runs detail)
Clear enough to supply this argument.
results › items › test_case_id
Alternative to instance_id: the test case ULID
Clear enough to supply this argument.
results › items › status
Passed, Failed, Skipped or Not Started (instance results are terminal — "In Progress" applies only to the run's overall status via tm_update_test_run)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
results › items › remarks
Optional note (e.g. failure detail)
Clear enough to supply this argument.
results › items › assignee
Assign this instance to an organization member (email, username, or user id; "none" clears). Omit to keep the current assignee.
Clear enough to supply this argument.
results › items › steps › items › step
Step number (1-based, in the order shown on the case/instance)
Clear enough to supply this argument.
results › items › steps › items › status
Passed, Failed or Skipped
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
results › items › steps › items › remarks
Optional step remark
Explain what happens when this optional value is omitted.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_record_test_results",
"title": "Record Test Results (Bulk)",
"description": "Record execution results on a MANUAL run's TEST RUN INSTANCES (the per-run copies of each test case) — max 500 per request, all-or-nothing (larger requests are rejected with nothing recorded). Manual runs only: KaneAI run results are recorded by KaneAI executions, so manual entry on a KaneAI run is rejected. Target an instance by instance_id, or just pass test_case_id and the instance is resolved automatically. Valid statuses: Passed, Failed, Skipped, Not Started (terminal — run-level \"In Progress\" is set via tm_update_test_run). Re-recording a step status replaces its result: an omitted step remark is cleared; response echoes per-step outcomes. Optional remarks and assignee per result, and per-step results via steps[] (mark individual test steps / BDD scenario rows Passed/Failed/Skipped with remarks, like the UI's per-step Mark Status). Note: this sets INSTANCE statuses; the run's overall status is set separately via tm_update_test_run.",
"inputSchema": {
"type": "object",
"required": [
"run_id",
"results"
],
"properties": {
"run_id": {
"type": "string",
"description": "Test run ID (ULID)"
},
"results": {
"type": "array",
"items": {
"type": "object",
"required": [
"status"
],
"properties": {
"steps": {
"type": "array",
"items": {
"type": "object",
"required": [
"step"
],
"properties": {
"step": {
"type": "number",
"description": "Step number (1-based, in the order shown on the case/instance)"
},
"status": {
"type": "string",
"description": "Passed, Failed or Skipped"
},
"remarks": {
"type": "string",
"description": "Optional step remark"
}
},
"additionalProperties": false
},
"description": "Optional per-step results: mark individual test steps (or BDD scenario rows) of this instance, like the UI's per-step Mark Status"
},
"status": {
"type": "string",
"description": "Passed, Failed, Skipped or Not Started (instance results are terminal — \"In Progress\" applies only to the run's overall status via tm_update_test_run)"
},
"remarks": {
"type": "string",
"description": "Optional note (e.g. failure detail)"
},
"assignee": {
"type": "string",
"description": "Assign this instance to an organization member (email, username, or user id; \"none\" clears). Omit to keep the current assignee."
},
"instance_id": {
"type": "number",
"description": "Run-instance id (from tm_get_test_runs detail)"
},
"test_case_id": {
"type": "string",
"description": "Alternative to instance_id: the test case ULID"
}
},
"additionalProperties": false
},
"description": "Results to record (max 500)"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Record Test Results (Bulk)",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description82/100
Update a milestone — title, description, dates, tags — or change its status (e.g. mark it Completed). Deleting milestones is not available through this connection.
Explain mutations, irreversible effects, or prerequisites that matter before calling this tool.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
milestone_id
Milestone ID (ULID)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project_id
Project ID (ULID)
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
title
New title
Explain the meaning of this value, not just its name.
description
New description
Explain the meaning of this value, not just its name.
start_at
Start date (YYYY-MM-DD)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
end_at
End date (YYYY-MM-DD)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
tags
Replace tags
Clear enough to supply this argument.
status
New status: Open (reopen) or Complete — the UI's two milestone states. "Active" and "Completed" are accepted as aliases and normalized to Open/Complete (any other stored value hides the milestone from the UI lists).
Clear enough to supply this argument.
owner
Change the milestone Owner — an organization member (email, username, or user id).
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_update_milestone",
"title": "Update Milestone",
"description": "Update a milestone — title, description, dates, tags — or change its status (e.g. mark it Completed). Deleting milestones is not available through this connection.",
"inputSchema": {
"type": "object",
"required": [
"milestone_id",
"project_id"
],
"properties": {
"tags": {
"type": "array",
"items": {
"type": "string"
},
"description": "Replace tags"
},
"owner": {
"type": "string",
"description": "Change the milestone Owner — an organization member (email, username, or user id)."
},
"title": {
"type": "string",
"description": "New title"
},
"end_at": {
"type": "string",
"description": "End date (YYYY-MM-DD)"
},
"status": {
"type": "string",
"description": "New status: Open (reopen) or Complete — the UI's two milestone states. \"Active\" and \"Completed\" are accepted as aliases and normalized to Open/Complete (any other stored value hides the milestone from the UI lists)."
},
"start_at": {
"type": "string",
"description": "Start date (YYYY-MM-DD)"
},
"project_id": {
"type": "string",
"description": "Project ID (ULID)"
},
"description": {
"type": "string",
"description": "New description"
},
"milestone_id": {
"type": "string",
"description": "Milestone ID (ULID)"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Update Milestone",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description95/100
Link a test case, test run, or a run result (instance) to a Jira issue (requirement / user story / epic / bug) — linked test cases are what give the issue its test coverage and traceability. Linking a result also links its case and run. Requires the Jira integration to be set up for the organization — otherwise a clear "set up Jira first" message is returned.
The description explains the capability, when to use it, and what to expect.
Inputs92/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
entity_type
What to link
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
entity_id
Id of the case (ULID), run (ULID) or instance (number as string)
Clear enough to supply this argument.
issue_id
Jira issue key, e.g. TE-123
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_link_jira_issue",
"title": "Link Jira Issue",
"description": "Link a test case, test run, or a run result (instance) to a Jira issue (requirement / user story / epic / bug) — linked test cases are what give the issue its test coverage and traceability. Linking a result also links its case and run. Requires the Jira integration to be set up for the organization — otherwise a clear \"set up Jira first\" message is returned.",
"inputSchema": {
"type": "object",
"required": [
"entity_type",
"entity_id",
"issue_id"
],
"properties": {
"issue_id": {
"type": "string",
"description": "Jira issue key, e.g. TE-123"
},
"entity_id": {
"type": "string",
"description": "Id of the case (ULID), run (ULID) or instance (number as string)"
},
"entity_type": {
"enum": [
"test_case",
"test_run",
"test_run_instance"
],
"type": "string",
"description": "What to link"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Link Jira Issue",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description95/100
Link a test case, test run, or a run result (instance) to an Azure DevOps work item (requirement / user story / bug) by its URL — linked test cases are what give the work item its test coverage and traceability. Requires the Azure DevOps integration to be set up for the organization — otherwise a clear "set up Azure DevOps first" message is returned.
The description explains the capability, when to use it, and what to expect.
Inputs81/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
entity_type
What to link
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
entity_id
Id of the case (ULID), run (ULID) or instance (number as string)
Clear enough to supply this argument.
project_id
Project ID (ULID) the entity belongs to
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
work_item_url
The Azure DevOps work item URL, e.g. https://dev.azure.com/<organization>/<project>/_workitems/edit/165
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "tm_link_ado_issue",
"title": "Link Azure DevOps Work Item",
"description": "Link a test case, test run, or a run result (instance) to an Azure DevOps work item (requirement / user story / bug) by its URL — linked test cases are what give the work item its test coverage and traceability. Requires the Azure DevOps integration to be set up for the organization — otherwise a clear \"set up Azure DevOps first\" message is returned.",
"inputSchema": {
"type": "object",
"required": [
"entity_type",
"entity_id",
"project_id",
"work_item_url"
],
"properties": {
"entity_id": {
"type": "string",
"description": "Id of the case (ULID), run (ULID) or instance (number as string)"
},
"project_id": {
"type": "string",
"description": "Project ID (ULID) the entity belongs to"
},
"entity_type": {
"enum": [
"test_case",
"test_run",
"test_run_instance"
],
"type": "string",
"description": "What to link"
},
"work_item_url": {
"type": "string",
"description": "The Azure DevOps work item URL, e.g. https://dev.azure.com/<organization>/<project>/_workitems/edit/165"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Link Azure DevOps Work Item",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description95/100
List SmartUI projects, or get one project with its settings — action=get returns baseline_branch, approvers[], smart_baseline, auto_approval_branch, overwrite_screenshot and project_category alongside platform and project_type. Start here when you do not have a project_id. Read-only.
The description explains the capability, when to use it, and what to expect.
Inputs80/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
action
list all projects, or get one by project_id
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project_id
Project id — required for action=get
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
search
Case-insensitive substring filter on project name (list only)
Clear enough to supply this argument.
limit
Page size (list only, default 50, max 200)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
page
Page number (list only, 1-based)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
The title clearly communicates the tool’s action and subject. Keep it concise.
Description97/100
List SmartUI builds in a project, get one build, or get the CI gate verdict for a build. Use action=gate in pipelines: it returns verdict (passed|failed|pending_approval|running|error), totals (including missing screenshots the baseline has), blocking_comparison_ids, and blocking[] with per-item detail. verdict=failed covers rejections AND builds that dropped baseline screenshots. Read-only.
The description explains the capability, when to use it, and what to expect.
Inputs81/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
action
list builds, get one build, or gate (CI verdict)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project_id
Project id (required)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
build_id
Build id — required for get/gate (or use build_name)
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
build_name
Build name — alternative to build_id for get/gate
Clear enough to supply this argument.
build_status
Substring filter on build status (list only), e.g. "pending-approval"
Clear enough to supply this argument.
branch
Filter builds by branch (list only)
Clear enough to supply this argument.
limit
Page size (list only, default 50, max 200)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
page
Page number (list only, 1-based)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
The title clearly communicates the tool’s action and subject. Keep it concise.
Description98/100
List all comparisons in a SmartUI build (each row returns comparison_id AND ss_id), or get one comparison's detail (mismatch %, status, correctly-labelled baseline/current/compared asset URLs). This is how you obtain a comparison_id — you never need the dashboard. Read-only.
The description explains the capability, when to use it, and what to expect.
Inputs81/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
action
list comparisons in a build, or get one by comparison_id
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project_id
Project id — required for action=list
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
build_id
Build id — required for action=list
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
comparison_id
Comparison id — required for action=get
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
status
Filter by status (list only), e.g. "changes_found", "approved"
Clear enough to supply this argument.
min_mismatch
Only comparisons with mismatch_percentage >= this (list only)
Clear enough to supply this argument.
limit
Page size (list only, default 50, max 200)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
page
Page number (list only, 1-based)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
The title clearly communicates the tool’s action and subject. Keep it concise.
Description98/100
Analyze one SmartUI comparison through a lens: consolidated (default), pixel, or dom. Returns the comparison data (mismatch %, verdict, correctly-labelled asset URLs) plus, for lens=dom, a real DOM byte delta when the artefact is served — no local filesystem needed. consolidated and pixel report upstream numbers and point at the assets; they do not run their own image analysis. lens=dom degrades to a structured error when DOM artefacts are not served. Read-only.
The description explains the capability, when to use it, and what to expect.
Inputs92/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
comparison_id
Comparison id (required) — from smartui_comparison_query
Clear enough to supply this argument.
lens
Analysis lens (default consolidated). layout and perceptual were retired — they returned the consolidated payload unchanged.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
include_assets
urls (default) returns asset URLs only. inline additionally attaches the screenshots themselves as image blocks — compared only for lens=pixel, baseline+current+compared for consolidated, none for lens=dom. Use inline when you cannot fetch URLs.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "smartui_comparison_analyze",
"title": "SmartUI Comparison Analyze",
"description": "Analyze one SmartUI comparison through a lens: consolidated (default), pixel, or dom. Returns the comparison data (mismatch %, verdict, correctly-labelled asset URLs) plus, for lens=dom, a real DOM byte delta when the artefact is served — no local filesystem needed. consolidated and pixel report upstream numbers and point at the assets; they do not run their own image analysis. lens=dom degrades to a structured error when DOM artefacts are not served. Read-only.",
"inputSchema": {
"type": "object",
"required": [
"comparison_id"
],
"properties": {
"lens": {
"enum": [
"consolidated",
"pixel",
"dom"
],
"type": "string",
"description": "Analysis lens (default consolidated). layout and perceptual were retired — they returned the consolidated payload unchanged."
},
"comparison_id": {
"type": "string",
"description": "Comparison id (required) — from smartui_comparison_query"
},
"include_assets": {
"enum": [
"urls",
"inline"
],
"type": "string",
"description": "urls (default) returns asset URLs only. inline additionally attaches the screenshots themselves as image blocks — compared only for lens=pixel, baseline+current+compared for consolidated, none for lens=dom. Use inline when you cannot fetch URLs."
}
},
"additionalProperties": false
},
"annotations": {
"title": "SmartUI Comparison Analyze",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description98/100
Upload screenshots to a SmartUI project as a new build, from local file_paths or from source_urls (fetched server-side, so it works without a client filesystem). Pass project_id to auto-resolve the project token. Set mark_baseline=true to seed a baseline. Returns build_id; follow with smartui_build_query(action=gate).
The description explains the capability, when to use it, and what to expect.
Inputs79/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
action
What to upload (currently images)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project_id
Project id — preferred; the projectToken is resolved automatically
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
file_paths
Absolute local image paths (.png/.jpg/.jpeg). Only usable when the MCP server runs locally over stdio — the hosted server cannot see your filesystem; use source_urls there.
Clear enough to supply this argument.
source_urls
Public http/https image URLs, fetched server-side (max 20). Works in hosted mode.
Clear enough to supply this argument.
build_name
Name for this build (optional)
Explain what happens when this optional value is omitted.
mark_baseline
Mark this build as the baseline
Explain the meaning of this value, not just its name.
screenshot_name
Name this screenshot (binds it to that baseline) instead of using the file/URL name. Only valid when uploading exactly one image.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "smartui_screenshot_upload",
"title": "SmartUI Screenshot Upload",
"description": "Upload screenshots to a SmartUI project as a new build, from local file_paths or from source_urls (fetched server-side, so it works without a client filesystem). Pass project_id to auto-resolve the project token. Set mark_baseline=true to seed a baseline. Returns build_id; follow with smartui_build_query(action=gate).",
"inputSchema": {
"type": "object",
"required": [
"action"
],
"properties": {
"action": {
"enum": [
"images"
],
"type": "string",
"description": "What to upload (currently images)"
},
"build_name": {
"type": "string",
"description": "Name for this build (optional)"
},
"file_paths": {
"type": "array",
"items": {
"type": "string"
},
"description": "Absolute local image paths (.png/.jpg/.jpeg). Only usable when the MCP server runs locally over stdio — the hosted server cannot see your filesystem; use source_urls there."
},
"project_id": {
"type": "string",
"description": "Project id — preferred; the projectToken is resolved automatically"
},
"source_urls": {
"type": "array",
"items": {
"type": "string"
},
"description": "Public http/https image URLs, fetched server-side (max 20). Works in hosted mode."
},
"mark_baseline": {
"type": "boolean",
"description": "Mark this build as the baseline"
},
"screenshot_name": {
"type": "string",
"description": "Name this screenshot (binds it to that baseline) instead of using the file/URL name. Only valid when uploading exactly one image."
}
},
"additionalProperties": false
},
"annotations": {
"title": "SmartUI Screenshot Upload",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description96/100
Approve or reject SmartUI comparisons — individually (comparison_ids or ss_ids), or for a whole build (all_matching:{status}). Ids are validated against the build before writing, and results are verified by re-reading status, so the response reports real per-item updated[]/failed[] and whether the baseline was promoted. Approving comparisons on the baseline branch can promote the build to baseline.
The description explains the capability, when to use it, and what to expect.
Inputs71/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
action
approve or reject the selected comparisons
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project_id
Project id (required)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
build_id
Build id the comparisons belong to (required)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
comparison_ids
Comparison ids to review (resolved to ss_ids server-side)
Clear enough to supply this argument.
ss_ids
Screenshot-variant ids to review directly
Clear enough to supply this argument.
all_matching › status
e.g. "changes_found", "under_review"
Resolve the mismatch between this description and its schema constraints.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
Name the specific action and subject instead of using a generic label such as ‘manage’ or ‘tool’.
Description97/100
Merge SmartUI baselines across branches or builds (to read baseline settings, use smartui_project_query with action=get). merge_branch/merge_build resolve source and target names to builds, merge them, then poll the merged build and report its real terminal status — a merge that lands in error or with zero screenshots is returned as a tool error, not as success. Merging permanently changes baseline state: the merged build takes the baseline flag, so a failed merge leaves the baseline on an empty build.
The description explains the capability, when to use it, and what to expect.
Inputs67/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
action
merge_branch merges one branch baseline into another; merge_build merges one build into another
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
project_id
Project id (required)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
source
Source branch (merge_branch) or build name (merge_build) to merge FROM
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
target
Target branch (merge_branch) or build name (merge_build) to merge INTO
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "smartui_baseline_manage",
"title": "SmartUI Baseline Manage",
"description": "Merge SmartUI baselines across branches or builds (to read baseline settings, use smartui_project_query with action=get). merge_branch/merge_build resolve source and target names to builds, merge them, then poll the merged build and report its real terminal status — a merge that lands in error or with zero screenshots is returned as a tool error, not as success. Merging permanently changes baseline state: the merged build takes the baseline flag, so a failed merge leaves the baseline on an empty build.",
"inputSchema": {
"type": "object",
"required": [
"action",
"project_id"
],
"properties": {
"action": {
"enum": [
"merge_branch",
"merge_build"
],
"type": "string",
"description": "merge_branch merges one branch baseline into another; merge_build merges one build into another"
},
"source": {
"type": "string",
"description": "Source branch (merge_branch) or build name (merge_build) to merge FROM"
},
"target": {
"type": "string",
"description": "Target branch (merge_branch) or build name (merge_build) to merge INTO"
},
"project_id": {
"type": "string",
"description": "Project id (required)"
}
},
"additionalProperties": false
},
"annotations": {
"title": "SmartUI Baseline Manage",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description98/100
Get an authenticated download URL (plus size/status metadata) for a specific HyperExecute job artifact. Requires artefactName (from getHyperExecuteJobArtifacts); optionally scope to a task with taskId. Returns a URL to fetch with your LambdaTest credentials rather than the raw file bytes.
The description explains the capability, when to use it, and what to expect.
Inputs92/100
Explain what happens when this optional value is omitted.
jobId
The HyperExecute job ID whose artifact to download
Clear enough to supply this argument.
artefactName
Name of the artifact to download (as returned by getHyperExecuteJobArtifacts)
Clear enough to supply this argument.
taskId
Optional: scope the artifact to a specific task ID
Explain what happens when this optional value is omitted.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "downloadJobArtifact",
"title": "Download Job Artifact",
"description": "Get an authenticated download URL (plus size/status metadata) for a specific HyperExecute job artifact. Requires artefactName (from getHyperExecuteJobArtifacts); optionally scope to a task with taskId. Returns a URL to fetch with your LambdaTest credentials rather than the raw file bytes.",
"inputSchema": {
"type": "object",
"required": [
"jobId",
"artefactName"
],
"properties": {
"jobId": {
"type": "string",
"description": "The HyperExecute job ID whose artifact to download"
},
"taskId": {
"type": "string",
"description": "Optional: scope the artifact to a specific task ID"
},
"artefactName": {
"type": "string",
"description": "Name of the artifact to download (as returned by getHyperExecuteJobArtifacts)"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Download Job Artifact",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description78/100
Retrieve the stages of a HyperExecute task (cache/prerun/scenario/etc.). Pass a stageId to return just that one stage. Stages are keyed by their parent task, so taskId is required.
Describe the returned information so the agent knows whether it will answer the request.
Inputs84/100
Input documentation gives an agent enough context to populate the arguments.
taskId
The HyperExecute task ID whose stages to fetch
Clear enough to supply this argument.
stageId
Optional: return only the stage with this ID
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "getHyperExecuteStage",
"title": "Get HyperExecute Stage",
"description": "Retrieve the stages of a HyperExecute task (cache/prerun/scenario/etc.). Pass a stageId to return just that one stage. Stages are keyed by their parent task, so taskId is required.",
"inputSchema": {
"type": "object",
"required": [
"taskId"
],
"properties": {
"taskId": {
"type": "string",
"description": "The HyperExecute task ID whose stages to fetch"
},
"stageId": {
"type": "string",
"description": "Optional: return only the stage with this ID"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Get HyperExecute Stage",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description99/100
Perform a full analysis of a HyperExecute job: fetches job info, sessions, traverses all tasks → scenario stages → console logs, and returns a structured report with test results, per-scenario logs, and pass/fail statistics. Use this for questions like "which tests failed and why" or "show me the console logs for job X".
The description explains the capability, when to use it, and what to expect.
Inputs50/100
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
jobId
The HyperExecute job ID to analyze
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "analyzeHyperExecuteJob",
"title": "Analyze HyperExecute Job",
"description": "Perform a full analysis of a HyperExecute job: fetches job info, sessions, traverses all tasks → scenario stages → console logs, and returns a structured report with test results, per-scenario logs, and pass/fail statistics. Use this for questions like \"which tests failed and why\" or \"show me the console logs for job X\".",
"inputSchema": {
"type": "object",
"required": [
"jobId"
],
"properties": {
"jobId": {
"type": "string",
"description": "The HyperExecute job ID to analyze"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Analyze HyperExecute Job",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
Loading score analytics…
Put your MCP to the test
A few tasks worth trying with this server, chosen from its reviewed tools. These have not been run.
01Get Test TrendsDaily trend of automation test results in a date range: for each day, total tests, passed, failed, completed without a pass/fail mark, pass rate (over tests…
02List Test Manager ProjectsList all Test Manager projects the authenticated user is allowed to see.
03Get Supported PlatformsLists the OS, browser and device combinations LambdaTest supports, to find valid os, browser and version values for a test configuration.
04Answer HyperExecute QuestionAnswers questions about HyperExecute features, configuration, usage, troubleshooting, and best practices by searching through documentation.
05Get Analytics DataSummarises automation test results in a date range: total tests, passed, failed, completed without a pass/fail mark, pass rate (over tests marked passed or f…
Want to run these tasks against your MCP server with us?
MCP Lambdatest setup, tools, quality score, publishing readiness, and alternatives.
How do I add MCP Lambdatest to Claude, ChatGPT, or Cursor?
Add MCP Lambdatest to Claude, ChatGPT, or Cursor by connecting its remote MCP URL in each client's MCP settings. In Claude, add a custom connector. In ChatGPT, add an MCP app. In Cursor, add an MCP server under Settings. The MCP URL is https://mcp.lambdatest.com/mcp.
Is MCP Lambdatest MCP ready for ChatGPT and Claude?
As of October 16, 2026, MCP Lambdatest scores 82/100 on Manufact's MCP publishing checklist. The scan does not yet meet ChatGPT publishing checks and does not yet meet Claude publishing checks. Passing these checks does not guarantee marketplace approval.
How clear is MCP Lambdatest's MCP tool documentation?
As of October 16, 2026, MCP Lambdatest scores 75/100 in Manufact's review of tool titles, descriptions, input and output schemas, and behavior annotations. The review covers 88 of 88 discovered tools. The quality score measures documentation clarity; runtime behavior and marketplace readiness require separate checks.
What are the best alternatives to MCP Lambdatest?
As of October 16, 2026, alternatives to MCP Lambdatest in developer-tools on the Manufact MCP catalog include Held at the Gate, Speko, turva.dev, AgentMail, and Celesto Cloud Computers.
How can MCP Lambdatest improve its MCP documentation?
getAutomationTestDetails is the lowest-scoring reviewed tool at 60/100. No output schema is declared. Add one for structured results so clients can interpret returned fields. Open its review for feedback and a copyable fix prompt, then rerun the documentation review after updating your tool metadata.
Not your MCP?
Review any public or OAuth MCP server for protocol compatibility, tool documentation, and ChatGPT and Claude publishing readiness. No account required.