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

Annotations only say the tool is not read-only and not destructive, so the description carries the behavioral disclosure burden. It surfaces two non-obvious facts: the call starts an asynchronous job that only returns an id, and it costs money. Both are exactly the kind of hidden behavior an agent needs before calling a paid, async generation endpoint.

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?

Two dense sentences carry all the essential information: action and endpoint first, then the critical follow-up behavior and cost warning. There is no filler, repetition of the schema, or unnecessary detail.

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?

The description is complete for a complex, paid, asynchronous tool: it identifies the job-based workflow, tells the agent how to track the result, and warns about cost. An output schema exists, so the description doesn't need to explain return values, and parameter details are already in the input 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?

Schema description coverage is 100%, with each parameter already well documented, so the baseline is 3. The tool description adds no per-parameter semantics, but it also doesn't need to repeat what the schema already provides.

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 opens with a concrete verb and resource ('Start a Kenari video job') and names the exact endpoint, which clearly identifies the tool's role. It is immediately distinguishable from read/status siblings like get_video_status and wait_for_video, and from image-focused siblings.

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 clear context for when to call this tool: when starting a new video generation job. It also tells the agent what to do after invocation, poll via get_video_status/wait_for_video. It does not explicitly contrast with alternatives like extend_video or generate_image, but the phrase 'video job' plus the sibling names makes the intended usage unambiguous.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, and the description adds operational details: it writes to KENARI_OUTPUT_DIR and fails with still_rendering before rendering completes. This clarifies side effects and error behavior beyond the structured fields, without contradicting them.

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 two concise phrases that front-load the core action and destination, then append the error condition. Every sentence earns its place with no unnecessary prose.

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?

With a single fully documented parameter, an output schema present, and annotations covering the safety profile, the description supplies the remaining essential operational facts: endpoint, output directory, and render-state error. Nothing needed for a correct call is missing.

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 100%, and the id parameter is fully documented in the schema as 'Kenari video job id whose finished bytes should be downloaded.' The description does not add further parameter detail, so the baseline of 3 applies.

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 states a specific verb and resource: 'Download finished video bytes via GET /v1/videos/{id}/content to KENARI_OUTPUT_DIR.' This clearly distinguishes the tool from sibling creation and status tools by focusing on retrieving completed content.

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 description implies when to use the tool by saying 'finished video bytes' and warns that it 'Errors with still_rendering while the job renders.' This gives clear context that the tool should be used only after rendering completes, though it does not explicitly name alternatives such as wait_for_video or get_video_status.

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

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

Annotations already indicate this is not read-only and not destructive, so the description's extra context about the POST endpoint, multipart structure, and the rejected 'transparent' background adds meaningful behavioral detail. It does not contradict the annotations, and it clarifies one non-obvious failure mode.

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 focused sentence that front-loads the core action and endpoint, then packs optionality and a rejection rule into a parenthetical. There is no filler or repeated schema content.

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 a fully documented input schema and an output schema, the description is largely complete: it names the endpoint, the required operation, the relevant multipart fields, and the key exception. Minor gaps such as cost or model lookup guidance are covered in the schema itself, so the description does not need to repeat them.

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 the baseline is 3. The description adds value by compactly showing the multipart field names and optionality ('image, mask?, prompt, model, n?, size?, background?') and by explaining that 'background=transparent is rejected', which supplements the enum in the schema.

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 opens with a specific verb and resource: 'Edit a local image via POST /v1/images/edits'. It also distinguishes itself from generate_image by explicitly noting that 'background=transparent is rejected' and directing the agent to the alternative tool.

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 description clearly implies when to use this tool: when a local image needs editing. It gives an explicit when-not rule by stating that transparent backgrounds are rejected and points to generate_image as the alternative. It does not enumerate all sibling comparisons, but the primary routing guidance is present.

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

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

Annotations already mark the call as non-read-only and non-destructive; the description adds that local paths are rejected before any HTTP call, which is useful fail-fast behavior. It does not discuss job asynchrony or side effects, but the annotations lower the burden and the added validation context is meaningful.

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 dense sentence front-loads the action and then packs in the endpoint, payload shape, and the key input constraint. No filler or redundant elaboration.

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?

With an output schema present and all parameters described in the schema, the description supplies the essential extra context: the endpoint and pre-HTTP validation behavior. A note on whether the call returns a job id asynchronously would be a nice addition, but the tool is still sufficiently 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?

Schema description coverage is 100%, so the schema already fully documents model, source, prompt, and duration. The description mostly restates the source semantics and gives the HTTP endpoint, adding little new parameter meaning beyond what the schema provides.

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 opening phrase 'Extend a finished video' names a specific verb and resource, and the POST endpoint with payload makes the operation unambiguous. It is clearly distinguishable from sibling tools like create_video or get_video_status.

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?

'Finished video' states the prerequisite, and the source restriction to a job id or https URL with local paths rejected tells the agent which inputs are valid. It does not explicitly name an alternative tool for non-extension generation, so it stops just short of full routing guidance.

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

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

Annotations establish that this is a write operation but non-destructive. The description adds valuable behavioral detail beyond the annotations: it saves PNG/JPG files to KENARI_OUTPUT_DIR, returns absolute paths, and incurs monetary cost. This gives the agent practical expectations about side effects.

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 compact and front-loaded, covering purpose, mechanism, output location, return value, and cost guidance in two sentences. Every clause contributes useful information without repetition or filler.

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 the fully described schema, existing output schema, and annotations, the description supplies the missing operational context: where files go, what is returned, and a prerequisite to check list_media_models. An agent has enough to call this tool correctly without ambiguity.

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 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides; the cost and model-id guidance mirrors the model parameter description. It does not harm or clarify individual params further.

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 opens with a specific verb and resource: 'Generate image(s)' and gives the exact API endpoint, POST /v1/images/generations. It clearly distinguishes this from sibling tools like edit_image and create_video by stating it creates images and saves them to disk.

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 description gives clear context: use this to generate images, expect per-image IDR costs, and check list_media_models first for model IDs and pricing. It does not explicitly contrast with edit_image or state when to avoid this tool, but the context is strong enough for an agent to select it appropriately.

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

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

The description adds important behavioral context beyond the annotations: although this is a GET endpoint, it auto-downloads to KENARI_OUTPUT_DIR when done, which explains the readOnlyHint=false annotation. This side effect is critical for an agent to invoke the tool safely. It does not detail auth or error handling, but the response semantics are largely covered by the output schema.

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 only two sentences and front-loads the endpoint, then packs statuses and the side effect into compact, useful phrasing. Every clause earns its place with no unnecessary filler.

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 single-parameter status tool with an output schema and annotations, the description covers the core purpose, the possible states, and a meaningful side effect. The main gap is the lack of explicit routing guidance among the closely related sibling tools, but this is a minor omission given the simple interface.

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 schema already fully describes the id parameter as the Kenari video job id returned by create_video or extend_video, with 100% coverage. The description only echoes {id} in the endpoint, adding no new parameter-level meaning beyond the schema.

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 a specific resource and action: 'GET /v1/videos/{id}' and 'Reports queued/rendering/done/failed/expired.' This clearly conveys what the tool does, but it does not explicitly contrast it with sibling tools like wait_for_video or download_video, so it stops short of full 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?

Usage context is implied rather than explicit. The auto-download note suggests callers may not need a separate download step when the status is done, but the description never tells the agent when to prefer this tool over wait_for_video or download_video, and no exclusions are stated.

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

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

Annotations already indicate a safe read-only operation, and the description adds useful auth context by stating that the call is public and requires no key. It does not discuss pagination or empty-result behavior beyond the schema-level note about video, but with readOnlyHint=true and an output schema present, the behavioral disclosure is adequate.

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 short, front-loaded, and contains no filler. The second sentence earns its place by adding the auth requirement. It loses a point only because the first sentence largely restates the tool title rather than adding substantially new information.

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 read-only listing tool with one optional parameter and an output schema, the description is complete enough. An agent knows what the tool does, that no auth is needed, and that modality filtering is available, while the schema and annotations cover the remaining details.

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 fully documents the single optional parameter, including its enum values, filtering semantics, and the caveat that the video list may be empty. The tool description itself adds no parameter-level meaning, so the baseline score of 3 applies.

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 states a specific verb (List), a concrete resource (Kenari media-capable models), and narrows the scope to image/video. This clearly differentiates it from the sibling generation and editing tools, which perform actions rather than list catalog data.

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 description gives clear context: this is a discovery/catalog tool for available media models, and the 'Public, no key needed' note signals that it can be called without setup. It does not explicitly state when-not-to-use it or name alternatives, but no sibling tool performs the same listing function, so the usage context is reasonably clear.

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

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

Beyond annotations, the description discloses the polling interval (5s), backoff cap (15s), terminal states (done/failed/expired), timeout default (20 min), auto-download side effect, and the important non-error timeout result (still_rendering with isError=false). This is rich behavioral context that annotations alone do not provide.

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?

Two sentences with no filler: the endpoint, polling policy, termination conditions, timeout semantics, and auto-download behavior are packed into a compact, front-loaded description. Every clause adds value.

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 3-parameter tool with a full input schema, an output schema, and annotations, the description covers the essential operational details: what is polled, how often, when it stops, what happens on timeout, and the auto-download side effect. Nothing critical for selecting or invoking the tool is missing.

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 100%, so the schema already documents id, download, and timeout_ms with clear meanings. The description restates the timeout default and poll behavior but does not add significant parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate.

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 a specific action (poll GET /v1/videos/{id}) with a clear resource and termination condition, and distinguishes this tool from get_video_status (single status check) and download_video (explicit download) by stating it polls until done and auto-downloads. The endpoint and behavior make the tool's role unmistakable.

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 description gives clear context: this is a blocking poll-and-wait tool that auto-downloads when finished, and timeout is a non-error retry signal. It does not explicitly name sibling alternatives or state when not to use it, but the polling and auto-download behavior strongly imply the intended use case.

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