Skip to main content
Glama
This server has been deprecated

Rebranded to ComposeLint AI. Repository has been moved to TechsOneAi/ComposeLintAI.

Related Servers

Alternatives to compose-bridge

No user-submitted related servers found.

    Related Servers

    • A
      license
      Not graded
      quality
      B
      maintenance
      A local-first MCP server that enables AI agents to inspect and debug Android apps and devices through typed tools for UI interaction, logcat, Java/Kotlin and native/Flutter debugging, performance traces, heap dumps, artifacts, and evidence-based diagnostics.
      1
      Apache 2.0
    • F
      license
      Not graded
      quality
      A
      maintenance
      MCP server that provides AI coding agents real Android development tools—Gradle, adb, logcat, lint, crash triage—through a local, permissioned interface. Enables agents to inspect projects, run safe Gradle tasks, capture logs/screenshots, and triage crashes.
      1
      -
    • A
      license
      B
      quality
      C
      maintenance
      Lets AI coding agents build, test, and lint Android projects with Gradle, control devices and emulators via adb, automate UI through screenshots and input injection, and use a live IDE bridge for refactoring, code inspection, and run configurations. Works with any MCP client over stdio or authenticated HTTP.
      46
      MIT
    • A
      license
      Not graded
      quality
      B
      maintenance
      Local-first code intelligence and safety layer for AI coding agents. MCP server exposes dependency graph, impact analysis, and AST-compressed repo context, backed by typed local memory, patch-scope safety gates, and git-independent transaction rollback.
      1
      MIT

    TDQS

    A3.7/5.0

    Scored across 36 tools

    Disambiguation3/5

    The core token-editing tools are largely distinct, but there is a dense, overlapping cluster of approval/rollback tools (approve_file_changes, approve_change, approve_all_files, reject_file_changes, reject_change, reject_all_files, reject_all_files_force, rollback_last, rollback_pattern) whose boundaries are hard to keep straight. Similarly get_ide_diagnostics vs scan_project_diagnostics and list_tokens vs get_all_token_groups overlap. Descriptions help but the set-level confusion is real.

    Naming Consistency4/5

    Almost everything follows a snake_case verb_noun pattern (list_tokens, add_token, run_gradle_build, reject_file_changes). Minor inconsistency in verb choice for analogous operations (list vs get for listings, and various approve/reject/rollback verbs), but overall predictable.

    Tool Count2/5

    36 tools is well above the comfortable range and the server bundles several distinct concerns (token design, file approval, gradle, sync, diagnostics, config) into one surface. While each concern has real functionality, the volume and the granular approval variants feel excessive rather than tightly scoped.

    Completeness4/5

    Coverage of the design-token lifecycle is strong: analysis, detection, edit, impact, approve/reject, and rollback are all present, plus gradle verification, sync, and config mapping. The main gap is no dedicated token deletion tool (orphans must be removed manually), and no explicit string-registry creation beyond set_text, but agents can work around these.

    Maintenance

    ActivityActive
    ResponsivenessNo recent community issues