droidasc-mcp

Overview Schema Source Related Servers Discussions Admin

asc_read_apk_entry

Read-only

Read bounded APK or standalone DEX entry bytes as UTF-8 or base64, with optional XML decoding, input hash, and provenance for safe inspection.

Instructions

Read bounded entry bytes as UTF-8 or base64, with input hash and entry provenance.

Binary XML decoding and returned-content truncation are separate statuses. Partial raw reads do not verify CRC. Resource IDs are not resolved; no filesystem extraction occurs. Standalone DEX bytes remain original, including 041 headers; code validation is separate.

Input Schema

Name	Required	Description
`apk_path`	Yes	Archive or standalone DEX path within allowed roots
`max_bytes`	No	Maximum returned content bytes before encoding
`decode_xml`	No	Decode complete XML entries up to 4 MiB; false reads raw bytes
`entry_path`	Yes	Exact entry path or standalone DEX basename from inventory
`byte_offset`	No	Byte offset in raw or fully decoded content; follow next_byte_offset

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"
+}

Changed9 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"

changedInput schema / properties / entry_path / description

Previous value: -"Exact relative ZIP entry path from inventory"New value: +"Exact entry path or standalone DEX basename from inventory"

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

A3.9/5.0

Behavior5/5

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

Annotations already declare this a safe read, and the description goes well beyond them: it discloses that XML-decode and truncation are reported as separate statuses, that partial raw reads do not verify CRC, that standalone DEX bytes (including 041 headers) are returned unmodified, and that no extraction occurs. These are exactly the operational caveats an agent needs before trusting the returned bytes.

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 core action is front-loaded in the opening sentence and every following sentence carries a distinct caveat with no filler. Some fragments are elliptical ('separate statuses' separate from what?), which slightly blunts the density, but overall the length is well matched to the tool's complexity.

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?

With annotations, a full output schema, and 100% parameter coverage, the description only needs to supply behavioral caveats, and it does so thoroughly (CRC, truncation, no extraction, DEX header preservation). The one gap is not pointing at asc_list_apk_entries as the source of valid entry_path values.

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%, so apk_path, entry_path, max_bytes, byte_offset, and decode_xml are already documented. The description adds only indirect context — that truncation and decoding are distinct statuses and that partial reads skip CRC — without explaining encoding selection or how byte_offset interacts with decoded versus raw content. Baseline 3 applies.

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 first sentence names a specific verb and resource — read bounded entry bytes from an APK/DEX archive — and adds the return encodings (UTF-8 or base64) plus provenance. It is clearly distinct from asc_list_apk_entries by being a read rather than an inventory operation, though it never names that sibling explicitly.

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?

Usage is implied through negative scoping: no resource-ID resolution, no filesystem extraction, code validation is separate. There is no positive routing such as 'use asc_list_apk_entries first to obtain entry_path', even though the schema's 'from inventory' phrasing gestures at it. An agent can infer scope but must work for it.

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

Deploy Server