UI-dbugbridge-mcp

Server Quality Checklist

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

Latest release: v0.1.5
Disambiguation5/5
Each tool serves a clear, distinct purpose, such as connection setup, UI inspection, element interaction, log retrieval, or runtime auditing. The two deprecated aliases are explicitly labeled as such, minimizing confusion despite their overlap with get_debug_page and inspect_ui.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., get_debug_page, tap_element, run_flow). Deprecated aliases also adhere to this pattern, so the naming style is uniform throughout.
Tool Count4/5
With 16 tools, the count is slightly above the typical 3-15 range, primarily due to two deprecated aliases. Excluding those, the 14 unique tools cover the domain comprehensively, making the count reasonable but marginally padded.
Completeness5/5
The tool set covers the full lifecycle of UI debugging: connection verification, port forwarding, UI tree inspection, runtime node retrieval, element interaction (tap, switches, text), log searching/waiting, screenshots, and Figma-based auditing. No significant gaps are evident for the stated purpose.
Average 3.5/5 across 16 of 16 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
Annotations are absent, so the description must disclose behavioral traits. It only states the core action, omitting the fact that the tool waits after tapping (timeoutMs, waitAfterMs, waitFor* parameters), potential side effects, and error behavior. The description adds no behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with a front-loaded verb (Tap) and no fluff. It is concise and well-structured, though extremely terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, nested objects, no annotations, and no output schema. The one-sentence description fails to explain the overall behavior (tap then wait for conditions), the meaning of the wait parameters, or return semantics. It is severely inadequate for this complexity.
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?
All 10 parameters have descriptions in the input schema (100% coverage). The tool description adds no additional parameter semantics beyond the schema, so the baseline 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 action (Tap) and the target (element), and specifies the identification method (stable DebugBridge ID). This distinguishes it from sibling interaction tools like set_text or type_text, which perform different actions.
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 guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Usage context is only implied by the action name, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, but it only says 'Run a UI operation flow.' It does not mention side effects (navigation, state changes), execution behavior (sequential, wait conditions), failure handling, or return values.
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 directly states the tool's core purpose without fluff or repetition. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (ordered step flows, many optional parameters, wait behavior), the description is too thin. It relies entirely on the schema for context and offers no high-level guidance about execution semantics, suitable scenarios, or expected outcomes.
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 schema already documents all parameters in detail. The description adds only 'using DebugBridge IDs or labels,' which is already reflected in the id/label property descriptions, so no meaningful semantic value is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Run a UI operation flow against the current app page using DebugBridge IDs or labels.' It distinguishes from sibling single-action tools (tap_element, set_text, etc.) by emphasizing 'flow,' though it doesn't explicitly contrast with those alternatives.
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 the sibling single-action tools. The name and description imply multi-step flows, but there is no stated context, exclusions, or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions writing artifacts but does not specify side effects, permissions, what gets modified, or what the output contains. It also fails to clarify the semantics of 'semantic audit artifacts' or the comparison process. This ambiguity is risky for a tool with side effects.
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 single-sentence description is concise and front-loaded, but it lacks important context. It is not verbose, but the brevity sacrifices essential information. A well-crafted description of this length can earn a higher score, but this one doesn't include usage or side-effect details, so it's adequate but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, a nested object, no output schema, and no annotations. The description covers only the high-level purpose and fails to explain return values, artifact format, retry behavior, or how the comparison works. The schema provides parameter details, but the description leaves significant contextual gaps, making it incomplete for a tool of this complexity.
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, so the schema already documents all 10 parameters. The description does not add additional parameter semantics beyond referencing 'Figma raw frame' and 'current DebugBridge page', which loosely correspond to figmaRawPath and expectedPageID. This meets the baseline but adds little value.
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: comparing a Figma raw frame with the current DebugBridge page and writing semantic audit artifacts. This verb+resource phrasing distinguishes it from sibling tools like get_debug_page or get_runtime_node, which focus on retrieval rather than comparison/audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or compare-and-contrast with sibling tools. It only states what the tool does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It mentions the device requirement and port forwarding goal, but it does not explain side effects, failure behavior if no device is present, whether it merely checks or actively modifies port forwarding, or any permissions required. This is a significant gap for a tool that likely sets up the debugging environment.
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 with no filler, immediately front-loading the key requirement ('Require a connected physical device') and the main action ('ensure the DebugBridge port is forwarded'). It is appropriately sized for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameter details, the description is too thin to fully understand the tool's role in a workflow. It does not specify success/failure conditions, preconditions beyond device connection, whether port forwarding is persistent, or how this tool relates to sibling tools like 'get_debug_page' or 'run_flow'. The description only provides a high-level statement without enough operational 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?
The input schema has zero parameters, so there is nothing to document beyond the schema itself. Per the baseline rule for 0 params, a score of 4 is appropriate. The description does not add parameter-level detail because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it requires a connected physical device and ensures the DebugBridge port is forwarded. The verb 'ensure' and the resource 'DebugBridge port' are specific. However, it does not explicitly distinguish this from sibling tools like 'ping' which also deal with device connectivity.
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?
There is no explicit guidance on when to use this tool versus alternatives. It implies it is a prerequisite for other debugging operations but does not state when to call it, what conditions warrant its use, or whether there are alternative tools for similar setups. The context signals show many siblings, but the description offers no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior, but it only mentions optional artifact saving. It does not explain retry/timeout behavior, error conditions, side effects of saving, or whether the operation is read-only, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and adds the optional artifact-saving behavior without redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having six parameters, retry logic, and no output schema, the description provides no return structure, retry semantics, or usage context. The one-sentence description is too sparse for the tool's complexity, leaving gaps beyond what the schema covers.
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 all six parameters are already documented in the input schema. The description adds little beyond the schema, only restating the artifact-saving capability, which the saveArtifact parameter already conveys.
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 ('Get') and identifies a unique resource: the semantic page and registered actionable element IDs from the in-app DebugBridge. It distinguishes this from sibling tools like get_page/get_ui_hierarchy by emphasizing DebugBridge and actionable element IDs.
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 gives no explicit guidance on when to use this tool over alternatives such as get_page or get_ui_hierarchy. It implies a debugging context but lacks exclusions or fallback conditions, leaving the agent to infer the appropriate scenario.
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 uses the verb 'Read,' which signals a non-mutating operation, and mentions 'directly from DebugBridge' for context. However, no annotations are present, and the description does not disclose further behavioral details such as return format, error conditions, or performance implications. It adds limited value beyond the name.
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 concise sentence with no unnecessary words, front-loading the core functionality.
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 explains the basic operation but does not address usage context, distinguish from get_ui_hierarchy, or describe the output format. With simple optional parameters and no output schema, the description is adequate but lacks completeness for an agent comparing related tools.
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?
All four parameters are documented in the schema with descriptions, giving 100% coverage. The description itself does not add additional parameter information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the current App UIWindow/UIView tree from DebugBridge, with a specific verb and resource. However, it does not distinguish itself from the sibling get_ui_hierarchy, which likely serves a similar purpose, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_ui_hierarchy. The description does not mention any prerequisites or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior. It only states the action and identifier, but omits important details such as waiting behavior, failure handling, or whether the switch state is forced. The many wait parameters in the schema are not referenced in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy, making it efficient. However, its brevity omits useful context, though for a simple action it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, a nested object, and no annotations or output schema, the one-sentence description is insufficient to guide an agent on using the optional wait parameters and understanding post-action behavior. The schema helps but the description does not integrate this context.
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?
All parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description's mention of 'stable DebugBridge ID' aligns with the id parameter but adds little beyond the schema's param 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 the action ('Set') and resource ('a UISwitch'), and identifies the identifier mechanism ('stable DebugBridge ID'). This distinguishes it from other input tools like set_text and tap_element.
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?
No explicit when/when-not or alternatives are mentioned, but the tool's name and description imply it is for changing a switch state, contrasting with sibling tools for text/typing. However, there is no discussion of prerequisites or conditions.
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?
With no annotations, the description carries the burden of behavioral disclosure. It mentions focusing the control and firing editing-change events, which are important side effects. However, it does not describe post-action waiting behavior or potential issues, despite the schema including many wait parameters.
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 with no filler, efficiently communicating the core action, target, and side effects. It is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the core action being clear, the description lacks context on when to use this tool versus type_text and does not mention the built-in waiting/timeout behavior after setting text—important given the many wait-related parameters. No output schema exists, so the description should have provided more post-condition context.
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 schema fully documents all 11 parameters. The description adds little beyond the schema, only clarifying that 'id' is a stable identifier and the action is to replace text. It does not elaborate on timeout or wait parameters, but the schema already does.
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 (replace text), target (UITextField/UITextView), method (by stable DebugBridge ID), and side effects (focusing, firing editing-change events). This specificity distinguishes it from siblings like type_text, which likely simulates typing rather than replacing.
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 is provided on when to use this tool versus alternatives like type_text or tap_element. The description does not state prerequisites, exclusions, or preferred scenarios, leaving the agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'using the configured screenshot command,' which hints at an external configuration, but it does not disclose what happens with the screenshot (e.g., saved file, base64 output), whether it is synchronous, or any side effects.
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, front-loaded sentence with no superfluous words. It is concise and fast to parse.
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?
Given the tool's simplicity, zero parameters, and lack of an output schema, the description is adequate but leaves a notable gap: it does not specify what the agent receives as a result (e.g., file path, image data) or any caveats about the 'configured screenshot command.' The core action is clear, but operational details are missing.
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 and the schema coverage is 100%, so there is nothing for the description to add about parameters. The baseline of 4 applies because no parameter semantics are needed.
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 function with a specific verb ('Capture') and resource ('screenshot'). It is distinct from sibling tools that fetch pages or UI hierarchies, leaving no ambiguity about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions, prerequisites, or context hints. The intended usage is only implicitly derived from the verb and noun.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It mentions a prerequisite but does not explain what 'check' entails (e.g., whether it sends a ping, returns a boolean, or has side effects). The agent is left guessing about the tool's operational effect on the DebugBridge.
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, front-loaded sentence with no redundant words. It immediately states the key requirement and the action, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what the agent can expect after calling this tool, such as return values or success/failure indicators. It does not, leaving the tool's output behavior completely unspecified. For a simple ping, this is a notable gap.
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 there is nothing to explain beyond the schema. The baseline for no params is 4, and the description adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'check' with a specific resource 'in-app DebugBridge', making it clear the tool verifies the debug bridge connection. It does not explicitly differentiate from siblings like ensure_ports or get_debug_page, but the action is distinct enough for a ping-like 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?
It clearly states a prerequisite: 'Require a connected physical iOS device', which tells the agent when this tool can be used. It does not explicitly list alternatives or exclusions, but the prerequisite provides strong context for usage.
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?
With no annotations, the description carries the burden of disclosing behavior. It correctly frames the operation as a read (suggesting non-destructive) and flags the optional artifact saving side effect. However, it omits important behavioral context such as prerequisites (DebugBridge must be active), failure behavior when the anchor isn't found, and whether saving artifacts affects the app or filesystem beyond creating files.
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, front-loaded sentence. It leads with the core action and resource, mentions the mechanism, and appends the optional artifact behavior in a compact clause. No filler words or redundant information present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no annotations, and no output schema. The description explains the primary read operation and optional artifact saving, but it fails to mention what the response contains (e.g., JSON structure) or any runtime prerequisites like DebugBridge being enabled. This leaves a significant gap for an agent deciding whether to call the tool and interpreting its result.
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 is fully described with 100% coverage, including defaults and types. The description adds no extra meaning about parameters beyond what the schema already provides, so the baseline of 3 applies. There are no examples or clarifications for the anchor format or artifact naming beyond schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the specific resource 'live UIKit node' via an anchor/accessibilityIdentifier, which distinguishes it from siblings like get_ui_hierarchy or get_page that operate on broader structures. The reference to DebugBridge and optional artifact saving adds specificity without ambiguity.
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 the tool should be used when a runtime anchor is available and one needs the corresponding node details. However, it does not explicitly state when not to use it or name alternatives (e.g., get_ui_hierarchy for whole-hierarchy queries), leaving usage criteria implicit.
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?
With no annotations, the description carries the transparency burden. It adds meaningful context by noting logs are temporary, not written to disk, and not addressed by cursor, but it does not explicitly state side effects, return behavior, or permissions, leaving some uncertainty.
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 ('Search...log pool') and add essential caveats in the second sentence. Every word earns its place, with no redundant or vague filler.
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 explains the source and temporary nature of logs but does not describe return format, ordering, or how results are presented. With no output schema, the agent is left to infer the result structure, making the description adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all four parameters, including their optionality and semantics. The description adds little beyond the schema, only implying that the parameters serve as filters. Baseline 3 is appropriate given the schema's thoroughness.
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 a specific verb ('Search') and a specific resource ('current app run's in-memory DebugBridge log pool'). It distinguishes from siblings by emphasizing 'current' and 'in-memory', differentiating it from tools like wait_app_logs or persistent log readers.
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 context such as 'current app run' and 'in-memory', implying the tool is for temporary, ephemeral logs, but it does not explicitly state when to use this tool versus alternatives like wait_app_logs, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions the deprecated alias and the UIWindow/UIView tree source, but does not disclose what the tool returns, whether it is read-only, potential errors, or deprecation consequences (e.g., may be removed). This is minimal behavioral disclosure.
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 with no filler. It front-loads the key fact (deprecated alias) and includes the tree source, making it appropriately concise and well-structured.
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?
Given the tool's simplicity (no params, no output schema), the description covers the essential guidance to avoid using it in favor of `inspect_ui`. However, it does not describe what the tool actually returns or any behavior, leaving the agent without a full picture if it were to use it. The deprecation warning helps, but completeness is moderate.
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?
There are zero parameters, and the input schema is empty with 100% coverage (vacuously). The baseline for no parameters is 4, and the description adds no parameter information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a 'Deprecated alias of inspect_ui' and mentions 'current App UIWindow/UIView tree', which clearly indicates the tool retrieves the UI hierarchy. However, it does not explicitly state what the tool returns or directly define its function beyond being an alias, so it is clear but not fully independent of the sibling 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?
The description explicitly labels the tool as 'Deprecated alias of inspect_ui', which strongly implies that users should use `inspect_ui` instead. This provides an explicit alternative and exclusion, making the usage guidance very clear.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the blocking nature and the in-memory pool, but lacks critical details such as timeout behavior (empty result vs. error), whether it returns single or multiple entries, and whether entries are consumed. This is a notable gap for a wait operation.
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, front-loaded sentence with no redundant words. It efficiently conveys the core purpose and a key distinguishing feature (no cursor).
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?
For a tool with no output schema and moderate complexity (5 optional parameters, blocking behavior), the description is incomplete. It does not explain what the tool returns when a match is found or on timeout, and the singular 'entry' potentially conflicts with the 'limit' parameter. Given this ambiguity, a score of 3 is appropriate.
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 the baseline is 3. The description adds minimal parameter-related value—it mentions 'matching entry' and 'no cursor' but does not elaborate on interaction between parameters (e.g., query vs. level) or return semantics. The schema already documents each parameter 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's action ('Wait for a new matching entry') and the resource ('current app run's in-memory DebugBridge log pool'). It distinguishes itself from sibling tools like read_app_logs by emphasizing the waiting and new-entry behavior, making its purpose unambiguous.
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: it is a blocking operation for new log entries, and explicitly notes that no cursor is required or returned, which guides usage. However, it does not explicitly name alternatives (e.g., read_app_logs) or state when not to use this tool, so it falls short of a full 5.
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 deprecated status, which is useful behavioral context. However, with no annotations, it does not disclose what the tool actually does (e.g., side effects, safety, return format). The behavior is only implied via the alias, so the agent must inspect get_debug_page to fully understand.
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, front-loaded with the most important fact (deprecated) and the alternative. 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 what is essentially a deprecated alias with no parameters and no output schema, the description is completely sufficient. It tells the agent everything needed: don't use this, use get_debug_page instead.
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 does not need to provide parameter details. The schema confirms this with an empty properties object. The baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a deprecated alias of get_debug_page, which tells the agent its purpose by referencing the canonical tool. It does not directly state what the tool does, but the alias relationship makes the purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Deprecated alias' and names the alternative tool (get_debug_page). This is a clear directive to avoid this tool and use get_debug_page instead, providing both when-to-use (never) and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explicitly states that the tool focuses the control and fires editing-change events, which adds valuable side-effect information beyond the name. It does not cover all potential edge cases, but it provides meaningful transparency for a text-entry tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action, target, identifier method, and side effects. Every element earns its place, with zero wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has many parameters (11), but the schema descriptions cover them thoroughly, so the description need not repeat them. The core purpose and side effects are stated clearly, and the description is sufficient for selecting this tool over siblings. It could mention the wait/post-action behavior, but the schema already documents 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?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter details beyond the schema; it only confirms the 'id' and 'text' purpose. No additional semantic value is provided for the wait-related parameters, but the schema already covers those.
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 ('Append') with a resource ('text to a UITextField or UITextView') and identifier type ('stable DebugBridge ID'), clearly distinguishing it from siblings like set_text. It also explains the focusing behavior, making the tool's purpose unambiguous.
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: use this tool to append text to a text field/view by ID, which implies it is not for replacing text (set_text would be for that). However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
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:

[![UI-dbugbridge-mcp MCP server](https://glama.ai/mcp/servers/Immmmmmortal1/UI-dbugbridge-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Immmmmmortal1/UI-dbugbridge-mcp)

Score Badge

Copy to your README.md:

[![UI-dbugbridge-mcp MCP server](https://glama.ai/mcp/servers/Immmmmmortal1/UI-dbugbridge-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Immmmmmortal1/UI-dbugbridge-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Immmmmmortal1/UI-dbugbridge-mcp'

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