compose-bridge
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
- AlicenseNot gradedqualityBmaintenanceA 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.1Apache 2.0
- FlicenseNot gradedqualityAmaintenanceMCP 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-
- AlicenseBqualityCmaintenanceLets 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.46MIT

Vibgrate AI Contextofficial
AlicenseNot gradedqualityBmaintenanceLocal-first MCP server that gives AI assistants codebase intelligence—code graph, drift analysis, vulnerability attribution, and version-correct library docs—all from the user's machine.1,475 npm6Apache 2.0- AlicenseNot gradedqualityBmaintenanceLocal-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.1MIT
- FlicenseNot gradedqualityBmaintenanceA local-first MCP server that gives AI coding agents durable project memory, dependency graphs, and impact analysis to answer team knowledge and cross-file change questions before editing.31 npm1-
TDQS
Scored across 36 tools
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.
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.
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.
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.