Kleo

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

Beyond annotations (readOnlyHint, idempotentHint), the description discloses that account_url is read-only and cannot sign anyone in, and that account_key grants full account takeover if exposed. These security and access implications are not in the annotations.

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 detailed but every sentence earns its place: it lists return values, usage triggers, and critical handling notes in a logical order. The security warning is front-loaded with the key explanation.

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 no output schema, the description fully covers the return fields and their semantics, plus when to call the tool and how to present results. An agent has all necessary context to invoke it correctly.

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 tool has zero parameters, so there is nothing to document. The description instead clarifies the meaning of the return fields (has_paid, account_url, account_key), which is valuable given the absence of an output 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 clearly states the tool's purpose: it provides account credits, order eligibility, a link to the account page, and a transfer key. It distinguishes itself from siblings by focusing on account state rather than video creation or job management.

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?

Explicit guidance is given: call before the first kleo_create_video and when users ask about credits, how to get more, or cross-device usage. It also instructs how to handle sensitive output (show account_key only on request).

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 (readOnlyHint=true) already indicate safety, but the description goes well beyond by disclosing cost ('Nothing is charged and no GPU is rented; it spends a little of Kleo's daily planning quota'), intentional nondeterminism ('Two identical requests get two different treatments on purpose'), and its interrogation behavior ('reads language, length and format off the request first and asks only for what is missing'). No contradiction with annotations.

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 long but justifiably so for a tool with 11 parameters and a complex workflow. It is front-loaded with the core purpose and step position, then flows logically into behavioral notes and handoff instructions. Every sentence adds information; there is no padding or repetition of 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?

Given the tool's complexity (11 params, no output schema), the description fully covers the workflow: what it produces, how it behaves, what the caller must do with the result (tell the user logline and decisions, pass the treatment object to kleo_create_video), and the consequences of not using it. It also explains the author parameter's tradeoffs. Nothing an agent needs to invoke it correctly 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 coverage is 100%, so the baseline is 3. The description adds value by clarifying the resolution strategy for several parameters: it reads language, length, format off the request and asks for missing ones, and for music, subtitles, and format it explicitly says to 'pass their answer, never a guess.' This goes beyond the schema's field descriptions and helps the agent use parameters correctly.

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 ('turns the user's request into the TREATMENT'), names the resource (the film treatment), and clearly distinguishes from siblings by labeling itself 'Step 1 (recommended)' and explaining its relationship to kleo_create_video. It also highlights a unique behavioral trait ('Two identical requests get two different treatments on purpose'), leaving no ambiguity about its role.

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 gives when-to-use guidance ('Step 1', 'call it once per video'), what to do with the output ('pass the returned treatment object ... to kleo_create_video'), and what happens if skipped ('Kleo writes a treatment itself while planning, and the user never sees it first'). It also provides a conditional alternative for the author parameter ('use only if you cannot write JSON yourself').

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 annotations already signal destructiveness and non-read-only behavior, and the description adds meaningful context beyond them: credit refund policy (full vs. proportional) and terminal states that make cancellation impossible. This gives the agent useful expectations about side effects and failure cases without contradicting the annotations.

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 short sentences, each carrying necessary information: what the tool cancels, the financial consequence, and the non-cancellable states. The most important action is front-loaded, and there is no filler or repetition of the schema.

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 cancellation tool with no output schema, the description covers the essential context: eligibility, credit impact, and invalid targets. The only minor gap is that it does not describe what the response looks like after a successful cancellation, but that is not critical given the tool's simplicity.

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 documents the only parameter, job_id, including where it comes from ('returned by kleo_create_video'). The description adds no additional parameter semantics, but with 100% schema coverage, the baseline of 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 opens with a specific verb and resource ('Cancels a video') and narrows the scope to videos 'waiting or rendering,' which clearly distinguishes it from sibling tools like kleo_get_job and kleo_create_video. It also states the intended effect in concrete terms, so an agent can determine what this tool does without opening the schema.

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 conditions for use: only waiting or rendering videos can be cancelled, and finished, failed, or already cancelled videos cannot be. It does not explicitly name an alternative tool, but the when/when-not guidance is concrete enough that an agent knows whether to attempt cancellation.

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 goes far beyond the sparse annotations: it discloses that a render spends a non-refundable credit, takes 25–35 minutes, runs on a rented GPU in the background, returns job_id/eta_min/credits, charges nothing on error, and that animatics have a flat 5-credit cost. This rich behavioral context is genuinely useful for an agent deciding whether and how to invoke the 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?

The description is a single dense wall of text with heavy redundancy: film and animatic definitions and pricing are repeated nearly verbatim, and many parentheticals restate schema content. It is front-loaded with the critical ask-first rule, but it is not concise; several sentences could be trimmed or converted to structured bullets without losing 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 tool with 13 parameters, nested objects, and no output schema, the description is exceptionally complete. It covers return shape, cost, timing, error behavior, user consent prerequisites, storyboard requirements, pricing rules, and the follow-up sibling tool. Nothing essential for correct invocation 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 coverage is 100%, so the schema already documents each parameter thoroughly. The description adds value by linking parameters to workflow decisions—e.g., prompt must be in the user's own words, product choice affects pricing, storyboard must include the direction block, and the render's cost depends on duration and product. This is a meaningful increment over the individual schema descriptions.

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 clearly states the tool starts rendering a video (film or animatic) from a prompt, length, format, and user preferences, naming the exact deliverable and workflow. It distinguishes itself from siblings by explicitly handing off to kleo_get_job for progress checks and referencing kleo_adapt_prompt and kleo_storyboard_guide as upstream 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?

The description gives explicit when-to-call and when-not-to-call guidance: 'Do not call this until the user has said, in their own words, what the video should be about.' It also states that short clear requests are sufficient, that missing subjects should be asked for, and that after calling, the agent should offer kleo_get_job to check progress.

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?

Although annotations include openWorldHint and no destructive hint, the description reveals the critical behavioral truth: this is a no-op placeholder that only records the request and returns a notice. This goes well beyond what the annotations convey and prevents false expectations.

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, with the most important caveat ('Not available yet') front-loaded. Every sentence contributes essential guidance and there is no 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 beta stub with two optional parameters< no output schema, and clear annotations, the description fully covers behavior, expectations, and the correct alternative. An agent has enough context to avoid misleading the user.

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 documents both parameters with 100% coverageikuha, so the description need not repeat them. It indirectly implies the parameters will not produce a thumbnail, but it does not add per-parameter details 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 first sentence immediately states this tool is unavailable and that finished videos already have thumbnails via kleo_get_result. The description also clarifies that calling it only records the request and returns a notice, so an agent understands this is a stub rather than the generation tool its title implies.

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 explicitly warns not to promise extra thumbnails and directs users to kleo_get_result for the existing thumbnail. This gives clear when-to-use and when-not-to-use guidance, plus a named alternative sibling.

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 declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds useful behavioral context beyond annotations: the exact state values, the fact that it reports current activity and ETA, and the special case of listing recent videos when job_id is omitted. It does not detail potential error conditions, but for a read-only query tool this is sufficient.

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 dense but efficient, front-loading the core purpose and output fields. The opening 'Step 4.' is a minor noise element that references a workflow step but does not add actionable information; otherwise every sentence earns its 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?

For a simple tool with one optional parameter and no output schema, the description adequately covers what the agent needs: state values, progress details, the alternative tool for waiting, and the next step (kleo_get_result). It omits edge cases like error handling, but these are not critical for a read-only status check.

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 description for job_id already includes the 'Omit to list recent videos' behavior, so the tool description adds no new semantics beyond what the schema provides. With schema coverage at 100%, the description correctly relies on the schema and does not need to repeat or expand parameter details.

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 clearly states the tool's purpose: checking the progress of a video, enumerating the specific state values and output fields (percent done, eta_min). It distinguishes itself from siblings by name (kleo_wait_for_video and kleo_get_result) and explicitly describes the alternate behavior when no job_id is provided (listing recent videos).

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 is explicitly scoped: 'Use it for a one-off status check; to wait until the video is ready use kleo_wait_for_video instead. When the state is done, call kleo_get_result.' It also clarifies the optional job_id behavior. This leaves no ambiguity about when to select this tool over alternatives.

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 establish readOnlyHint and idempotentHint, so the tool's safety is known. The description adds valuable behavioral context beyond the annotations by detailing the composition of the response (MP4, thumbnail, subtitles, and their contents), which helps the agent anticipate what it receives.

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, tightly structured sentence that front-loads the purpose ('Step 5. Download links') and packs all necessary details without redundancy. Every phrase contributes to clarity, and it avoids unnecessary 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?

For a one-parameter, read-only tool with no output schema, the description is fully sufficient. It explains when to use it (finished video), what it returns (all link types and their contents), and relies on annotations for safety. Nothing needed to invoke it correctly 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% for the single parameter job_id, and the description repeats the same context ('the video number returned by kleo_create_video') without adding new semantics. Per calibration, the baseline 3 applies when the schema fully documents the parameter.

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 clearly states the tool's purpose: retrieving download links for a finished video (film or animatic). It specifies the exact artifacts (MP4, thumbnail, .srt) and explains that burned-in subtitles and music are inside the MP4 when requested. This distinguishes it from sibling tools like kleo_get_job (status) or kleo_wait_for_video (waiting).

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 opens with 'Step 5.' and explicitly says 'for a finished video', making it unambiguous that this tool is used after video creation and completion. It doesn't name alternative tools, but the step context and condition clearly route the agent to this tool at the right time.

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 declare readOnlyHint=true and idempotentHint=true, so there is no safety contradiction. The description adds meaningful behavioral context beyond annotations: pricing models for each product, credit-pack prerequisites, duration limits, and the fact that music/subtitles are opt-in only when the user confirms.

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 one dense sentence, but every clause carries needed product distinctions and behavior. It is front-loaded with the resource name and list intent; only minor restructuring could make the pricing and options list easier to parse.

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 parameterless list tool whose safety profile is carried by annotations, this description is complete: it names the items being listed, their variants, pricing, length limits, and optional add-ons. An agent has enough context to invoke it and interpret its results without additional schema or output 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?

The input schema has zero parameters and 100% description coverage, so there is nothing for the description to clarify about arguments. Per rubric, zero-parameter tools get a baseline 4; the description appropriately focuses on output content instead.

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 'Lists Kleo's one template...' and enumerates the exact resource and its subitems: the film and animatic products, including formats, durations, and pricing. This goes well beyond the title and clearly separates this informational tool from sibling tools like kleo_create_video or kleo_get_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 content makes it obvious this is the discovery/lookup tool for Kleo's template and product options, but it never explicitly states when to call it versus alternatives or names exclusions. Usage is implied by the list semantics rather than stated as 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?

The annotations already declare readOnlyHint and idempotentHint, and the description is consistent with those. It adds substantial context beyond the annotations: the order in which the storyboard must be written, billing limits Kleo enforces, the fact that the same storyboard serves both looks, and the once-per-conversation guidance.

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 long but dense: each clause contributes operational detail such as ordering, billing limits, one worked example, and once-per-conversation usage. The key workflow instruction is front-loaded as 'Step 2 (recommended)', making it easy for an agent to parse the most important guidance first.

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 read-only guide with no output schema, the description thoroughly covers what the returned guide contains, the order in which to write it, the limits Kleo enforces, and the two visual styles. It also anchors the tool in the workflow relative to kleo_create_video, so an agent has everything needed to call it correctly.

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 useful context for the `style` parameter by explaining the two looks and that the same storyboard serves both the film and animatic. It does not add syntax details for `format`, `template`, or `duration_s`, but those are already well documented 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 names a specific verb and resource ('Returns how to write a storyboard Kleo renders') and clearly distinguishes this guide from kleo_create_video by positioning it as Step 2. The enumerated content scope (direction, scene/shot shapes, limits, worked example) removes any ambiguity about its role.

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 explicitly states when to call it ('Step 2 (recommended)', 'Call it once per conversation, before kleo_create_video') and explains the consequence of not using it ('Kleo plans a more generic one from the prompt'). It does not explicitly name an alternative tool to use instead, but the workflow placement is clear and actionable.

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 goes beyond annotations by disclosing the polling nature of the tool, the expected number of calls (15–25 for Shorts), and the interaction pattern (silent repeated calls). It also clarifies when to stop, which is critical behavioral context that annotations do not cover.

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 dense but efficient, front-loading the core purpose and then providing essential usage loop instructions. Every sentence contributes actionable guidance, and the structure flows logically from what to do to how to do it.

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 an agent: it covers when to use, how to call repeatedly, how to handle progress, when to stop, and what to expect (links or progress). It also mentions failure/cancellation handling, making it self-contained for correct usage.

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?

While schema coverage is 100%, the description adds practical advice on the max_wait_s parameter (recommending to leave it empty and providing client-specific defaults). This adds meaning beyond the schema, though job_id is already well-described.

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 clearly states the tool's function: it waits for a video to be ready and returns download links or progress. It distinguishes itself from siblings by explicitly tying it to the creation workflow and positioning it as the polling mechanism for delivering videos.

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 provides explicit usage guidance: it instructs the agent to call this tool repeatedly after kleo_create_video until links are returned, and to avoid stopping or asking the user unless the user requests it or failure/cancellation occurs. This is a clear 'when and how to use' directive.

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