Clipform

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

Annotations only indicate a mutating, non-idempotent operation, so the description carries the behavioral burden. It discloses the default insertion point, the auto re-linking side effect, and the boundary of that behavior (branching still needs explicit logic). This is meaningful context beyond the annotations.

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

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

The description is compact, front-loaded with the core action, and every sentence contributes either behavioral context or usage guidance. It references sibling tools without wasted explanation.

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

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

Given the output schema exists and the input schema has 100% parameter coverage, the description is sufficiently complete. It covers the default behavior, positioning override, re-linking behavior, and the config-schema reference. A brief mention of expected output could push it higher, but the output schema covers that.

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

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

Schema description coverage is 100%, so the structured definitions already explain form_id, after_node_id, node, and context. The description adds some value by clarifying the insertion position and pointing to clipform_create_form for node type/config schemas, but most of this is also embedded in the schema.

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

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

The description opens with a specific verb and resource: 'Add a new node to an existing form,' which clearly distinguishes this from create_form, update_node, and delete_node. It also names the insertion behavior and positions itself in the form-editing 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?

The description gives concrete guidance: for linear flows, a simple insert automatically re-links the chain and does not require clipform_set_logic, while branching requires an explicit logic write. It does not enumerate all alternative tools, but the most relevant sibling (set_logic) is directly 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?

Beyond the annotations (idempotent, destructive, non-read-only), the description adds useful behavioral context: multiple items attach sequentially, works only on media-supporting node types, and media assets are reusable. It does not disclose overwrite behavior or partial-failure semantics, but the core behavioral profile is well covered.

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 dense sentences, each adding a distinct, useful constraint: target and max count, sequential processing, and node-type/reusability limitations. There is no filler or redundant repetition of schema 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?

The definition covers the key operational constraints an agent needs: supported node types, max items, source of the asset, and reuse behavior. With an output schema present and full parameter schema coverage, this is largely complete. A brief mention of overwrite or failure behavior would make it fully comprehensive.

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

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

Schema description coverage is 100%, so the schema already documents each parameter in detail. The description adds helpful context about the items array (sequential attachment, reusability, source of media_asset_id), but it does not need to repeat parameter-level meaning. A baseline 3 with mild value from the description 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 states a specific action ('attach an existing workspace media asset') with a clear target ('one or more nodes'), a max count, and the source tool. It clearly differentiates from related sibling tools like clipform_delete_node_media and clipform_get_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?

It explicitly names the prerequisite source tool (clipform_upload_media_asset) and constrains valid node types ('choice, open, scale, draw, binary, button'). It does not name explicit alternatives or when-not-to-use cases, but the context is clear enough for an agent to select it appropriately.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavior beyond that: returns output URLs for completed renders, one line of status per job, typical render time, automatic attach behavior, and the fact that attach results are reported here once known.

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 efficient and front-loaded, with the purpose stated first and batch guidance following quickly. A few extra clauses about attach behavior add length but each contributes useful operational detail, so the structure remains justified.

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 input schema, output schema, and annotations, the description covers all essential context: which tools produce these jobs, how to check single vs. batch, what the response includes, expected timing, and the automatic attach behavior. Nothing critical is missing.

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

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

The input schema already describes all three parameters clearly (100% coverage). The description adds practical semantics by explaining the batch vs. single-job calling pattern and the one-call batching benefit, earning credit above 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 states a specific verb ('check the status') and a clear resource ('render jobs started by clipform_generate_video, clipform_render_video_template, or clipform_render_composition'). It differentiates this tool from the render-producing siblings by defining the object being acted on.

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 context: call it after render jobs, pass job_id for a single job or job_ids for a batch in one call. It does not explicitly name alternative status-checking tools or exclusion conditions, so it stops just short of full 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?

Beyond the annotations (idempotentHint, readOnlyHint false), the description reveals meaningful behavior: the API verifies storage before flipping status, and this call is required for visibility. It also notes that video uploads are handled automatically, adding real behavioral context not present in annotations or schema.

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

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

Three sentences, all necessary: action, mechanism/timing, and exclusion. The most important instruction is front-loaded, and there is 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?

The description fully explains the tool's role in the upload workflow, including prerequisites, timing, consequences of misuse, and when it is unnecessary. With an output schema available and strong annotations, nothing an agent needs to correctly invoke this tool is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description reinforces that media_asset_id comes from clipform_upload_media_asset but doesn't add new parameter semantics beyond what the schema descriptions already provide.

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 the exact action ('Confirm a signed-PUT still image upload finished') and ties it to a specific resource and prior step (upload_url from clipform_upload_media_asset). It clearly differentiates from the upload tool and clarifies scope (still images only).

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 tells the agent when to call ('right after the PUT succeeds') and what happens if it doesn't ('asset stays invisible in the library'). It also gives a clear exclusion for video uploads, so the agent knows when not to use it.

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

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

Beyond the annotations, the description discloses substantial behavioral details: authenticated clients place the form in the user's workspace, anonymous sessions receive a claim URL, and the tool returns both a viewer URL and form ID. It also documents per-node defaults, config shapes, and AI-PROTECTED restrictions, which gives the agent realistic expectations for the mutation.

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: the core purpose and ownership behavior are front-loaded, followed by node-type details and an example. The final provenance note about @vid-master/config is slightly redundant but does not seriously detract from usability.

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 creation tool with nine parameters, nested node configs, and seven node types, the description is remarkably complete. It covers return values, authentication-dependent behavior, defaults, config schemas, constraints, and provides an example, while the output schema fills in the remaining return-value details.

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

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

Although the input schema already covers all parameters, the description adds significant value by documenting the seven node types, their config keys, default values, and constraints like allowed option counts. The worked example also makes the relationship among title, nodes, and config much clearer than 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 identifies the operation as creating a new Clipform, defines it as an interactive video-style form, and states the key return values (viewer URL and form ID). This differentiates it from siblings like clipform_update_form and clipform_list_forms without ambiguity.

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 using the tool: creating a new form, with ownership/workspace behavior explained for both authenticated and anonymous MCP sessions. It does not explicitly name alternatives like clipform_update_form or clipform_import_form, but the creation context is unmistakable and the example reinforces the intended 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?

Even though annotations already mark the tool as destructive, the description adds valuable behavioral detail: data is moved to trash, can be restored, stops accepting responses immediately, and requires user confirmation. This goes well beyond the annotations and sets accurate expectations for a destructive operation.

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

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

Three short sentences convey the effect, immediate consequence, recoverability, and confirmation requirement without unnecessary detail. It is front-loaded with the most important action.

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

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

For a destructive tool, the description adequately covers what happens, what does not happen, and what guardrail exists. Combined with the annotations and full schema coverage, an agent has enough information to decide and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description adds no significant parameter-specific meaning beyond confirming the destructive nature already explained by the confirm parameter description.

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 a specific action ('Move a form and all its nodes to the trash'), the resource affected, and the scope. It also differentiates from sibling tools like clipform_delete_node by emphasizing it covers an entire form plus its nodes.

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

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

The description implies when to use it: when a form should stop accepting responses and be recoverable later. However, it does not explicitly give alternatives, such as clipform_update_form for disabling a form or clipform_delete_node for removing only one node, so some inference is required.

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 and readOnlyHint=false. The description adds meaningful behavioral details: the logic chain is automatically re-linked, start and final end nodes are protected, and user confirmation is required before execution. This goes beyond the annotation fields.

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 concise sentences cover the action, the side effect, the constraints, and the confirmation requirement. No filler or redundancy; the most important action is 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 destructive single-node deletion tool, the description covers purpose, side effects, restrictions, and confirmation. It does not explain whether attached media is also deleted or what response is returned, but the schema and annotations already carry substantial 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 coverage is 100%, so the baseline is 3. The description adds extra meaning by constraining valid node_id values: the start node and last end screen cannot be targeted. It also reinforces the confirmation requirement that the confirm parameter encodes.

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

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

The description opens with a specific verb and resource: 'Delete a node from a form.' It clearly distinguishes this from sibling tools like clipform_delete_form and clipform_delete_node_media by focusing on deleting a single node while automatically re-linking the logic chain.

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 when-not-to-use constraints: 'Cannot delete the start node or the last end screen.' It also states the confirmation requirement. It does not explicitly name alternative tools, but the constraints and sibling list make the intended use 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 adds substantial behavior beyond the annotations: it specifies exactly what gets destroyed (media record, Mux video asset, storage file) and that user confirmation is required. This complements the destructiveHint and idempotentHint annotations without 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 concise sentences carry the core action, the side-effect cleanup details, and the confirmation requirement. The most important information is front-loaded with no unnecessary filler.

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

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

For a destructive tool with rich annotations and fully documented parameters, the description covers the essential behavioral context: what is deleted, what external resources are affected, and that confirmation is required. No output schema exists, so return-value details are not needed.

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

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

Schema description coverage is 100%, and the schema already documents all four parameters, including detailed guidance for the confirm flag. The description adds no parameter-level detail, so the 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 states a specific verb ('Remove'), a clear resource ('media from a node'), and details what deletion entails: removing the media record and cleaning up external resources such as Mux video assets and storage files. This clearly differentiates it from sibling tools like delete_node or 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 usage context is clear: use this tool when media attached to a node needs to be removed. It does not explicitly name alternatives or exclusion conditions, but the resource-focused description and destructive confirmation guard make the appropriate scenario evident.

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 cover read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable behavioral context by explaining that the output is simplified GeoJSON and detailing how mainlandOnly affects the result with concrete examples (Corsica, Hawaii). It does not contradict the annotations.

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

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

The description is extremely concise: the first sentence communicates the core function and output usage, and the second clarifies a key parameter. No filler words; every sentence earns its place and the most important information is 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?

With an output schema present, the description does not need to detail return values. It covers the tool's purpose, output format, and the key parameter behavior. Minor gap: the description lists 'country, city, or region' but omits 'state' from the schema enum, though the schema itself clarifies this. Overall adequate for an agent to select and call the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning for mainlandOnly by giving examples of excluded islands, which goes beyond the schema's generic 'Keep only the largest landmass' phrasing. It also implies the effect of simplification in the first sentence, supplementing maxPoints.

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 ('Fetch') and resource ('GeoJSON boundary polygon'), and immediately states the output's purpose ('ready to use as the boundary prop in the Map composition'). It clearly distinguishes the tool from rendering, media, and form-management siblings by focusing on geographic boundary retrieval.

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 context for when to use the tool: when a GeoJSON boundary is needed for a Map composition. It does not explicitly name alternatives or exclusions, but the purpose is specific enough that no other sibling tool competes for this function. This is clear context without explicit when-not guidance.

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

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

Annotations only provide generic hint flags (readOnlyHint=false, idempotentHint=false), so the description carries the behavioral burden. It adds concrete details: accepts up to 10 items, runs multiple items in parallel, returns audio URLs and word-level captions, and mandates a single voice across the whole form. It does not cover side effects or rate limits, but nothing here contradicts the annotations.

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

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

Every paragraph earns its place: purpose, use cases, voice selection, tone direction, and batch/return behavior. The most important decision rules (same voice for the whole form, tone matching) are given dedicated emphasis rather than buried.

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 output schema exists, the description need not re-explain return structure, but it still mentions the key output. It covers use cases, voice/tone selection rules, batch limits, and parallel behavior, making it complete for an agent to call and configure correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds real value beyond the schema by explaining voice personality choices (e.g., 'ryan British male, clear') and providing concrete tone examples for quizzes and surveys, plus the rule to reuse the same voice globally.

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

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

The description opens with 'Generate narration audio from text with word-level captions', clearly identifying the verb, resource, and output. It lists concrete use cases like quiz question narration and survey introductions, but does not explicitly contrast it with sibling tools such as 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 when-to-use guidance ('Use this for quiz question narration, survey introductions...') and proactive recommendation to suggest narration for quizzes. It gives strong voice-consistency and tone-matching rules, but it does not mention when to prefer a different tool or state 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?

Beyond the annotations, the description discloses key behaviors: fixed 9:16 720x1280 output with Ken Burns effects, muted video clips by default, duration derivation from audio_url, immediate job ID vs blocking URL, attach-on-complete behavior including form republishing, and expected render latency (15-120 seconds per render). These materially inform invocation decisions.

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 highly structured: purpose, use cases, workflow guidance, sibling-tool decision rules, and node-attachment caveats each occupy purposeful paragraphs. Every section adds operational value rather than restating schema fields.

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 16-parameter tool with nested objects and an output schema, this description covers the important operational context: return modes, rendering time, parallel patterns, sibling selection, and side effects. Combined with 94% schema coverage and an output schema, nothing an agent needs to call it correctly is missing.

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

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

Although schema coverage is already high (94%), the description adds critical semantics not in the schema: the wait=false parallel workflow, node_id auto-attachment replacing manual upload/attach steps, captions only having effect when node_id is set, and audio-driven duration. This goes well beyond repeating parameter names.

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

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

The description opens with a specific verb+resource: 'Generate a video from images, video clips, or both, synced to an audio track.' It names concrete use cases (narrated question backgrounds, topic visualisations) and distinguishes itself from clipform_render_video_template and clipform_render_composition, so an agent can identify the correct tool.

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

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

Gives explicit when-to-use guidance and names alternatives: use a video template for recognisable form beats, use this tool for narrated/audio-synced media montages, and use clipform_render_composition only when neither fits. It also gives a montage disambiguation rule and multi-render workflow advice (wait: false, then poll 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?

Annotations already declare read-only and non-destructive behavior, so the description doesn't need to cover side effects. It adds useful behavioral context by stating the sequential ordering guarantee, the inclusion of routing, and the data provenance from clipform_set_logic, which goes beyond the bare 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?

Two tightly packed sentences with no filler. The action and resource are front-loaded, and the second sentence enumerates the return components efficiently. Every clause adds useful 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 an output schema, annotations, and 100% parameter coverage, the description is complete enough for a read-only retrieval tool. It explains the return scope and ordering, though it stops short of explicitly routing agents away from sibling tools or mentioning edge cases like missing forms or empty node lists.

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

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

Schema description coverage is 100%, and both required parameters are individually explained (including distinguishing form_id from the short share_id). The tool description does not add any parameter-specific meaning beyond what the schema already provides, so the 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 uses a specific verb ('Retrieve') and resource ('a form's details'), and adds precise scope: all nodes in sequential order, their routing, title, settings, options, config, media status, and next node. This clearly distinguishes it from listing tools or workflow-specific tools among the siblings.

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

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

The intended use is implied by the detailed return description, and the mention of 'from clipform_set_logic' hints at the read counterpart of that tool. However, there is no explicit when-to-use/when-not-to-use guidance or named alternative, so an agent must infer the boundary against sibling tools like clipform_list_forms or clipform_get_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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds valuable behavioral context by specifying the return format as markdown, detailing the information payload, and clarifying the exclusion of workflow content. This goes beyond what annotations alone provide.

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

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

The opening sentences are front-loaded with the core purpose and the crucial differentiation from clipform_get_workflow. The alias list is long but justified because alias resolution is essential for correct invocation. Slight redundancy exists in listing types twice, but overall the content is dense and purposeful.

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

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

For a read-only, idempotent knowledge-retrieval tool with no output schema, the description is complete: it explains what the result contains, its format, the accepted inputs, aliases, variants, and the key sibling exclusion. An agent has everything needed to select and correctly call this 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%, but the description significantly enriches parameter understanding: it expands the 'type' parameter with the full list of supported types, an extensive alias map, and further clarifies the optional 'variant' parameter with its valid values and purpose. This is far more informative than 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?

States a precise verb and resource: 'Retrieve craft knowledge for building a specific form type' and enumerates the concrete knowledge categories returned. Explicitly distinguishes itself from clipform_get_workflow, so an agent can differentiate it from the most closely related sibling without ambiguity.

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?

Directly states what the tool does not do and names the correct alternative: 'Does NOT return a step-by-step build workflow - use clipform_get_workflow for that.' It also provides the complete set of accepted types, aliases, and optional variant guidance, making the selection criteria explicit and actionable.

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

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

Annotations already mark the call read-only and idempotent, so the safety profile is covered. The description adds that the response includes processing status, which is the main behavioral nuance beyond a plain fetch; no rate limits or side effects need disclosure for this simple read.

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 sentences with no filler, and the core behavior is in the first sentence. The use-case sentence earns its place by giving the agent a practical trigger for when to call the tool.

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 low-complexity read with a complete schema and an output schema present, the definition gives enough to call it correctly. It could add explicit handling of non-processing states, but the current guidance plus annotations is sufficient for an agent to select and invoke 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?

The schema already describes all three parameters, including the important distinction between form_id and the short share_id, so the description does not need to repeat them. It adds no new parameter-level detail; node_id remains minimally described as 'The node ID,' but the schema has 100% coverage.

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 concrete read operation: retrieving media attached to a node, and extends it with 'including processing status,' so an agent knows both the resource and the extra signal it returns. This clearly differentiates it from mutation siblings like clipform_attach_node_media 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 phrase 'Useful for checking if a video upload has finished processing' gives a concrete invocation scenario. It does not mention when to prefer another tool such as clipform_search_media or clipform_list_assets, so it stops at clear context rather than explicit routing.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses key behaviors: text-only answers, redaction of contact details/uploads/payments/audio/video, default newest-first sorting, and the explicit sort override. These are meaningful operational details not present in the annotations.

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

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

The description is efficient and information-dense. It front-loads the core purpose and key differentiator, then provides examples, caveats, and default behavior in a natural order. Every sentence adds operational 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?

For a read-only listing tool with a rich schema and output schema present, the description covers purpose, filtering semantics, sorting defaults, content limitations, and the path to get redacted data. Given the annotations already convey safety and idempotency, nothing critical is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra semantic value by explaining what 'sort' does in context ('sorted newest first unless sort: oldest'), clarifying that 'query' filters text answers, and tying time filtering to real questions. This is modest but useful enrichment 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 uses a specific verb ('List') and resource ('individual responses (submissions)'), and immediately distinguishes itself from clipform_get_results by noting it 'complements' the aggregate tool. The scope and object are unambiguous, so an agent can easily tell this apart from sibling tools.

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

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

It explicitly names clipform_get_results as the sibling that handles aggregates, gives concrete example questions the tool answers, and notes that non-text content is redacted and viewable via the dashboard URL from clipform_get_form. This effectively communicates when to use this tool and when to look elsewhere.

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

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

The description adds meaningful behavioral detail beyond the readOnlyHint annotation: it clarifies that certain answer types are only counts, that open-text answers are limited to 'recent' ones, and that per-response detail requires the dashboard. This helps set expectations for the data returned. 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 two tight sentences with no filler. The first sentence front-loads the main purpose, and the second adds a precise limitation. Every word 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 read-only aggregation tool, the description covers the core output categories and key limitations. The missing pointer to clipform_get_responses as the tool to use for full per-response detail is a minor gap, but the explicit scoping of the returned data makes the tool usable as-is.

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?

Both parameters are already well documented in the schema: form_id is explicitly distinguished from the short share_id, and context is described as the user's underlying goal. The tool description adds no additional parameter-level meaning, so the baseline of 3 applies.

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

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

The description states a specific verb ('View') and a clear resource: response counts, choice/action answer breakdowns, and recent open-text answers for a form. It is clear and precise, but it does not explicitly differentiate this tool from the closely named sibling clipform_get_responses.

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 conveys what data is available and notes that contact, file, draw, camera, and payment answers are counts only, directing users to the dashboard for per-response detail. However, it does not name a tool alternative such as clipform_get_responses, so when-to-use versus alternatives is only implied rather than explicit.

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

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

The annotations already signal readOnly and idempotent, and the description reinforces this as a retrieval operation. It also discloses what the tool will and will not return, including the negative boundary around craft knowledge and the variant-specific workflow behavior, which goes beyond the annotations and helps set expectations.

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

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

The description is long but every section earns its place: core behavior first, exclusions second, type list, aliases, variants, then type-specific args. The structured layout makes the large amount of necessary information scannable, and there is no filler or redundancy with the schema.

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

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

For a tool with 19 parameters and no output schema, the description is remarkably complete: it states return value shape, supported types, aliases, variants, and per-type optional parameters. The only element not expanded on is the required 'context' parameter, but the schema already documents it clearly, so the description does not need to repeat 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 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema: default values (question_count 8, response_format all, needs_consent true), which optional args apply to which type, and how variants change the meaning of parameters. The alias list also clarifies how non-canonical type values map to supported types.

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

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

The description opens with a specific verb and resource: 'Retrieve a step-by-step build workflow for creating a specific form type.' It then itemizes exactly what the returned recipe contains, and explicitly contrasts itself with clipform_get_guide, so an agent can distinguish it from siblings without ambiguity.

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

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

The description gives explicit when-to-use guidance and names the alternative: 'Does NOT return craft knowledge... use clipform_get_guide for that.' It also provides all accepted aliases, variant conditions, and type-specific optional arguments, so the agent knows exactly which parameters apply for each form type.

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

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

Beyond the annotations, the description discloses important behavioral details: the new Clipform is created as a DRAFT, unsupported question types are skipped rather than guessed, and the result reports exactly what was imported vs skipped and why. This gives the agent a clear model of side effects and limitations.

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?

Every sentence earns its place: the core action, supported sources, public-access requirement, draft/publish workflow, and skip/report behavior. The description is detailed but not bloated, and important constraints are 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 two-parameter tool with an output schema and annotations, this description is complete. It covers what inputs are accepted, what constraints apply, what side effects occur, and what the result includes. The agent has enough context to call the tool correctly and know what to expect.

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

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

The schema already documents both parameters with 100% coverage. The description adds meaningful URL-level constraints: which domains are supported, which URL forms count, and the public-access requirement. It also reinforces the intended meaning of context by framing it as the user's underlying goal in the schema.

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

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

The description opens with a specific verb and object: "Convert a public Google Form, Typeform, or Tally form into a new Clipform." It clearly names the supported sources and distinguishes this importer from general form creation by emphasizing that it takes an existing external 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 gives clear usage context: use it for public forms from supported providers, and explicitly excludes private forms whose questions cannot be read. It also directs the user to the next step via clipform_update_form. It does not explicitly mention starting from scratch with clipform_create_form as an alternative, but the context is otherwise strong.

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, so the safety profile is well covered. The description adds a small amount of context by specifying 'available' and 'for video compositions', but it does not disclose response shape, pagination, authentication needs, or filtering behavior beyond the asset categories.

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 concise sentence that front-loads the action and resource, then immediately lists the relevant categories. There is no filler, repetition, or unnecessary detail.

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

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

For a simple read-only list operation with well-described parameters and strong annotations, the description is essentially complete. The only minor gap is that it does not describe the return format or pagination behavior, but that is not critical for an agent deciding whether to invoke the 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?

Both parameters are fully documented in the schema: 'type' has an enum, default, and description, and 'context' has a clear instruction. The description does not add parameter-level meaning beyond what the schema already provides, so the 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 uses a specific verb ('List') and a specific resource ('available creative assets'), names the asset categories (sound effects, animations, fonts), and scopes them to video compositions. This clearly distinguishes it from sibling list tools such as list_compositions, list_forms, and list_video_templates.

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 no guidance about when to choose this tool over alternatives like search_media, search_music, or list_video_templates. It does not state exclusions, prerequisites, or typical use cases, so the agent must infer usage from the tool name and resource type.

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 non-destructive behavior, so the safety profile is covered. The description adds useful context about what the tool returns: available compositions and their props schemas, and positions it as a discovery step before rendering. 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?

Three sentences, each earning its place: what the tool does, the usage guidance with a specific sibling, and the alternative routing. The key discovery purpose is 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-only list tool with an output schema, annotations, and one well-documented parameter, the description is complete. It provides the necessary contextual relationships to sibling tools without omitting anything an agent needs to select and call it correctly.

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

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

Schema description coverage is 100%, and the single 'context' parameter is fully documented in the schema. The description does not add parameter-level detail, but that is acceptable because the schema already explains exactly what to provide.

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 ('Browse') and resource ('available video compositions') and clarifies it exposes expected props schemas. It differentiates from the sibling render and generation tools by naming them explicitly, so an agent can tell this is the discovery/pre-flight step.

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

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

It gives explicit guidance: call this before clipform_render_composition to discover visual styles and input props. It also provides a clear exclusion: for narrated slideshows from images, use clipform_generate_video instead. This covers both when-to-use and when-not-to-use.

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, so the description's burden is light. It adds genuinely useful behavior: results are cursor-based paginated, and next_cursor appears when more results exist. This tells the agent how to iterate and when to stop.

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

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

Three compact sentences, each with a distinct job: core action, pagination behavior, and search guidance. No redundant filler, and the most important information is 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?

Even with 8 parameters, the schema fully documents each one, and an output schema exists. The description covers the key behavioral aspects not in the schema—cursor-based pagination and the search shortcut—so an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema. It frames the search parameter as the way to resolve a form by name in one call, and explains the cursor/pagination flow. This contextual guidance is not present in the individual parameter 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?

States a specific verb 'List' and resource 'forms in your workspace' with optional filtering. Clearly distinguishes itself from single-form retrieval siblings like clipform_get_form by emphasizing a list operation. The description immediately conveys what the tool does.

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 clear context for when to use the search parameter instead of paginating to find a form by name. This guides the agent's strategy within the tool. It does not explicitly exclude alternatives like clipform_get_form, but the intended use case is well implied.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond annotations by explaining what templates are (bed + overlay + sane defaults) and scoping the result contents ('template names and their exposed controls'). No contradiction exists between the description and annotations.

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

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

Three sentences, each earning its place: the first defines the concept, the second gives usage sequencing, and the third routes to an alternative. The action is front-loaded and there is zero filler.

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

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

For a simple read-only list tool with a fully documented single parameter, a rich output schema, and complete safety annotations, the description closes all remaining gaps: domain vocabulary, expected output contents, and call sequencing. Nothing an agent needs to select and invoke it correctly is missing.

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

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

Schema description coverage is 100%; the single required context parameter is already well-documented ('Describe the user's underlying goal in one sentence - not the tool you're calling'). The description adds no additional parameter-level meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Browse') with a clear resource ('available video templates') and grounds it conceptually ('curated Scene arrangements (bed + overlay + sane defaults)'). It also explicitly differentiates itself from clipform_render_video_template and clipform_render_composition, so an agent can tell the tools apart without opening schemas.

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 sequencing guidance ('Call this before clipform_render_video_template to see template names and their exposed controls') and an explicit alternative ('For a fully custom layer stack, assemble Scene layers directly via clipform_render_composition instead'). This is exactly the when/when-not/alternatives guidance the dimension requires.

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

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

Beyond the annotations, the description reveals the tool is an internal audit side effect, not a user-facing action, and records provenance. It doesn't detail return values or duplicate-call behavior, but the core side effect and context are clearly conveyed.

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 focused sentences with the purpose and the critical usage constraint front-loaded. Every word contributes; no boilerplate.

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 what the tool does, when to call it, and when not to, with all required parameters documented in the schema. It doesn't mention the return value or duplicate behavior, but for an internal audit logging step the operational context is 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 description coverage is 100%, so the schema carries parameter semantics. The description only mentions 'sources, image attributions' which mirrors the schema and adds no new per-parameter 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?

States a specific verb and resource: 'Records a completed generation's content provenance (sources, image attributions)'. It also distinguishes itself from sibling tools by explicitly labeling it an 'internal audit step' and 'Not a user action'.

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

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

Gives explicit timing: 'only call it as the final step of a generation workflow you are running' and an explicit exclusion: 'never in response to a plain create or edit request.' This clearly separates it from user-driven create/edit 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?

The description richly discloses behavior beyond the annotations: wait:true blocks and returns a URL, wait:false returns a job ID, batch renders fire in parallel, inputProps are strictly validated, map-wide shots may round coordinates, and completed renders auto-attach to form nodes. This goes well beyond the destructiveHint/readOnlyHint annotations and gives the agent accurate expectations.

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

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

The description is long but organized into clearly front-loaded paragraphs covering purpose, alternatives, modes, routing, and attachment behavior. It earns most of its length given the tool's complexity, but there is some redundancy, for example the clipform_generate_video guidance appears both early and again in the 'Choosing a render tool' section.

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 9 parameters, nested objects, an output schema, and many siblings, the description is remarkably complete. It covers output formats, single vs batch behavior, result retrieval, alternatives, attachment semantics, and common pitfalls, so an agent has enough context to invoke the tool correctly without additional research.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description reinforces parameter-related usage choices (items, wait, node_id, form_id), but most of that meaning is already present in the input schema descriptions. It adds workflow context but not much genuinely new parameter semantics beyond the structured fields.

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

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

The description opens with a specific verb and resource: 'Render a specialised video composition to MP4 or PNG'. It also distinguishes itself from clipform_generate_video by stating it covers 'custom animated visuals' such as geography animations or designed motion graphics, making the tool's purpose unmistakable relative to siblings.

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

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

The 'Choosing a render tool' section explicitly tells the agent when to prefer clipform_render_video_template, when to use clipform_generate_video, and when to fall back to this tool. It also gives clear batch-vs-single guidance and explains the correct node-attachment workflow, including what not to do (do not poll clipform_check_render or manually chain upload/attach).

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

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

The description goes beyond annotations by disclosing the render lifecycle: 'A render for a form node is not done until it is attached to that node,' and that passing node_id 'attaches itself automatically... and republishes the form if it's currently live.' This adds meaningful context about side effects, non-idempotence, and async behavior beyond the destructiveHint=true annotation. 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 longer than average but stays focused and front-loaded: the first sentence states the core action, followed by prerequisite, sibling-tool selection, and lifecycle warning. Every section earns its place, though the render-tool selection paragraph is dense and could be slightly tighter.

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, nested captions object, output schema, and multiple sibling render tools—the description is complete. It covers prerequisites, alternative tool routing, automatic attachment behavior, republish side effects, and explicitly warns against polling or manual chaining. The output schema covers return values, so no additional return documentation is needed.

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

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

Schema description coverage is 100%, so the schema already documents every parameter well. The description reinforces workflow context—such as controls being 'template-specific' and node_id enabling auto-attachment—but most of that detail is already present in the input schema. It does not add substantial new meaning for individual parameters beyond what the schema provides.

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

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

The description opens with a specific verb and resource: 'Render a curated video template... to MP4 or PNG from a small controls object.' It also clarifies what the tool is not ('instead of hand-assembling Scene layers') and distinguishes it from related render tools. This makes the tool's 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 says when to use this tool versus siblings: use it first for recognisable form/quiz beats, use clipform_generate_video for narrated/audio-synced montages, and use clipform_render_composition only for custom layer stacks. It also gives clear workflow guidance: call clipform_list_video_templates first, pass node_id/form_id for auto-attachment, and do not poll or manually chain upload/attach steps.

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 readOnlyHint and idempotentHint already set, the description adds valuable behavior beyond annotations: batch execution in one call, all results pre-cleared for commercial use, and result descriptions/alt text. This gives the agent useful expectations without needing to infer them.

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

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

Every sentence earns its place: scope, batching behavior, downstream workflows, licensing, result-description guidance, and a compact example. It is front-loaded with the main action and contains no filler.

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

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

The description, together with the rich input schema and output schema, covers what the tool does, how to batch queries, what to do with results, and important constraints (commercial clearance, alt text). Nothing critical for a search tool is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds a concrete example showing the queries array shape, count override, and default portrait orientation. It also clarifies the semantic that multiple query objects run in one call, which the schema does not state.

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

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

The description opens with a specific verb and resource ('Search images or stock video clips') and immediately differentiates from sibling tools by scope (media vs music/news). The downstream references to clipform_generate_video and clipform_upload_media_asset further anchor its role.

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

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

It explicitly explains batching ('Pass one query or many (max 10) - multiple queries run in one call instead of separate tool calls') and the intended downstream paths for results. It does not explicitly name search_music/search_news as exclusions, but the scope statement makes the 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds behavioral context by noting the results are royalty-free download URLs and that they can be passed into video generation/render tools. This goes beyond the annotations without contradicting them.

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

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

The description is well-structured: purpose first, usage context second, integration guidance third, and returned fields last. Every sentence earns its place, and the length is appropriate for the tool's complexity. It is informative without being verbose.

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 tool has an output schema, detailed parameter descriptions, and clear annotations, so the description does not need to repeat those details. It adds the missing integration context by explaining how to pass the returned URL to video tools. For an agent selecting and invoking this tool, the description is complete.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description does not add meaningful parameter-level guidance beyond mentioning that the returned URL can be used as audio, which relates to output rather than a specific parameter. Baseline 3 is appropriate here.

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

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

The description states a specific verb and resource: 'Search for royalty-free music tracks and ambient sounds.' This clearly distinguishes it from sibling tools like clipform_search_media and clipform_search_news by tool type and content category. It also outlines downstream usage, reinforcing what the tool produces.

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 concrete use cases: 'Quiz forms especially benefit from background music' and 'Also consider it for multi-step surveys and longer forms.' It explains why music fits these contexts. It does not explicitly state when not to use it or name alternatives, but the guidance is clear enough for a niche search tool.

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 this as read-only, open-world, and idempotent. The description adds substantial behavioral context beyond that: it returns structured articles from two named providers, covers only post-May-2025 content, excludes timeless topics, and lists the exact response fields. It also warns about being narrower/less current than native web search. 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 efficiently structured: the core purpose is front-loaded in the first sentence, followed by clear coverage limitations and a concise return list. Every sentence adds value without repetition or fluff. Despite covering multiple aspects, it remains compact.

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 three parameters, full schema coverage, rich annotations, and an output schema, the description covers all necessary context: when to use, what it can/cannot find, what providers are used, and the return shape. An agent has everything needed to select and invoke this tool correctly without external references.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level meaning beyond what the schema provides. It does mention the return data structure, which indirectly helps frame the query, but it doesn't elaborate on 'context' or 'count' beyond the schema's own 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 opens with 'Fallback news lookup', specifying the exact verb and resource. It distinguishes itself from sibling search tools like clipform_search_media and clipform_search_music by being news-specific, and explicitly contrasts itself with native web search tools (WebSearch, web fetch). The return fields are listed, making the tool's purpose unmistakable.

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

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

The description states clearly when to use this tool: 'for clients without native web search' and that it is 'Narrower and less current than native web search tools (WebSearch, web fetch) when available.' It also explains coverage boundaries: recent events post-May-2025, not timeless topics. This gives an agent explicit routing criteria.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds meaningful context beyond that: 'A call replaces that node's routing entirely - it does not merge with any prior target.' This clarifies exactly what destructive behavior to expect.

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

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

Front-loads the core purpose, then covers batching, branching exclusion, replacement behavior, and an example. Every sentence earns its place and there is no filler.

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

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

Complete for this tool: it explains purpose, batching, routing constraints, branching exclusion, and replacement semantics. The schema and output schema cover parameter details and return behavior, so nothing critical is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds practical value with the linear-route explanation and a concrete example showing how node_id and target_node_id relate in the nodes array.

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

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

States a specific action and resource: 'Set the next node for one or more nodes, wiring a linear route (A to B to C).' It also explicitly distinguishes itself from branching, so an agent can tell it apart from related node-editing tools.

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

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

Gives concrete usage guidance: batch multiple nodes in one call, and explicitly states branching is not handled here but in the dashboard's Build tab. It also clarifies that the call replaces routing entirely, which tells the agent when this tool is appropriate.

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 carry the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true), lowering the description's burden. The description adds value with the 'only sends fields that are provided' guarantee and the AI-PROTECTED pointer, though it stays silent on republish/offline semantics that live in the is_live parameter. 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?

Two sentences with the verb+resource front-loaded and zero filler. Every sentence earns its place: the partial-update semantic and the AI-PROTECTED pointer are both decision-relevant, though the AI-PROTECTED sentence could arguably be absorbed into the schema note.

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 16-parameter mutation tool, the description is short but the surrounding structured data does the heavy lifting: 100% schema coverage, an output schema, and safety-carrying annotations. The main gap is that the choice between update vs. create/delete vs. update_node is left entirely to inference.

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

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

Schema description coverage is 100%, so the schema documents all 16 parameters, including AI-PROTECTED restrictions, hex patterns, and the is_live republishing expectation. The description's 'title, publish status, settings, or tags' list groups parameters only at a high level and adds no meaning beyond the schema — baseline 3 applies.

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

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

States a specific verb and resource — 'Update a form's title, publish status, settings, or tags' — and enumerates the field categories affected. The partial-update note ('Only sends fields that are provided') helps differentiate it from create/delete siblings, though it does not explicitly name an alternative like clipform_update_node.

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 conveys the partial-update semantic — omitted fields remain unchanged — which tells an agent what to expect when updating a subset of fields, and it flags AI-PROTECTED parameters with a pointer to per-field restrictions. It does not explicitly state when to prefer this over clipform_create_form or clipform_update_node, leaving routing to be inferred.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the description does not need to restate those. It adds useful behavioral guarantees beyond the schema: 'Does not change node positions in the flow' and that config schemas derive from @vid-master/config. This helps an agent predict side effects and schema provenance without contradicting the annotations.

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

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

Four dense but purposeful sentences. The main action is front-loaded, followed by batching advice, prerequisites, a non-obvious behavioral guarantee, and a config-schema pointer. No filler or repetition; every sentence earns its place.

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

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

For a mutation tool with a rich input schema and an output schema present, the description covers the essentials: what is updated, batching, required IDs, what does not change, and where type definitions come from. Combined with the annotations and schema, an agent has enough to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining that multiple updates should be batched, that updates do not affect flow positions, and that type definitions/config schemas come from @vid-master/config. This gives an agent practical guidance for filling the 'updates' parameter correctly without duplicating schema content.

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

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

The description opens with a specific verb and resource: 'Update one or more existing nodes' text, type, config, or options.' This clearly distinguishes the tool from siblings like clipform_add_node or clipform_update_form, which target different resources or actions. It also scopes the operation to existing nodes, leaving no ambiguity about what the tool does.

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 context: it states the operation targets existing nodes, requires node IDs, and names the exact returning tools (clipform_create_form, clipform_add_node, clipform_get_form). It also gives batching guidance ('Pass multiple updates in one call instead of separate tool calls'). It does not explicitly mention when not to use this tool or name alternatives, so it stops short of a 5.

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

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

Beyond the sparse annotations (readOnlyHint=false, idempotentHint=false), the description discloses meaningful operational behavior: public URLs are fetched and stored automatically, video is ingested via Mux while images go to Supabase, and captions from clipform_generate_tts enable per-word highlighting. These backend and sequencing details are exactly the kind of context annotations cannot convey. It stops short of describing failure/atomicity behavior for multi-item uploads, but is 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?

Four tight sentences, each earning its place: the core action plus constraints and workflow position, then URL-fetch behavior, storage backends, and caption implications. The most decision-relevant information (what it does, max, next step) is front-loaded. No filler or repetition of schema content.

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

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

For a workflow-step tool with an output schema and 100% parameter documentation, the description covers the essentials: action, capacity, sequencing, storage path, and downstream attachment step. The only genuine omissions are multi-item failure semantics (partial success) and explicit conflict behavior for existing assets — minor given the schema richness and the feature-flagged annotations.

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

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

Schema description coverage is 100%, so the schema fully documents items, url, captions, media_type, ai_generated, media_source, and context — including the verbatim-copy guidance for words. The description adds a couple of semantic enrichments (max 10, sequential upload, TTS pipeline link), but the schema carries the heavy lifting, which matches the baseline-3 expectation.

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

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

The description opens with a specific verb-resource pair: 'Put one or more media files into your workspace media library,' with hard constraints (max 10, sequential). It is explicitly framed as 'step one of attaching media to a node,' which clearly differentiates it from the sibling clipform_attach_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 gives a concrete workflow directive: follow up with clipform_attach_node_media to place the returned media_asset_id on a node. This names the exact next step and alternative tool. It does not enumerate when-not-to-use cases against other siblings (e.g., clipform_complete_media_upload or clipform_search_media), but the workflow context is strong enough that an agent can route correctly.

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 and idempotentHint, so no side-effect disclosure is needed. The description adds value beyond those annotations by specifying the exact identity-related data returned: auth modes, workspace, and plan limits. It is consistent with the read-only and idempotent hints.

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 action, the resource, and the specific outputs without any filler. Every element 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 read-only identity-introspection tool with one well-described parameter, an output schema, and strong annotations, the description is complete. It tells the agent what will be returned without needing to explain return structure, since the output schema exists.

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

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

Schema description coverage is 100%, and the only parameter, 'context', has a clear description in the schema. The tool description does not add anything about the parameter, but the schema already carries the full semantic weight, so the 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 begins with a specific verb ('Show') and a clear resource ('current identity'), then enumerates exactly what is included: auth mode, active workspace, and plan limits. This is unambiguous and easily distinguishes the tool from the many form/media/render siblings.

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

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

The description clearly implies when to use this tool: whenever the agent needs to know authentication context, the active workspace, or plan limits. It provides clear context, though it does not explicitly name alternatives or exclusion conditions.

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, so the safety profile is covered. The description adds no additional behavioral context such as what 'check' entails, whether it makes a network call, or what side effects (if any) occur beyond the annotations.

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

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

The description is a single, front-loaded sentence with no wasted words. It quickly communicates the action and the conditions for use, making it efficient and easy to parse, though it could be slightly more structured with a separate usage note.

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 clear usage guidance but does not explain what the tool returns or what happens after 'checking' for tools. With no output schema present, the description carries the burden of explaining the result, which it fails to do. For a simple one-parameter tool, this is a notable gap, though not severe.

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 single parameter 'context' is already documented with a clear description in the schema. The tool description adds no additional semantic meaning beyond what the schema provides, which aligns with the baseline of 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?

The description clearly states the tool's function: checking for additional tools when a task could benefit from specialized capabilities. It distinguishes itself from the sibling clipform_* tools by being a meta-tool for tool discovery rather than a domain-specific operation, though it does not explicitly name this distinction.

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

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

The description provides explicit usage guidance: use this tool whenever specialized capabilities might help, even if existing tools could work as a fallback. This gives the agent a clear decision rule, though it does not mention when not to use it or list alternative tools.

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