Kreavo

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds only that the underlying job is asynchronous, which hints at polling but never states cadence, terminal states, or failure behavior.

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 and very short, with the purpose stated first. The 'Params: task_id' fragment adds no information and is essentially filler, but the overall text is not bloated.

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?

There is no output schema, so the description carries the burden of explaining what a status check returns, and it says nothing about possible status values or response shape. For an async polling tool this leaves an agent unable to interpret the result.

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% and the sole parameter task_id has no schema description at all. 'Params: task_id' merely restates the property name without saying where the id comes from (presumably the generation call) or its format, so the description does not compensate for the coverage gap.

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 and resource: checks async image generation status. The word 'image' distinguishes it from the sibling kreavo_check_video_status, though that sibling is never named.

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?

No guidance on when to call it, how often to poll, or what to do once a terminal status is reached, and no explicit routing away from kreavo_check_video_status or kreavo_generate_image.

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, idempotentHint, destructiveHint=false, so safety is covered and the description needs only add context. 'Automatically polls external providers' adds useful behavior information, but it is ambiguous — it is unclear whether a single call blocks until completion or returns the current state, which is the single most important behavioral fact here. The mention of polling external providers also sits in mild tension with openWorldHint=false.

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 front-loaded fragments with no padding, and the core purpose leads. The trailing 'Params: task_id' is dead weight that duplicates the schema, costing it a point.

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?

There is no output schema, so the description is the only place an agent can learn what a status check returns — pending/completed/failed states, a video URL, or error semantics — and none of that is present. For a polling tool with a 0%-documented parameter, this is a significant gap.

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% for the single task_id parameter, so the description must carry the meaning and it does not. 'Params: task_id' merely restates the schema; it never says where the task_id comes from (the generate_video response) or what form it takes, and there is no statement of what happens with an invalid or expired id.

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 and resource: 'Check async video generation status', which separates it from the image counterpart (kreavo_check_image_status) and from the generation siblings. It does not explicitly name those siblings, so it falls just short of a 5.

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?

'async video generation status' implies the tool is used after kreavo_generate_video / kreavo_generate_product_video returns a task, but this is left to inference. There is no explicit when-to-use, no statement about whether it must be called once or repeatedly, and no routing to kreavo_check_image_status for image tasks.

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?

Adds real context beyond the annotations by disclosing that the call consumes Kreavo credits and where to check pricing and balance — something the destructiveHint/idempotent flags cannot convey. It does not state whether credits are charged on failure, nor that the result is an async job needing status polling, which are the remaining behavioral unknowns.

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-loads the credit-spend warning ahead of the purpose statement, then compresses params into one clause with no filler. The dense parenthetical citations make it slightly telegraphic but nothing is wasted.

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 six-param generative tool with no output schema, the description covers cost, inputs and the ambiguous enum-like field. The notable omission is that nothing tells the agent this produces a job to be tracked via kreavo_check_video_status, which is required for correct use given sibling tools exist for polling.

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 carry the load; it does list all six params and clarifies that background_source takes 'character|reference', which the schema does not express as an enum. image_url, reference_video_url, resolution and aspect_ratio get no explanation of format or accepted values, so the compensation is partial.

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?

Names a specific verb and resource ('Generate a video with motion from a reference video applied to a character image'), which is clearly distinct from plain kreavo_generate_video or kreavo_generate_product_video. It stops short of naming the sibling it differs from, so the differentiation is inferred rather than stated.

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?

Gives useful preconditions by pointing at kreavo_list_models for cost and kreavo_get_credits for balance, which tells the agent to budget before calling. It never says when to prefer this over kreavo_generate_video or kreavo_generate_product_video, so the main selection decision is left implicit.

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 flag destructive/non-idempotent, but the description is what explains why: the call spends prepaid credits, and it names the two tools that reveal cost and balance before committing. That is genuine context beyond the hints. It does not say whether a failed creation refunds credits or what the created record contains, which keeps it from a 5.

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 tight clauses: cost/credit routing first, then purpose, then parameters. Every sentence carries information an agent needs, and nothing is repeated from the annotation block.

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 no output schema, the description never says what a successful creation returns — a character id, an image, or an async job that must be polled via kreavo_check_image_status. For a credit-spending creation tool that is a meaningful gap, though the cost and parameter coverage is solid.

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 0% — no parameter descriptions and no declared enum — so the description carries the full burden, and it does list all three params with the model being optional plus the allowed values (nano-banana-2|nano-banana-pro|nano-banana). Guidance on what a good physical_description should contain, or name constraints, is missing.

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?

"Create an AI influencer from a physical description (no image needed)" gives a specific verb plus resource and immediately distinguishes it from the image-based siblings (kreavo_generate_image, kreavo_image_edit, kreavo_upload_image). An agent can route here without opening any 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 "no image needed" clause tells the agent when this path is appropriate versus image-driven tools, and the description routes to kreavo_list_models for cost and kreavo_get_credits for balance before spending. It stops short of naming an explicit alternative or exclusion (e.g. versus kreavo_generate_photoshoot).

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 credit-spend disclosure adds real value beyond the annotations, which only declare openWorld, destructive, and non-idempotent. What is missing is the operation lifecycle: nothing says whether this returns a job ID that must be polled via kreavo_check_image_status, or what happens to credits on failure. For a destructive, non-idempotent, paid generation call that gap matters.

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 cost warning is correctly front-loaded, but the standalone sentence "Generate an AI image." is buried after it and largely restates the title. The trailing parameter block is a dense wall of 18 model names that is useful but unstructured.

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?

There is no output schema, so the description must explain what comes back — yet it says nothing about async job handles or polling, even though a dedicated kreavo_check_image_status sibling exists. Combined with unexplained image-URL parameters, an agent cannot reliably complete the full invoke-and-collect cycle from this definition.

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?

With 0% schema description coverage, the description does the heavy lifting by enumerating allowed model values and the default (nano-banana-2), plus aspect_ratio and quality options. But the three image-URL parameters — reference_image_url, secondary_person_url, product_image_url — are listed by name only, leaving their distinct roles ambiguous.

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?

"Generate an AI image" names a specific verb and resource, and the opening clause about spending Kreavo credits immediately signals the cost side of the operation. It does not distinguish itself from close siblings like kreavo_image_edit, kreavo_generate_photoshoot, or kreavo_virtual_tryon, so an agent must infer which generator fits.

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 helpfully routes the agent to kreavo_list_models for pricing and kreavo_get_credits for balance before spending — a genuine pre-flight signal. However, there is no guidance on when to choose this over sibling generation/edit tools, and no stated prerequisites beyond having credits.

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 declare destructiveHint=true, readOnlyHint=false, and non-idempotent, and the description adds genuinely new information beyond them: this call consumes Kreavo credits from the user's account and where to check cost and balance. That is the kind of material consequence annotations cannot express. It stops short of stating whether credits are charged on failure or whether the call returns an image or a job to poll.

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 and front-loads the credit-spend warning, which is the right priority. But the trailing "Params: character_id, scene_prompt, model?, aspect_ratio?, quality?" list duplicates the schema verbatim and earns no space, and the parenthetical cost/balance pointers are telegraphic rather than written out.

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 costly, non-idempotent generation tool with 5 undocumented parameters and no output schema, the description leaves key gaps: it does not say whether the result is returned inline or requires polling via kreavo_check_image_status, nor does it enumerate valid values for model, quality, or aspect_ratio. The sibling list suggests an async job flow that the description never acknowledges.

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% across 5 parameters, so the description must compensate and does not. It merely restates parameter names with question marks for optionality, adding no meaning about what character_id refers to, what scene_prompt should contain, or what values model, aspect_ratio, and quality accept.

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 and resource: "Generate a photoshoot image with an AI character in a scene," which separates it from generic siblings like kreavo_generate_image and kreavo_virtual_tryon by naming the character-in-scene framing. It never explicitly names the sibling it displaces, so the differentiation is implied rather than stated.

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 useful pre-flight context by pointing to kreavo_list_models for cost and kreavo_get_credits for balance, which tells the agent what to check before spending. However, there is no explicit when-to-use vs. when-not guidance relative to kreavo_generate_image, kreavo_virtual_tryon, or kreavo_create_character, so the agent must infer the selection criteria.

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 destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the call spends real Kreavo credits from the user's account and where to check cost and balance beforehand. It omits whether generation is asynchronous and must be polled with kreavo_check_video_status, which would have made this a 5.

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 blocks — cost warning, purpose, parameter spec — with no filler. The cost/balance pointer is front-loaded because it changes whether an agent should call at all, and the dense param shorthand is scannable rather than padded.

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 destructive, credit-consuming, open-world generation tool with seven undocumented parameters and no output schema, the description covers cost and parameter options but omits the lifecycle. It never says the call returns a job or video id, nor that results are retrieved via kreavo_check_video_status, which the presence of that sibling strongly implies and which an agent needs to complete the task.

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 carry the load, and it largely does: it enumerates provider values with a stated default (seedance-fast), the duration range (4-15s), and the resolution and aspect_ratio option sets, none of which appear in the schema. Gaps remain for character_id provenance and what the script field should contain (length, language, tone).

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 gives a specific verb and resource ('Generate a UGC product video with an AI influencer + product image'), which makes the required ingredients unambiguous. It stops short of explicitly distinguishing itself from the sibling kreavo_generate_video, so an agent must still infer that this is the influencer-plus-product variant rather than the generic one.

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 by naming the credit-lookup prerequisites (kreavo_list_models for cost, kreavo_get_credits for balance), which is helpful pre-call guidance. However, there is no statement of when to prefer this tool over kreavo_generate_video, kreavo_generate_photoshoot, or kreavo_virtual_tryon, and no exclusions or prerequisites about where character_id must come from.

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 destructive, non-idempotent and open-world behavior, so the bar is lower, and the description still adds the credit-spend consequence and where to look up cost and balance. It omits whether the call is asynchronous and requires polling via kreavo_check_video_status, which is the main remaining behavioral gap.

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 credit-cost warning is front-loaded and the parameter reference is compressed into one dense but scannable block. The long inline enum list is bulky yet earns its place for a parameter with no schema enum, so there is little wasted wording.

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 7-parameter, credit-consuming, non-idempotent generation tool with no output schema, the description covers inputs well but says nothing about what is returned or the follow-up polling step. An agent still has to infer the async lifecycle from sibling tool names.

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 compensate, and it does for most parameters: it enumerates 16 valid model values with a stated default, gives the duration range (4-15s), and lists resolution and aspect-ratio options. It leaves 'prompt' and 'image_url' entirely unexplained, and a few listed model names look inconsistent with the naming pattern, but overall it adds substantial meaning beyond the bare 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 states a specific verb and resource ('Generate a video from image(s) (I2V)'), which is enough to separate it from image-oriented siblings such as kreavo_generate_image and kreavo_image_edit. It does not, however, draw a line against kreavo_generate_product_video or kreavo_control_motion, which are the nearest video-producing alternatives.

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 useful prerequisite pointers (cost via kreavo_list_models, balance via kreavo_get_credits) so the agent knows to check affordability first. It never says when to choose this over a sibling video tool, nor what to do after submission, so the when-to-use guidance is only implied.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — it does not say what the response contains (balance units, remaining credits, plan limits) even though there is no output schema to carry that information. For a zero-parameter read tool this is a minor but real gap.

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 short sentence with zero filler, and the resource being retrieved is front-loaded. Nothing in it is redundant or hedged.

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 trivial, zero-parameter read tool with rich annotations, the description is adequate to select and invoke it. However, because no output schema exists, it leaves the return value undefined — an agent cannot know whether to expect a numeric balance, a currency unit, or plan metadata.

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 takes zero parameters, so the baseline is 4; there is nothing in the input schema needing explanation. The description correctly implies no arguments are needed by not mentioning any.

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 ('Check') and resource ('your Kreavo credit balance'), so an agent knows exactly what the tool retrieves. It is naturally distinct from the sibling generation tools (generate_image, generate_video, etc.) by name and function, though the description itself does not point that out.

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 only implied: an agent can infer this is the tool for verifying available credits, presumably before or after costly generation calls. There is no explicit statement of when to call it, no mention of rate limits, throttling, or any alternative tool for cost/usage information.

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 destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description adds one trait not present in annotations: the call consumes credits and the pricing/balance siblings to consult first. It says nothing about what is destroyed, whether the original image is overwritten, or whether the operation is asynchronous.

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 cost disclosure is front-loaded and the purpose follows immediately, with no filler sentences. The trailing "Params:" enumeration is redundant with the schema and could be dropped, costing it a point.

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 four-parameter, credit-spending mutation with no output schema and no parameter documentation, the description leaves key questions open: whether the response is an image or a job id needing kreavo_check_image_status, what models and aspect ratios are accepted, and what happens to the source image. The presence of a status-check sibling strongly suggests an async flow that is never mentioned.

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 carry parameter meaning, but it only restates the four property names with a question mark for the optional ones — information the schema already encodes via the required array. No valid model values, aspect_ratio formats, or prompt constraints are explained.

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?

"Edit/inpaint an existing image" gives a specific verb pair and object, and the phrase "existing image" implicitly separates it from kreavo_generate_image and kreavo_virtual_tryon. It never names the sibling it competes with, so the differentiation is inferred rather than explicit.

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 routes the agent to kreavo_list_models for pricing and kreavo_get_credits for balance, which is genuine when-to-use context for the cost check. However, it gives no guidance on when to edit versus generate a fresh image, and no prerequisites such as image ownership or upload requirements.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description adds nothing beyond that: no mention of scope (the calling user's characters only), pagination or result limits, or what an empty result means. It does not contradict the annotations, but it contributes no behavioral context of its own.

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 short sentence with no filler and the key information up front. It is not verbose, though its brevity reflects under-specification rather than disciplined editing, which is captured in the other dimensions.

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 zero-parameter read tool this is close to the minimum viable amount of text, and the annotations carry the safety story. However, there is no output schema, so the description is the only place an agent could learn what a character record contains or that the returned character identifiers feed into kreavo_generate_image / kreavo_generate_photoshoot, and that information is absent.

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 takes zero parameters and the schema is empty, so there is no parameter semantics to explain; baseline 4 applies. The description correctly does not invent parameters that do not exist.

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 supplies a verb ("List") and a resource ("AI influencer characters"), so the basic operation is inferable. But it is essentially a restatement of the title "List AI influencers" with a possessive added, and it does nothing to distinguish this from siblings like kreavo_list_scenes or kreavo_list_models, which are also list operations in the same namespace.

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?

There is no guidance on when to call this versus kreavo_list_scenes, kreavo_list_models, or kreavo_create_character. No prerequisites, no mention of whether characters must exist first, and no indication of whether this is a prerequisite step before generation tools that reference a character.

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, idempotentHint and destructiveHint=false, so the safety profile is fully covered. The description adds one genuine piece of behavioral context — that results include credit cost — but says nothing about the shape of each entry, whether the list is paginated or static, or how models are identified.

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 well-formed sentence that front-loads the verb and resource and appends the most decision-relevant extra detail (credit cost). No filler, no restatement of the title beyond what is needed.

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 zero-parameter, read-only listing tool with full annotation coverage, this is close to sufficient. The only shortfall is that there is no output schema, so the description is the sole source of information about what each returned entry contains, and it gestures at cost without describing identifiers or fields.

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 takes no parameters and the schema is empty, so there is nothing for the description to clarify; baseline 4 applies. The description correctly avoids inventing filtering options that the schema does not support.

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?

"List the image and video models available through Kreavo" is a specific verb plus resource, and it adds the distinguishing detail that each entry carries its cost in credits. It doesn't explicitly name a sibling tool, but the discovery nature of the call is unambiguous against generate_image, image_edit, and the status-check 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?

Usage is only implied: an agent can infer it should call this to see which models and prices exist, presumably before generating. There is no explicit statement such as "call this first to obtain a model identifier for kreavo_generate_image", and no exclusions or alternatives are named.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds genuine scope context by explaining that system templates are shared across all users while custom scenes are the caller's own extracted scenes. It says nothing about result count, ordering, or pagination, which is the remaining behavioral gap.

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 purpose, then scope semantics, then parameters — no filler sentences. The inline "Params: ..." formatting is compact and readable, though it is slightly listing-style rather than 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?

For a zero-required-parameter read tool with no output schema, the definition covers purpose, filter semantics, and allowed values well. What keeps it from being complete is the absence of any note on how the two filters interact or what the listed results contain beyond template names.

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 0% and the schema declares both parameters as bare strings with no enum, so the description carries the full load — and it delivers by enumerating valid values for both (all|system|custom and the seven category values) plus the default of "all" for filter. The only omission is a default or behavior note for category when it is left out.

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?

"List available scene templates" states a specific verb (list) and a specific resource (scene templates), and the follow-up sentences define what a scene template is by contrasting system vs custom. It is clearly distinct from siblings like list_characters and list_models, though it never names them.

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 only implied: an agent can infer this is the discovery step before scene-based generation, and the system/custom distinction hints at which filter to pick for which need. There is no explicit when-to-use or when-not-to-use statement and no alternative tool is named.

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=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds real value by disclosing the return contract (a public URL) even though no output schema exists, which is beyond what annotations provide. It omits size limits, accepted image formats, whether a data-URI prefix is expected, and whether repeated uploads duplicate storage objects.

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 with the action and return value front-loaded; nothing is padded. The trailing "Params: image_base64, filename?" list is low-value restatement of the schema but costs little.

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 two-parameter upload tool the definition covers the core action and the return value, which is important since there is no output schema. It leaves notable gaps around input encoding format, size limits, and the effect of filename, which an agent needs to call it correctly on the first try.

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 carries the full burden for the two parameters, yet it only restates their names ("Params: image_base64, filename?"). It never states that image_base64 must be raw base64 versus a data URI, whether size or format limits apply, or how filename influences the returned URL. It adds essentially no 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 gives a specific verb and resource ("Upload a local image to Kreavo storage") plus the key outcome ("Returns a public URL"), which clearly separates it from all sibling tools that generate, edit, or list assets. It stops short of explicitly naming those siblings or stating the role of this tool as a prerequisite for image-to-image workflows.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as kreavo_generate_image or kreavo_image_edit. An agent must infer on its own that this is the way to feed a local file into the generation pipeline.

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 the annotations, it discloses the most consequential trait: this operation spends Kreavo credits, is gated to paid plans, and requires consent for the person depicted. That is real context an agent needs before invoking a paid mutation. It still omits whether the call is synchronous or returns a job to poll via kreavo_check_image_status, and what a successful response contains.

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?

Information-dense with no wasted sentences, and the parameter block is compact. It does front-load the credit-spend note ahead of what the tool actually does, which slightly buries the purpose, but every clause 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?

With four parameters, no output schema, and no annotation detail beyond hints, the description covers inputs well but leaves the return path ambiguous. An agent cannot tell from this whether it gets an image URL directly or a job id requiring kreavo_check_image_status, which matters for a credit-consuming open-world call.

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% and the schema declares no enums, so the description carries the full burden. It documents all four parameters and supplies the missing enum domains (upper_body|lower_body|dress) plus the aspect_ratio options and the 3:4 default, which the schema does not convey at all. Only URL format or image constraints are left unstated, a minor gap.

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?

"Virtual try-on: see how a garment looks on a person" states a specific action and resource that is clearly distinct from generation siblings like kreavo_generate_photoshoot or kreavo_image_edit. It does not explicitly name those siblings, so differentiation is inferred rather than taught.

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 a hard precondition ("Only use photos of people who agreed to it") and routes to kreavo_list_models for cost and kreavo_get_credits for balance. However, it never says when this should be chosen over siblings such as photoshoot or product video, leaving tool selection to inference.

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