get_app_datasafetyGoogle Play "Data safety" section for one app: data shared, data collected, security practices, and privacy policy URL. Google only — passing store="apple" returns a not_supported error.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Google package name. | |
| lang | No | Language. | |
| store | No | Must be google. Default google. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive operations. The description adds behavioral context beyond these by specifying that non-Google store values yield a not_supported error and enumerating the returned data categories, which is not in the 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 two sentences that efficiently convey the tool's purpose, output contents, and a key error condition. No wasted words; front-loaded with the main purpose.
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 no output schema, the description compensates by listing the content areas returned (data shared, collected, security practices, privacy policy URL). It also covers the platform limitation with an error example. The tool is simple (3 params), so this is sufficiently complete, though it lacks explicit return structure details.
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 provides descriptions for all three parameters (100% coverage). The description does not add new parameter-specific semantics beyond the schema; it merely reinforces the store='google' constraint already in 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 identifies the tool as retrieving the Google Play Data safety section for a single app, listing the specific content areas (data shared, collected, security practices, privacy policy URL). It distinguishes itself from sibling tools like get_app_permissions by focusing on data safety, and the Google-only limitation is explicit.
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 states the tool is Google-only and that passing store='apple' results in a not_supported error, providing a clear exclusion. It gives context that it is for the data safety section of one app, implying when it should be used, though it does not directly compare to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct data resource: app details, reviews, permissions, data safety, charts, categories, developer, similar apps, search, autocomplete, and ASO keyword/rank tools. Even get_app vs get_apps_batch is clearly separated by single vs batch/bundleId lookups.
Most tools follow a get_* verb_noun pattern (get_app, get_charts, get_developer), but autocomplete_suggest and search_apps deviate slightly. The style is otherwise consistent with clear snake_case naming.
13 tools is well within the ideal range for a store data API serving both Apple and Google. Each tool covers a distinct aspect, and none are redundant or excessive.
The tool set covers all major read-only store data needs: search, detailed app info, reviews, charts, categories, developer, similar apps, and ASO insights. Minor gaps include lack of time-series rank tracking and no dedicated changelog endpoint, but version history is included in get_app.