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

The description adds a behavioral note that untracked URLs are scraped fresh and not persisted, which is useful. But with no annotations, it does not disclose whether the tool is read-only, if any caching occurs, or what the response looks like, leaving significant gaps for a non-annotated tool.

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 sentences, front-loaded with the main action and object. The second sentence efficiently explains the dual input types with no redundancy or filler, making it appropriately sized and well-structured.

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?

With no output schema and no annotations, the description supplies core input semantics and a side-effect note, but omits what the comparison output includes, error scenarios, or performance caveats. It is adequate for basic invocation but not fully complete given the lack of structured context.

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 description essentially restates the input schema's property descriptions (id vs url) without adding new meaning. Since schema coverage is 50% but the existing descriptions are already clear, the description neither enriches nor harms parameter understanding.

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 compares the privacy posture of two apps side by side, using a specific action ('Compare') and resource ('privacy posture'). It distinguishes itself from siblings like get_app or list_apps, which do not perform comparisons.

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?

It explicitly describes the two acceptable input types (tracked id vs untracked URL) and their differing behavior, giving clear context for use. However, it does not name alternative tools or state when not to use this tool, so it stops 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.

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool returns a privacy dossier with specific components, including a conditional policy summary ('if one has been generated'), which adds useful behavioral context. It does not discuss errors or permissions, but the read-only nature is evident from 'Get' and the focus on returning data.

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 a single, well-structured sentence that front-loads the core action and then lists the return contents in a clear, readable format. Every part adds value, with no wasted 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 simple single-parameter tool with no output schema, the description is complete. It explains the scope ('single tracked app'), the nature of the data (privacy dossier), the major return fields, and the conditional policy summary. It gives an agent enough information to decide whether to invoke this tool and what to expect from the result.

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 100%, so the single parameter appId is already fully documented in the schema, including its format and source (App Store URL /id<NNN>). The description does not add parameter-specific semantics beyond referring to 'a single tracked app,' but this is acceptable because the schema already provides the necessary detail. Baseline of 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 uses a specific verb ('Get') and resource ('full privacy dossier for a single tracked app'), clearly distinguishing it from sibling tools like list_apps or compare_apps. It also enumerates the returned contents (identity, privacy types/categories, last snapshot, policy summary), making the tool's purpose unmistakable.

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 phrase 'for a single tracked app' provides clear context for when to use this tool—when you need details for one app, not a list or comparison. It does not explicitly mention alternatives or exclusions, but the sibling tool names (list_apps, search_apps, compare_apps) make the distinction implicit.

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

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

With no annotations provided, the description must disclose behavior itself. It does so by specifying the exact contents of the output (every snapshot diff, including label changes, policy revisions, wayback baselines), the chronological ordering, and the inclusion of the triggering event. It stops short of mentioning potential size limits, error conditions, or data availability caveats, but for a read-only get tool, the core behavior is well described.

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 a single, information-dense sentence with no filler words. It front-loads the main action and then efficiently enumerates what the changelog contains and how it is organized. Every clause adds value, making it highly concise while remaining readable.

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 has only one parameter, no annotations, and no output schema, the description carries the burden of explaining the return value. It thoroughly specifies the output contents (all diff types, chronological order, trigger info), giving the agent a complete picture of what to expect. With full parameter documentation in the schema, nothing else is needed for a tool of this simplicity.

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 only parameter appId is fully described in the schema as 'The numeric Apple track ID', so schema coverage is 100%. The description adds no additional meaning about the parameter beyond reinforcing that it identifies 'one app', which is already implied. Baseline 3 is appropriate because the schema handles the semantics completely.

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 verb 'Get' and the resource 'full privacy changelog for one app', then elaborates with specific content (snapshot diffs, label changes, policy revisions, wayback baselines) and ordering (chronological) plus trigger info. This differentiates it from siblings like get_changelog, which likely covers all apps, by explicitly scoping to a single app.

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 provides clear context: it is for retrieving a comprehensive changelog for a specific app. It implicitly tells the agent when to use this tool (when a detailed, chronological history of an app's privacy changes is needed) but does not explicitly name alternatives or exclusions. The 'for one app' phrasing helps distinguish it from global changelog tools, earning a 4 rather than 3.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It explains the row semantics (single change event with app context) and mentions pagination, but it does not disclose whether the operation is read-only, any authentication requirements, rate limits, or ordering behavior. The description adds some useful context beyond the schema but is not fully transparent.

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 sentences with no filler. The first sentence states the core purpose, and the second adds row-level detail and capability highlights. Every clause earns its place, and it is front-loaded with the most important information.

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 has 7 optional parameters, no output schema, and no annotations, the description provides a clear picture of the output (rows of change events) and available filters. It does not explain ordering or default time window, but the schema covers most parameter details. Overall, it is reasonably complete for a read-only list tool, though a bit more detail on sorting or return structure would be helpful.

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 has 100% description coverage for all 7 parameters, so the schema already explains each parameter. The description merely lists the filter dimensions (app, time window, type, category) and pagination without adding new meaning or clarifying parameter formats or interactions, so it meets the baseline of 3 without exceeding it.

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 a specific verb ('Get') and resource ('universal privacy changelog across every tracked app'), and the phrase 'universal' distinguishes it from the sibling tool 'get_app_changelog', which is likely per-app. It also enumerates the event types in each row, removing ambiguity about what is returned.

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 when to use the tool ('Get the universal privacy changelog') and mentions filtering by app, time window, type, and category, but it does not explicitly contrast with alternatives like 'get_app_changelog'. No exclusionary guidance is provided, so while the context is clear, there is no explicit when-not-to-use guidance.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds useful context like calendar-quarter alignment and the type of outputs, but it does not explicitly state that the operation is read-only or mention any rate limits or error conditions. The 'Get' verb implies safety but doesn't make it explicit.

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 sentences long, front-loaded with the verb and resource, and provides precise output details without any fluff. Every word 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?

Since there is no output schema, the description does a good job covering the main return components and temporal bucketing. It doesn't mention edge cases like empty results or invalid appId, but it's sufficiently complete for a single-parameter read tool.

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 schema fully describes the appId parameter as 'The numeric Apple track ID.' (100% coverage). The tool description adds no additional parameter-level meaning beyond restating the resource context. 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 identifies the resource (one app) and the specific outputs (per-quarter category trend with added/removed, and a sparkline of change-event counts). This distinguishes it from siblings like get_changelog that likely return raw events.

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 the tool is for aggregated history stats, but it does not explicitly contrast it with get_changelog or get_app_changelog. It provides clear context without exclusions, so it earns a 4 rather than a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool is read-only, does not mark anything as read, and provides the maximum count and unread count. This is adequate for a simple read operation, though it does not mention authentication or rate limits.

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 concise and front-loaded, consisting of two sentences that convey all essential information without waste. Every word adds value.

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 simple, parameterless notification retrieval tool without an output schema, the description is complete. It specifies the response content (up to 30 notifications, unread count) and side effects (read-only), which is sufficient for this context.

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 tool has zero parameters, so the schema provides no parameter information. The description correctly adds no parameter semantics because there are none, which is appropriate given the baseline of 4 for 0-parameter tools.

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 specific action ('Get'), the resource ('privacy-change notifications'), and additional details (up to 30, plus unread count). It is unambiguous and distinct from sibling tools like list_apps or get_changelog.

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 usage for retrieving recent notifications, but it does not explicitly state when to use this tool versus alternatives or mention exclusions. No alternative tools are referenced.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It lists the exact data returned (run state, start time, last log lines, summary readiness) and implies a read-only operation. It does not explicitly state side effects or error conditions, but for a status-checking tool this is fairly transparent. A 4 is appropriate because it goes beyond a vague 'get status' and details the output.

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 sentences, front-loaded with the main purpose, and every phrase adds value. It lists the key output fields without clutter and provides a clear pointer to a sibling tool. No wasted 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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description provides a complete picture: it states what the tool does, what fields it returns, and how it relates to get_app. The possible state values (idle/running/done/error) are also included. This is sufficient for an agent to select and invoke the tool 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?

The input schema already describes the only parameter appId as 'The numeric Apple track ID.' Description coverage is 100%, so the schema does the heavy lifting. The description adds no meaningful parameter detail beyond what the schema provides, but it does mention 'for one app,' which aligns with the single parameter. Baseline 3 is correct.

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's function: 'Get the privacy-policy AI run status for one app' and enumerates the specific outputs (run state, start time, last log lines, summary ready flag). It also distinguishes itself from the sibling tool get_app by directing users to get_app for the actual summary content.

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 explicitly mentions an alternative: 'Use get_app for the actual summary content.' This tells the agent when to use this tool (to check status) and when to use a different tool (to fetch the summary), providing clear usage guidance.

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

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

Without annotations, the description adds the key behavioral detail of returning a 404 when the version is the first scrape, and specifies the diff type (line+word). It does not cover other potential traits like auth or rate limits, but for a read-only diff tool this is adequate.

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?

Two short sentences; the first states the action and scope, the second notes an important edge case. No wasted 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?

Given the simple single-parameter tool and no output schema, the description covers purpose, scope, and a key error condition. It lacks explicit output format details, but the 'line+word diff' phrasing gives a general idea.

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 only parameter, versionId, has a 100% schema description that already explains its purpose. The description adds no additional parameter semantics beyond the schema.

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?

Description states the specific operation: getting a line+word diff between two consecutive versions of the same app. It clearly distinguishes from siblings like compare_apps (which compares apps) by specifying 'for the same app' and 'immediately before it.'

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 the tool is for viewing changes between adjacent versions, but does not explicitly mention alternatives or when not to use it. Sibling tools like compare_apps exist, but no exclusions are provided.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly discloses the output dimensions (running, last ran, next due, interval), which is helpful. However, it does not mention potential side effects, authentication requirements, or whether the status is real-time or cached. This is acceptable for a simple getter but not deeply transparent.

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 a single, well-structured sentence that front-loads the operation and resource, then concisely lists all provided status components. There is no unnecessary information or redundancy.

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 parameterless, simple status getter, the description provides enough semantic context about the return content. However, since there is no output schema, it could specify exact response field names or timestamp formats (e.g., ISO 8601) to make it fully complete. The low complexity keeps it adequate.

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 tool has zero parameters and schema description coverage is 100% (vacuously). The description does not need to add parameter details, and the baseline for zero parameters is 4. The description adds no parameter-specific meaning, but none is required.

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 verb 'Get' and the resource 'background sync scheduler status', and enumerates exactly what information is returned (running state, last run time, next due time, interval). This distinguishes it from sibling tools like get_policy_status and get_history_stats, which target different resources.

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 its use for checking sync health, but does not explicitly state when to use it versus alternatives or mention any exclusions. It lacks guidance like 'use this when you need to verify the scheduler is active' or 'not for checking individual sync errors.'

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

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

Since there are no annotations, the description must disclose behavior and does so by listing return fields and the optional grouped view. However, it omits potential behavioral traits such as pagination, sorting, or rate limits, which are relevant for a listing tool.

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 sentences, front-loaded with the primary purpose, and includes the optional grouping in a concise manner. There is no redundant or unnecessary wording.

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 simple list tool, the description covers the operation, return fields, and parameters sufficiently. The absence of an output schema is mitigated by listing the returned data. However, it lacks guidance on alternative tools and edge-case behaviors, which prevents a perfect score.

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 only parameter 'grouped' is fully documented in the input schema (100% coverage). The description's phrase 'Optionally returns a grouped view' mirrors the schema without adding new semantic meaning, so the baseline of 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 it lists every app in the PrivacyTracker library with specific fields (developer, bundle id, change counts, timestamps). The verb 'List' and scope 'every app' distinguish it from siblings like get_app (single app) and search_apps (filtered search).

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 is provided on when to use this tool versus alternatives. It does not mention that search_apps might be used for filtering or that this tool is the comprehensive listing, leaving the selection criteria to the agent's inference.

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

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

With no annotations, the description carries the full transparency burden. It states that the tool returns candidate matches with App Store URLs, which conveys the search-like, non-exact nature of results and the downstream workflow. It does not detail failure modes or result limits, but these are less critical for a simple read-only search.

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 sentences with no filler. The first sentence gives the core action, and the second adds workflow and parameter-combination guidance. Every sentence 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 simple search tool with optional parameters and no output schema, this description is nearly complete: it provides the purpose, return type (candidate matches with App Store URLs), and intended use case. It could elaborate on the structure of each candidate match, but the schema covers parameters and the description is sufficient to invoke the tool 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?

The input schema already describes all three parameters (100% coverage), but the description adds guidance on combining `names` and `bundleIds` ('Pass either `names` or `bundleIds` (or both)') and clarifies that the returned URLs are for adding to PrivacyTracker. This adds value beyond the schema.

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 uses a specific verb ('Search') with a clear resource ('iTunes Store for App Store entries') and identifies the key search dimensions (name or bundle id). It also distinguishes the tool from siblings like list_apps or get_app by framing the result as candidate matches for adding to PrivacyTracker.

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 explains the tool's context: search the App Store to find apps to add to PrivacyTracker. It also instructs to pass either `names` or `bundleIds` (or both). However, it does not explicitly name alternative tools for retrieving existing apps, so it lacks explicit exclusions.

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