Clipform

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

Annotations are minimal (no readOnlyHint, destructiveHint false) and description does not contradict them. The description adds insertion context but lacks details on side effects, permissions, or error handling. Given the lack of annotation support, the description could offer more behavioral context.

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

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

Two sentences, no fluff, front-loaded with action. Every sentence adds essential detail (insertion logic and config reference). Highly efficient.

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 has 3 parameters, required fields, nested objects, and an output schema (not shown), the description is largely complete. It references clipform_create_form for config details and clipform_get_guide for guidance, which compensates for brevity. However, it lacks explanation of error conditions or prerequisites (e.g., form must exist).

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 all parameters. The description adds context for after_node_id (insertion position) and references clipform_create_form for node config, but does not provide new meaning beyond what the schema already conveys. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Add' and the resource 'node to an existing form', distinguishing it from siblings like clipform_delete_node and clipform_update_node. It also specifies insertion behavior and references clipform_create_form for config details.

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 usage when adding a new node to a form, but does not explicitly state when not to use it or recommend alternatives like clipform_update_node for modifications. The insertion behavior is clarified, but guidance on when to choose this tool over others is minimal.

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 all false, so description carries burden. Describes attachment action, reusability, and critical fit_media guidance for renders. 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?

Four sentences, each concise and valuable. Front-loaded with core purpose, then constraints and usage tips. No unnecessary words.

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?

Covers purpose, constraints, and key behavioral tips. With output schema present, return values need not be detailed. Slight gap on error scenarios but adequate for the tool's complexity.

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%, but description adds value beyond field descriptions by explaining sequential attachment, the special fit_media rule, and source of media_asset_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?

Clearly states 'Attach an existing workspace media asset' to nodes, with specific resource mention (from clipform_upload_media_asset), constraints (max 10), and sibling differentiation (distinct from delete/upload/get).

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?

Specifies compatible node types and the sequential nature of multiple items. Lacks explicit comparison to alternatives but provides sufficient context for correct 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?

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context beyond these: it explains that output URLs are returned for completed renders, that attachment is automatic when node_id was provided, and that no polling is needed. No contradictions.

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 concise (3 sentences) and well-structured: first sentence states purpose, second explains usage patterns, third gives typical time and automatic behavior. Every sentence adds necessary information without fluff.

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 that an output schema exists (not shown but context signals 'true'), the description does not need to detail return values. It covers the key points: batch vs single, automatic attachment, typical time. It is complete enough for the agent, though it could mention that only completed jobs return URLs.

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% (parameters job_id and job_ids have descriptions). The description adds meaning by explaining the batch usage: 'Pass job_ids to check a whole batch in ONE call - one line of status per job' and contrasting with single job_id. This adds 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 clearly states it checks the status of render jobs from three specific tools, and it distinguishes itself from sibling tools by being the only status checker. It uses specific verbs ('check', 'returns') and defines the resource ('render jobs').

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 clear when-to-use guidance: check status of renders from specific tools. It suggests batch checking via job_ids and mentions typical render time. However, it does not explicitly state when not to use or list alternatives, though siblings are distinct.

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

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

Annotations already indicate idempotency and non-destructiveness. The description adds behavioral context: the API verifies the object in storage before flipping the asset from 'processing' to 'ready'. This adds useful detail beyond 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?

Two sentences front-load the core action and provide essential context. Every sentence adds value: first states the action, second adds verification and timing, third excludes unnecessary use cases. No wasted words.

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 single-parameter tool with output schema, the description covers purpose, usage guidelines, behavioral details, and parameter context completely. No critical gaps.

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% with clear parameter description. The description mentions the parameter's origin (from clipform_upload_media_asset) but does not add significant meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly defines the tool's purpose: confirming completion of a signed-PUT upload for still images. It specifies the required prerequisite (call after PUTting bytes to the upload_url from clipform_upload_media_asset) and distinguishes it from video uploads, which are handled automatically.

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?

Provides explicit timing guidance ('call this right after the PUT succeeds') and consequences of not calling it ('asset stays invisible'). Also explicitly states when the tool is not needed (video uploads), effectively guiding the agent to the correct workflow.

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

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

Beyond annotations (which show readOnlyHint=false), the description discloses creation behavior, return values, and authentication-dependent outcomes. 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 well-structured with clear sections for node types and an example. Every sentence adds value, though a bit verbose for the node config details.

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 complexity (8 parameters, nested node configs) and that an output schema exists, the description covers creation behavior, returns, and node specification adequately. Missing details like error cases or rate limits, but overall 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 coverage is 100% (all parameters described), but the description adds significant value: defaults, node type configs, constraints (e.g., option limits), and AI-protected parameter notes. This far exceeds the schema 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 ('Create') and resource ('Clipform'), and clearly states what it returns ('viewer URL and form ID'). This distinguishes it from siblings like clipform_update_form and clipform_delete_form.

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 explains when to use (creating forms) and how authentication affects the result (authenticated vs anonymous sessions). It includes an example but does not explicitly list when not to use or compare with 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 declare destructiveHint=true. The description adds 'This cannot be undone' and details the confirmation requirement, adding value beyond the annotation. No contradiction.

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

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

The description is two concise sentences that front-load the critical information. No wasted words.

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 destructive nature and no output schema, the description covers the essential behavioral aspects. It could mention what happens on success (e.g., returns confirmation), but the schema and annotations are adequate.

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 provides detailed parameter descriptions. The tool description does not add extra parameter meaning beyond what's in the schema, meeting the baseline.

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 'Permanently delete a form and all its nodes' with specific verb and resource. It distinguishes from sibling tools like clipform_delete_node and clipform_update_form.

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 specifies 'Requires user confirmation before it runs' and the confirm parameter description provides guidance on when to set it. While it doesn't explicitly mention alternatives, the context implies usage for deletion only.

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 provides behavioral details beyond the annotations: destructive action (confirmed by destructiveHint: true), automatic re-linking, and the need for user confirmation. This adds useful context not present in the structured 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 three concise sentences with no unnecessary words. The main action is stated first, followed by important behavior details and constraints.

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 lack of an output schema, the description covers the essential outcomes (deletion, re-linking, what cannot be deleted). It provides enough context for an agent to understand the tool's effect and limitations.

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?

All three parameters have descriptions in the schema, but the description adds extra semantic guidance, such as when to set 'confirm' to true and how 'form_id' differs from the share_id. This enhances understanding beyond the schema 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 clearly states the action ('Delete a node from a form') and adds specific details like automatic re-linking and constraints (cannot delete start node or last end screen). This distinguishes it from sibling tools like clipform_delete_form or clipform_delete_node_media.

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 mentions that user confirmation is required and that certain nodes cannot be deleted. It gives context for when to use the tool, but does not explicitly contrast with alternatives. However, the constraints are clear enough for an agent to decide appropriately.

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

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

Annotations already mark destructiveHint=true, and the description adds behavioral details: 'Requires user confirmation' and 'cleans up external resources (Mux video asset, storage file).' This provides transparency about the tool's side effects beyond the annotation.

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

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

The description is two sentences, front-loaded with the core action, and contains zero fluff. Every sentence adds necessary 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?

With 3 well-documented parameters and a destructiveHint annotation, the description covers the essential aspects: action, resource cleanup, and confirmation requirement. No output schema exists, but for a deletion tool this is acceptable. Slightly incomplete regarding what happens after deletion (e.g., no return value), but adequate for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with detailed descriptions for all three parameters. The tool description adds no additional semantic value beyond what the schema provides, so a baseline score 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 explicitly states 'Remove media from a node' with a specific verb and resource. It details cleanup of external resources (Mux video asset, storage file), which distinguishes it from sibling tools like clipform_delete_node (deletes node itself) and clipform_upload_node_media (uploads).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly instructs that user confirmation is required before execution, and the confirm parameter schema elaborates on how to handle confirmation. However, it does not explicitly mention when not to use this tool compared to alternatives like clipform_delete_node, leaving some ambiguity.

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. Description adds useful context about returned GeoJSON being simplified and ready for Map, and explains mainlandOnly behavior with examples, enhancing trust beyond 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?

Two clear sentences plus a separate line for mainlandOnly. Every sentence adds value, no redundancy.

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?

Without output schema, description adequately explains return format (simplified GeoJSON) and use case. For a read-only fetch tool, this is complete and sufficient for correct agent 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 covers 100% parameters with descriptions. Description adds practical examples for mainlandOnly (Corsica, Hawaii), providing extra clarity beyond 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?

Title and description clearly state the verb 'Fetch' and resource 'GeoJSON boundary polygon' for country, city, or region. Distinguishes from sibling CRUD tools by being a pure read operation.

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?

Description provides context (for Map composition 'boundary' prop) but does not explicitly compare to alternatives or state when not to use. Guidance is implied but not structured.

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?

Discloses parallel processing of up to 10 items and output format (audio URL + word captions). Annotations are false, so description carries the burden and does so well.

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 core function, then use cases, then parameter details. Every sentence adds value without redundancy.

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?

Covers input (text, tone, voice), behavior (parallel, max 10), and output. Output schema exists, so return values are documented. Adequate for a TTS generation tool.

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% with descriptions for each parameter. The description adds voice selection guidance and tone examples, providing marginal extra value over 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 'Generate narration audio from text with word-level captions,' clearly identifying the tool's function. It distinguishes itself from siblings like clipform_generate_video by focusing on audio narration.

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?

Specifies use cases ('quiz question narration, survey introductions, form instructions') and suggests proactive use for engagement. Provides context but no explicit exclusion of 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?

Discloses output format (9:16, 720x1280, Ken Burns, public URL), behavior with wait parameter (blocking vs. job ID), and auto-attachment via node_id. Annotations are minimal, so description fully carries the burden and does so well.

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?

Description is well-structured with paragraphs and bullet points, front-loading main functionality. Some repetition (e.g., items type explanation overlaps schema) but overall efficient for the complexity.

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 15 parameters, nested objects, and output schema, the description is thorough. Covers return value, parallel rendering, auto-attachment, and integration with sibling tools. No gaps in understanding the tool's role.

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 93% schema coverage, baseline is 3. The description adds significant context beyond schema: explains Ken Burns for images, cover-cropped for video, duotone effect, texture patterns, captions usage, transition types, style presets, and background audio. Slightly redundant on items but overall adds 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 clearly states the tool generates video from images/clips synced to audio, specifies use cases (narrated question backgrounds, topic visualisations), and distinguishes from siblings like clipform_render_video_template and clipform_render_composition.

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 on when to use this tool vs. video templates or composition render, including disambiguation for montage types. Also advises using wait:false for parallel renders and suggests combining with clipform_generate_tts and clipform_search_media.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by specifying that nodes are returned in sequential order, which is not in 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?

Two sentences, front-loaded with action and scope, every word is informative. No redundancy.

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 retrieval tool with one parameter, output schema present, and rich annotations, the description fully covers what the agent needs to know 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?

Schema coverage is 100% and the parameter description is detailed (UUID format, distinction from share_id). The description does not add extra parameter meaning, but the schema suffices, so baseline 3.

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?

Description clearly states the action ('Retrieve') and the resource ('a form's details'), and differentiates by mentioning all nodes in sequential order, distinguishing it from sibling tools like clipform_list_forms.

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 use when full form details including nodes are needed, but does not explicitly state when to use or not use alternatives. However, the context of siblings makes the usage straightforward.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns markdown, does not return a workflow, and details quiz variant behavior. No contradictions. Additional context like alias processing and variant-only-for-quiz is provided.

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 structured: core purpose, a negative statement to avoid misuse, then a list of types and aliases, and finally variant details. Each sentence provides essential information without redundancy. Efficiently packed with value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 2 parameters and no output schema, the description is fully complete. It explains inputs (including aliases and variant conditions) and outputs (markdown with specific sections). It also references the sibling tool when appropriate, leaving no gaps.

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% with descriptions for both parameters. The description adds significant meaning: lists all types with aliases, explains the optional variant parameter is only for quiz, and describes the effect of different variants. This goes well 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 clearly states it retrieves craft knowledge for building a specific form type, lists what is returned (question psychology, difficulty curves, etc.), and explicitly distinguishes what it does NOT return (step-by-step workflow). This differentiates it clearly from sibling tool clipform_get_workflow.

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 says when to use (get craft knowledge) and when not to use (if need step-by-step workflow, use clipform_get_workflow). Provides a comprehensive list of accepted types and aliases, giving precise guidance on input 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?

Annotations already declare readOnly, idempotent, and not destructive. The description adds value by mentioning 'processing status', indicating the response includes state information beyond the media itself. No contradictions or missing safety details.

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

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

Two sentences deliver complete information with no waste. The first sentence states the action and scope, the second provides a concrete use case. Perfectly front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with an output schema (not shown), the description is sufficient. It highlights the key information (processing status) without overloading. Could mention error cases or file types, but not necessary given schema coverage.

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 for both parameters is 100%, with descriptions in the schema. The tool description does not add any extra parameter context, so it meets the baseline without adding 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 clearly states the action ('Get the media attached to a node') and specifies additional detail ('including processing status'). It effectively distinguishes from sibling tools like clipform_upload_node_media and clipform_delete_node_media by focusing on retrieval and status checking.

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 context for use: 'Useful for checking if a video upload has finished processing.' This guides the agent to appropriate scenarios. While it doesn't list exclusions, the purpose is clear enough to avoid misuse.

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, and the description is fully consistent—it describes a read-only retrieval operation. The description adds valuable context about what is not returned (craft knowledge) and the structure of the output (build recipe components), going beyond annotations to clarify scope.

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 front-loaded with the core purpose and well-structured with clear sections (exclusions, aliases, variant info, parameter groups). While lengthy, every sentence serves a purpose given the tool's complexity. Minor redundancy (e.g., repeating type lists) could be tightened, but overall it's efficient.

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 provides a high-level overview of the output (build recipe components) but lacks details on exact return structure, error handling, or examples. Given no output schema, more specificity (e.g., sample output or expected format) would enhance completeness. Still, the parameter grouping and usage notes cover essential context for 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?

With 100% schema coverage, the baseline is 3. The description adds significant extra value by grouping parameters by form type, indicating defaults (e.g., question_count default 8), and explaining variant-specific behavior. This reduces cognitive load for the agent, justifying a higher score.

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 it retrieves a step-by-step build workflow for a specific form type, listing what it returns (tool sequence, settings, etc.) and what it does not (craft knowledge). It differentiates from sibling clipform_get_guide and provides type aliases, making the purpose unambiguous.

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 explicitly directs users to clipform_get_guide for craft knowledge, providing a clear exclusion. It also lists type aliases and variant-specific parameters, guiding context-appropriate usage. However, it does not explicitly contrast with other siblings like clipform_get_form, leaving some ambiguity about when to use this versus retrieving a form directly.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and no destructiveness. The description adds minimal behavioral context ('List available creative assets') but does not reveal additional traits like response format or sorting. 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?

Single sentence directly stating purpose; no extraneous words. Front-loaded with verb and resource.

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 listing tool with one optional parameter and an output schema, the description is adequate. It specifies the domain (video compositions) and asset types. Minor missing details like pagination are acceptable given output schema availability.

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 baseline is 3. The description lists natural language equivalents ('sound effects, animations, fonts') for the enum values, adding minor readability but no new 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 clearly states the tool lists available creative assets (sound effects, animations, fonts) for video compositions, directly matching the tool name and distinguishing it from sibling tools like clipform_list_compositions and clipform_list_forms.

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 on when to use this tool versus alternatives such as clipform_search_media or clipform_search_music. The description implies usage for listing assets, but lacks when-not or alternative 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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds workflow context (discovery before rendering) and mentions 'expected props schemas' and 'visual styles,' which are behavioral traits beyond annotations. No contradictions.

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

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

Two sentences with no wasted words. Front-loaded with the core action and purpose. Efficient and clear.

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 input parameters, an output schema exists, and annotations cover safety, the description fully covers when and why to use this tool, including its role in the workflow relative to siblings.

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?

No parameters exist, so schema coverage is 100%. Baseline for 0 params is 4. Description does not need to add parameter info.

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: 'Browse available video compositions and their expected props schemas.' It specifies the action (browse) and the resource (compositions and props schemas), and distinguishes from sibling tools clipform_render_composition and clipform_generate_video.

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?

Provides explicit usage guidance: 'Call this before using clipform_render_composition' and 'For narrated slideshows from images, use clipform_generate_video instead.' Clearly states when to use and when not to, with 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 indicate read-only, idempotent, non-destructive. The description adds context beyond annotations: pagination (cursor-based, next_cursor), workspace scope, and optional filtering. It does not contradict 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?

Two concise sentences, front-loaded with main action and filtering, then pagination detail. No unnecessary words.

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 7 optional parameters, pagination, and an output schema, the description covers key aspects: listing forms, optional filtering, cursor-based pagination. Could mention default sort order, but not essential.

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 baseline 3. The description adds value by explaining the cursor parameter (next_cursor included when more results exist). No other parameter elaboration needed as schema is sufficient.

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 'List forms in your workspace with optional filtering' – a specific verb and resource. It distinguishes from sibling tools like clipform_get_form (singular) by emphasizing listing and pagination.

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 implied but not explicit. No mention of when to use this versus alternatives like clipform_get_form or when not to use it. However, the context of sibling tools makes the general use case clear.

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

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

Annotations already declare readOnly and idempotent hints; description adds context about curated Scene arrangements and return of template names and controls.

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 front-loaded sentences with no fluff: purpose, usage link, and alternative each earn their 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?

Tool is simple with zero params and output schema exists; description fully covers what the tool does and returns.

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?

No parameters; baseline 4 applies as schema covers everything and description doesn't need to add parameter info.

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?

Clearly states verb 'browse' and resource 'video templates', distinguishing from siblings clipform_render_video_template and clipform_render_composition.

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 advises calling before clipform_render_video_template and provides alternative (clipform_render_composition) for custom layer stacks.

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 provide basic read/write info (readOnlyHint=false). The description confirms a write operation but adds no extra behavioral details like idempotency, side effects, or prerequisites. Minimal value beyond 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?

Two sentences, front-loaded with the main action, no redundancy. Every word is informative and 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 logging tool with no output schema, the description covers the basic purpose. However, it lacks context about when to call this tool (e.g., after form creation) and any prerequisites, making it moderately 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 coverage is 100%, so baseline is 3. The description mentions 'sources and image attributions' which map to the details object, but doesn't add meaning beyond the schema's field 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 it saves an audit trail for a generated form, specifying the verb 'Save' and resource 'audit trail.' It distinguishes from sibling tools like clipform_create_form or clipform_update_form by focusing on recording attribution and sources.

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 use this tool versus alternatives. For instance, it doesn't specify that it should be called after form generation or that it's not for other logging purposes.

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?

Despite all annotations being false, the description fully discloses behavior: renders produce public URLs, wait parameter blocks or returns job ID, batch mode fires parallel renders with one job ID per item, strict validation of inputProps with specific map behavior (camera.zoom < 9 rounding). No contradictions 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?

Description is long but well-structured: starts with core purpose, then alternative tool guidance, then parameter details, then batch/single mode. Every sentence is informative, though some redundancy exists (e.g., repeating 'for batch mode, set' for multiple parameters). Front-loaded with main use case.

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 complexity (8 parameters, nested objects, batch mode), the description is complete. Covers all usage modes, error handling, node attachment workflow, and relationships with sibling tools (clipform_list_compositions, clipform_generate_video, clipform_render_video_template, clipform_check_render). Output schema exists but is not needed in description.

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%, but the description adds significant value beyond schema: explains batch vs single mode logic, node attachment requirements, strict validation with error behavior, and specific map composition rounding details. Also clarifies that batch mode requires form_id at top level and node_id per item.

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?

Clearly states it renders specialized video compositions to MP4 or PNG, distinguishing from clipform_generate_video and clipform_render_video_template by citing specific use cases (geography animations, designed motion graphics). The description also references sibling tool clipform_list_compositions for available compositions.

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?

Provides explicit when-to-use and when-not-to-use guidance: recommends video templates first for form/quiz beats, clipform_generate_video for narrated montages, and this tool only for custom layer stacks. Also details batch vs single mode, node attachment workflow, and when to use clipform_check_render.

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?

Discloses that rendering happens through Scene composition under the hood, automatic attachment behavior, and advises not to poll or manually chain steps. No contradiction with annotations (readOnlyHint, destructiveHint 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?

Well-structured with clear paragraphs front-loading purpose then guidelines. Slightly verbose but each sentence adds value; minor redundancy with sibling tool guidance.

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?

Complete coverage: prerequisites, workflow, alternative tools, automatic attachment, and output schema existence reduces need for return value description. Fits the tool's complexity.

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% with descriptions for all parameters. Description adds value by explaining the purpose of controls, captions, wait, and node_id attachment benefits, but schema already covers basics, so not 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?

Description clearly states verb 'render' and resource 'curated video template', specifies output formats (MP4/PNG), and distinguishes from siblings by contrasting with clipform_generate_video and clipform_render_composition.

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 directs to call clipform_list_video_templates first, provides a decision tree for choosing between video template, generate_video, and render_composition, and instructs on attaching renders automatically via node_id.

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, idempotentHint, destructiveHint) already indicate safe read. Description adds 'All results are pre-cleared for commercial use' and mentions results include description/alt text, providing beyond-annotation context.

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

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

Two paragraphs, front-loaded with key info, example demonstrates usage. No wasted words.

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 low parameter count, full schema coverage, and annotations, the description covers purpose, usage, and output contents (alt text, commercial use) adequately. Points to related tools for complete workflow.

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%, baseline 3. Description adds value with an example query and explains orientation default (portrait) and why it fits 9:16 frame, enhancing understanding.

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 'Search images or stock video clips' with a specific verb and resource. It distinguishes from sibling tools like clipform_search_music and clipform_search_news by specifying the media types.

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 to pass one or many queries (max 10) for efficiency, and points to downstream tools (clipform_generate_video, upload). Lacks explicit 'when not to use' but provides clear 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?

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to repeat safety. It adds value by specifying what the tool returns: 'download URLs, duration, artist, and license info.' This is helpful contextual information beyond the annotations. No contradictions 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 four sentences, each adding distinct value: purpose, use case, integration with other tools, and return values. No redundancy or fluff. Extremely 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?

Despite having 6 parameters (1 required) and an output schema, the description covers: what the tool does, when to use it, how to use results, and what it returns. It is complete for a search tool without needing to enumerate errors or limitations. The presence of an output schema reduces the burden, but the description still adds value.

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 baseline is 3. The description provides an example query ('upbeat quiz background') which adds context, but it does not elaborate on individual parameters beyond what is already in the schema. The description focuses more on usage and output, not on parameter details. Thus, adequate but not exceeding baseline.

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 purpose: 'Search for royalty-free music tracks and ambient sounds.' It provides a specific verb ('search') and resource ('music tracks and ambient sounds'). The additional context about usage in quiz forms and surveys adds value without obscuring the core purpose. It distinguishes from sibling 'clipform_search_media' by focusing on music/audio specifically.

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 usage scenarios: 'Quiz forms especially benefit from background music... Also consider it for multi-step surveys and longer forms.' It also explains how to use the results with other tools (clipform_generate_video, clipform_render_video_template). However, it does not provide explicit when-not-to-use guidance or mention alternatives like clipform_search_media or clipform_generate_tts.

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, and destructiveHint=false, indicating safe read operations. The description adds value by disclosing the data sources (NewsAPI, The Guardian), coverage post-May-2025, and exclusion of timeless topics. It does not contradict annotations. Minor omission: no mention of rate limits or pagination, but overall transparent.

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 concise at four sentences, with each sentence serving a clear purpose: purpose, coverage/limitations, comparison to alternatives, and return fields. No redundant information, and well-structured for quick comprehension.

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 moderate complexity, presence of an output schema, and comprehensive annotations, the description is complete. It explains what the tool does, its limitations, and return fields, leaving no critical gaps for an AI agent 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?

Input schema coverage is 100%, with both parameters (query, count) described adequately in the schema. The description does not add significant new meaning beyond the schema, so a baseline score of 3 is appropriate. The example queries in the description provide minor additional context.

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 as a fallback news lookup, specifying it returns structured current-news articles from NewsAPI and The Guardian. It explicitly distinguishes itself from native web search tools, making it distinct from siblings like clipform_search_media.

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 explicitly states when to use this tool: as a fallback for clients without native web search, and when not to use it: when native web search tools (WebSearch, web fetch) are available. It also provides coverage limitations, making usage context clear.

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

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

The description discloses that only linear routing is supported and that conditional branching is a planned feature, adding context beyond annotations. Annotations indicate idempotentHint: true, which is not contradicted.

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 concise with no redundant sentences. It front-loads the core purpose and follows with necessary details and an example, earning its place efficiently.

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 output schema and moderate complexity, the description covers the essential behavioral aspects (routing types, default rules, future feature) adequately. A slight gap is the lack of explanation about rule ordering or conflicts, but overall sufficient.

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 baseline is 3. The description adds meaning by explaining default rules, rule structure, and providing an example, which helps the agent understand parameter usage beyond schema definitions.

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 sets routing logic on nodes, distinguishes it from sibling tools like clipform_update_node, and provides a specific verb-resource pairing.

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 advises using one call for multiple nodes instead of separate calls, and explicitly warns against using conditional branching as it is not yet supported. It lacks explicit alternatives or when-not-to-use, but context is clear.

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

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

Description explains partial update behavior (only sends provided fields) and highlights AI-PROTECTED restrictions, adding value beyond annotations which already indicate idempotentHint: true. No contradiction.

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

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

Two clear, front-loaded sentences that state purpose and key behavior without waste.

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 should indicate what the tool returns (e.g., updated form object) but omits this. Parameter details are covered, but overall completeness is adequate but lacks return value information.

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 parameters are well-documented in schema. Description adds context about partial updates and AI-PROTECTED restrictions, enhancing understanding beyond 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?

Clearly states verb 'Update' and resource 'form', and lists specific aspects (title, publish status, settings, tags). Distinguishes from sibling tools like clipform_create_form and clipform_delete_form.

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?

Provides guidance on partial updates and AI-PROTECTED parameters, but does not explicitly state when to use this tool versus alternatives (e.g., when to update vs. create or get). Usage context is implied, not direct.

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

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

Beyond annotations (idempotentHint=true, destructiveHint=false), the description adds key behavioral traits: 'Does not change node positions in the flow' and details config merging behavior (e.g., 'When type is changed in the same call, config replaces the stored configuration instead of merging'). This fully informs agent 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 description is four sentences with no waste. It front-loads the purpose, then adds batching benefit, prerequisites, side-effect clarification, and source of definitions. 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?

Given complexity (batch update, config merging), the description covers key aspects: what can be updated, batching, node ID sources, and config source. It mentions what is not changed (positions). Output schema exists so return values aren't needed. Could mention max batch size (in schema) but overall adequate.

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% with detailed descriptions for each property. The description adds little beyond the schema, such as noting that config schemas come from '@vid-master/config'. Baseline 3 is appropriate as the schema already provides solid semantics.

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 'Update one or more existing nodes' text, type, config, or options', specifying the verb and resource. It distinguishes from siblings like clipform_add_node (adds) and clipform_delete_node (deletes) by focusing on updating existing nodes and explicitly mentioning batching.

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 advises 'Pass multiple updates in one call instead of separate tool calls', indicating when to use batching. It requires node IDs and lists where they come from. It does not explicitly state when not to use, but the context of siblings and the batching hint provide implicit 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?

Discloses sequential upload, media type processing (Mux/Supabase), and caption requirements for highlighting. Adds behavioral context beyond annotations which only indicate non-readonly, non-destructive.

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. First sentence delivers core purpose and constraints, second gives workflow, third adds processing details. Efficient and front-loaded.

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?

Covers all essential aspects: purpose, workflow, behavioral details, parameter hints. Output schema exists, so return values need no explanation. Complete for an upload tool.

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 has 100% coverage, baseline 3. Description adds useful context for 'captions' (pass full objects with words) and 'ai_generated' (drives disclosure chip), enhancing schema meaning.

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 'Put' and resource 'media files into your workspace media library', with constraints (max 10, sequential). It distinguishes from siblings by framing as step one and naming clipform_attach_node_media as follow-up.

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 describes the two-step workflow and next tool to use. Does not list when-not-to-use cases, but the context signals and sibling list provide 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 declare readOnly/read-only. Description adds return values (transcript, title, channel, duration) and failure cases. No contradictions.

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

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

Two short paragraphs, front-loaded with main purpose. Every sentence adds value—no fluff.

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 no output schema, description fully explains what is returned. Covers limitations, supported URL formats, and defaults. Complete for this simple extraction tool.

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 covers 100% of parameters with descriptions. Description does not add extra meaning or usage details beyond what schema provides, so baseline 3 is appropriate.

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

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

Description clearly states action: 'Extract the transcript, title, and channel info'. Specific verb+resource, and distinct from all sibling tools (none are transcript-related).

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 states when NOT to use: private/age-restricted videos, disabled captions, non-YouTube URLs. Provides clear context, but does not name alternative tools (though no relevant siblings exist).

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