Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@devicecloud-mcp diagnose the most recent failed run"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Triage failing DeviceCloud runs so your agent can fix them, without opening the dashboard.
When a DeviceCloud run goes red in CI, the reason why is buried in the web dashboard: the fail reason, the failure screenshot, the logs. This server pulls all of it straight into your editor, so your AI assistant (Claude Code, Cursor, Claude Desktop, etc.) can read the evidence, find the root cause, and fix the flow or app code. You commit, CI re-runs, and the dashboard stays closed.
DeviceCloud is a platform for running Maestro flows on real devices. Your CI triggers the runs; this server is how you debug the ones that fail.
It lets the assistant:
diagnose a run in one call: failed flows, fail reasons, failure-screenshot paths, and a passed/failed/flaky summary, ready to act on
rank suite health: classify every flow as healthy, flaky, broken, or regression over a window so you know what's worth fixing first
list recent uploads, filter by name (commit message + short SHA) or date
read per-flow status and failReason for any upload
pull the JUnit XML report
download and auto-unzip the HTML report (with failure screenshots highlighted)
download raw artifacts (logs, screenshots, video) as a zip
spot flaky vs genuinely-broken flows with per-flow pass-rate analytics
drill into run history for a specific flow file
The server is read-only against the DeviceCloud REST API: no dcd CLI dependency, and nothing an agent does can trigger billable runs. Triggering and re-running tests stay with your CI; cancelling a run stays in the dashboard.
Requires Node.js 22+ — check with node --version. There's no separate install step; the server runs on demand via npx.
Add this to your MCP client config:
{
"mcpServers": {
"devicecloud": {
"command": "npx",
"args": ["-y", "devicecloud-mcp"],
"env": {
"DEVICE_CLOUD_API_KEY": "<your-key>"
}
}
}
}Get your API key at console.devicecloud.dev/settings.
Skip editing JSON — register the server in one step:
claude mcp add devicecloud --env DEVICE_CLOUD_API_KEY=<your-key> -- npx -y devicecloud-mcpAdd -s user to make it available in every project instead of only the current one.
Related MCP server: kobiton
The config block above is the same for every client; only the file location differs.
.mcp.json)Add to a .mcp.json at the root of any project where you want the tools available:
{
"mcpServers": {
"devicecloud": {
"command": "npx",
"args": ["-y", "devicecloud-mcp"],
"env": {
"DEVICE_CLOUD_API_KEY": "${DEVICE_CLOUD_API_KEY}"
}
}
}
}Then export the key from your shell profile so Claude Code's child process inherits it:
# ~/.zshrc or ~/.bashrc
export DEVICE_CLOUD_API_KEY="<your-key>"Setting it only in an interactive shell isn't enough; Claude Code spawns the MCP from its own environment, so the variable needs to be in the profile.
~/.claude.json)If you want it available everywhere instead of per-project, add the same devicecloud block under mcpServers in ~/.claude.json.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows). Restart Claude Desktop after saving; a tools icon appears in the chat input once the server connects.
Add to ~/.cursor/mcp.json (global) or .cursor/mcp.json at the project root (project-scoped).
Edit ~/.codeium/windsurf/mcp_config.json.
Any client that supports stdio MCP servers uses the same { command, args, env } shape. Consult the client's docs for the config file location.
Note: OpenAI products (ChatGPT, Codex, the Assistants API) use their own tool protocol and do not support MCP servers.
After restarting your assistant:
List recent DeviceCloud uploads, limit 3.You should see a JSON-shaped response with an uploads array. If instead you get DEVICE_CLOUD_API_KEY env var is required, the variable isn't reaching the spawned process; re-check that it's exported from your shell profile (not just the current shell).
Tool | Purpose |
| Start here. One-call triage of a run ( |
| Classify every flow over a lookback window into healthy, flaky, broken, or regression, ranked worst-first, so you can tell whether a failure is worth fixing before diving in. Regressions (passing, then recently failing) come first. Same filters as |
| List recent uploads. Filter by |
| Overall status + per-test status, duration, |
| Per-flow rows for one upload: |
| Raw JUnit XML for an upload. |
| Downloads + auto-unzips the HTML report. Returns the extraction dir and an inventory with |
| Zip of raw artifacts (logs, screenshots, video). |
| Per-flow pass rate, run counts, avg duration over a lookback window (default 14 days). Useful to tell flakes from genuinely-broken flows. |
| Individual run history for one flow file ( |
Uploads are typically named after the commit or build that triggered them. A common convention is to include the short SHA:
fix(login): handle expired session (a1b2c3d4)Filter with name = "*a1b2c3d4*" to find every upload for a specific commit. The wildcard is *, not %.
DeviceCloud uploads are created when you trigger a run, via the CLI, a CI step, the GitHub Action, or the API directly. Whether a given commit has an upload depends entirely on your CI setup. If list_uploads returns nothing for a SHA you expect, the run probably wasn't triggered for that commit.
DEVICE_CLOUD_API_KEY env var is required: the variable isn't visible to the spawned MCP. Export it from ~/.zshrc / ~/.bashrc, restart your assistant.
unzip failed (from get_html_report): the unzip binary is missing or crashed. Install with brew install unzip (macOS ships with it; Linux usually does too).
HTTP 401 / 403: the API key is wrong or revoked. Regenerate it at console.devicecloud.dev/settings.
Empty list_uploads for your SHA: a run probably wasn't triggered for that commit. See "When uploads do and don't exist" above.
Triage one DeviceCloud run in a single call. Resolves the upload, folds retries per flow, and returns the failed flows with fail reasons, durations, and failure-screenshot paths (auto-downloaded from the HTML report), plus a passed/failed/flaky summary and suggested next steps. The highest-signal tool for debugging a red CI run — use this first, then read the screenshots and fix the flow or app code.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Upload name; most recent match wins. Provide this or uploadId. | |
| uploadId | No | Upload UUID. Provide this or name. | |
| outputDir | No | Parent directory for the extracted report. Defaults to /tmp. | |
| includeReport | No | Download + unzip the HTML report to surface failure screenshots. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses the tool's behavior: resolves uploads, folds retries, returns failed flows with reasons/durations, auto-downloads screenshot paths from the HTML report, and gives a summary. No hidden side effects; the agent understands exactly what the tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first densely packs the tool's actions and outputs, the second gives usage priority. No unnecessary words; information is front-loaded and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains return values (failed flow details, screenshots, summary, next steps). It covers all 4 parameters (described in schema) and provides context for CI debugging. The tool's complexity is low (no enums, no nested objects), and the description is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add meaningful parameter-level information beyond what the schema already provides (e.g., defaults for outputDir and includeReport, or the 'most recent match wins' behavior for name). It integrates parameters into the workflow but does not enhance understanding of individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'triages one DeviceCloud run' and enumerates specific actions: resolving uploads, folding retries, returning failed flows with details. It distinguishes itself from sibling tools like list_uploads or get_results by positioning as the highest-signal tool for debugging a red CI run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'use this first, then read the screenshots and fix the flow or app code', providing clear context for when to use (debugging a failed run). Does not explicitly list when not to use, but the guidance is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download raw run artifacts (logs, screenshots, videos) as a ZIP. Use when the HTML report doesn't contain enough detail (e.g. need full logcat, video recording, or non-failure screenshots).
| Name | Required | Description | Default |
|---|---|---|---|
| results | No | Whether to download only failed flows' artifacts or all. | FAILED |
| uploadId | Yes | ||
| outputDir | No | Directory for the zip. Defaults to /tmp. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions output is a ZIP but does not disclose any potential side effects, required permissions, rate limits, or error handling (e.g., what if uploadId does not exist). For a download operation, more transparency on expected behavior is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with purpose and usage context. Highly efficient and structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers basic purpose and usage, it lacks details on return format (ZIP binary stream), potential errors, and prerequisites. Given no output schema and moderate schema coverage, a bit more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with uploadId missing schema description. The description adds no new information about parameters beyond what the schema already states (e.g., results enum, outputDir default). Does not explain uploadId or results semantics further, which would help the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Download raw run artifacts (logs, screenshots, videos) as a ZIP' with a specific verb and resource. Explicitly contrasts with sibling tools like get_html_report by specifying when to use this tool (when HTML report lacks detail).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit guidance on when to use ('Use when the HTML report doesn't contain enough detail') and gives concrete examples (need full logcat, video recording, non-failure screenshots). Implies not to use when HTML report suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List individual runs for a specific Maestro flow file. Returns id, status, createdAt, durationSeconds, failReason, testUploadId, uploadName per run. Use to drill into the history of one flow — e.g. after list_flow_analytics surfaces a flaky or broken flow.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | No | Filter by app bundle id. | |
| limit | No | Max runs to return. | |
| endDate | No | ISO 8601 end of range. | |
| fileName | Yes | Flow file name to look up (e.g. login.yaml). | |
| platform | No | Filter by platform. | |
| startDate | No | ISO 8601 start of range. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description indicates a read operation listing runs, which is reasonable. However, it does not disclose potential behavioral traits like pagination, sorting defaults, or rate limits, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with essential info: purpose and return fields, followed by usage context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, return fields, and use case. Lacks explanation of output shape beyond field names (no output schema), but for a list tool with clear field list, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are documented. Description does not add extra parameter meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists runs for a specific Maestro flow file, enumerates return fields, and distinguishes from sibling tool 'list_flow_analytics' by specifying the drill-down use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly suggests when to use: after list_flow_analytics surfaces a problematic flow. Lacks explicit 'when not to use' or alternatives, but context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download AND auto-unzip the HTML report (HTML + screenshots + logs) for an upload. Returns the local extraction directory and an inventory of files, with failure screenshots highlighted at the top — those are typically the highest-signal artifact for debugging.
| Name | Required | Description | Default |
|---|---|---|---|
| uploadId | Yes | ||
| outputDir | No | Parent directory for the extracted report. Defaults to /tmp. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses key behaviors: automatic unzipping, return of local directory and inventory, and emphasis on failure screenshots. It does not mention async behavior, auth, or rate limits, but the core behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the action, output, and a key feature. It is front-loaded with the main action and ends with a notable detail. Slightly more structure could improve readability, but it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, no output schema, and no annotations, the description covers purpose, output format, and a key debugging hint. It lacks error scenarios or prerequisites, but for a straightforward download tool it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: outputDir has description in schema, which matches the description. uploadId lacks schema description; the description mentions 'for an upload' but provides no additional detail like format or how to obtain it. The description adds marginal value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads and auto-unzips an HTML report including screenshots and logs, and returns a local directory and file inventory. This specific verb+resource combination distinguishes it from sibling tools like get_junit_report or download_artifacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies debugging use by highlighting failure screenshots as high-signal artifacts, but does not explicitly state when to use this tool versus alternatives like get_junit_report or download_artifacts. Some guidance on when not to use it is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the JUnit XML report for an upload. Returns raw XML.
| Name | Required | Description | Default |
|---|---|---|---|
| uploadId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions only that it returns raw XML, but does not disclose authentication needs, idempotency, rate limits, or any side effects. The 'get' prefix implies read-only, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise at two sentences, front-loading the action and output. However, it could include critical context without becoming verbose, such as the uploadId parameter meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and lack of annotations or output schema, the description is too sparse. It does not address potential error conditions, required permissions, or how to obtain uploadId. An agent would need additional context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the sole parameter uploadId. However, it does not mention uploadId at all, failing to clarify its meaning, source, or format. The parameter's purpose is only implied by the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'JUnit XML report for an upload', and explicitly mentions the output format 'Returns raw XML'. This distinguishes it from sibling tools like get_html_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_html_report or get_results. The context from sibling names suggests different report formats, but the description does not clarify when to choose this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List individual flow results for an upload. Each result includes id, test_file_name, status, fail_reason, duration_seconds, retry_of. Optional client-side status filter.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter results client-side by status. | |
| uploadId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses it is a list operation with client-side filter, but does not explicitly state read-only nature, permissions, or side effects. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no output schema and no annotations, the description covers basic functionality and parameter usage. It could mention sorting or pagination, but is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 50% (uploadId lacks description). Description adds that status filter is client-side and enumerates result fields, but does not clarify uploadId format or constraints. Partially compensates for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List individual flow results for an upload', specifying the verb (list), resource (flow results), and scope (for a given upload). It lists included fields, distinguishing it from siblings like list_uploads or get_flow_runs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: to retrieve results for a specific upload, with optional status filtering. It does not explicitly mention when not to use it or provide alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get status summary for one upload. Returns overall status plus per-test name, status, durationSeconds, failReason. Provide either uploadId or name (most recent matching name wins).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| uploadId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Discloses that name resolution picks most recent match and returns failReason. Lacks explicit read-only indication but implies it by nature of 'status summary'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no filler. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with no output schema, description covers return fields and param usage. Could add error handling or format specifics, but sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description explains parameters are alternatives ('Provide either uploadId or name') and behavior of name (most recent wins). This adds value beyond schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Get status summary for one upload' clearly distinguishing from siblings like list_uploads (which lists all) and get_results (different data). Also lists return fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on using either uploadId or name, but does not clarify when to use this tool vs. siblings like diagnose_run or suite_health. No explicit when-not or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregated pass-rate and run-count analytics per Maestro flow file over a lookback window. Use to identify flaky flows (low pass_rate but many passed_runs) vs. genuinely broken flows. Returns flow_name, file_name, pass_rate, passed_runs, failed_runs, total_runs, avg_duration, last_run_at, tags, daily_data per flow.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window. Default 14. | |
| tags | No | Comma-separated tag filter (e.g. smoke,critical). | |
| appId | No | Filter by app bundle id, e.g. com.datacamp. | |
| endDate | No | ISO 8601 — defaults to now. | |
| platform | No | Filter by platform. | |
| startDate | No | ISO 8601 — overrides days. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the lookback window, default 14 days, and lists all returned fields (flow_name, file_name, pass_rate, etc.). It does not mention any destructive behavior or limitations, but as a read-only analytics tool, this is acceptable. Minor gap: no mention of rate limits or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the core purpose, and uses three efficient sentences. Every sentence adds value, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 optional parameters and no output schema, the description covers the return fields and main use case. It doesn't explain the structure of 'daily_data' in detail, but the listed fields provide sufficient context for an agent. Slightly incomplete for a complex aggregation tool, but adequate for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description adds no new information about parameter semantics; it only repeats the lookback window concept. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides aggregated pass-rate and run-count analytics per Maestro flow file over a lookback window, which distinguishes it from sibling tools like diagnose_run (single run) and suite_health (overall health). The verb 'list' is consistent with the resource 'flow analytics'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to identify flaky flows vs. genuinely broken flows,' providing a clear use case. It doesn't explicitly exclude other tools or mention alternatives, but the context is sufficient for the agent to decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Maestro uploads from DeviceCloud. Filter by name (supports * wildcard), date range, and pagination. Returns id, name, created_at, consoleUrl per upload.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO 8601 timestamp — uploads on or before this date. | |
| from | No | ISO 8601 timestamp — uploads on or after this date. | |
| name | No | Filter by upload name. Supports * as wildcard. | |
| limit | No | Default 20. | |
| offset | No | Default 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return fields (id, name, created_at, consoleUrl) and filtering capabilities. It does not contradict annotations. No mention of auth or rate limits, but for a read-only list operation, the provided info is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action (list uploads) and key features (filtering, return fields). No wasted words or redundancy. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 5 parameters and no output schema, the description adequately covers return values and filtering options. Minor omission: default pagination values (limit 20, offset 0) are not mentioned, but they are present in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter already described (e.g., ISO 8601 timestamps, wildcard support, limits). The description only summarizes the filters without adding new meaning beyond the schema, so it meets the baseline but does not exceed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists Maestro uploads from DeviceCloud, specifies filtering by name with wildcard, date range, and pagination, and lists return fields. This distinguishes it from sibling tools like get_upload_status or get_results, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing uploads with optional filters, but does not provide explicit guidance on when to use this tool over alternatives (e.g., get_upload_status for status of a single upload) nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify every Maestro flow over a lookback window into healthy, flaky, broken, or regression, ranked worst-first, so you can tell whether a failure is worth fixing before diving in. Regressions (a flow that was passing and recently started failing) are surfaced first, since a recent change likely broke them. Use this to prioritize, then diagnose_run to fix a specific run. Filters mirror list_flow_analytics.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window. Default 14. | |
| tags | No | Comma-separated tag filter (e.g. smoke,critical). | |
| appId | No | Filter by app bundle id, e.g. com.example.app. | |
| endDate | No | ISO 8601 end of range. Defaults to now. | |
| platform | No | Filter by platform. | |
| startDate | No | ISO 8601 start of range. Overrides days. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the classification categories, ranking order (worst-first), and the prioritization of regressions. It also notes that filters mirror list_flow_analytics. Though it doesn't mention rate limits or auth, the behavioral insight is sufficient for this analytics tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph. It front-loads the core purpose, then explains the regression significance, provides a usage recommendation, and notes filter mirroring. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about the output format or return structure, which is notable given no output schema is provided. It adequately covers the classification and usage context but would benefit from clarifying what the tool returns (e.g., a list of flow analytics). Given the tool's complexity and 6 parameters, completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no further parameter-level details beyond stating that filters mirror list_flow_analytics. It does not provide additional meaning or usage examples beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool classifies Maestro flows into healthy, flaky, broken, or regression categories, ranked worst-first. It explicitly distinguishes from siblings by recommending diagnose_run for fixing specific runs, and mentions filters mirror list_flow_analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: use this to prioritize failures before diving into fixes, and then use diagnose_run to fix a specific run. It highlights that regressions are surfaced first due to recent changes, providing clear context for when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.2diagnose_rundownload_artifactsget_flow_runsget_html_reportget_junit_reportget_resultsget_upload_statuslist_flow_analyticslist_uploadssuite_healthEach tool targets a distinct aspect of DeviceCloud workflows: run triage, suite health, upload listing, status, results, reports, artifact download, analytics, and flow history. Detailed descriptions clearly differentiate their purposes, with no overlap.
Most tools follow a consistent verb_noun pattern (e.g., list_uploads, get_upload_status, download_artifacts). The outlier suite_health uses a noun_noun format, which slightly breaks the pattern but remains readable.
With 10 tools, the surface is well-scoped for a CI debugging and monitoring server. Each tool serves a clear and necessary function, covering key operations without redundancy or excess.
The tool set provides comprehensive coverage for diagnosing and analyzing Maestro test runs: from high-level health to per-run artifacts and historical analytics. No obvious gaps exist for typical debugging workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agentic testing: HyperExecute jobs, test failure triage, SmartUI visual diffs, a11y audits
Direct access to Cypress tests results and accessibility reports in your AI workflow.
Cloud iOS simulators and Android emulators your agent can create, drive, and throw away.
Run App Store Connect from your IDE: pricing, listings, screenshots, releases, AI visibility.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RubenGlez/devicecloud-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
