build.build_release_candidate

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

With no structured annotations, the description carries the full burden of behavioral disclosure. It includes bracketed tags [approval required][workspace write][network][risk:dangerous] that clearly signal side effects, privilege, and danger. It also states that release signing is delegated to the target project, which is important context. It does not detail what gets overwritten or the final artifact location, but the risk profile is well communicated.

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?

The description is exceptionally concise: one sentence with risk/approval tags front-loaded, followed by a clear statement of the core function and a note about signing delegation. No filler words or redundant details. Every part earns its place.

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 tool with one optional enum parameter and no output schema, the description covers the high-risk side effects and signing delegation. However, it omits what the tool returns (e.g., APK path) and does not explain how 'kind' influences behavior. Given the tool's build context and the presence of sibling build tools, this is a moderate gap that prevents full autonomous invocation.

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?

Schema description coverage is 0% and the description does not mention the 'kind' parameter at all. Although the schema itself enumerates allowed values (flutter, react-native, android), the description provides no additional meaning about how kind affects the build or which value to select. Since coverage is low and the description fails to compensate, parameter semantics are minimal.

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?

The description clearly states the action ('Build a release candidate APK') with a specific resource type. It distinguishes itself from sibling tools like build.build_debug_apk by naming 'release candidate' and mentions delegation of release signing. This gives an unambiguous purpose.

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?

No explicit guidance on when to use this tool versus alternatives such as build_debug_apk or flow.run_script. The tags imply approval and risk, but there is no statement of conditions or exclusions. The agent must infer usage from the name and generic build context.

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