neurover_wait_generation

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

Annotations already declare that this is a safe read operation, and the description adds useful traits beyond them: 45-second maximum wait, the need to poll, and a single-poll mode. The final clause loosely says it verifies the orientation of the result, but it does not say what happens when the orientation is wrong, so this behavior stays vague.

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?

Three compact sentences cover the step label, the purpose, the polling semantics, and the readiness check, with no filler. Front-loading 'ШАГ 3' before the purpose is fine in this pipeline, though it is slightly less immediately useful than leading with the verb.

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 polling-status tool with no output schema and 0% parameter description coverage, the description leaves important gaps: the required workflowId is unexplained, the effect of 'verifying orientation' is undefined, and the return format is not hinted at. The minimum viable polling behavior is there, but not enough to confidently handle edge cases.

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%, so the description must document six parameters. It explains messageId, nodeId, and timeoutSeconds well (up to 45 seconds, 0 means poll once), but it never explains the required workflowId or the account and details parameters, leaving half the schema without added meaning.

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 has a clear verb and resource: it checks generation status by messageId or nodeId, and the 'ШАГ 3' label places it in the generation pipeline after the prepare and submit steps. However, it never explicitly distinguishes this tool from the sibling neurover_generations or neurover_draft_view, so an agent must infer which one to call.

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?

It gives real usage guidance: call it repeatedly until ready, set timeoutSeconds=0 to just check the status once, and do not wait more than 45 seconds in one call. What is missing is any comparison with alternatives, such as when to use this tool instead of listing generations or downloading directly.

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