droidasc-mcp

Overview Schema Source Related Servers Discussions Admin

asc_list_apk_entries

Read-only

List APK, archive, or standalone DEX entries without extracting files, with filtering by entry kind or path prefix and pagination for inspection.

Instructions

List archive contents or a standalone DEX file without extracting files.

SHA-256 binds this page to the input. Standalone DEX entries use the original basename and bytes, without code validation or ZIP CRC metadata. Archive CRCs are declarations. Native rows are an archive inventory, not ELF analysis. Follow next_offset for more.

Input Schema

Name	Required	Description
`kind`	No	Entry category; omit for all file entries
`limit`	No	Page size, capped by server limits
`offset`	No	Zero-based offset in sorted filtered entries
`prefix`	No	Case-sensitive literal ZIP path prefix
`apk_path`	Yes	Archive or standalone DEX path within allowed roots

Output Schema

Name	Required	Description	Default
`code`	No
`entry`	No
`items`	No
`limit`	No
`total`	No
`module`	No
`offset`	No
`status`	Yes
`backend`	No
`content`	No
`decoded`	No
`message`	No
`sources`	No
`apk_path`	No
`coverage`	No
`encoding`	No
`has_more`	No
`input_id`	No
`truncated`	No
`apk_sha256`	No
`entry_path`	No
`session_id`	No
`xml_format`	No
`byte_offset`	No
`limitations`	No
`next_offset`	No
`crc_verified`	No
`artifact_path`	No
`returned_bytes`	No
`artifact_sha256`	No
`backend_version`	No
`decoding_status`	No
`content_complete`	No
`next_byte_offset`	No
`selected_modules`	No
`decoding_warnings`	No
`format_validation`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv0.2.5Oct 29, 2026

addedOutput schema / $defs / Entry / properties / module

Added value: +{
+  "title": "Module",
+  "type": "string"
+}

addedOutput schema / $defs / Source / properties / container_sha256

Added value: +{
+  "title": "Container Sha256",
+  "type": "string"
+}

addedOutput schema / $defs / Source / properties / container_size_bytes

Added value: +{
+  "title": "Container Size Bytes",
+  "type": "integer"
+}

addedOutput schema / $defs / Source / properties / logical_header_offset

Added value: +{
+  "title": "Logical Header Offset",
+  "type": "integer"
+}

addedOutput schema / $defs / Source / properties / logical_size_bytes

Added value: +{
+  "title": "Logical Size Bytes",
+  "type": "integer"
+}

addedOutput schema / $defs / Source / properties / module

Added value: +{
+  "title": "Module",
+  "type": "string"
+}

addedOutput schema / $defs / Source / properties / normalization

Added value: +{
+  "title": "Normalization",
+  "type": "string"
+}

addedOutput schema / $defs / Source / properties / original_dex_version

Added value: +{
+  "title": "Original Dex Version",
+  "type": "string"
+}

addedOutput schema / $defs / Source / properties / snapshot_entry

Added value: +{
+  "title": "Snapshot Entry",
+  "type": "string"
+}

addedOutput schema / $defs / Source / properties / stored_size_bytes

Added value: +{
+  "title": "Stored Size Bytes",
+  "type": "integer"
+}

addedOutput schema / properties / module

Added value: +{
+  "title": "Module",
+  "type": "string"
+}

addedOutput schema / properties / selected_modules

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "title": "Selected Modules",
+  "type": "array"
+}

Changed8 schema fields changedv0.2.4Oct 27, 2026

changedInput schema / properties / apk_path / description

Previous value: -"APK path within the configured allowed roots"New value: +"Archive or standalone DEX path within allowed roots"

removedOutput schema / $defs / Entry / properties / abi / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / $defs / Entry / properties / abi / type
```
Added value: +[
+  "string",
+  "null"
+]
```

addedOutput schema / properties / format_validation

Added value: +{
+  "const": "not_performed",
+  "title": "Format Validation",
+  "type": "string"
+}

removedOutput schema / properties / next_byte_offset / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / next_byte_offset / type
```
Added value: +[
+  "integer",
+  "null"
+]
```

removedOutput schema / properties / next_offset / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / next_offset / type
```
Added value: +[
+  "integer",
+  "null"
+]
```

Addedv0.2.3Oct 23, 2026

TDQS

A4/5.0

Behavior5/5

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

Goes well beyond the readOnly/destructive annotations by disclosing data-trust caveats: CRC values are declarations not verified, standalone DEX entries lack code validation and ZIP CRC metadata, and native rows are an archive inventory rather than ELF analysis. It also explains that SHA-256 binds each page to the input for stable pagination.

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?

Purpose is front-loaded and every sentence carries useful caveat or pagination information. Some sentences are telegraphic fragments ('Archive CRCs are declarations.') that could be marginally clearer, but there is no wasted content.

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?

With full schema coverage, an output schema, and explicit safety annotations, the description fills the remaining gaps: no extraction, stable pagination, and caveats about CRC and native-row interpretation. An agent has enough context to call it correctly and interpret the results.

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 meaning to kind, prefix, apk_path, or the paging parameters beyond what the schema already documents; 'Follow next_offset' refers to an output field rather than clarifying inputs.

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?

States a specific verb and resource: 'List archive contents or a standalone DEX file'. The phrase 'without extracting files' contrasts with read/extract behaviour, but no sibling tool is named, so the differentiation is implicit rather than explicit.

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 pagination guidance ('Follow next_offset for more') and notes SHA-256 binding across pages, but never states when to choose this tool over alternatives such as asc_read_apk_entry, asc_apk_info, or asc_inspect_artifact. Usage is implied, not prescribed.

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

Deploy Server