What can you do with this server?

This server is an MCP adapter that exposes Droid ASC's Android APK decompiler as six typed, read-only tools. * asc_ping: Check server/engine versions and effective runtime limits. * asc_apk_info: Inspect APK size, SHA-256 hash, manifest presence, and DEX entries. * asc_get_manifest: Decode and page through AndroidManifest.xml lines. * asc_list_classes: List class descriptors with optional prefix filtering and pagination. * asc_get_class_source: Decompile a single class and page through its source lines. * asc_find_refs: Search DEX files for string, type, method, or field references. * All operations support pagination (total, offset, limit, truncated, next_offset) and are restricted to configured APK root directories. * The server enforces timeouts, output size caps, memory limits, concurrency limits, and runs analysis in isolated subprocesses without a shell.

Which integrations are available for this server?

Provides on-demand decompilation and analysis of Android APK files, including APK metadata inspection, AndroidManifest.xml decoding, class listing, class source decompilation, and reference searching across DEX files.

How do I use droidasc-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@droidasc-mcp List classes in com.example from /samples/app.apk" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

droidasc-mcp

by cnlnn

Overview Schema Source Related Servers Discussions Admin

Python

Local

droidasc-mcp

A small, defensive MCP server for Droid ASC, the fast on-demand Android APK decompiler.

droidasc-mcp exposes ASC's public CLI as six typed, read-only MCP tools. Every analysis runs in an isolated subprocess group, accepts only APK paths under configured roots, and returns paginated structured data instead of unbounded terminal output.

Community project. Not affiliated with or endorsed by the Droid ASC maintainers.

中文文档

Tools

Tool	Purpose
`asc_ping`	Show adapter/engine versions and effective runtime limits
`asc_apk_info`	Return size, SHA-256, manifest presence, and DEX entries
`asc_get_manifest`	Decode `AndroidManifest.xml` with line pagination
`asc_list_classes`	List class descriptors with prefix filtering and pagination
`asc_get_class_source`	Decompile one class with line pagination
`asc_find_refs`	Find string, type, method, or field references across DEX files

Related MCP server: jadx-rpc

Install

Python 3.10 or newer is required. CI checks Linux and native Windows runners on Python 3.10-3.13, including all six tools over stdio/HTTP against a source-built acceptance APK and package installation. macOS remains unverified.

Install the version-pinned GitHub release on Linux:

python -m venv .venv
.venv/bin/python -m pip install https://github.com/cnlnn/droidasc-mcp/releases/download/v0.2.1/droidasc_mcp-0.2.1-py3-none-any.whl

Windows (PowerShell):

py -3 -m venv .venv
.\.venv\Scripts\python.exe -m pip install https://github.com/cnlnn/droidasc-mcp/releases/download/v0.2.1/droidasc_mcp-0.2.1-py3-none-any.whl

Windows uses .venv\Scripts\droidasc-mcp.exe for the server command. For development, clone this repository and run uv sync --locked --extra dev instead.

Connect

The default transport is stdio. Limit the server to directories that contain APKs:

export DROIDASC_MCP_ALLOWED_ROOTS=/absolute/path/to/apks
.venv/bin/droidasc-mcp

Codex

codex mcp add droidasc \
  --env DROIDASC_MCP_ALLOWED_ROOTS=/absolute/path/to/apks \
  -- /absolute/path/to/droidasc-mcp/.venv/bin/droidasc-mcp

Claude Desktop and compatible hosts

{
  "mcpServers": {
    "droidasc": {
      "command": "/absolute/path/to/droidasc-mcp/.venv/bin/droidasc-mcp",
      "env": {
        "DROIDASC_MCP_ALLOWED_ROOTS": "/absolute/path/to/apks"
      }
    }
  }
}

Streamable HTTP

DROIDASC_MCP_ALLOWED_ROOTS=/absolute/path/to/apks \
  .venv/bin/droidasc-mcp --transport streamable-http --host 127.0.0.1 --port 8000

The endpoint is http://127.0.0.1:8000/mcp. Keep it on loopback unless you add an authenticated, TLS-terminating reverse proxy.

Examples

Ask an MCP host to call:

asc_apk_info(apk_path="/samples/app.apk")
asc_list_classes(apk_path="/samples/app.apk", prefix="com.example", limit=100)
asc_find_refs(apk_path="/samples/app.apk", kind="string", value="Authorization")
asc_get_class_source(apk_path="/samples/app.apk", class_name="com.example.MainActivity")

Results include total, offset, limit, truncated, and next_offset. Use next_offset for the next request (null means done): the response budget can shorten a page. A single line that exceeds the budget produces an explicit error rather than silent truncation.

Reference fields are best-effort parsing of ASC CLI text. Embedded newlines can split records; total counts output lines, not semantic references. Reference lines are sorted before pagination. Snapshots are decoded and sorted once, then cached for 60 seconds (up to 8 entries). The cache budget accounts for Python strings and tuple pointers, not just original output bytes. Identical concurrent queries share a single computation; unrelated queries and cache hits do not wait on a global computation lock. Snapshots are keyed by query and file identity/size/timestamps. Cache misses rerun ASC; this is not an immutable content-addressed evidence store. Do not modify APK files between pages.

Configuration

Environment variable	Default	Meaning
`DROIDASC_MCP_ALLOWED_ROOTS`	current directory	Allowed roots, separated by `os.pathsep` (`:` on Unix, `;` on Windows)
`DROIDASC_MCP_TIMEOUT_SECONDS`	`180`	Per-operation timeout
`DROIDASC_MCP_MAX_APK_BYTES`	`2147483648`	Maximum accepted APK size
`DROIDASC_MCP_MAX_OUTPUT_BYTES`	`67108864`	Captured stdout limit and aggregate decoded snapshot budget
`DROIDASC_MCP_MAX_WORKER_MEMORY_BYTES`	`2147483648`	Worker-tree budget (Windows Job aggregate; POSIX per-process address-space cap plus aggregate RSS watchdog)
`DROIDASC_MCP_MAX_PAGE_SIZE`	`1000`	Maximum lines returned by one call
`DROIDASC_MCP_MAX_PARALLEL`	`2`	Maximum concurrent ASC subprocesses

Design

Uses the public droidasc CLI module entry point; it does not import ASC private internals.
Never invokes a shell and does not expose a generic command tool.
Drains stdout and stderr concurrently with hard capture caps; no bulk output files are created.
Caps stderr at 64 KiB and budgets page content conservatively within 256 KiB.
Runs ZIP inspection and hashing in a supervised worker under the same concurrency budget.
On POSIX, kills the operation's process group on completion or failure, even if its leader exited.
On Windows, assigns the worker to a kill-on-close Job Object before starting ASC. Cleanup includes descendants even after the worker exits; Job setup failure prevents analysis from starting.
Propagates MCP request cancellation through queue/snapshot waits and active sync tools; cleanup completes before the cancelled server task exits, and the session can continue serving requests.
Applies the configured worker memory ceiling before importing ASC. Windows limits aggregate committed memory for the Job tree. POSIX applies an inherited per-process kernel RLIMIT_AS and samples aggregate tree RSS every 50 ms, terminating the tree if it crosses the same budget.
Resolves symlinks before checking the allowed-root policy.

ASC and its dependencies still parse untrusted binary input. Use a container or disposable VM for hostile APKs. This adapter is a process boundary, not a malware sandbox.

Native Windows CI checks live-parent and orphan cleanup, including grandchildren, successful completion, output overflow, reader termination, and repeated-operation handle counts. Capture buffers, snapshots being built, and active pages can coexist with the cache; this budget is not a hard MCP-host total-RSS cap. The POSIX aggregate tree check is a sampled watchdog, while the inherited per-process address-space ceiling is kernel-enforced. Dense outputs may hit the decoded-memory budget before the wire cap.

Development

See local acceptance checks for real-process tests, optional APK transport checks, measured outcomes, and the remaining verification limits.

uv sync --locked --extra dev
uv run ruff check .
uv run pytest --cov --cov-report=term-missing
uv run python scripts/validate_corpus.py /path/to/one.apk /path/to/another.apk
uv run python scripts/stability_check.py /path/to/one.apk --duration 300 --workers 2
uv build
# Python 3.12+; use fresh dist outputs matching the current version:
uv run python scripts/verify_dist.py dist/droidasc_mcp-0.2.1.tar.gz dist/droidasc_mcp-0.2.1-py3-none-any.whl

License

Apache License 2.0. Droid ASC is a separate upstream project and retains its own copyright and license.

Available Tools

6 tools

asc_apk_infoA

Inspect APK size, SHA-256, manifest presence, and top-level DEX entries.

ParametersJSON Schema

Name	Required	Description	Default
`apk_path`	Yes
`include_sha256`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses the tool is read-only in nature ('Inspect') and lists what it returns, but it doesn't mention whether the APK is parsed locally, whether the SHA-256 computation is expensive, or any failure modes. The description adds some behavioral context but not rich detail.

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, efficient sentence that front-loads the verb and lists the key outputs. No wasted words, and the structure is easy to scan.

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 tool has an output schema, so return values are documented elsewhere. The description covers the main purpose and key outputs, but with no annotations and no usage guidance, an agent might not know when to prefer this over asc_get_manifest or asc_list_classes. It's adequate but not 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?

Schema description coverage is 0%, so the description must compensate. It mentions 'size, SHA-256, manifest presence, and top-level DEX entries' which maps to the output, but it doesn't explain the 'apk_path' format or the 'include_sha256' flag's effect beyond what the schema's default suggests. The description adds some meaning but leaves parameter semantics mostly to 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 ('Inspect') and resource ('APK'), and lists concrete attributes: size, SHA-256, manifest presence, and top-level DEX entries. This distinguishes it from siblings like asc_get_manifest and asc_list_classes, though it doesn't explicitly name them.

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 this is the tool for inspecting APK-level metadata, and the sibling names suggest alternatives for manifest details or class listing. However, it doesn't explicitly state when to use this tool versus asc_get_manifest or asc_list_classes, leaving some inference to the agent.

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

asc_find_refsC

Find cross-DEX references to a string, type, method, or field.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	Yes
`limit`	No
`value`	No
`offset`	No
`threads`	No
`apk_path`	Yes
`class_name`	No
`fuzzy_class`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

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 disclosure burden. It communicates that the operation searches across DEX references, but it does not state whether it is read-only, expensive, limited, or what the result surface looks like beyond the output schema.

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, front-loaded sentence with no filler and the core scope delivered immediately. However, the brevity contributes to underspecification for such a parameter-rich tool.

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?

A tool with eight parameters, two required, zero schema descriptions, and no annotations cannot be adequately invoked from this description. The output schema covers return shapes, but the missing parameter semantics and usage guidance are critical gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not compensate. Eight parameters exist, including required apk_path and kind, plus value, limit, offset, threads, class_name, and fuzzy_class. The only semantic hint is that references can target string, type, method, or field, which maps weakly to the 'kind' enum.

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 action ('Find') and resource ('cross-DEX references') and enumerates the reference kinds: string, type, method, or field. This distinguishes it from sibling tools like asc_list_classes or asc_get_class_source, which target different concerns.

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 instead of siblings, and no exclusions or prerequisites. An agent must infer its role from the tool name and sibling list rather than from explicit instructions.

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

asc_get_class_sourceA

Locate and decompile one class, returning a bounded page of source lines.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`threads`	No
`apk_path`	Yes
`class_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the result is a bounded page (suggesting pagination) and that decompilation is a read-like operation, but it does not mention side effects, performance implications (e.g., the threads parameter), error behavior, or whether the APK is modified. This is adequate but not rich.

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, front-loaded with the core purpose, and no fluff. Every word adds value: 'locate and decompile', 'one class', 'bounded page'. This is a model of concise, structured writing.

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 five parameters, two required, with zero schema descriptions and no annotations. A single-sentence description is not enough to cover parameter semantics, usage prerequisites, or error cases. While an output schema exists, the description still leaves significant gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for all five parameters. It only hints at class_name ('one class') and limit/offset ('bounded page'), but omits apk_path and threads entirely. This is insufficient for an agent to know how to set each parameter correctly.

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 ('decompile') and resource ('one class') and clarifies the output ('bounded page of source lines'). It clearly distinguishes this tool from siblings like asc_list_classes (lists classes) and asc_find_refs (finds references) without needing to open the schema.

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 a clear context: use this when you need the decompiled source of a single class. It implies contrast with list/find tools but does not explicitly name alternatives or state when not to use it, so it stops 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.

asc_get_manifestA

Decode AndroidManifest.xml and return a bounded page of XML lines.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`apk_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the operation is non-destructive (decode) and that output is paginated (bounded page). However, it does not mention error conditions, permissions, or the meaning of the pagination parameters, which are needed for safe invocation.

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 with no filler. The verb and resource are front-loaded, and it communicates the essential behavior and output format efficiently.

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 tool is relatively simple with an output schema that presumably covers return value structure. The description covers the core behavior but leaves pagination semantics and failure modes unaddressed. Given the 0% schema description coverage, more context about offset/limit would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter documentation. It does not explain apk_path, limit, or offset explicitly; the phrase 'bounded page' only hints at pagination. Parameter names are self-explanatory, but the description adds almost no semantic 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 names a specific resource (AndroidManifest.xml), a specific action (Decode), and the output shape (a bounded page of XML lines). It is easily distinguished from sibling tools like asc_list_classes or asc_find_refs, which target different artifacts.

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: call this when you need the manifest content as XML. However, it does not explicitly state when not to use it or how it compares to siblings like asc_apk_info or asc_list_classes, leaving the choice to inference.

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

asc_list_classesB

List class descriptors, optionally filtered by package or class prefix.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`prefix`	No
`threads`	No
`apk_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

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 of behavioral disclosure. It conveys that the operation lists descriptors and supports optional filtering, but it does not disclose behavior around pagination, filtering semantics, required APK context, or any operational caveats beyond the bare verb 'List'.

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 compact sentence that front-loads the action and key optional filtering capability. Every word earns its place with no filler or repetition.

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 five parameters, zero schema description coverage, and no annotations, the description is too sparse to be complete. The presence of an output schema lessens the need to explain return values, but the description still fails to cover the required apk_path argument and pagination/concurrency parameters, leaving significant gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the 'prefix' filtering concept, but it does not clarify the required 'apk_path', nor does it mention the meaning or role of 'limit', 'offset', or 'threads'. An agent is left without parameter-level guidance.

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 starts with a specific verb ('List') and resource ('class descriptors'), and immediately notes optional filtering by package or class prefix. This clearly differentiates it from siblings like asc_get_class_source (source code) and asc_find_refs (reference searching).

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 guidance about when to prefer this tool over alternatives, nor any mention of exclusions or prerequisites. The description implies usefulness for enumerating classes but does not state how it relates to siblings like asc_get_class_source or asc_find_refs.

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

asc_pingA

Report server, engine, path-scope, and pagination configuration.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the behavioral transparency burden. 'Report' strongly implies a read-only operation, but the description does not explicitly state that there are no side effects, does not mention authentication or connectivity requirements, and does not describe failure behavior. It is minimally adequate but could be more explicit.

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 filler. Every term — server, engine, path-scope, pagination configuration — adds distinct information, and the verb is 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 no-parameter, configuration-reporting tool with an output schema available, the description adequately covers what the tool does. Return-value details can be left to the output schema, and there are no input decisions for the agent to make.

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 input schema is empty, so there is no parameter documentation burden on the description. Per the zero-parameter baseline, this is handled appropriately; the description's enumerated configuration categories orient the agent toward what the tool returns.

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 action ('Report') and a specific resource scope: server, engine, path-scope, and pagination configuration. It is immediately distinguishable from the sibling APK/source-introspection tools, so an agent knows exactly what this tool provides.

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 about when to use this tool versus alternatives, nor any exclusions or prerequisites. The agent must infer from the tool name and description that this is a configuration/health probe, which is weaker than explicitly stating usage context.

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.

6 tool updatesv0.1.1Sep 20, 2026
- First observedasc_apk_info
- First observedasc_find_refs
- First observedasc_get_class_source
- First observedasc_get_manifest
- First observedasc_list_classes
- First observedasc_ping

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-09-20 18:45 across 6 tools

Disambiguation5/5

Each tool targets a distinct concern: configuration, APK metadata, manifest decoding, class listing, source decompilation, and cross-DEX reference searching. There is no meaningful overlap between tool purposes, so an agent can reliably select the right tool.

Naming Consistency4/5

The tools share a clear asc_ prefix and mostly follow a verb_noun pattern (ping, get_manifest, list_classes, get_class_source, find_refs). The single exception is asc_apk_info, which uses a noun phrase rather than a verb, creating a minor inconsistency.

Tool Count5/5

Six tools is well-scoped for an APK static analysis server. Each tool covers a distinct capability without redundancy or bloat, making the surface easy for an agent to navigate.

Completeness4/5

The tool set covers the core APK inspection workflow: metadata, manifest, class enumeration, source decompilation, and reference lookup. Minor gaps exist such as resource decoding or raw DEX dumping, but the provided surface supports common reverse-engineering tasks end to end.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Android Security Analyzer A
io.github.ako2345
MCP server for static security analysis of Android source code
Security Code Analysis Testing & QA Tools
422
androidcliagentgate-mcp
com.clauxel.androidcliagentgate
Remote MCP for Android CLI agent build gate, structured receipts, audit logs, and reviewer-ready evi
Developer Tools CI/CD & DevOps Command Line
2
runtime
com.formatho
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
Developer Tools Blockchain Security
1
Singularity - MCP Discovery & Security Gateway AOAuth
io.github.gaurav-kumar-sinha-060705
Find, vet, and run MCP tools through a secure audited gateway with prompt-injection risk scoring
Security Developer Tools
11

Related MCP Servers

APK Security Guard MCP Suite
Security Penetration Testing
il-il1
F
license
Not graded
quality
D
maintenance
Provides a one-stop automated solution for Android APK security analysis by integrating tools like JEB, JADX, APKTOOL, FlowDroid, and MobSF into unified MCP standard API interfaces.
Updated 10 months ago (2025-12-03 12:17 UTC)
11
-
jadx-rpc
Code Analysis Developer Tools
AsherDLL
A
license
Not graded
quality
B
maintenance
MCP server for analyzing Android APK, DEX, or JAR files via a headless jadx engine, enabling LLM agents to query decompiled code, symbols, call graphs, and more.
Updated 2 months ago (2026-07-27 20:18 UTC)
2
GPL 3.0
mcp-flutter-apk-injector
Penetration Testing Code Analysis
MarwanDevSpace
A
license
A
quality
A
maintenance
Enables Android APK reverse engineering and Flutter runtime injection through a six-step pipeline of decompile, analyze, synthesize, inject, patch, and repackage. Provides MCP tools for authorized security research and penetration testing.
Updated 20 days ago (2026-09-09 07:42 UTC)
2
9
43 npm
5
MIT
apk-docforge
Penetration Testing Security Developer Tools
alejandrojlamas
F
license
B
quality
C
maintenance
Enables local-first static and optional controlled dynamic analysis of Android APK artifacts, with provenance-aware downloads, Markdown reports, and structured security findings via MCP stdio tools.
Updated 11 days ago (2026-09-19 03:41 UTC)
9
-