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

Annotations declare a non-readonly, non-destructive, closed-world write, and the description adds substantive behavior beyond them: the returned task_id/status/progress envelope, the terminal-state semantics (succeeded/partially_succeeded/failed), the fact that ending the wait is not a cancellation, and the findings_error convention meaning unavailable rather than absent. It does not mention auth or rate constraints, but coverage is strong for a task-starting 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?

Front-loaded with the action and focus areas, then the return/state semantics, then the sibling exclusions. Information-dense and free of filler, though the middle stretch packs several distinct facts (statuses, findings_error, wait semantics) into successive short sentences without grouping.

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?

Given a two-parameter, non-destructive write with an output schema, the description covers what is needed: what triggers what, how to continue polling, which states are terminal, cancellation semantics, and error conventions. An agent can invoke and follow up correctly without consulting anything else.

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 coverage is 100%, so baseline is 3, and the description earns above it by spelling out the focus values (clarity, problem framing, completeness, all) in prose where the schema's own text is only 'The analysis focus area'. It does not add anything for invention_id, which the schema already documents with pattern and length bounds.

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?

States a specific verb (Starts automated analysis) plus the resource (a registered innovation description) and enumerates the focus areas. It also names the sibling capabilities it is NOT (novelty assessment, patent search, FTO, attorney review, patent preparation), so an agent can discriminate it from surrounding tools.

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?

Explicitly routes ongoing work to get_task_status with the same task_id, states which statuses are terminal, and clarifies that ending the wait does not cancel analysis. It lacks an explicit 'use this when X, use that when Y' trigger statement, but the boundary with adjacent request types is clearly drawn.

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