post_dataforseo_app_apple_app_reviews_submitThis endpoint will provide you with reviews published on the App Store platform for the app specified in the app_id field. The returned results are specific to the indicated language and location parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / properties / body / items / properties / depth / descriptionPrevious value: -"parsing depth optional field number of reviews to be returned in the API response; we strongly recommend setting the parsing depth in the multiples of 50, because our system processes 50 reviews in a row; default value: 50; maximum value: 500; Your account will be billed per each SERP containing up to 50 results; Setting depth above 50 may result in additional charges if the search engine returns more than 50 results; The cost can be calculated on the Pricing page."New value: +"parsing depth optional field number of reviews to be returned in the API response; we strongly recommend setting the parsing depth in the multiples of 25, because our system processes 25 reviews in a row; default value: 25; maximum value: 500; Your account will be billed per each SERP containing up to 25 results; Setting depth above 25 may result in additional charges if the search engine returns more than 25 results; The cost can be calculated on the Pricing page."Input schema / properties / body / items / properties / language_code / descriptionPrevious value: -"search engine language code required field if you don’t specify language_name if you use this field, you don’t need to specify language_name you can receive the list of available languages with their language_code by making a separate request to https://api.dataforseo.com/v3/app_data/apple/languages example: en"New value: +"search engine language code required field if you don't specify language_name if you use this field, you don't need to specify language_name you can receive the list of available languages with their language_code_by making a separate request to https://api.dataforseo.com/v3/app_data/apple/languages example: enn"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=true, i.e. a non-idempotent write that creates a billable task. The description instead frames the tool as retrieving reviews, which reads like a safe read operation and obscures the task-creation, pricing, and callback behavior. This is a direct inconsistency with the structured 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?
Two sentences with no padding, so it is concise. But the wording appears lifted from the fetch endpoint, so the brevity comes at the cost of saying the wrong thing about an async submit operation.
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 task-submission endpoint with a rich nested schema (priority billing, pingback/postback URLs, depth-based charges) and an output schema, the description omits every operational detail an agent needs: that this enqueues work, that results arrive later via fetch or postback, and that high priority and extra depth cost money.
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 single top-level body parameter has no description at all (0% coverage), so the description would need to compensate for the required app_id, the location/language either-or constraint, and the postback pairing. It adds none of that; the only meaningful documentation lives in the nested schema properties, which the description does not reference or clarify.
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 names a specific resource (App Store reviews) and a specific key field (app_id), so the subject matter is clear. However, it presents the endpoint as one that 'will provide you with reviews', when the tool name and annotations indicate it is an asynchronous task-submission endpoint that returns a task ID, not the reviews. It also fails to distinguish itself from the sibling get_dataforseo_app_apple_app_reviews_fetch.
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 guidance on when to use this submit endpoint versus the fetch counterpart, and no mention of the prerequisite location/language pair or the postback workflow that the schema enforces. The agent must infer the submit-then-fetch pattern entirely on its own.
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.