devicecloud-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.2
Disambiguation5/5
Each 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4/5 across 10 of 10 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 41 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![devicecloud-mcp MCP server](https://glama.ai/mcp/servers/RubenGlez/devicecloud-mcp/badges/card.svg)](https://glama.ai/mcp/servers/RubenGlez/devicecloud-mcp)

Score Badge

Copy to your README.md:

[![devicecloud-mcp MCP server](https://glama.ai/mcp/servers/RubenGlez/devicecloud-mcp/badges/score.svg)](https://glama.ai/mcp/servers/RubenGlez/devicecloud-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/RubenGlez/devicecloud-mcp'

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