@callirra/mcp

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

With no annotations, the description carries the full burden. It discloses that only queued or running tasks are cancellable, which is useful. However, it does not mention whether cancellation is reversible, whether it can fail, or what side effects occur beyond the task being cancelled.

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, front-loaded sentence with no filler. Every word contributes to the core meaning: the action, the target, and the valid task states.

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 one-parameter cancellation tool, the description is minimally adequate. However, with no output schema and no annotations, it omits return behavior, error conditions, and idempotency details, leaving some ambiguity for an agent invoking it.

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 description never references the 'id' parameter. The agent must infer that 'id' is the task identifier. Since coverage is low, the description needed to compensate by clarifying the parameter's role, and it does not.

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 ('Cancel') with a clear resource ('video task') and a precise scope ('queued or running'). It is immediately distinguishable from siblings like get_task, create_video, and list_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 phrase 'queued or running' implies the tool is meant for active tasks, but there is no explicit guidance on when not to use it, what to do for completed/failed tasks, or why an agent might prefer get_task first. Usage context is implied rather than 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?

With no annotations, the description carries the full behavioral burden, but it only discloses that the operation is asynchronous. It does not mention side effects such as cost/credit consumption, the need to poll a task endpoint, or what the created task object contains, so an agent cannot anticipate the mutation 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?

The single sentence is free of filler and front-loaded with the core action. However, for a tool with 25 parameters and no annotations, this is under-specification rather than appropriately concise structure.

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, no annotations, and no parameter documentation, yet the description provides only the one-line action statement. An agent has no information about return values, polling, error handling, or parameter constraints, making the tool difficult to invoke 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 0% and the description names none of the 25 parameters. It provides no hints about required inputs (model, prompt), mode, duration, resolution, audio, or any of the many optional fields, leaving the agent to guess semantics from names alone.

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 ('create') and a specific resource ('an asynchronous video generation task'), and the async qualifier distinguishes it from synchronous result-returning tools. This clearly separates it from sibling tools such as generate_image and from task management tools like get_task/cancel_task.

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 about when to choose this tool over alternatives, when not to use it, or how to follow up on the async task. The async wording hints at intended use but does not explain the workflow or exclusions.

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 are not provided, so the description carries the full burden. It only states that the tool generates an image, implying a mutation but not disclosing details like cost implications, processing time, rate limits, or what happens with nsfw_checker or google_search flags. The presence of parameters like nsfw_checker and google_search suggests behavioral nuances that are not explained. It gives minimal behavioral context, but no contradiction exists.

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 sentence, concise and to the point. It is front-loaded with the core action. There is no wasted text, but it is so brief that it sacrifices necessary detail, which is a trade-off. Structurally efficient but not informative.

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 (8 parameters, no output schema, no annotations), the description is severely lacking. It does not mention how to obtain a valid model (sibling list_models), nor does it hint at the output format or error conditions. It leaves the agent to guess about parameter interactions and prerequisites, making it incomplete for reliable invocation.

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%, meaning the description must compensate for 8 undocumented parameters. However, the description does not elaborate on any parameter meanings. For example, it doesn't explain what 'model' should be set to (though 'supported model' hints at list_models), nor the difference between image_input and reference_images, nor the purpose of nsfw_checker or google_search. This is a significant gap given the high parameter count and the need to disambiguate similar options.

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 clear verb ('Generate') and resource ('an image'), and mentions 'with a supported model', which hints at the model parameter. However, it does not distinguish this tool from the sibling create_video, which likely has a similar structure. It is not a tautology, but it lacks specificity about what makes it unique.

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 use this tool versus alternatives. It does not mention that create_video is for video generation, nor conditions like 'use for still images', nor any prerequisites, exclusions, or alternatives. An agent would not know if this is the right tool for a task without additional context.

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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action ('Check') without clarifying whether the operation is read-only, what the response looks like, or any side effects. For a balance-check tool, this is minimal but not misleading.

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 with no extraneous words. The core action and target are front-loaded, making it highly efficient and easy 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 tool with no parameters and no output schema, the description is adequate but lacks detail about the return value (e.g., currency, format, or whether it includes both credits and balance separately). An agent might benefit from knowing what data is returned, but the simple nature of the tool keeps this gap minor.

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, and the schema coverage is 100% (vacuously). The description adds no parameter information because none exist. Per guidelines, the baseline for 0 parameters is 4, and the description does not detract from that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Check') and a specific resource ('credits and available balance'), making the tool's purpose immediately understandable. It distinguishes itself from siblings like get_usage, which likely concerns usage statistics rather than account balance.

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 explicit guidance is given on when to use this tool versus alternatives, but the name and description make the use case obvious (checking balance). There are no exclusions or alternative references, which is acceptable for a simple getter.

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?

No annotations are provided, so the description must disclose behavior itself. It only restates that the tool gets a knowledge base; it does not indicate read-only behavior, output format, pagination, or whether content is static or dynamic. The 'Get' verb weakly implies non-mutation, but nothing beyond that is disclosed.

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 short sentence with no filler or repetition, and it front-loads the action and resource. It loses a point only because the noun phrase is vague ('curated knowledge base') and could have been more informative without adding length.

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 parameters, invocation is trivial, so the description is adequate for calling the tool. However, there is no output schema and no mention of what the returned knowledge base contains or how an agent should consume it, leaving a meaningful completeness 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?

The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline for zero-parameter tools is 4, and the description does not need to compensate for any missing parameter documentation.

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 ('Get') and a specific resource ('curated creative/art/image/video knowledge base'), so it is clear what the tool returns. It does not explicitly contrast with siblings, but the resource is distinct from generation/listing tools like generate_image or list_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?

There is no guidance about when to use this tool versus alternatives such as list_prompt_recipes or get_prompt_recipe. The description implies a read operation for knowledge content but does not say when an agent should prefer it or what problem it solves.

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?

With no annotations provided, the description carries the disclosure burden. It clearly describes the returned contents and even notes the link is pre-filled, which is useful. However, it does not mention side effects, authorization needs, error behavior, or other operational traits beyond the basic read operation implied by 'Get'.

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, front-loaded sentence that states the operation first and then uses a colon-delimited list to pack the return details efficiently. Every phrase earns its place, with no filler or repetition.

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 get-by-identifier tool with one parameter and no output schema, the description covers the main thing an agent needs to know: what the response will contain. It does not explain how slug maps to a recipe or handle error cases, but the low complexity keeps the missing detail relatively minor.

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 should compensate by explaining the slug parameter, but it never mentions slug or how the recipe is identified. The only guidance comes from the property name itself and minLength=1, so the description adds no parameter-specific semantic value.

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 ('Get') and resource ('prompt recipe') and enumerates what 'in full' includes: prompt text, settings, credits, and a pre-filled generator link. It is distinguishable from the sibling list_prompt_recipes by the 'one' vs list contrast, though it does not explicitly name the alternative.

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 the tool is for retrieving one complete recipe, but it never says when to prefer it over list_prompt_recipes or get_scene_recipe, nor does it mention any exclusions or prerequisites. No alternative routing guidance is provided.

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?

There are no annotations, so the description carries the burden. The 'Get' wording and recipe content imply a read-only lookup, and the note about 'what a filtered route refuses' adds useful behavior. However, it does not explicitly state side effects, auth needs, credit consumption, or error behavior for unknown scenes.

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, information-dense sentence that front-loads the tool's purpose, then lists both outputs and scene categories. The live URL is a useful supplementary pointer and does not bloat the description.

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 one-parameter lookup with no output schema, the description covers the key inputs, outputs, and available scene options. It is missing only explicit handling instructions for unknown or omitted scenes, and a clearer statement that this is a read-only retrieval.

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 there are no enums, so the description compensates by enumerating plausible scene values: wedding, swimwear, real-face, night-club, conflict, dance. It does not clarify whether the scene parameter is required or what happens when omitted, which keeps it from a 5.

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-resource pair: 'Get Callirra's worked Seedance 2.5 scene recipes.' It lists concrete scene types and the exact payload contents (prompt, settings, credits, refusals), making it easy to distinguish from sibling tools like get_prompt_recipe.

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?

Clear context is provided: use this tool when you need a paste-ready Seedance 2.5 scene recipe for one of the listed scenes. It does not explicitly exclude alternatives such as get_prompt_recipe or list_prompt_recipes, 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?

With no annotations, the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not state idempotence, auth requirements, polling behavior, or what the status response contains. This is minimal behavioral transparency.

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 short, direct sentence with no filler, and the core action is front-loaded. It is appropriately concise for a simple getter, though it could have used the available space to mention the task ID and response behavior.

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 absence of an output schema and annotations, the description should explain what the status response looks like and how to interpret it, but it only promises 'status'. It also omits guidance for choosing between this and related sibling tools, leaving an agent to make assumptions.

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 exposes a single required 'id' parameter with zero description coverage, and the tool description does not explicitly clarify that 'id' is the video task identifier or where to obtain it. This is inferable from context, but the description adds no real semantic value 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 states a clear verb and resource: it retrieves the status of a video task. It is distinguishable from siblings like create_video, cancel_task, or list_videos because it is specifically about checking status. However, it does not explicitly name or contrast itself with those siblings, so it falls short of a top score.

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 is provided about when to call this tool versus list_videos, cancel_task, or other siblings. The description states only what the tool does, with no context on prerequisites, exclusions, or 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?

With no annotations, the description carries the full burden of behavioral disclosure, but 'Check recent usage records' only weakly implies a read-only operation. It does not mention permissions, rate limits, side effects, or what 'recent' means, leaving important behavior undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence with no filler, which is concise. However, it is under-specified: it omits parameter meaning and usage context, so the brevity comes at the cost of completeness rather than being efficiently informative.

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?

Despite the low complexity of one optional parameter, the description is missing key operational details like what `limit` controls, what counts as a usage record, and how this relates to `get_balance`. With no output schema and no annotations, an agent has too little context to use the tool confidently.

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 description does not mention the only parameter, `limit`. An agent cannot tell whether `limit` controls the number of records, time range, or something else; the description adds no meaning beyond the raw 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 uses a clear verb ('Check') and resource ('recent usage records'), making the tool's purpose obvious. It does not explicitly distinguish itself from siblings like get_balance, but the unique resource and name are enough to avoid confusion.

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 no guidance on when to use this tool versus alternatives such as get_balance or list_videos. There are no use-case conditions, exclusions, or prerequisites, so an agent gets no help choosing between related tools.

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?

With no annotations, the description carries the behavioral burden. 'List' clearly implies a read-only operation, but the description does not disclose what the returned model data looks like (e.g., IDs, names, capabilities) or whether the list is paginated. It is adequate but not rich.

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, front-loaded sentence with no filler. Every word earns its place, and the description is appropriately sized for a zero-parameter list operation.

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, zero-parameter list tool, the description is nearly complete. It names the resource and the action, though it could be slightly more explicit about the shape of the returned model list since no output schema is provided.

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 the baseline is 4. The description does not need to explain parameter semantics because there are none to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and a clear resource ('available image and video models'). It is unambiguous and distinct from sibling tools like list_videos or generate_image, so an agent can tell what it 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 no guidance on when to call this tool versus alternatives, nor any prerequisites or exclusions. There is no mention that it should be used before generation to select a model, leaving usage context to inference.

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?

No annotations are provided, so the description carries the full burden. 'Browse' implies a read-only operation, and the description lists what each row contains, which is useful. However, it does not explicitly state that no data is modified, mention pagination, rate limits, or whether the list is exhaustive or cached. It is not misleading, but leaves some behavioral aspects implied.

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 sentences with no fluff. The purpose and scope are stated up front, the sibling pointer is given, and the live URL is presented as a separate reference. Every sentence contributes 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?

The description gives a good summary of output content (scene, settings, credits) and directs to the sibling for prompt text. However, with no output schema and no parameter descriptions, it leaves gaps: how filtering works, what the response structure looks like, and any pagination or default behavior. It is adequate for a simple listing tool but not fully 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 0%, so the description must compensate for parameter meaning. It does not mention 'limit', 'scene', or 'category' explicitly. While 'scene' appears in the phrase 'model scene', that is describing the output rows, not the filter parameter. The agent is left to infer parameter semantics from names and the schema enum alone.

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 ('Browse'), names the resource ('Callirra's curated prompt recipes'), and provides concrete details (172 across 12 categories) that distinguish it from siblings like get_prompt_recipe. It also explicitly names the sibling for retrieving prompt text, so an agent can tell the tools apart immediately.

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 for when to use this tool: to browse recipe metadata (scene, settings, credits). It explicitly routes the agent to get_prompt_recipe when the prompt text itself is needed. It does not cover all possible alternatives, but the primary alternative is addressed.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'recent video jobs' and does not explain what 'recent' means, whether jobs are returned in a particular order, if completed jobs are included, or what fields the list contains. Minimal behavioral insight is offered.

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 extremely concise and front-loaded, with no filler or redundant wording. It could be slightly more informative without losing conciseness, but as written it is efficient and well-structured.

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 one-parameter list tool with no output schema or annotations, the description is too sparse. It does not clarify what a 'video job' is, how 'recent' is determined, how the limit parameter behaves, or what the return value looks like, so incomplete guidance is provided.

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 description never mentions the 'limit' parameter. The parameter's meaning, default value, and effect on results are left entirely undocumented, so the description adds no semantic value beyond the raw 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 uses a specific verb ('list') and resource ('recent video jobs'), which clearly identifies the operation. It is distinguishable from siblings like create_video or get_task, though it does not explicitly differentiate itself and 'recent' is somewhat vague.

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 is given on when to use this tool versus alternatives such as get_task or list_models. It does not provide context, exclusions, or routing logic, leaving the agent to infer appropriate usage.

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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the upload action and signed URL output, omitting side effects, authentication requirements, rate limits, or data handling details. For a mutation tool, this is a significant 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?

One sentence with no filler. The core action and result are front-loaded, and every word contributes to the tool's purpose.

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 annotations, no output schema, and incomplete parameter documentation, the description is minimal. It does not specify file size limits, accepted formats, or what the signed URL enables. An agent might call it successfully but lacks context on constraints and expected behavior.

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. It mentions base64 encoding for the data parameter but does not explain filename or content_type semantics. The description adds minimal value beyond the schema and fails to clarify the purpose of optional parameters.

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 clear action ('Upload'), a specific resource ('base64-encoded reference image'), and the outcome ('get a signed URL'). It distinguishes itself from sibling tools like generate_image and create_video by focusing on uploading existing media rather than generating new 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?

Implies usage for uploading reference images but does not explicitly contrast with alternatives or provide when/when-not guidance. The mention of 'reference image' hints at a common scenario, but no exclusions or alternative tool references are given.

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