AIsa On-Page Audit

Setting OnPage Tasks

post_dataforseo_on_page_submit

Destructive

OnPage API checks websites for 60+ customizable on-page parameters defines and displays all found flaws and opportunities for optimization so that you can easily fix them. It checks meta tags, duplicate content, image tags, response codes, and other parameters on every page. You can find the full list of OnPage API check-up parameters in the Pages section.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`body`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

changedInput schema / properties / body / items / properties / custom_js / description

Previous value: -"custom javascript optional field Note that the execution time for the script you enter here should be 700 ms maximum, for example, you can use the following JS snippet to check if the website contains Google Tag Manager as a scr attribute: let meta = { haveGoogleAnalytics: false, haveTagManager: false };\\r\\nfor (var i = 0; i = 0)\\r\\n meta.haveGoogleAnalytics = true;\\r\\n\\tif (src.indexOf(\\\"gtm.js\\\") >= 0)\\r\\n meta.haveTagManager = true;\\r\\n }\\r\\n}\\r\\nmeta;the returned value depends on what you specified in this field. For instance, if you specify the following script: meta = {}; meta.url = document.URL; meta.test = 'test'; meta; as a response you will receive the following data: \"custom_js_response\": { \"url\": \"https://dataforseo.com/\", \"test\": \"test\" } Note: the length of the script you enter must be no more than 2000 characters Note: if you use this parameter, additional charges will apply; learn more about the cost of tasks with this parameter in our help article; the cost can be calculated on the Pricing Page"New value: +"custom javascript optional field Note that the execution time for the script you enter here should be 700 ms maximum, for example, you can use the following JS snippet to check if the website contains Google Tag Manager as a scr attribute: let meta = { haveGoogleAnalytics: false, haveTagManager: false };rnfor (var i = 0; i < document.scripts.length; i++) {rn let src = document.scripts[i].getAttribute(\"src\");rn if (src!= undefined) {rn if (src.indexOf(\"analytics.js\") >= 0)rn meta.haveGoogleAnalytics = true;rntif (src.indexOf(\"gtm.js\") >= 0)rn meta.haveTagManager = true;rn }rn}rnmeta;the returned value depends on what you specified in this field. For instance, if you specify the following script: `meta = {}; meta.url = document.URL; meta.test = 'test'; meta;` as a response you will receive the following data: `\"custom_js_response\": { \"url\": \"https://dataforseo.com/\", \"test\": \"test\" }` Note: the length of the script you enter must be no more than 2000 characters"

First observedSep 15, 2026

TDQS

D1.8/5.0

Behavior2/5

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

Annotations declare destructiveHint=true, openWorldHint=true and idempotentHint=false, but the description adds nothing behavioral: it doesn't say this is an asynchronous task submission, that it consumes credits/charges (several schema params mention additional charges), or that results must be retrieved via separate endpoints/pingback. With the annotation bar already low, the description still fails to add useful context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences of generic API prose that never front-load the tool's actual action. Nothing is wasted in a harmful way, but the content is misallocated — the reader finishes without knowing what invoking this tool does.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation isn't required, but for a destructive, non-idempotent, credit-consuming task submission with a complex 40+ field body, the description omits task-submission semantics, cost implications, and result-retrieval flow. It is materially incomplete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is reported at 0%, so the description must compensate for the single top-level 'body' array parameter — and it does not mention the body, required fields, target, or max_crawl_pages. The rich per-field documentation lives entirely in the schema, so the description adds no parameter meaning of its own.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description never states the tool's action — it explains what the OnPage API is and what it checks, not that this tool submits/creates an OnPage crawl task. Only the title ('Setting OnPage Tasks') hints at the verb, and the description never distinguishes this from sibling endpoints like force_stop or raw_html. This is closer to API marketing copy than a tool-purpose statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives despite a large sibling set (e.g., force_stop to cancel, content_parsing/keyword_density to consume results). An agent gets no routing signal at all.

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

All AIsa On-Page Audit tools Inspect

Try in Browser

Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?