audit_ios_privacy

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false; the description reinforces this by saying it 'Reads' inputs rather than mutating anything. It adds meaningful behavioral scope: what is inspected (Info.plist, app.json, PRIVACY.md, entitlements, source), and what kinds of issues are flagged. It also notes 'Same return shape as audit_page,' which gives return-consistency context. No contradiction with annotations.

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 dense yet well-structured: it leads with the purpose, then input alternatives, optional inputs, flag categories, and finally return-shape consistency. Despite its length, every phrase contributes to the agent's ability to select and invoke the tool correctly. There is no filler or restatement of the name.

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?

Given the tool's complexity (multiple input formats, optional cross-references, many detection categories) and the absence of an output schema, the description provides strong contextual coverage. It states what the tool reads, what it flags, and that it matches the return shape of audit_page. It leaves the exact return structure implicit by referencing audit_page, which is acceptable but not a full output description.

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?

The input schema already describes and covers all five parameters, so baseline is 3. The description adds key semantics above the schema: it clarifies that managed Expo apps have no Info.plist, that source enables code-vs-declaration contradiction checks, and that transient fields like expo.ios.infoPlist, expo.android.permissions, plugins, and extra are audited. This adds meaningful guidance for how the parameters are used together, supporting a 4.

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 opens with a specific verb and resource: 'Audit an iOS or React Native/Expo app's privacy posture for App Review and user trust.' It precisely names the audit domain and differentiates itself from general-purpose audit siblings like audit_page, audit_ios_a11y, and audit_asset_integrity by focusing on privacy posture.

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 establishes clear when-to-use context: for an iOS/React Native/Expo app's privacy posture in App Review and user trust contexts. It explains that a native Info.plist OR an Expo app.json is read, plus optional supplementary files. It does not explicitly name alternative tools or give exclusion conditions (e.g., 'use audit_ios_a11y if auditing accessibility instead'), but the use case is unambiguous.

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