Server data from the Official MCP Registry
Triage failing DeviceCloud Maestro test runs — fail reasons, screenshots, flaky-flow analytics
Triage failing DeviceCloud Maestro test runs — fail reasons, screenshots, flaky-flow analytics
Valid MCP server (2 strong, 4 medium validity signals). No known CVEs in dependencies. Package registry verified. Imported from the Official MCP Registry. Trust signals: trusted author (3/3 approved).
6 files analyzed · 1 issue found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
This plugin requests these system permissions. Most are normal for its category.
Set these up before or after installing:
Environment variable: DEVICE_CLOUD_API_KEY
Add this to your MCP configuration file:
{
"mcpServers": {
"io-github-rubenglez-devicecloud": {
"env": {
"DEVICE_CLOUD_API_KEY": "your-device-cloud-api-key-here"
},
"args": [
"-y",
"devicecloud-mcp"
],
"command": "npx"
}
}
}From the project's GitHub README.
Triage failing DeviceCloud runs so your agent can fix them, without opening the dashboard.
Project page: rubenglez.dev/devicecloud-mcp
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:
failReason for any uploadThe 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 24+ — 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-mcp
Add -s user to make it available in every project instead of only the current one.
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 |
|---|---|
diagnose_run | Start here. One-call triage of a run (uploadId or name): folds retries per flow and returns failed flows with fail reasons, durations, and auto-downloaded failure-screenshot paths, plus a passed/failed/flaky summary and suggested next steps. Set includeReport: false to skip the screenshot download; outputDir sets where the report extracts (default /tmp). |
suite_health | 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_flow_analytics (platform, appId, days, startDate, endDate, tags). |
list_uploads | List recent uploads. Filter by name (* wildcard), from, to, limit, offset. |
get_upload_status | Overall status + per-test status, duration, failReason. Provide uploadId or name. |
get_results | Per-flow rows for one upload: id, test_file_name, status, fail_reason, duration_seconds, retry_of. Optional client-side status filter. |
get_junit_report | Raw JUnit XML for an upload. |
get_html_report | Downloads + auto-unzips the HTML report. Returns the extraction dir and an inventory with failureScreenshots[] highlighted (these are the highest-signal debugging artifact). |
download_artifacts | Zip of raw artifacts (logs, screenshots, video). results: "FAILED" (default) or "ALL". Saves to /tmp by default; not auto-unzipped. |
list_flow_analytics | Per-flow pass rate, run counts, avg duration over a lookback window (default 14 days). Useful to tell flakes from genuinely-broken flows. |
get_flow_runs | Individual run history for one flow file (fileName required). Returns status, duration, failReason, and the uploadId each run belongs to. Use to drill into a specific flow after list_flow_analytics. |
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).list_uploads for your SHA: a run probably wasn't triggered for that commit. See "When uploads do and don't exist" above.Be the first to review this server!
by Modelcontextprotocol · Developer Tools
Web content fetching and conversion for efficient LLM usage
by Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.
by mcp-marketplace · Developer Tools
Create, build, and publish Python MCP servers to PyPI — conversationally.