Skip to main content
Glama
MarwanDevSpace

mcp-flutter-apk-injector

by MarwanDevSpace
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Build, align, and sign APK output

recompile_align_and_sign
Destructive

Rebuild a modified APK workspace into an aligned, signed APK, using either a provided keystore or an auto-generated debug key.

Instructions

Rebuild a modified decoded workspace with apktool, 4-byte align the uncompressed APK with zipalign, and cryptographically sign the binary with apksigner (v1-v4 schemes). Mutates the filesystem by overwriting outputApkPath and creating temporary alignment artifacts; requires a valid workspaceDir containing modified Smali and AndroidManifest.xml. Pass keystoreConfig with custom keystorePath, passwords, and keyAlias for authorized release signatures; if keystoreConfig is omitted, generates an auto-signed debug test artifact.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workspaceDirYesPath to decompiled APK workspace root directory containing modified Smali, assets, and AndroidManifest.xml
outputApkPathYesDestination file path for final recompiled, 4-byte aligned, and cryptographically signed APK
keystoreConfigNoOptional signing keystore configuration. If omitted, an auto-generated debug keystore is used

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
alignedYesWhether zipalign completed successfully.
verifiedYesWhether apksigner verification completed successfully.
sizeBytesYesFinal APK byte size.
keystorePathYesKeystore used for signing, when available.
outputApkPathYesAbsolute path to the signed output APK.
signingSchemeYesDetected APK signature schemes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.1.3
    • addedInput schema / properties / keystoreConfig / description
      Added value: +"Optional signing keystore configuration. If omitted, an auto-generated debug keystore is used"
    • addedInput schema / properties / keystoreConfig / properties / cn / description
      Added value: +"Common Name (CN) owner string for self-signed debug certificate"
    • addedInput schema / properties / keystoreConfig / properties / keyAlias / description
      Added value: +"Private key alias name inside signing keystore"
    • addedInput schema / properties / keystoreConfig / properties / keyPass / description
      Added value: +"Password for specific private key alias"
    • addedInput schema / properties / keystoreConfig / properties / keystorePass / description
      Added value: +"Keystore password for signing keystore access"
    • addedInput schema / properties / keystoreConfig / properties / keystorePath / description
      Added value: +"Path to custom JKS/PKCS12 signing keystore file (auto-generates debug keystore if omitted)"
    • addedInput schema / properties / outputApkPath / description
      Added value: +"Destination file path for final recompiled, 4-byte aligned, and cryptographically signed APK"
    • addedInput schema / properties / workspaceDir / description
      Added value: +"Path to decompiled APK workspace root directory containing modified Smali, assets, and AndroidManifest.xml"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "aligned": {
+      "description": "Whether zipalign completed successfully.",
+      "type": "boolean"
+    },
+    "keystorePath": {
+      "description": "Keystore used for signing, when available.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "outputApkPath": {
+      "description": "Absolute path to the signed output APK.",
+      "type": "string"
+    },
+    "signingScheme": {
+      "description": "Detected APK signature schemes.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "sizeBytes": {
+      "description": "Final APK byte size.",
+      "minimum": 0,
+      "type": "integer"
+    },
+    "verified": {
+      "description": "Whether apksigner verification completed successfully.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "outputApkPath",
+    "signingScheme",
+    "keystorePath",
+    "aligned",
+    "verified",
+    "sizeBytes"
+  ],
+  "type": "object"
+}
  2. First observedv0.1.2

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, and the description adds crucial behavioral details: 'Mutates the filesystem by overwriting outputApkPath and creating temporary alignment artifacts' and mentions the specific signing schemes (v1-v4). It also notes the requirement for a valid workspaceDir. This goes beyond the annotation by specifying what is overwritten and the auto-signing fallback, though it does not mention permissions or error conditions, which are less critical.

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 moderately long but well-structured: it opens with the core action, then notes side effects, prerequisites, and optional keystore behavior. Every sentence contributes meaningful information—there is no filler. It could be slightly shorter, but the content justifies the length, and the most important information is front-loaded.

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?

Given the tool's complexity (multiple build steps, filesystem mutation, optional signing config) and the presence of an output schema (which covers return values), the description covers the essential operational aspects: what it does, side effects, prerequisites, and keystore behavior. It lacks explicit failure modes or environment dependencies, but these are not critical for an agent to call the tool correctly. The description is complete enough for safe invocation.

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 each parameter is already documented. The description reinforces the purpose of workspaceDir and outputApkPath but adds little new semantic meaning beyond the schema. It does clarify the keystoreConfig fallback behavior, but that is also present in the schema ('If omitted, an auto-generated debug keystore is used'). Therefore, the description adds minimal extra value over the schema, warranting a baseline score of 3.

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's purpose with specific verbs and resources: 'Rebuild a modified decoded workspace with apktool, 4-byte align the uncompressed APK with zipalign, and cryptographically sign the binary with apksigner.' It distinguishes from siblings like decompile_apk by describing the build/sign step. The scope and inputs/outputs are explicit.

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 implies usage context by stating it 'requires a valid workspaceDir containing modified Smali and AndroidManifest.xml', which indicates it should be used after patching. It also explains the behavior when keystoreConfig is omitted (auto-signed debug artifact), guiding whether to pass custom keystore. While it doesn't explicitly name alternative tools, the prerequisites and output clearly position it as the final build step, so usage is reasonably clear.

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

Deploy Server

Other Tools