build_apk

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

With no annotations, the description supplies the essential caveats itself: the produced APK is unsigned and must be signed separately, and apktool must be on PATH. This covers the main behavioral risks (installing an unsigned build, missing dependency) better than most tools. It does not describe output location or failure behavior, but those are secondary for a build operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each earning its place: purpose, critical artifact caveat, and prerequisite. It is front-loaded with what the tool does and wastes no words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a build tool without annotations or output schema, the description covers the workflow context, artifact safety, and environment requirement. It does not state the output path or return value, but the schema already documents the parameters and the description gives enough to invoke it correctly.

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

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

All three parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description adds only the pipeline framing that inputDir is decoded and possibly edited, which is already in the schema's inputDir description. No extra parameter-level meaning is contributed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Uses the specific verb 'Rebuild' with a precise resource ('an APK from an apktool-decoded project directory') and is clearly the inverse of decode_apk among siblings. The unsigned-result caveat further disambiguates what the build artifact is.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description positions the tool within the decode → edit → build → sign → install flow by calling the input an apktool-decoded project and warning to sign before installing. This implies use after decode_apk and before adb_install, though it never names those siblings explicitly. That is clear usage context without formal exclusions.

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