audit_kotlin_security

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

With no annotations, the description must carry the behavioral burden. It does disclose that it audits for secret leaks, unencrypted preferences, cleartext traffic, and scaffolds two specific components, but it does not explicitly state side effects such as whether files are modified, what the return format is, or how the audit result is delivered.

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 two focused sentences, with the audit scope front-loaded and the remediation behavior stated immediately after. Every sentence adds distinct, useful information with no filler.

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 no output schema and no annotations, an agent still cannot tell whether calling the tool returns a findings report, scaffolded code, or writes files into a project. The description covers what is checked and scaffolded but omits return behavior and boundary conditions, making it adequate but not complete.

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 coverage is 100%, so the schema already documents codeSnippet and enableBiometrics. The description's mention of BiometricPrompt loosely aligns with enableBiometrics, but it does not add format, interaction, or default-value semantics beyond the schema. Baseline 3 is appropriate.

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 tool audits Kotlin code for specific security issues and scaffolds concrete remediation classes, AndroidX EncryptedSharedPreferences and BiometricPrompt. This distinguishes it from sibling audit tools like audit_kotlin_codebase and audit_kotlin_accessibility.

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 implies it should be used when a Kotlin security audit or security remediation is needed, but it does not explicitly mention alternatives, exclusions, or when not to use it. There is no routing guidance beyond the obvious scope.

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