post_dataforseo_on_page_non_indexableThis endpoint returns a list of pages that are blocked from being indexed by Google and other search engines through robots.txt, HTTP headers, or meta tags settings.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / properties / body / items / properties / filters / descriptionPrevious value: -"array of results filtering parameters optional field you can add several filters at once (8 filters maximum) you should set a logical operator and, or between the conditions the following operators are supported: regex, not_regex, , , >, >=, =, , in, not_in, like, not_like you can use the % operator with like and not_like to match any string of zero or more characters example: [\"reason\",\"=\",\"robots_txt\"][[\"reason\",\"\",\"robots_txt\"], \"and\", [\"url\",\"not_like\",\"%/wp-admin/%\"]] [[\"url\",\"not_like\",\"%/wp-admin/%\"], \"and\", [[\"reason\",\"\",\"meta_tag\"],\"or\",[\"reason\",\"\",\"http_header\"]]] The full list of possible filters is available by this link."New value: +"array of results filtering parameters optional field you can add several filters at once (8 filters maximum) you should set a logical operator and, or between the conditions the following operators are supported: regex, not_regex, <, <=, >, >=, =, <>, in, not_in, like, not_like you can use the % operator with like and not_like to match any string of zero or more characters example: [[\"reason\",\"<>\",\"robots_txt\"], \"and\", [\"url\",\"not_like\",\"%/wp-admin/%\"]] [[\"url\",\"not_like\",\"%/wp-admin/%\"], \"and\", [[\"reason\",\"<>\",\"meta_tag\"],\"or\",[\"reason\",\"<>\",\"http_header\"]]] The full list of possible filters is available by this link."Input schema / properties / body / items / properties / offset / descriptionPrevious value: -"offset in the results array of returned pages optional field default value: 0 if you specify the 10 value, the first ten pages in the results array will be omitted and the data will be provided for the successive pages"New value: +"offset in the results array of returned pages optional field default value: 0 maximum value: 2000000 if you specify the 10 value, the first ten pages in the results array will be omitted and the data will be provided for the successive pages"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and readOnlyHint=false, yet the description characterizes the operation purely as a retrieval ('returns a list of pages'). An agent reading the description would assume a safe read, directly conflicting with the destructive annotation, so the safety profile is misrepresented.
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?
A single, well-formed sentence that front-loads the core purpose with no filler. It is appropriately sized, though it omits any usage or prerequisite framing that would make it more actionable.
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?
An output schema exists, so return values need not be explained, but the description omits the task-ID prerequisite, any usage guidance, and any parameter/pagination context. For a POST endpoint that requires an id obtained elsewhere, this leaves meaningful gaps for correct invocation.
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?
With 0% schema description coverage reported and a single required 'body' array parameter, the description carries the full burden of parameter explanation, yet it says nothing about limit/offset pagination, filters syntax, or the required task id. The description adds no parameter meaning beyond what the nested schema already provides.
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 verb and resource ('returns a list of pages that are blocked from being indexed') and even defines what 'non-indexable' means via robots.txt/HTTP headers/meta tags. It is clearly distinguishable from other OnPage endpoints conceptually, though it does not explicitly contrast itself with the many sibling post_/get_ tools.
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?
There is no guidance on when to use this tool versus alternatives, nor any mention of the prerequisite workflow. The schema's 'id' field reveals you must first obtain a task ID from the Task POST endpoint, but the description never states this dependency, leaving the agent without the context needed to invoke it successfully.
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.