Skip to main content
Glama
duonglkh

claude-android

by duonglkh
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

claude-android

MCP server + Claude Code skills toolkit for Android dev workflows. Expose Gradle / Manifest / R8 context to Claude, ship a curated library of skills that consume it.

Status License Node MCP

What it does

Android projects with Kotlin DSL + convention plugins + KMP + AGP-upgrade pain repeat the same tasks: read versions, scan dependencies, plan migrations, audit R8 rules. Each task makes Claude grep files line by line.

claude-android is an MCP server that exposes a small set of read-only tools (Gradle, Manifest, ProGuard) so Claude can answer "what's my AGP version, what plugins, what permissions" in milliseconds — and a skills library (agp-upgrade, r8-audit, string-sync, …) that orchestrates those tools to deliver complete workflows.

┌──────────────────┐    stdio     ┌─────────────────────┐    fs    ┌──────────────┐
│  Claude Code     │  ────────▶   │  claude-android     │  ──────▶ │ your Android │
│  (CLI / agent)   │              │  MCP server         │           │ project      │
└──────────────────┘   tools list └─────────────────────┘  parsed   └──────────────┘
                                        ▲                  JSON
                                        │
                                ┌────────────────┐
                                │ skills/        │
                                │  agp-upgrade/  │
                                │  r8-audit/     │
                                │  ...           │
                                └────────────────┘

Related MCP server: replicant-mcp

v0.1 scope

What ships today:

Component

Status

MCP server (stdio transport)

✅

Tool: get_project_info (settings.gradle + libs.versions.toml)

✅

Tool: read_gradle (module build.gradle.kts)

✅

Tool: read_manifest (AndroidManifest.xml)

✅

Skill: agp-upgrade (workflow only — no auto-apply)

✅

Tool: read_proguard_rules

⏳ v0.2

Tool: run_lint

⏳ v0.2

Skill: r8-audit

⏳ v0.2

Skill: string-sync

⏳ v0.3

Requirements

Install

Option A — From npm (after publish)

npm install -g @duonglkh/claude-android

Option B — From source (v0.1 preview)

git clone https://github.com/duonglkh/claude-android.git
cd claude-android
npm install
npm run build
npm link    # so `claude-android-mcp` is on your PATH

Register the MCP server with Claude Code

claude mcp add android claude-android-mcp

Verify:

claude mcp list
# expected: "android" with status "connected" (or similar)

Use the skills

Skills live in skills/. To use them in Claude Code:

# Copy / symlink skills into Claude Code's skills directory
mkdir -p ~/.claude/skills
cp -r ./skills/agp-upgrade ~/.claude/skills/

# Or, if installed via npm globally:
# Symlink from the global install:
ln -s "$(npm root -g)/@duonglkh/claude-android/skills/agp-upgrade" ~/.claude/skills/agp-upgrade

Then in any Android project:

cd ~/your-android-project
claude
> /agp-upgrade

Claude will:

  1. Call mcp__android__get_project_info to read AGP / Kotlin / modules.

  2. Ask which AGP version to target.

  3. For each module, call mcp__android__read_gradle to find breaking changes.

  4. Produce a step-by-step migration plan without applying any changes.

  5. Wait for confirmation before patching.

Tools reference

get_project_info

Input:

{ "projectPath": "/absolute/path/to/android/project" }

Output (example):

{
  "projectPath": "/Users/me/MyApp",
  "rootProjectName": "MyApp",
  "modules": ["app", "core:ui", "feature:home"],
  "agpVersion": "8.7.3",
  "kotlinVersion": "2.0.21",
  "composeBomVersion": "2024.12.01",
  "isKmp": false,
  "hasBuildLogic": true,
  "warnings": []
}

read_gradle

Input:

{ "modulePath": "/absolute/path/to/module" }

Output includes: plugins, namespace, compileSdk, minSdk, targetSdk, applicationId, versionCode, versionName, composeEnabled, dependencies.

read_manifest

Input:

{ "manifestPath": "/absolute/path/to/AndroidManifest.xml" }

Output includes: packageAttr, permissions, applicationName, applicationLabel, applicationIcon, applicationTheme, usesCleartextTraffic, activities, services, receivers, providers.

Roadmap

  • v0.1 (this release) — read-only tools + agp-upgrade skill

  • v0.2 — read_proguard_rules, run_lint; r8-audit skill

  • v0.3 — string-sync skill (locale catalogs)

  • v0.5 — first npm publish (@duonglkh/claude-android)

  • v1.0 — write tools (apply patches with confirmation), Crashlytics adapter

See issues for current work.

Status

v0.1 preview — tools are functional but parsers are regex-based, not full AST. They handle modern Kotlin DSL Gradle projects well; legacy Groovy build.gradle may parse poorly. Open an issue with a sample if you hit it.

Contributing

PRs welcome. Open an issue first for non-trivial changes. New skills are especially valued — if your team has an Android workflow that Claude could orchestrate, propose it.

Part of the hidev open-source ecosystem

See duonglkh.github.io for the full roster.

License

MIT © 2026 Hidev (Hung Duong)

Available Tools

3 tools
get_project_infoA

Read root Android project info: AGP version, Kotlin version, modules list, project name. Pass projectPath = absolute path to the project root (the directory containing settings.gradle.kts).

ParametersJSON Schema
NameRequiredDescriptionDefault
projectPathYesAbsolute path to the Android project root.

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description uses the verb 'Read', implying it is read-only and non-destructive. It specifies the required path format. Without annotations, this conveys adequate behavioral context for a simple read 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?

Two sentences: first states purpose, second gives parameter guidance. 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?

For a simple tool with one parameter and no output schema, the description lists the returned fields (AGP version, Kotlin version, modules list, project name). It is adequate, though a more explicit format or structure would enhance completeness.

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%, and the description adds extra semantic detail by specifying that the project path must be to the root containing settings.gradle.kts, which is not implicit from 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 the tool reads root Android project info, listing specific data points (AGP version, Kotlin version, modules list, project name). It distinguishes from siblings which read specific files like gradle or manifest.

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 instructions on how to use the tool: pass the absolute path to the project root containing settings.gradle.kts. However, it does not explicitly state when to use this tool versus siblings, though it is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_gradleA

Read a module's build.gradle.kts and return parsed structure: plugins, android { } block, dependencies block. Pass modulePath = absolute path to the module directory (e.g. /path/to/project/app).

ParametersJSON Schema
NameRequiredDescriptionDefault
modulePathYesAbsolute path to the Gradle module directory.

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It mentions reading and returning a parsed structure but lacks disclosure of error handling (e.g., file not found), permissions needed, or side effects. Minimal behavioral context beyond the basic action.

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 efficiently conveys the tool's purpose, output, and parameter usage. 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?

Given the lack of output schema, the description partially covers return values (plugins, android block, dependencies) but omits error conditions, structure details, or edge cases. Adequate for a simple read operation but not fully 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?

The description adds value over the schema by specifying that modulePath is an absolute path to the module directory (not the file) and provides an example. Schema coverage is 100%, but the description enriches the parameter meaning.

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 resource 'module's build.gradle.kts', and specifies the returned parsed structure (plugins, android block, dependencies). It distinguishes itself from siblings by focusing on Gradle build file parsing.

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 an example of the required parameter (modulePath) but does not explicitly state when to use this tool versus sibling tools like get_project_info or read_manifest. No when-not or alternative guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_manifestA

Read AndroidManifest.xml and return parsed structure: package, permissions, application class, activities. Pass manifestPath = absolute path to the AndroidManifest.xml file.

ParametersJSON Schema
NameRequiredDescriptionDefault
manifestPathYesAbsolute path to AndroidManifest.xml.

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Implies read-only behavior with 'Read and return parsed structure', but no details on error handling, permissions, or side effects. Since no annotations exist, description carries burden but lacks depth.

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 return value, then parameter details. No unnecessary 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 one-parameter read tool without output schema, description covers what it does, what it returns, and the required input. Complete given low 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?

Schema coverage is 100% and description repeats the schema's description. No additional meaning added 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?

Explicitly states the tool reads AndroidManifest.xml and returns a parsed structure including specific elements (package, permissions, etc.). Distinguishes from siblings (get_project_info, read_gradle) by targeting a specific file type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides the required parameter and its format ('absolute path'), but no explicit guidance on when to use this tool over alternatives or conditions to avoid.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.0
    • First observedget_project_info
    • First observedread_gradle
    • First observedread_manifest
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool targets a distinct file type: project info, Gradle build file, and Android manifest. There is no overlap in functionality.

Naming Consistency5/5

All tool names follow a clear verb_noun pattern (get_project_info, read_gradle, read_manifest) with consistent snake_case. The verbs 'get' and 'read' are synonymous in this context.

Tool Count4/5

Three tools is on the low side but appropriate for a focused read-only server that inspects core Android project files. Each tool serves a distinct purpose without unnecessary bloat.

Completeness3/5

The set covers the essential files for reading an Android project, but lacks write capabilities and may miss some auxiliary files (e.g., settings.gradle.kts, proguard rules). This leaves some gaps for interactive modification.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • replicant-mcp

    thecombatwombat
    A
    license
    B
    quality
    B
    maintenance
    An MCP server that enables AI assistants to build, test, and debug Android applications by interacting directly with the Android development environment. It provides tools for managing emulators, executing Gradle tasks, running ADB commands, and performing UI automation via accessibility trees.
    14
    121
    16
    MIT

  • Android Skills MCP

    skydoves
    F
    license
    Not graded
    quality
    B
    maintenance
    Provides AI coding assistants with access to Google's Android development skills library through an MCP server. Enables developers to discover, search, and apply Android best practices directly within their coding environment without manual copying.
    215
    -

Latest Blog Posts

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/duonglkh/claude-android'

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