devilge

by Yercko

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.2.3
Disambiguation5/5
Each tool has a distinct purpose with clear names and descriptions. Overlaps like multiple tap tools are differentiated by matching strategy (text, resource-id, coordinates). Logging, preview, and UI tools are also well separated.
Naming Consistency5/5
All tools follow the 'devilge_verb_noun' pattern using snake_case. The naming is uniform and predictable, making it easy to infer tool functionality from the name alone.
Tool Count4/5
33 tools is above the typical well-scoped range, but the tool surface covers a broad domain (device interaction, UI automation, app lifecycle, Gradle, Maestro, batch operations). The count feels justified given the comprehensiveness, though some consolidation might be possible.
Completeness5/5
The tool set covers the full spectrum of Android development/testing automation: device discovery, logging, UI interaction, app management, preview inspection, build tasks, network monitoring, and Maestro integration. No major gaps are apparent for the stated purpose.
Average 4.3/5 across 33 of 33 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 9, 2026
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states 'kills every process', indicating destructive behavior, but annotations include destructiveHint=false, a clear contradiction. No further details on side effects or irreversibility.
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 the core command and purpose, no unnecessary words.
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 core action is clear, the contradiction with annotations undermines completeness. No output schema exists, but the return value is implied. Additional context on process-killing effects would improve completeness.
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 description adds no extra meaning beyond the schema. The description does not elaborate on parameter formats or constraints.
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 specifies the action ('force-stop'), the target resource ('app'), and the underlying command ('am force-stop'). It distinguishes from sibling tools like launch_app by stating it kills all processes.
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 mentions two use cases: ensuring cold start before relaunch and handling hung apps. While it doesn't explicitly list when not to use, the positive scenarios provide sufficient guidance.
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?
The description adds the behavioral trait of polling (repeated checks) beyond the annotation's readOnlyHint. However, it does not disclose other behavioral aspects like error handling, default timeout behavior, or what happens on timeout. The annotations provide the safety profile (non-destructive, read-only), so the description adds some but limited context.
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 sentence that immediately states the core action (polls) and the condition. It is concise and front-loaded, with no unnecessary words.
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 covers the basic behavior (polls until found or timeout) but is incomplete in several aspects: it does not mention the return value (if any), error handling on timeout, or the fact that it requires a device serial. The context of Android UI automation is implicit from the tool name and siblings. Given the lack of an output schema, the description should provide more clarity on what the tool returns.
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?
Since all three parameters have descriptions in the schema (100% coverage), the description adds minimal additional semantics. It references the 'resource-id' parameter but does not explain the serial or timeoutMs parameters beyond what the schema provides. Therefore, it meets the baseline for parameter semantics.
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 that the tool polls the UI dump until a specific resource-id node appears, with a timeout. This verb+resource combination is unambiguous and differentiates it from similar tools like wait_for_text that wait for text content.
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?
The description lacks any guidance on when to use this tool versus alternatives like wait_for_text or dump_ui. It does not specify prerequisites, typical use cases, or when not to use it. The only implied usage is waiting for a resource-id, but no contextual advice is provided.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds value by specifying that the tool performs a static scan (no runtime side effects) and returns specific artifacts (locations and annotation parameters). This clarifies behavior beyond the safety profile, but it does not detail the scanning scope (e.g., whether it scans compiled code or only source) or performance characteristics.
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 sentence of 18 words that immediately conveys the core action and result. Every word contributes meaning, and the structure is front-loaded with the verb 'list' and the key object '@Preview composables'. There is zero wasted text.
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 states it returns 'locations and parsed annotation parameters' but does not specify the format (e.g., file paths, line numbers) or any limitations (e.g., only previews in configured modules, ignores dynamic compositions). With no output schema, the agent needs more detail to correctly interpret the results. However, the description is minimally adequate for a listing tool.
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%, with each parameter having a clear description in the schema. The tool description does not elaborate on parameters beyond the schema, which is acceptable given the high coverage. The baseline for such cases is 3, and no additional semantic value is provided.
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 action ('statically scans'), the target ('configured Android/KMM project for Jetpack Compose @Preview functions'), and the result ('returns their locations plus parsed annotation parameters'). This distinguishes it from sibling tools like 'devilge_get_compose_preview_source' or 'devilge_get_compose_previews_tree', which retrieve source or tree structures for specific previews, making the purpose both specific and well-differentiated.
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?
The description provides no explicit guidance on when to use this tool versus its siblings (e.g., 'devilge_get_compose_previews_tree'). It does not mention when not to use it, such as if a runtime scan is needed, nor does it list any prerequisites. The agent must infer usage from the tool name alone, which is insufficient for optimal tool selection.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read operation. Description adds that the command runs `adb exec-out screencap -p` and saves a file to a specific directory, providing context about file creation. However, it does not disclose potential failure modes or prerequisites (e.g., device must be connected).
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?
Three concise sentences, each serving a distinct purpose: action and output, return value, and default directory. Information is front-loaded with the core functionality first. No redundant or verbose content.
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?
For a simple, read-only tool with one optional parameter and full annotations, the description covers the essential aspects: what it does, how it works, where output is saved, and what is returned. No output schema required as return value is clearly stated.
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% for the single parameter 'serial', with a clear description of its default behavior. The tool description adds no additional parameter semantics. According to guidelines, baseline 3 applies when schema coverage is high.
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 captures device screen via adb, saves PNG to configured directory, and returns absolute path. The verb 'captures' and resource 'screenshot' are specific and unambiguous. Distinguishes from siblings like devilge_dump_ui by focusing on visual screenshot capture.
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 explicit guidance on when to use this tool versus alternatives like devilge_dump_ui or devilge_get_logcat. The description only describes the action without context of typical use cases or exclusions.
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?
Annotations already indicate the tool is not read-only and not destructive. The description adds that it sends a key event via ADB, which is helpful but does not disclose additional behavioral traits like potential side effects or permissions.
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, clear sentence followed by a list of allowed keys. It is concise, front-loaded, and every part earns its place with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool, the input schema fully documents both parameters, and annotations cover the safety profile. The description is complete enough for an agent to use the tool correctly without additional context.
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 coverage is 100% with descriptions for both parameters. The description adds the mapping to `KEYCODE_<NAME>` for the `code` parameter, providing extra context beyond the schema. The `serial` parameter's default behavior is only in the schema, but the description compensates sufficiently.
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 sends a key event via `adb shell input keyevent`, specifying the allowed keys. It distinguishes from sibling tools like devilge_input_tap, devilge_input_text, and devilge_input_swipe, which handle different input types.
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 explicit guidance on when to use this tool versus alternatives. The description lists allowed keys but does not provide context for when to choose this over other input tools or mention any constraints.
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?
The description adds behavioral context beyond annotations: text is typed via adb, spaces escaped, NUL and newlines rejected, and requires a focused field. Annotations provide mutation/side-effect info, and description complements well.
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?
Extremely concise: two sentences pack the core action, underlying mechanism, and key constraints. No unnecessary words.
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?
Adequate for a simple input tool with full schema coverage and annotations. However, it lacks mention of what happens if no field is focused or the device state required. Missing return value info (though likely none). Could be slightly more complete.
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 coverage is 100%, so baseline is 3. The description adds meaning beyond schema by explaining the adb escaping mechanism for spaces and the character rejection rules, which aids agent understanding of how text is processed.
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 function: types text into the currently focused field using adb shell input text. It differentiates from sibling tools like devilge_input_key (for special keys) and devilge_set_text (which may imply setting text directly), by focusing on the focused field and mentioning character limitations.
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 explicit guidance on when to use this tool vs alternatives. The schema note about using input_key for newlines is present, but the description itself does not provide usage context or exclusions. Agent must infer from name and siblings.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as safe/read-only. The description adds useful context by specifying that it returns 'full source code including its annotations and body,' which extends beyond the annotations and clarifies the output scope.
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?
A single sentence of 14 words that is front-loaded and contains no wasted words. It efficiently conveys the core functionality.
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 read-only tool with two clearly described parameters, the description adequately covers the return value ('full source code'). However, it lacks details about error scenarios (e.g., if the preview or file is not found) and the exact format of the returned source code (e.g., as a string). With no output schema, slightly more detail would be beneficial but not critical.
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% as both parameters (filePath, functionName) have descriptions in the schema. The description does not add additional meaning beyond the schema, so 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 returns the full source code of a @Preview composable, including annotations and body. It uses a specific verb ('Returns') and resource ('source code of a @Preview composable'), distinguishing it from sibling tools like devilge_list_compose_previews which only list previews.
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 examining a specific preview's source code but does not explicitly state when to use it versus alternatives (e.g., reading the file directly) or provide any exclusions. The purpose is clear, but context for selection is absent.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by detailing the output structure (hierarchical with modules, files, functions, variants, totals, orphans), which goes beyond annotations. No contradictions.
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, no fluff. The first sentence front-loads the core purpose, and the second adds essential nuance about grouping and summary. Every word earns its place.
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 optional parameters and no output schema, the description gives a good picture of the result structure (hierarchical tree, grouping, totals, orphans). It is mostly complete for a listing tool, though it could mention what happens if no maxFiles is specified (default 5000, but that is in 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 description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond what the schema already provides (the schema describes maxFiles and moduleFilter adequately).
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 that the tool returns a hierarchical tree of Compose previews organized by modules, files, functions, and variants, including grouping of multiple annotations and a totals summary. This is specific and distinguishes it from sibling tools like devilge_list_compose_previews (which likely returns a flat list).
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 it is for exploring previews in a tree structure but does not explicitly state when to use this tool versus alternatives like devilge_list_compose_previews. No guidance on exclusions or specific scenarios is provided.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds minimal extra behavioral context beyond stating it 'reads' and uses adb. It does not describe potential blocking, buffer clearing, or return format details.
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 two sentences long, front-loaded with the primary function, and efficiently includes use cases. No unnecessary words or fluff.
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's simple nature and schema coverage, the description is adequate. It mentions use cases and the basic operation. However, it could briefly note that output is limited by maxLines and that filters apply, though these are clear from the schema. No output schema exists, so the description could hint at the output format.
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 does not add any additional meaning beyond the parameter descriptions in the schema. It does not explain nuances like tagFilter pattern or minLevel enum semantics.
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 specifies the action (reads), the resource (logcat output from connected Android device/emulator), and the use cases (diagnosing crashes, ANRs, runtime errors, tracing logs). It distinguishes itself from sibling tools like devilge_take_screenshot and devilge_list_devices.
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 states when to use the tool (diagnosing crashes, ANRs, etc.) but does not provide explicit when-not-to-use or mention alternatives among siblings. The context is clear enough for an agent to decide.
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?
Annotations already indicate readonly and non-destructive behavior. The description adds valuable context: it parses Ktor and OkHttp formats, auto-detects format, requires active logging, and redacts sensitive headers. This goes beyond what annotations provide.
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, with just three sentences. The first sentence states the main purpose, the second details supported formats, and the third covers prerequisites and data redaction. There is no unnecessary text.
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 tool with 7 parameters and no output schema, the description explains the core functionality, supported formats, prerequisites, and redaction behavior. It could be slightly more complete by mentioning that returned objects are NetworkCall structures, but the maxCalls parameter hint partially covers that.
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?
The input schema covers all 7 parameters with descriptions, achieving 100% coverage. The description itself does not elaborate on parameters beyond the schema, so the baseline score of 3 is appropriate per guidelines.
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 returns recent HTTP request/response pairs from a running Android app. The verb 'returns' and the resource are explicit, and the tool is differentiated from siblings like devilge_get_logcat by specifying it parses and formats HTTP traffic from logcat.
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 provides implicit usage context by stating prerequisites (HTTP logger must be active with certain log levels) and mentions auto-detection of formats. However, it does not explicitly say when to use this tool versus alternatives like parsing raw logcat, nor does it clarify 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that the list is based on current ADB visibility, which is useful but not a deep behavioral trait. No contradictions.
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?
Single sentence, front-loaded with action and resource, zero unnecessary words. Efficient and clear.
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, the description adequately states the result (list of devices/emulators) but omits details about return format (e.g., IDs, serial numbers). Given the tool's triviality, this is acceptable.
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?
Zero parameters, so baseline is 4. Description does not need to explain 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 uses specific verb ('Lists') and resource ('every Android device or emulator currently visible to ADB'), clearly distinguishing it from sibling tools that perform actions like screenshot or input.
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 context (when ADB devices are needed), but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. No sibling comparison is made.
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?
Annotations already indicate this is a write operation (modifies UI state). The description adds that it's more stable across locale changes, but doesn't detail error handling or side effects. With annotations present, this is adequate.
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-load the core purpose and key comparison, with no wasted 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?
For a simple tap tool, the description explains purpose, advantage over sibling, and when to use, which is sufficient. No output schema needed.
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 has 100% parameter description coverage. The description adds no additional parameter-specific meaning beyond what schema provides, so baseline score 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 taps a node by resource id, and distinguishes it from devilge_tap_text by specifying the matching criterion and stability advantage.
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?
It provides guidance on when to use (when resource id is available, for stability) and implies alternative (text matching) without explicit exclusion.
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?
Annotations indicate it modifies state (readOnlyHint=false) and is not idempotent. Description adds heuristic steps and action sequence (locate, tap focus, type). Missing detail on whether existing text is cleared or appended.
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 and heuristic summary. Every sentence adds value with no 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?
Describes heuristic but return value is vague ('matched field summary'). No output schema, so more detail on return structure would improve completeness.
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 coverage is 100%, baseline 3. Description adds heuristic matching details for 'label' parameter, explaining it can match contentDescription, hint, or sibling label, which aids understanding 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?
Title and description clearly state the action: find input field by label and type into it. Description details heuristic steps, distinguishing it from siblings like devilge_input_text (which types without finding) and devilge_tap_text (which taps without typing).
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?
Usage context is implied by the name and description, but no explicit when-to-use or when-not-to-use is given. No mention of alternatives like devilge_tap_resource_id or when the heuristic might fail.
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?
Annotations already indicate non-read-only, non-destructive, non-idempotent, and open-world. The description adds behavioral context by naming the underlying command (adb shell input swipe), default duration, and typical effects (scroll, dismiss, gesture). No contradictions.
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, no unnecessary words. Action and parameters in first sentence, use cases in second. Excellent 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 gesture tool with 6 parameters and no output schema, the description covers purpose, parameters, and usage context. Missing details like coordinate limits or response behavior, 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 coverage is low (33%) with only serial and durationMs described. The description explains the overall meaning of coordinates and duration but does not detail each parameter's bounds or coordinate system. It adds value but could be more precise.
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 sends a swipe gesture using adb shell input swipe, specifies coordinates and duration, and gives example use cases (scrolling, dismissing overlays). It distinguishes from sibling input tools (tap, text, key) by the action type.
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 includes explicit use cases ('useful for scrolling lists, dismissing overlays, performing simple gestures'), providing context for when to use. It does not explicitly mention alternatives or when not to use, but the examples are sufficient for typical 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?
Annotations declare readOnlyHint, idempotentHint, and non-destructive, so the tool's safety is clear. The description adds value by explaining the output includes process running status and PID, which is not in annotations.
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 primary action, followed by a practical usage hint. No superfluous text.
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?
The description explains the main output (process status and PID) but does not detail the format or structure. Given no output schema, a bit more detail would enhance completeness, but it is still sufficient for an agent.
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% with well-documented parameters. The description does not add significant meaning beyond the schema, so baseline 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 lists installed Android applicationIds with optional filtering and reports process status and PID. It distinguishes itself by explicitly positioning the tool as a prerequisite for devilge_get_app_errors.
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 recommends using this tool to discover the packageName before calling devilge_get_app_errors. While it does not list exclusions, this guidance 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive, but the description adds detailed behavioral context: it returns a structured summary with parsed compile errors, test results, lint findings, and failure blocks. It also mentions blocking destructive task patterns. This goes beyond the annotations by clarifying output format and safety constraints.
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 two sentences with no extraneous content. The first sentence states the core purpose and output structure; the second adds safety context about blocked patterns. Information is front-loaded and every part earns its place.
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?
The description adequately covers the tool's output and safety constraints. However, it omits prerequisites (e.g., project must exist, gradlew wrapper must be present) and does not explain error behavior beyond the structured response. Given the tool's complexity and lack of output schema, a brief note on environment expectations would improve completeness.
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?
The input schema has 100% description coverage, with each parameter well-documented (examples, constraints, defaults). The tool description does not add additional parameter semantics beyond the schema. Baseline 3 is appropriate since the schema already does the heavy lifting.
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 runs a Gradle task using the project's gradlew wrapper, specific to Android/KMM projects. It lists the structure of the return value, including success flag, compile errors, test results, etc. This distinguishes it from sibling tools, which are all device interaction or other non-Gradle operations.
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 implicitly defines usage: for running any Gradle task (build, test, lint, etc.). The parameter description for 'task' provides explicit guidance on blocked destructive patterns, aiding safe use. However, there is no explicit 'when to use vs alternatives' statement, though no sibling tools overlap in functionality.
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?
Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds that the tool never throws and returns a structured object with matched, attempts, elapsedMs, and matchedNode. This provides additional behavioral context beyond the annotations.
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: first explains the polling mechanism, second explains the return value and non-throwing guarantee. No wasted words, front-loaded with key information.
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?
The description covers the return shape and behavior, which compensates for the lack of an output schema. It mentions the polling and timeout behavior. The serial default is documented in the schema. A note about the default serial could be added, but the description is largely sufficient.
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 adds that matching applies to both text and contentDescription, which is not in the text parameter description. However, this is a minor addition; the schema already covers the parameters adequately.
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 polls UI dump until text or contentDescription matches, specifying the return object and behavior. This distinguishes it from sibling tools like devilge_wait_for_resource_id and devilge_wait_for_idle.
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 usage for waiting for text, but does not explicitly contrast with alternatives like waiting for resource ID or idle. Given the sibling list, a brief when-to-use note would improve clarity, but the purpose is still clear.
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?
Annotations already declare readOnlyHint=true, and the description adds value by specifying the underlying method ('uiautomator dump') and return structure (fields like text, resourceId, bounds), which are not conveyed by annotations.
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?
Three sentences with no wasted words. Action, method, return fields, and use cases are front-loaded and clearly 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?
For a simple tool with one optional parameter and no output schema, the description fully covers purpose, method, return format, and usage scenarios, making it self-contained and actionable.
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% and the description does not add further semantics beyond what the schema already provides for the 'serial' parameter, so baseline of 3 applies.
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 uses a specific verb ('Captures') and resource ('foreground UI tree') and clearly differentiates from siblings like screenshots and tap actions by focusing on UI hierarchy inspection.
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 provides clear context for use ('before tapping', 'reasoning about layout state') but does not explicitly mention when not to use or list alternatives, though sibling tool names imply alternatives.
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?
Annotations already indicate it's not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). Description adds the specific adb command but no further behavioral context beyond annotations.
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 core action and usage guidance. No wasted words.
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?
For a simple tool with full schema coverage and adequate annotations, the description is complete. No output schema needed.
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 baseline is 3. Description adds no additional parameter meaning beyond what the schema already provides.
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 sends a tap at device pixel coordinates using adb shell input tap, distinguishing it from the sibling tool devilge_tap_text which is higher-level and more resilient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises preferring devilge_tap_text when available for resilience to layout changes, giving clear when-to-use guidance versus alternatives.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the key behavioral trait that the tool works without Maestro installed, and explains the return values. It does not contradict annotations.
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 two sentences long, with the first sentence covering the core functionality and the second adding usage guidance. Every word is informative with no fluff.
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 zero-parameter tool with no output schema, the description is fairly complete: it states what files are listed, what is returned, and when to use it. It doesn't explain what DEVILGE_FLOWS_ROOT is, but that is likely environment-specific knowledge.
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?
The tool has zero parameters, so the description cannot add parameter meaning. The baseline for zero parameters is 4. The description does add context about what the tool returns, which is relevant but not parameter-related.
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 specifies the action 'Lists every *.yaml/*.yml flow file', the resource 'under DEVILGE_FLOWS_ROOT', and the returned fields (name, relative path, size, 5-line preview). It also distinguishes from sibling tools by noting it works without Maestro installed.
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 suggests using this tool to discover existing flows before deciding to install Maestro, providing clear usage context. However, it does not explicitly state when not to use it or mention alternative tools for similar listing needs.
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?
The description adds crucial behavioral context beyond annotations: the buffer resize applies only to future captures, and already lost entries are gone. This aligns with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) and provides transparency.
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 concise (two sentences) and front-loaded with the core purpose. It efficiently conveys key information, though a more structured format (e.g., bullet points) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, clear annotations), the description covers all necessary aspects: purpose, usage context, behavioral effect, and parameter hints (default in schema). No gaps are present.
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?
The input schema covers 100% of parameters with clear descriptions, including a default for sizeMb. The tool description adds no extra meaning beyond what the schema provides, so baseline 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 title and description clearly state the action (increase/resize) and resource (logcat ring buffer), with a specific purpose: preventing log eviction. It distinguishes itself from sibling tools like devilge_get_logcat, which retrieves logs, by being a configuration tool.
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 provides explicit guidance on when to use (Ktor LogLevel.ALL) and a caveat (effect only on subsequent captures). However, it does not mention alternatives or when not to use, which would make it a 5.
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?
While annotations already indicate `destructiveHint=true`, the description adds specific behavioral details: the exact command (`pm clear <pkg>`), what data is wiped, and the result (app behaves like fresh install). This significantly enhances the agent's understanding beyond annotations.
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 extremely concise: two sentences plus a bold warning. Every sentence adds value, and the key command and warning are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers purpose, behavior, and safety adequately. No gaps remain.
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 description adds no additional parameter meaning beyond what the schema provides. 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 the tool wipes all app data via `pm clear`, specifying exactly what is removed (caches, databases, SharedPreferences, tokens) and the effect (fresh install). This distinguishes it from sibling tools like `devilge_launch_app` or `devilge_force_stop_app`.
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 recommends using it only on dev emulators or wiped test devices and warns against personal devices. However, it does not mention alternative tools for non-destructive data operations, so a slight deduction.
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?
Annotations already show readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: returns empty if app not running, defaults to minLevel='E', and explains PID resolution and stack trace coalescing.
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 compact (3 sentences) and front-loaded. Every sentence adds value, but it could be slightly better structured (e.g., bullet points for default exclusions and followMs).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description sufficiently explains the return format (entry with message+stackTrace[]), default behavior, and edge cases (app not running, followMs window). The parameter documentation is thorough and no critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description adds meaning beyond the schema: default minLevel, default exclusions, the behavior of followMs (real-time listening and error if app stops), and the output format (message+stackTrace[]).
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 returns error-level logs for a specific Android app, filtered by package name. It distinguishes itself from the generic sibling tool devilge_get_logcat by specifying curation, stack trace coalescing, and system noise exclusion.
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 (for app-specific errors) and explains real-time capture via followMs. However, it does not explicitly contrast with devilge_get_logcat, leaving some ambiguity for the agent.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds value by specifying the scope (high-level snapshot) and content (modules, types, source sets, versions), but does not contradict annotations. It complements them well, earning a 4.
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 sentence. It front-loads the main action ('Returns a high-level snapshot') and then lists the relevant details. No unnecessary words or repetition. It is highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and the annotations fully cover its read-only nature, the description provides sufficient information for an agent to understand and invoke it. It explains the returned content without needing further elaboration, making it complete for this simple tool.
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?
The tool has no parameters, and the schema coverage is effectively 100% (empty properties). With zero parameters, the baseline score is 4. The description does not need to explain parameters and does not attempt to; it remains clear and accurate.
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 uses the specific verb 'Returns' and clearly identifies the resource as a 'high-level snapshot of the configured Android/KMM Gradle project'. It lists the included details (modules, types, source sets, versions), making the purpose unmistakable. Among siblings, this tool is uniquely focused on project structure, so there is no confusion.
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 clearly states what the tool does, but does not explicitly provide when to use it or when not to. Since there are no sibling tools with a similar purpose, the context is sufficient for an agent to infer appropriate usage. It lacks explicit exclusions or alternatives, which prevents a score of 5.
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?
Annotations are basic (readOnlyHint false, etc.), but the description adds significant behavioral context: Maestro is optional and returns MAESTRO_NOT_INSTALLED with install command, runScript blocks are denied by default (with env var to allow), MAESTRO_DISABLE_ANALYTICS is always injected, and params are injected as -e KEY=VALUE.
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 five sentences, front-loaded with the main action, and each sentence adds unique information. No redundant or unnecessary text.
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?
No output schema, so the description covers return value for the not-installed case but does not detail the success output (likely Maestro's stdout). Given the complexity of the tool (external process execution), the description is mostly complete but could mention the standard output format.
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 coverage is 100% (both parameters described), so baseline is 3. The description adds value by explaining that 'name' is a basename without .yaml extension and lives under DEVILGE_FLOWS_ROOT, and that 'params' are injected as -e KEY=VALUE. This provides meaningful context beyond the schema's generic descriptions.
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 executes a Maestro YAML flow, using a specific verb and resource. It distinguishes from sibling tools like devilge_list_maestro_flows (listing) and devilge_validate_maestro_flow (validation) by explicitly saying 'Executes'.
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 implicitly says when to use (to run a flow) and provides context like the optional nature of Maestro and the install command if missing. However, it does not explicitly exclude other sibling tools or provide alternative guidance.
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?
Annotations already show idempotentHint=true and destructiveHint=false. The description adds critical behavioral info: persistence until reboot and the visual effects (markers, debug strip). No contradictions.
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?
Three sentences, front-loaded with the main action, no fluff. Every sentence adds value: what it does, why useful, and when to use/disable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 boolean params, no output schema), the description covers the core behavior, persistence, and usage recommendation comprehensively. No gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have schema descriptions, but the tool description adds value by explaining the effect of enabling (visible markers, live coords) and the persistent nature. For a 2-param tool with 100% schema coverage, this adds meaningful context.
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 that the tool toggles 'Show touches' and 'Pointer location' developer options, specifying the exact verb and resource. It distinguishes from sibling input tools by focusing on visualization, not the inputs themselves.
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 recommends enabling at the start of a driving session and disabling when done, providing clear context for usage. Missing explicit when-not-to-use or alternatives, but the recommendation implies a natural lifecycle.
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?
Describes polling mechanism, structural digest, and timeout behavior. Annotations confirm read-only, no contradictions. Description adds valuable detail beyond annotations.
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: first explains operation, second states usage. No fluff, front-loaded with key behavior.
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?
Adequately explains behavior for a simple polling tool with optional parameters. No output schema, but return condition (stable or timeout) is clear. Could mention what happens on timeout.
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 100% coverage with clear descriptions. Description ties 'stableSamples' to 'N consecutive identical dumps', adding context. Could elaborate more on 'serial' default behavior.
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 polls UI dumps and returns when stable or timeout. Distinct from siblings like devilge_wait_for_text (waits for element) and devilge_dump_ui (single dump).
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 says 'Useful between a tap and the next action to absorb animations / asynchronous updates without sleeps.' Provides clear usage context but could mention alternatives more directly.
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?
Annotations already mark destructiveHint=true and idempotentHint=false. The description adds that it uses `adb install -r` (which replaces existing app) and is faster. Could mention overwrite behavior more explicitly, but still adds value beyond annotations.
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?
Four sentences, well-structured, front-loaded with key purpose and contrast. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high schema coverage, annotations, and clear behavior, the description is complete. No output schema needed as install is a side-effect operation.
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 coverage is 100% with descriptions. The description adds meaning: mutual exclusivity of `apkPath` and `module`, auto-location pattern for module, default variant. Adds value beyond the schema alone.
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 installs an APK via `adb install -r`, bypassing Gradle. It distinguishes itself from sibling `run_gradle_task installDebug` by being faster for the re-install loop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends workflow: assemble once with `run_gradle_task assembleDebug`, then re-install with this tool on each iteration. Contrasts with `run_gradle_task` and provides when-to-use context.
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?
The description discloses the return structure (success, testResults, compile errors, etc.) and reuse of JUnitXmlParser. It is consistent with annotations (no contradiction) and adds behavioral context beyond what annotations provide.
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 two sentences: first states the core function, second covers return format and reuse. Every sentence is necessary and well-structured, with no redundancy.
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?
The description covers the return format and references a related tool, which is sufficient given the 5 parameters are fully documented in the schema and the tool has no output schema.
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 coverage is 100%, so baseline is 3. The description adds value by explaining how `testClass` and `testMethod` interact for filtering, and notes default values for `module`, `tailBytes`, and `timeoutMs`.
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 explicitly states it runs `:<module>:connectedDebugAndroidTest` against an attached device, with optional filtering to a single class or method. This clearly identifies the tool's function and distinguishes it from siblings like `devilge_run_gradle_task`.
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 usage for Android instrumented tests and references `devilge_run_gradle_task` for comparison, but does not explicitly state when not to use it or list alternative tools for other test types.
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?
The description discloses all behavioral traits beyond annotations: it launches an app with side effects, returns metrics, conditionally force-stops and wipes data (clean=true), and falls back to monkey. Annotations only provide readOnlyHint=false and destructiveHint=false, but the description clarifies the conditional destructive nature, adding value.
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 sentence that front-loads the main action and return value, then concisely explains each parameter variant. No redundant or unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value (cold-start metrics). It covers all five parameters and their effects, including conditional behavior, fallback, and device serial. The tool's complexity is fully addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the description adds significant context beyond the schema, such as the return of cold-start metrics, the force-stop and wipe behavior for clean=true, the mutual compatibility of deepLink and activity, and the fallback to monkey when resolution fails. This enhances understanding of parameter interactions.
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 launches an app via `am start -W`, specifies it returns cold-start metrics, and distinguishes itself from sibling tools (no other launch tool among siblings). The verb 'Launches' and resource 'app' are precise, and the description covers all usage variants.
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 explains when to use each parameter (clean, deepLink, activity, serial) and how they interact. It also describes the automatic resolution fallback. However, it does not explicitly state when not to use this tool or provide explicit alternatives, though none exist among siblings.
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?
Discloses significant behavior: internal UI dump, exact matching fields, bounding box tapping. Annotations indicate non-read-only and non-idempotent, which align with the mutating tap action. No contradiction; description adds value beyond annotations.
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 cover purpose, mechanism, error conditions, and disambiguation. No redundant words; every sentence earns its place.
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 3 parameters and no output schema, the description is nearly complete. Missing return value (likely void or success indicator), but the core operation is well-covered. Could mention post-tap state handling.
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 already documents all parameters (100% coverage). Description adds context: 'text' matches text or contentDescription, 'contains' enables substring match. This clarifies semantics beyond 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's action: dumps UI, finds unique node by text or contentDescription, and taps its bounds center. It distinguishes from siblings like devilge_tap_resource_id by focusing on text matching. Error conditions are explicitly mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when errors occur (0 or >1 matches) and provides guidance: disambiguate with more specific text or use 'contains' for substring match. This helps the agent decide when to use this tool vs 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?
The description discloses key behaviors: stops on first error, capped at 20 actions, input validation before each step, concatenated output with step labels, and error reporting with isError=true. Annotations (openWorldHint=true, idempotentHint=false) are consistent, and description adds substantial context beyond them.
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 and well-structured: a clear opening sentence, a bulleted rules list, and a returns line. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is remarkably complete. It covers all behavioral aspects (error handling, output format, constraints) and provides usage context, leaving no significant gaps.
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 coverage is 100%, so baseline is 3. The description adds extra constraints not in schema: cannot include destructive tools (devilge_clear_app_data, devilge_install_apk), cannot call itself, and mentions input validation. These add meaningful value beyond 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 executes a sequence of devilge tools sequentially in a single MCP call, and gives a concrete example (tap → wait_for_idle → take_screenshot) to illustrate its purpose. It distinguishes from siblings by being a batch/sequencing tool.
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?
It explicitly says when to use (to chain predictable steps, reducing overhead and permission prompts) and when not to use (destructive tools must be invoked directly). It also states it cannot call itself, providing clear usage boundaries.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by detailing specific validation checks (appId, separator, steps, runScript) and confirms no execution. No contradiction.
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, no filler. First sentence covers purpose and key checks; second clarifies non-execution and recommends usage. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and annotations covering safety, the description fully informs about what the tool does, why to use it, and what to expect. No gaps.
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 already describes the single 'name' parameter with pattern and length. Description adds context by linking validation details to the flow name, but does not elaborate on parameter syntax. With 100% coverage, baseline is 3; slight extra context earns a 4.
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?
Verbs like 'validates' and 'Statically validates' clearly define the action. Resource is specified as 'flow YAML'. Distinguishes from sibling 'run_maestro_flow' by stating it does NOT execute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this before run_maestro_flow to catch issues early. Mentions it works without the binary, which sets expectations. No exclusions needed, but clear context.
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:

[![devilge MCP server](https://glama.ai/mcp/servers/Yercko/devilge/badges/card.svg)](https://glama.ai/mcp/servers/Yercko/devilge)

Score Badge

Copy to your README.md:

[![devilge MCP server](https://glama.ai/mcp/servers/Yercko/devilge/badges/score.svg)](https://glama.ai/mcp/servers/Yercko/devilge)

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/Yercko/devilge'

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