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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. Beyond that, the description discloses a genuinely important behavioral trait the annotations can't express: the call depends on prior state from query_contexts and will produce a wrong body if steps 1–2 are skipped. It still doesn't state failure modes or rate-limit/external-API behavior.

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?

Front-loads the workflow position and uses a compact numbered prerequisite list, which is the right structure for a gated tool. Minor waste: "Always call step 2 to see the exact body structure" and "Rely on info from steps 1-2" restate what the numbered list already said.

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 an output schema exists, return values need no explanation, and the multi-step precondition—the hardest part of this tool—is well covered. But for a tool whose single parameter is an entirely opaque free-form body, the description never explains what actions are available or how this differs from execute_action, leaving an agent's biggest decision unaddressed.

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?

There is one parameter, 'body', which is a free-form object with additionalProperties and 0% schema description coverage, so the schema carries no meaning at all. The description compensates by telling the agent exactly where to obtain the body structure (actions_details), but 'Follow the schema exactly' is misleading when the schema declares an unconstrained object with no defined properties.

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?

"Query DataForSEO data" names a verb and resource and places itself as step 3 (FINAL) of a workflow, which helps position it against query_contexts. However, it never says what kind of query this is (which endpoint family, what a 'query body' executes) and says nothing to distinguish it from the sibling execute_action, which sounds functionally equivalent.

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?

Very explicit prerequisites: it names query_contexts with request='accounts', then request='actions_details' with concrete actions, and insists step 2 always be run first. What's missing is guidance on when to pick this over execute_action, but the entry conditions are unambiguous.

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