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

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: no read-only confirmation, no pagination/limit behavior, no rate limits, no auth or cost profile, no note on what response_mode compact vs full changes. A single vague sentence is inadequate for a multi-operation research tool.

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?

It is a single short sentence with no preamble, so it is structurally clean and front-loaded. However it is under-specified rather than genuinely concise, trading away needed detail for brevity.

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 tool with 12 operations, nested filter/order objects, and an output schema, the description is far too thin. It never explains the operations, the compact/full response modes, or how keyword vs keywords are chosen, leaving significant gaps even though return values are covered by the output schema.

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 description adds no parameter meaning at all. While the nested schema does carry descriptions for operation, keyword, keywords, language, location, and target, the top-level payload and remaining fields (filters, order_by, date ranges, include_clickstream_data) are undocumented, so the description does not compensate for the stated coverage gap.

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 verb 'research' is vague, but the resource is clearly keyword data and the description enumerates the sub-capabilities (demand, ideas, difficulty, intent, history) which roughly map to the 12-operation enum. It does not differentiate this tool from keyword-adjacent siblings such as trend-data or search-ads-data, leaving the agent to guess at boundaries.

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 explicit when-to-use, when-not-to-use, or alternative-tool guidance. With 12 operations available under a single payload, the description gives no hint of which operation suits which research goal, which is the primary selection problem an agent faces here.

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