Clipform

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

The description discloses important side effects, such as automatic re-linking of the linear chain and the need for explicit logic writes in branching cases. It does not describe all potential failure modes, but the key state-changing behavior is transparent.

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

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

The description is concise and well-structured, covering purpose, placement, logic implications, and config guidance in four focused sentences. No redundant or vague wording is present.

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 rich input schema and high parameter coverage, the description adds the necessary context about insertion behavior, linear versus branching logic, and where to find type-specific config guidance. It is complete for an agent to use correctly.

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

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

The schema provides detailed descriptions for all parameters, including form_id being the UUID not share_id, and options constraints. The description adds cross-references to clipform_create_form and clipform_get_guide for config schemas, supplementing the schema well.

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

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

The description clearly states the tool's purpose: adding a new node to an existing form. It distinguishes this from create_form, update_node, and delete_node, and provides specific insertion details like 'before the end screen'.

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

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

The description explains when to use this tool versus alternatives, explicitly noting that simple linear inserts do not require clipform_set_logic while branching still does. It also clarifies placement behavior with after_node_id.

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

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

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?

Annotations are minimal (readOnlyHint false, destructiveHint false), so the description carries the burden. It adds genuinely useful behavior: the workspace-vs-claim-URL delivery difference between authenticated and anonymous sessions, and the note about AI-PROTECTED parameters. These go beyond what annotations declare. The return of a viewer URL and form ID is also additive, though an output schema exists.

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

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

The description is long, but the complexity justifies it — eight node types each with config shapes and defaults cannot be compressed much further. It front-loads the core purpose and returns, uses structured bullets per node type, and closes with a concrete example. Every section earns its place; the verbosity is necessity, not padding.

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 complex tool with 9 parameters and 8 node types, the description is thorough: purpose, returns, auth-dependent behavior, full config documentation, an example, and a pointer to clipform_get_guide for craft guidance. The output schema covers return values, so not restating them is acceptable. No significant gaps remain for a capable agent to invoke it correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds substantial meaning beyond the schema: it documents every node type's config keys, shapes, and defaults (choice, open, details, payment, button, redirect, file_download, end_screen), and explains the score/is_correct mapping for options — detail the schema defers to this description. This meaningfully raises agent competence in crafting correct node configs.

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: 'Create a new Clipform (interactive video-style form)' and what it returns (viewer URL and form ID). The word 'new' distinguishes it from sibling mutation tools like clipform_update_form, clipform_import_form, and clipform_add_node without needing to open their 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?

Gives clear context: explains authenticated vs anonymous session behavior and instructs the agent to offer to build a first form with suggested starting points when the user is vague. However, it never names alternatives (e.g., clipform_update_form for modifying, clipform_import_form for importing), so exclusion guidance is absent. Clear context but no explicit 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?

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description adds valuable behavioral context: it explains parallel execution for multiple items, returns audio_url and caption_ref per item, and instructs passing caption_ref downstream. It does not mention side effects like cost or rate limits, but this is not required and the existing detail is sufficient.

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

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

The description is well-organized into distinct paragraphs (overview, voice guidance, tone guidance, batch handling) and each section adds unique information. It is slightly verbose with repeated emphasis on voice selection, but remains structured and focused.

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 only two parameters and no visible output schema, the description provides comprehensive context: it explains what the tool returns, how to chain the caption_ref downstream, and the batching behavior. Nothing needed to successfully invoke the 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?

The schema already provides rich descriptions for each parameter (e.g., voice details, tone suggestions). The description augments this with practical rules (reuse the same voice across the form, infer tone from context) that go beyond the schema's static descriptions, making parameter usage fully clear.

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

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

The description clearly states the tool generates narration audio with word-level captions and gives explicit use cases (quiz narration, survey introductions, form instructions). It also distinguishes itself from sibling tools by mentioning caption_ref downstream, making its 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 provides strong when-to-use guidance (e.g., 'use this for...') and even contrasts with hand-copying captions. However, it does not explicitly compare with alternative sibling tools (like clipform_generate_video) or state when not to use it, so it falls slightly short of fully explicit usage instructions.

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 flag a destructive, non-idempotent, open-world write, and the description adds substantial context on top: fixed 9:16 720x1280 output, Ken Burns motion, public URL return, 15-120s per sequential render, and that passing node_id/form_id auto-attaches and republishes a live form. This is real behavioral disclosure beyond the annotation flags.

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 purpose is front-loaded and every section carries signal, but the parallel-render advice is restated in both the main body and elsewhere, making it somewhat denser than necessary. Structure is otherwise clean and scannable.

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 17-parameter, nested-schema, output-schema-bearing tool, the description covers the workflow (generate, check, attach), the alternatives, and the cost characteristics. Nothing an agent needs to call this correctly appears to be 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 goes further by explaining orchestration semantics for wait (fire all renders, then poll clipform_check_render), the auto-attach behavior of node_id/form_id, and the media-type distinction for items. It reinforces rather than merely repeats 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?

States a specific verb and resource ('Generate a video from images, video clips, or both, synced to an audio track') and explicitly distinguishes itself from the two sibling render tools. An agent can identify exactly what this produces without opening the schema.

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

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

Contains a dedicated 'Choosing a render tool' block that gives when-to-use for this tool versus clipform_render_video_template and clipform_render_composition, plus a montage disambiguation rule (narrated/audio-synced here vs silent slideshow template). It also prescribes wait:false for multi-question builds and warns against polling to completion.

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 readOnlyHint annotation, the description discloses additional behavioral traits: redaction of contact details, file uploads, audio/video answers, and payment details staying in the dashboard. This is valuable non‑obvious behavior not captured in the 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?

The description is slightly long and contains a somewhat convoluted clause about redaction that repeats 'payment details'. However, it is front‑loaded with the core purpose and examples, and remains readable and focused.

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, no return‑value explanation is needed. The description covers purpose, usage, behavior, and relationship to siblings, making it fully self‑contained for an agent to decide when and how to call 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?

Schema descriptions cover all 7 parameters (100% coverage), so baseline is 3. The description adds marginal value by clarifying that responses contain text answers and a non‑PII payment summary, which indirectly reinforces parameter usage (e.g., query searches text answers).

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

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

Clearly states it lists individual form responses with time filtering, and explicitly distinguishes from clipform_get_results (aggregates). Examples of questions it answers further clarify its purpose.

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 names the complementary sibling tool (clipform_get_results) and explains the difference (individual responses vs. aggregates). Provides concrete example use cases, making it obvious when to choose this 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?

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds useful context beyond that: the call is a discovery/listing operation whose payoff is the props schema, and it is a prerequisite step to rendering. It stops short of stating pagination or result size, keeping it at a 4.

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

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

Front-loaded with the core purpose, then prerequisite ordering, then exclusions – a sensible information hierarchy. The final sentence is dense (three sibling tool names in one clause) but each name earns its place as a routing target.

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?

An output schema exists, so return values need not be explained; the description instead covers the remaining agent needs – when to call it, what it enables downstream, and which tools to prefer for montage use cases. Nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100% and the single 'context' parameter is fully documented in the schema, so the baseline is 3. The description adds no extra guidance on how to phrase the context string, which is the only parameter.

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

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

States a specific verb and resource ('Browse available video compositions') and goes further by naming the expected output ('their expected props schemas'). It explicitly distinguishes itself from clipform_render_composition and the video-template siblings, so an agent can place it without opening a schema.

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

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

Gives explicit ordering guidance ('Call this before using clipform_render_composition') and a concrete when-not/alternative branch ('For an image or photo montage, reach for clipform_list_video_templates + clipform_render_video_template or clipform_generate_video'). Both the correct path and the wrong path are named.

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

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

Annotations already declare readOnlyHint, idempotentHint, 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?

Adds substantial behaviour beyond the annotations: batch renders fire in parallel and return one job ID per item, wait=true blocks and returns a URL while wait=false returns a job ID, returns a public URL, and auto-attachment via node_id means the render should not be polled. It does not explain why destructiveHint=true is set (e.g. whether an auto-attach overwrites existing node media) or disclose rate/limit behaviour, so one meaningful gap remains.

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

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

Front-loaded with purpose, then output formats, then batch mechanics, then routing guidance — a logical order. It is fairly long, but nearly every sentence carries operational content (token budget, parallelism, attachment semantics) rather than filler, so the length is close to 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?

For a 10-parameter tool with nested batch objects and an output schema, the description covers the essentials: what it produces, the two execution modes, how results are retrieved, how renders attach to form nodes, and how it differentiates from the other two render paths. Nothing an agent needs in order 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?

Schema coverage is already 100%, but the description adds real meaning: inputProps are validated strictly with unknown/missing props failing rather than silently defaulting, wide map shots (camera.zoom < 9) may round lat/lng while pin drops keep full precision, and it clarifies the top-level vs per-item split for batch mode. This goes beyond restating 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?

States a specific verb and resource (render a specialised video composition to MP4/PNG) and immediately bounds the scope: 'custom animated visuals that clipform_generate_video can't provide, such as geography animations or designed motion graphics.' It explicitly names the sibling tools it supersedes, so an agent can distinguish it without opening any schema.

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

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

The 'Choosing a render tool' paragraph gives explicit routing rules: video templates first for recognisable form/quiz beats, clipform_generate_video for narrated/audio-synced montages, and this tool only when neither fits. It also states when to use batch vs single mode and the anti-pattern to avoid (polling to completion or manually chaining 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?

Discloses key runtime behavior beyond annotations: rendering happens through Scene composition, results are not finalized until attached to a node, passing node_id auto-attaches and republishes live forms, and the caller should fire-and-forget rather than poll. This matches the destructiveHint/idempotentHint annotations and adds useful operational detail.

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: core purpose, tool-selection guidance, and attachment workflow each occupy their own paragraph. A few phrases like 'under the hood' add slight redundancy, but every section serves a clear informational purpose.

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

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

Given the tool's complexity and large sibling set, the description supplies prerequisites, alternative tool guidance, async behavior, attachment/republish side effects, and pointers to related tools (list_video_templates, check_render). It does not deeply explain error states or output schema details, but those are partially covered by the schema and sibling 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?

The input schema already covers all 9 parameters with 100% description coverage, so the narrative parameter guidance is a bonus rather than a necessity. The description reinforces the source of 'controls' and the relationship between node_id/form_id, but does not substantially exceed the schema's per-parameter explanations.

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

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

Clearly states the action (render), the resource (curated video template), the output formats (MP4/PNG), and distinguishes it from hand-assembling Scene layers and other sibling render tools. 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?

Explicitly instructs the caller to call clipform_list_video_templates first, provides a decision tree for choosing this tool versus clipform_generate_video or clipform_render_composition, and warns against polling or manually chaining upload/attach steps when node_id is provided.

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

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

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 indicate destructive and idempotent behavior. The description adds precise details about config merge semantics, null deletion, wholesale replacement of nested objects, and full config replacement on type change, which clarifies the destructive nature.

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 tight and information-dense without filler. Each sentence carries essential guidance, and parameter descriptions are detailed but relevant.

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 complex update tool, the description covers batching, ID provenance, config behavior, option constraints, and cross-references to authoritative sources. An output schema exists, so return-value documentation is not required.

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 parameter descriptions add substantial guidance beyond the schema: merge behavior, option scoring semantics, correct-answer marking, and references to create_form/get_guide for type-specific config. This is far beyond a baseline schema restatement.

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

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

Clearly states the tool updates existing nodes and lists the mutable aspects (text, type, config, options). It is distinct from sibling tools like clipform_add_node or clipform_delete_node, and references how to obtain node IDs.

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

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

Explicitly says to pass multiple updates in one call instead of separate calls and notes that node IDs come from specific prior tools. It could mention alternatives like add/delete more directly, but the intent is clear.

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

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

Annotations already indicate non-readonly, non-idempotent, non-destructive behavior. The description goes further by detailing how media is fetched and stored (video via Mux, image via Supabase), and how captions are attached (via caption_ref or provided captions). No hidden side effects or contradictions with annotations.

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

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

The description is well-structured and front-loaded: the first sentence states the core action and constraint. It efficiently packs usage notes and workflow context without redundancy, keeping every sentence meaningful.

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 (multiple media items, captions, integration with TTS), the description covers all necessary aspects: the workflow with sibling tools, handling of URLs, caption attachment options, and AI-generated/media-source settings. With an output schema present, no additional return-value explanation 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 descriptions cover 100% of parameters and their nested fields. The tool description adds extra semantic meaning, such as the difference between 'caption_ref' (opaque handle) and 'captions' (full objects), and clarifies the 'context' parameter's purpose as describing the user's goal rather than the tool being called.

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: 'Put one or more media files into your workspace media library' with explicit constraints (max 10, uploaded sequentially). It also distinguishes itself from sibling tools by referencing clipform_attach_node_media for the next step and describing its role in the media 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 provides explicit usage guidance: it identifies this as 'step one' and directs the user to follow up with clipform_attach_node_media. It also explains when to use caption_ref vs captions, and how to obtain captions from clipform_generate_tts, giving clear 'when-to-use' instructions.

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.