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

With no annotations, the description carries the burden. It discloses two key behavioral traits: the URL is 'fresh signed' (time-limited) and the job must be 'completed'. However, it does not mention what happens if the job is incomplete or expired, nor any auth requirements or rate limits. This is adequate but not rich.

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

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

One concise sentence, front-loaded with the action, no filler. Every word contributes meaning ('fresh', 'signed', 'completed').

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 one-parameter read-only getter with no output schema, the description is nearly complete. It tells the user what to provide (implicitly via schema) and what they'll receive (a download URL). It lacks error-condition details, but the simplicity of the operation makes this acceptable. A 5 would require explicit mention of timeout or error behavior, which is not essential here.

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 jobId as 'Completed render job ID'. The description repeats 'completed render job' but adds no extra semantic detail beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the verb ('Get') and resource ('signed download URL') and specifies the scope ('for a completed render job'). This distinguishes it from siblings like get_render_status (status vs URL) and render_template (render vs download).

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 'for a completed render job' provides clear context for when to use this tool—after a render is finished. It doesn't explicitly mention alternatives, but the sibling names indicate distinct purposes, and the wording implies this is a final step, not a status check. No exclusions are given, but the context is clear enough for a simple getter.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only query by saying 'Return' and 'Use this before', but it does not explicitly state the absence of side effects, error handling, or any special behavior for invalid layer types.

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

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

The description is two sentences, front-loaded with the primary function, and contains no redundant or filler content. Every word adds value.

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

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

The description tells what is returned (effects and transitions) and the filtering basis (layer type), which is sufficient for a simple query tool. With no output schema, a bit more detail on return structure would be ideal, but the given information is reasonably complete for the tool's simplicity.

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% for both parameters, with clear descriptions in the schema. The tool description adds no further parameter semantics beyond the schema, 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 'Return' and identifies the exact resource: 'built-in effects and transitions' filtered by 'layer type'. This clearly distinguishes it from sibling tools focused on templates, rendering, and local previews.

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 states when to use the tool: 'Use this before choosing effects or transitions for a layer.' This provides clear context and a direct call to action, though it does not mention exclusions or alternative tools for similar queries.

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

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

No annotations are provided, so the description must disclose behavioral traits itself. It only restates the tool's purpose ('Check the status') without adding information about whether it is read-only, whether it can be polled, how it handles errors, or what the response format is. This is a minimal disclosure that does not go beyond the tool name's implication.

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

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

The description is a single sentence that is direct and front-loaded with the main action and resource. It contains no filler or redundant information, effectively communicating the tool's purpose in a concise manner.

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

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

With no output schema and no annotations, the description should provide more context about the tool's behavior and result interpretation. It does not mention possible statuses, polling behavior, or what the response looks like. While the tool is simple, the missing context makes it incomplete for an agent to 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 covers 100% of the parameters, and the schema's description of jobId ('returned by ilovevideoeditor_render_json or ilovevideoeditor_render_template') is more informative than the tool description's simple 'by its job ID.' The tool description adds no additional meaning to the parameter beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Check the status of a render job by its job ID.' It specifies the action (check), the resource (render status), and the required input (job ID). This distinguishes it from sibling tools like render_json/render_template (which start jobs) and get_download_url (which retrieves the final result).

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 tool description itself does not explicitly mention when to use it or alternatives. However, the context is implied: one must first create a render job via render_json or render_template, and then poll its status. No exclusions or alternative tools are referenced in the description, making the usage guidance merely 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?

With no annotations provided, the description carries the full transparency burden. It states what is returned but does not disclose whether the operation is read-only, permissions required, error handling, or any side effects. This is a significant gap for a tool with no annotation safety 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 concise sentence that front-loads the purpose and key detail (variable schema). Every word earns its place, and there is no redundant or vague phrasing.

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

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

For a simple read tool with one parameter, the description is minimally adequate. However, since there is no output schema, it leaves the full return structure vague (only 'detailed information' and 'variable schema' are mentioned). More context about the returned fields or typical use cases would improve completeness.

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 fully documents templateId with a description and example, so the schema already provides complete parameter coverage. The description adds no extra semantic meaning beyond confirming that the template is 'specific', yielding a baseline score.

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

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

The description clearly states the tool retrieves detailed information about a specific template, explicitly including the variable schema. This verb-resource pairing is specific and distinguishes it from list-oriented sibling tools like list_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 implies use with a specific templateId but provides no explicit when-to-use guidance or alternatives. It doesn't mention when to prefer this over list_templates or other sibling tools, so usage is only implied.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. The verb 'List' signals a read-only operation, but the description does not mention pagination, response format, or any limitations. It's not misleading, but it lacks additional context beyond the obvious read-only implication.

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, clear sentence with no filler words. Every word contributes to understanding the tool's purpose.

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

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

For a zero-parameter, no-output-schema tool, the description provides sufficient context by stating it lists all templates for personalized video generation. It does not explain the exact structure of the list (e.g., template IDs vs. names), but given the low complexity, this is a minor gap.

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

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

The tool has zero parameters, which sets a baseline of 4. The description correctly does not attempt to explain non-existent parameters. No additional parameter semantics are needed.

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 the specific verb 'List' with the resource 'available iLoveVideoEditor templates' and adds context 'for generating personalized videos.' This clearly distinguishes it from sibling tools like ilovevideoeditor_get_template, which retrieves a specific template rather than enumerating all.

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 a clear use case: enumerating all available templates. It doesn't explicitly state when to use alternative tools like get_template, but the intent is unambiguous for a listing operation. No exclusions or prerequisites are mentioned, so it falls short of an explicit 5.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It states that the tool analyzes and returns metrics/issues, implying a read-only operation, and adds specific categories of issues. However, it does not mention whether a local preview must be active, whether it has side effects, or any prerequisites.

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

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

A single, well-structured sentence that front-loads the action and resource and immediately provides concrete examples of the output. No wasted words.

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

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

For a simple tool with one optional parameter and no output schema, the description provides the essential information: what it analyzes, where it analyzes, and what it returns. It could be slightly more explicit about prerequisites, but overall it is sufficiently complete for correct invocation.

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

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

The input schema covers 100% of the single parameter ('time') with a clear description. The tool description does not add extra meaning about the parameter, but the schema itself is sufficient, so the 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?

The description uses a specific verb ('Analyze'), identifies the resource ('generated VideoJSON layout in the local preview'), and specifies the output ('structured metrics and issues' with concrete examples). This clearly distinguishes it from sibling tools like local_preview or local_capture.

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 the tool: when you need to analyze a layout for overflow, overlap, font fallback, etc. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough for an agent to select 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?

No annotations are provided, so the description must disclose behavior. It does not state whether the screenshot is returned as data or saved, nor does it mention any side effects or permission requirements. Additionally, 'at a given time' implies the time parameter is required, but the schema marks it optional, which is a minor inconsistency with the behavioral context.

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

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

The description is a single, focused sentence with no unnecessary words. It is well-structured and front-loaded with the 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 tool with no output schema and no annotations, the description leaves important gaps: it does not specify the return format of the screenshot or what 'given time' means if omitted. It also does not explain how the local preview is accessed or what happens if it isn't running, making it incomplete for an agent to invoke confidently.

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

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

The input schema already provides descriptions for both parameters, and the description adds little beyond the phrase 'at a given time.' Format and default behavior are covered by the schema, so the description adds marginal value.

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

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

The description clearly states it captures a screenshot from the running local preview at a given time, which is a specific verb and resource. It distinguishes this tool from siblings like render or analyze by focusing on screenshot capture from the local preview.

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 a use case—capturing a screenshot from the running local preview—but does not explicitly contrast it with alternatives or state when not to use it. The mention of 'running local preview' signals a prerequisite, but no explicit guidance is given.

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

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

With no annotations provided, the description must disclose behavioral traits, but it only says 'Start or stop the local preview dev server.' It does not explain side effects (e.g., port usage, resource cleanup), what 'status' reports, or any requirements for starting. This is a significant gap for an operation that modifies local state.

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, front-loaded with the primary action. Every word earns its place. The description is concise and immediately readable.

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 dev server control tool, the description plus schema may be sufficient for basic use. However, there is no output schema and the description does not mention what 'status' returns or how the server lifecycle works. The ambiguity around 'file required for start' (not in required list) also leaves the agent with unanswered questions.

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 both parameters and the enum. The description adds the 'before capturing frames' context but repeats nothing new about parameter meanings. Baseline of 3 is appropriate since the schema does the heavy lifting.

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 starts or stops a local preview dev server, which is a specific verb+resource. It distinguishes itself from siblings by noting it is used before capturing frames, but it omits the 'status' action from the schema, so it is not fully complete.

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 'Use this before capturing frames' gives clear temporal context for when to invoke this tool relative to capture/analyze siblings. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of a 5.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states that a payload is submitted and a job ID is returned. It does not mention potential side effects, authentication requirements, asynchronous behavior, validation, or error handling. This is a significant gap for a mutation tool, similar to the update_drive example which scored 2.

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 outcome. There is no wasted wording, and it conveys all necessary information in a clear structure.

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

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

The tool has a simple input schema (one object param) and no output schema. The description mentions receiving a job ID, which is the return value, but it does not explain subsequent steps (e.g., checking render status or retrieving the download URL) which are likely needed given the sibling tools. This gap prevents it from being fully complete, but for a basic submit-and-get-ID operation, it is sufficient. A 3 reflects the missing 'what next' 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% with the only parameter 'videoJSON' described as 'A valid VideoJSON scene definition'. The description adds the qualifier 'raw' suggesting it expects direct JSON rather than a reference, but this adds little beyond the schema. With high schema coverage, baseline is 3, and no additional parameter detail is provided in the description, so a 3 is appropriate.

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

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

The description clearly states the action: 'Submit a raw VideoJSON payload to the iLoveVideoEditor render queue and receive a job ID.' It uses a specific verb ('submit'), specifies the resource (raw VideoJSON payload), and the outcome (job ID). This distinguishes it from sibling tools like render_template, which presumably uses templates rather than raw JSON.

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 implicitly indicates when to use this tool: when you have a raw VideoJSON payload to render. It does not explicitly state when not to use it or mention alternatives, but the context from sibling tools (e.g., render_template) makes the choice fairly clear. This is clear context without explicit exclusions, so a 4 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?

With no annotations provided, the description carries the full burden. It discloses that the tool queues the video for rendering (async) and returns a job ID, which is a key behavioral trait. It does not cover error handling or prerequisites, but the async nature is well 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?

The description is a single, front-loaded sentence that mentions purpose, process (queueing), and output (job ID). Every word earns its place, achieving high conciseness without omitting essential 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?

The tool is simple (2 params) but has no output schema, so the description must explain the return. It says 'return a job ID', which covers that. It lacks guidance on next steps (e.g., use get_render_status to poll), but given the sibling context, the core information is present and 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?

The input schema already documents both parameters with clear descriptions (templateId, variables). The description adds minimal parameter-specific value beyond restating 'named template' and 'variables', so with 100% schema coverage, a baseline 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 clearly states the tool's specific action: generate a video from a named template with variables, queue it, and return a job ID. This distinguishes it from siblings like render_json (which likely takes raw JSON) and list_templates/get_template (which manage 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 implies usage: you need a templateId and variables to generate a video. It does not explicitly contrast with the sibling render_json or mention when to choose this over alternatives, so it earns a mid-range score for implied usage.

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