list_generation_jobs

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is clearly safe and non-mutating. The description adds the 'local' scoping qualifier, which is useful, but it does not disclose further behavior such as default ordering, pagination behavior, or whether the list is limited to the current session. Given that annotations already carry the key safety traits, a 3 is appropriate.

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?

The description is a single, short sentence with no filler. It states exactly what the tool does in the fewest possible words while still including the important 'local' scope qualifier.

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 simple list operation with all parameters documented and annotations covering idempotency and read-only behavior, the description is mostly sufficient. The only minor gap is that it does not mention what the returned list contains or whether results are paginated, but since there is no output schema and this is a straightforward list action, the current level of detail is nearly complete.

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 input schema has 100% description coverage: each parameter (limit, status, media_type) has a clear description and type. The description itself does not need to repeat parameter details. The baseline 3 applies because the schema does the heavy lifting and the description adds no extra parameter guidance beyond that.

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 uses a specific verb ('List') and a specific resource ('local Raven creative generation jobs'), making the operation unambiguous. The scope qualifier 'local' and the domain qualifier 'Raven creative generation' help distinguish it from the many sibling tools, particularly get_generation_job and create_generation_job.

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?

The verb 'List' implies this tool is for enumerating jobs rather than retrieving or creating one, but the description does not explicitly state when to prefer this over get_generation_job or create_generation_job. The usage context is inferable from the name and siblings, but no direct guidance or exclusions are given.

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