neurover_generations

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only a list of returned fields, which is closer to return-value documentation than behavioral disclosure, and omits pagination behavior (limit/beforeId), whether history is truncated, and any account scoping semantics. With no output schema, some credit is due for describing what comes back, but not much.

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 compact sentence, front-loaded with the resource, with no filler. It is efficient, though the colon-separated field list substitutes enumeration for explanation rather than earning each item's place.

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?

Five parameters with zero schema documentation, no output schema, and a paginated history tool that never explains paging or the meaning of details/account. The definition is not complete enough for an agent to invoke it confidently beyond passing workflowId.

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?

Schema description coverage is 0% for 5 parameters, so the description carries the full burden and largely fails: limit, account, details and beforeId are never mentioned, and even the required workflowId is only hinted at via the word 'полотно' (canvas). Only a vague implication that results are scoped to a canvas generation exists.

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 the resource and its content specifically: generation history of the canvas, enumerating prompts, settings, sent references, price, results and messageId. This makes it clearly a read/history tool and distinguishes it from creation-oriented siblings like neurover_submit_generation or neurover_prepare_generation. It falls short of a 5 because it never states the scope/verb in a routing way (e.g. per-workflow history) and offers no explicit sibling differentiation.

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 call this versus adjacent read tools such as neurover_media, neurover_statistics, neurover_charges or neurover_wait_generation. No prerequisites, no mention of needing a workflow ID first. The agent must infer usage entirely from the tool name.

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