AndroJack-mcp

Android Code Validator

android_code_validator

Read-onlyIdempotent

Validate Kotlin, XML, and Gradle code against 34 Android rules to catch deprecated APIs, coroutine misuse, and version issues. Returns PASS/WARN/FAIL with line-level fixes and doc links.

Instructions

Call after generating every Android code block, before returning it. Checks Kotlin, XML, and Gradle against 34 rules (removed/deprecated APIs, Android 16/17 behaviour, coroutine misuse, kapt). Returns PASS/WARN/FAIL with line-level fixes and doc links, plus structuredContent. Comments are ignored. On FAIL, fix and re-run.

Input Schema

TableJSON Schema

Name	Required	Description
`code`	Yes	The code block to validate
`minSdk`	No	App minSdk (e.g. 24)
`language`	No	File type — auto-detected from content if omitted
`targetSdk`	No	App targetSdk (e.g. 37)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`counts`	Yes
`minSdk`	Yes
`verdict`	Yes
`language`	Yes
`targetSdk`	Yes
`violations`	Yes
`rulesEvaluated`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv2.1.0Oct 18, 2026

changedInput schema / properties / minSdk / description

Previous value: -"App minSdk for API level context (e.g. 24)"New value: +"App minSdk (e.g. 24)"

changedInput schema / properties / targetSdk / description

Previous value: -"App targetSdk for API 36 compliance checks (e.g. 36)"New value: +"App targetSdk (e.g. 37)"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "counts": {
+      "additionalProperties": false,
+      "properties": {
+        "error": {
+          "type": "integer"
+        },
+        "info": {
+          "type": "integer"
+        },
+        "warning": {
+          "type": "integer"
+        }
+      },
+      "required": [
+        "error",
+        "warning",
+        "info"
+      ],
+      "type": "object"
+    },
+    "language": {
+      "enum": [
+        "kotlin",
+        "xml",
+        "gradle",
+        "unknown"
+      ],
+      "type": "string"
+    },
+    "minSdk": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "rulesEvaluated": {
+      "type": "integer"
+    },
+    "targetSdk": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "verdict": {
+      "enum": [
+        "PASS",
+        "WARN",
+        "FAIL"
+      ],
+      "type": "string"
+    },
+    "violations": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "column": {
+            "type": "integer"
+          },
+          "docUrl": {
+            "type": "string"
+          },
+          "line": {
+            "type": "integer"
+          },
+          "message": {
+            "type": "string"
+          },
+          "replacement": {
+            "type": "string"
+          },
+          "ruleId": {
+            "type": "string"
+          },
+          "severity": {
+            "enum": [
+              "error",
+              "warning",
+              "info"
+            ],
+            "type": "string"
+          },
+          "snippet": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "ruleId",
+          "severity",
+          "line",
+          "column",
+          "snippet",
+          "message",
+          "replacement",
+          "docUrl"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "verdict",
+    "language",
+    "minSdk",
+    "targetSdk",
+    "counts",
+    "rulesEvaluated",
+    "violations"
+  ],
+  "type": "object"
+}

First observedv1.7.1Jun 11, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real value beyond them: the 34-rule coverage areas, PASS/WARN/FAIL outcome shape, line-level fixes with doc links, structuredContent, and that comments are ignored. It omits any limits on code size or rate behavior, keeping it below 5.

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?

Five short sentences, each carrying distinct information: when to call, what is checked, what is returned, an edge case, and remediation. The call timing is front-loaded with no filler.

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?

An output schema exists so return values need not be spelled out, yet the description still summarizes the PASS/WARN/FAIL contract. Call timing, scope, language coverage, and remediation loop are all present, leaving nothing an agent needs missing.

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 schema already documents code, minSdk, targetSdk and language (including its enum). The description repeats the language set but adds no syntax or format detail about minSdk/targetSdk, so the baseline 3 is appropriate.

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?

Specific verb (validate/check) applied to a clearly bounded resource (Kotlin, XML and Gradle code blocks) with an explicit scope of 34 rules. It is easily distinguished from siblings such as gradle_dependency_checker or android_component_status, which serve different purposes.

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?

Gives an explicit trigger ('call after generating every Android code block, before returning it') and a follow-up loop ('on FAIL, fix and re-run'). It does not name alternative validation tools (e.g. gradle_dependency_checker) or state when not to use it, so it falls 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.