Server Quality Checklist

Tool Scores

• delete_objectC
  2.9/5.0
  Behavior3/5

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

  The description adds behavioral context beyond the bare action by explaining that subsequent object indices are packed. However, with no annotations provided, it fails to disclose other crucial traits such as whether deletion is permanent, requires specific permissions, or affects other scenes.

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

  Conciseness5/5

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

  The description is extremely concise, consisting of one short sentence followed by a clear behavioral note. Every word earns its place, and the key action is front-loaded.

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

  Completeness2/5

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

  With three parameters, no output schema, and no annotations, the description is too sparse to be contextually complete. It does not explain what 'path' refers to, how 'object_index' is scoped, the role of 'scene', or the expected success/failure behavior, leaving significant gaps for a deletion operation.

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

  Parameters1/5

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

  Schema description coverage is 0% and the tool description provides no explanation of the parameters 'path', 'scene', or 'object_index'. The description fails to compensate for the lack of schema documentation, leaving users guessing at parameter meanings and relationships.

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

  Purpose4/5

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

  The description clearly states the tool deletes an object and adds a specific behavioral note about reindexing subsequent objects. However, it does not distinguish this tool from the sibling 'live_delete_object', leaving ambiguity about which delete operation to use.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like live_delete_object, nor are any prerequisites or intended scenarios mentioned. The description simply states what it does without contextual usage direction.

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

• live_delete_objectB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of disclosing behavioral traits. It states the operation is a deletion, implying destructive action, but does not mention irreversibility, side effects on dependent objects, or whether it applies to the currently active project (only the title implies real-time). No error handling or success/failure behavior is documented.

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

  Conciseness4/5

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

  The description is a single concise sentence that front-loads the key mechanism (layer/frame_start identification). It is free of fluff or repetition. It could be slightly more detailed without becoming verbose, so it doesn't earn a 5, but it is well-structured and easy to parse.

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

  Completeness2/5

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

  As a destructive operation with no annotations, no output schema, and a very terse description, the context is incomplete. Missing are details on sequence (e.g., must be in a live session), consequences, reversibility, and expected return values. The description provides only the core mechanism, leaving significant gaps for an agent to safely decide to invoke this tool.

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

  Parameters3/5

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

  The description adds meaning to the parameters by stating that layer and frame_start together identify the target object. This goes beyond the schema's bare integer types and minimum constraints. However, it does not explain what these values semantically represent or how they uniquely locate the object, so the compensation is partial rather than complete.

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

  Purpose5/5

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

  The description clearly states the tool's function: it identifies and deletes an object using layer and frame_start parameters. The verb '削除する' (delete) plus the specific resource ('対象オブジェクト') makes the purpose unambiguous. The title further clarifies it operates on a running project in real-time, distinguishing it from sibling live_* tools and the non-live delete_object.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives like delete_object or live_update_object. The description only explains how the object is identified, not the context in which this real-time deletion is appropriate. It doesn't mention prerequisites (e.g., project must be running) or exclusions.

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

• create_projectB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden. It discloses the file type and path constraints, but omits important behavioral details such as overwrite behavior, directory creation, permissions, error handling, or return values.

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

  Conciseness5/5

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

  The description is three short sentences, each contributing distinct information: the core action, a path suffix requirement, and a location prohibition. It is front-loaded and free of redundant wording.

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

  Completeness2/5

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

  With 7 parameters, no annotations, and no output schema, the description leaves critical gaps: it doesn't cover overwrite semantics, default parameter interactions, or what the tool returns. The constraints provided are useful but insufficient for a complex creation tool.

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

  Parameters2/5

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

  Schema description coverage is only 29% (2 of 7 properties have descriptions). The description adds path-related constraints for the 'path' parameter, but does not explain the meaning or behavior of width, height, overwrite, audio_rate, frame_rate, or scene_name.

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

  Purpose5/5

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

  The description clearly states the tool creates an empty AviUtl2 project file with a specific verb and resource. It distinguishes from siblings like read_project or update_scene by specifying the action of creation and the .aup2 file type.

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

  Usage Guidelines3/5

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

  The purpose implies when to use it, but there is no explicit guidance on alternatives or when not to use. It does provide usage constraints (path must end .aup2, cannot be in AviUtl2 main/data folder), but no direct comparison with other tools.

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

• uninstall_scriptB
  3.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It discloses a key behavioral trait: the deletion scope is restricted to the managed folder and cannot delete elsewhere. However, it does not mention irreversibility, side effects, or error handling, which are relevant for a destructive action.

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

  Conciseness5/5

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

  The description is two concise sentences with no unnecessary words. It clearly delivers the action and a key constraint, making it efficiently structured and front-loaded.

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

  Completeness2/5

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

  The tool is simple, but the description is incomplete for correct usage. The missing parameter semantics (what 'filename' should contain) and lack of behavioral details (irreversibility, failure behavior) mean the agent lacks necessary context. No output schema or annotations exist to fill these gaps.

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

  Parameters1/5

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

  The input schema has one required parameter 'filename' with no description, and the tool description does not explain how to specify it (e.g., full path, extension, relative name). With 0% schema description coverage, the description fails to compensate, leaving the parameter ambiguous.

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

  Purpose5/5

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

  The description clearly states the tool deletes a script from a specific managed folder (C:\ProgramData\aviutl2/Script/MCP), providing a specific verb, resource, and scope. It distinguishes from sibling tools like install_script by specifying deletion rather than installation.

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

  Usage Guidelines3/5

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

  The description implies usage for removing scripts from the managed folder and explicitly states the exclusion that it cannot delete from other locations. However, it does not explicitly mention when to use this tool over alternatives or provide when-not-to-use guidance.

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

• update_sceneB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a mutation ('change') but does not clarify whether existing settings are overwritten, whether the scene must exist, or any side effects. The basic action is clear, but deeper behavioral context is missing.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that efficiently states the tool's purpose and includes a parenthetical list of example keys. Every word earns its place, with no redundant or filler content.

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

  Completeness3/5

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

  The tool has three parameters including a nested settings object, but no output schema and no annotations. The description highlights the settings keys but omits details about `path` and `scene`, and does not mention return values or error behaviors. It is adequate for basic use but leaves notable gaps.

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

  Parameters3/5

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

  The description adds meaning to the `settings` parameter by mapping human-readable terms (resolution, frame rate, name) to example keys (video.width, video.height, video.rate, audio.rate, name). However, the `path` and `scene` parameters are not explained, and schema coverage is only 33%, so the description only partially compensates for the missing parameter documentation.

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

  Purpose5/5

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

  The description clearly states the tool's function: changing scene settings such as resolution, frame rate, and name, with concrete example keys (video.width, video.height, etc.). This makes it easily distinguishable from sibling tools like update_object and live_update_object, which target object properties rather than scene-level settings.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It simply states what the tool does without contextual usage cues.

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

• live_add_objectA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden and does disclose a key behavior: it fails if the frame range overlaps with existing objects. It also states that it acts on the currently editing scene without reopening. However, it omits details about success behavior, return values, or reversibility, leaving some gaps in operational expectations.

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

  Conciseness5/5

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

  The description is two concise sentences, front-loaded with the main purpose. The first sentence states what it does, and the second adds a parameter note and a critical failure condition. Every word earns its place with no redundant or filler content.

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

  Completeness2/5

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

  Given the tool has 10 parameters (including nested objects), no output schema, and no annotations, the description is under-specified. It does not describe return values, success indicators, or how the nested object parameters (effects, draw_params, text_params) should be structured. The reference to add_objects helps, but the description alone is incomplete for a tool of this complexity.

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

  Parameters2/5

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

  The input schema has 0% description coverage for its 10 parameters. The description only mentions the type enum (video/image/audio/text/raw) and says parameters follow add_objects, but it does not explain layer, frame_start/end, effects, or nested objects. This does not sufficiently compensate for the lack of schema descriptions.

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

  Purpose5/5

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

  The description states a specific action: adding an object to the currently editing scene of a running AviUtl2 instance without reopening. It also distinguishes itself from the sibling add_objects by referencing the same parameter format and highlighting the live aspect. This clearly identifies the tool's unique role.

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

  Usage Guidelines4/5

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

  The description indicates the tool is for live additions to a running AviUtl2 project, contrasting with file-based add_objects. It notes that parameters match add_objects, implying when to use it. However, it does not explicitly state when not to use it or mention alternative tools like live_update_object, so it lacks exclusions.

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

• live_update_objectA
  3.8/5.0
  Behavior2/5

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

  Without annotations, the description carries the full burden. It discloses that changes are applied in place and that frame_start must match, but it does not mention side effects, reversibility, or what happens if the object is not found. For a mutation tool, this is a significant gap.

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

  Conciseness5/5

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

  The description is a single sentence that efficiently conveys purpose and a key prerequisite without unnecessary filler. It is front-loaded with the identifying mechanism and immediate effect, making it easy to parse.

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

  Completeness2/5

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

  For a real-time modification tool with nested parameters and no output schema, the description does not address return values, error behavior, or limitations. It provides the essential trigger context but leaves out important operational details needed for an agent to use it safely.

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

  Parameters4/5

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

  The description adds meaning to the required parameters layer and frame_start by explaining they identify the target object and that frame_start must match live_get_state. The other parameters (sets, move_to) are already described in the schema, so the description supplements the 50% coverage effectively.

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

  Purpose5/5

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

  The description clearly states that the tool modifies settings or positions of an object in a live project, identifying the object by layer and frame_start. It distinguishes itself from sibling tools like live_add_object and live_delete_object by focusing on modification, making its purpose specific.

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

  Usage Guidelines4/5

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

  The description explicitly instructs that the frame_start must match live_get_state's frame_start, implying the prerequisite of calling live_get_state first. It does not mention alternative tools or exclusion cases, but the context is clear enough for selecting this tool in a live editing workflow.

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

• update_objectA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden, but it only discloses the merge-update behavior for params and the source of object_index. It does not mention side effects, reversibility, permissions, or error conditions, which are particularly relevant for a mutation tool. The merge behavior is already partially stated in the schema, so the description adds limited extra transparency.

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

  Conciseness5/5

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

  The description is compact at two sentences, front-loads the primary action, and adds only essential clarifications about object_index and effect_index. Every phrase is useful, and it neither repeats schema information nor wastes words.

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

  Completeness2/5

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

  For a complex tool with 10 parameters, no annotations, and no output schema, the description is too terse. It covers the core action but omits critical context such as return values, behavior for edge cases (e.g., invalid indexes, deletion restrictions), and relationships with related tools. The description does not give an agent enough to safely invoke the tool in all scenarios.

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

  Parameters3/5

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

  Schema coverage is only 40%, so the description should compensate, but it only directly explains object_index (from read_project) and effect_index ('specify to merge-update its params'). It hints at layer/frame range via 'レイヤー/フレーム範囲' but does not detail the individual parameters like layer, frame_start, frame_end, or path. The merge behavior is also already in the schema, so added value is moderate.

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

  Purpose5/5

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

  The description clearly states the verb (変更する, to modify) and the resource (既存オブジェクト, existing object), and lists the specific aspects being modified (layer/frame range/effect parameters). It distinguishes the tool from siblings like delete_object and add_objects by focusing on editing an existing object.

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

  Usage Guidelines4/5

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

  The description provides clear context: it is for modifying existing objects, implying it should be used after reading a project (object_index from read_project). However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a full 5.

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

• live_get_stateA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral burden. It discloses that the tool returns scene settings and all objects in alias format in real time, which is useful. However, it does not mention error handling, side effects (though a getter is likely safe), or the exact response format, leaving some behavioral aspects undisclosed.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that immediately states the action, source, and scope. Every phrase carries meaning—'起動中のAviUtl2', '現在編集中シーン', '全オブジェクト(エイリアス形式)', 'リアルタイム'—with no redundancy.

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

  Completeness3/5

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

  The tool has no parameters and no output schema, so the description is the primary guide for what is returned. It mentions scene settings and all objects in alias format, but lacks detail on the exact structure of the response or potential error conditions. This is adequate for a low-complexity tool, but leaves some ambiguity about the return shape.

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

  Parameters4/5

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

  The input schema has zero parameters, so the baseline is 4. The description does not add parameter-specific details (there are none), but this is acceptable given the tool takes no inputs.

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

  Purpose5/5

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

  The description uses a specific verb '取得する' (retrieve) and clearly identifies the resource: from the running AviUtl2, it retrieves current scene settings and all objects in alias format. This distinguishes it from sibling tools like live_add_object or live_delete_object, which are mutation operations.

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

  Usage Guidelines3/5

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

  The description implies usage when AviUtl2 is running and real-time state is needed ('起動中のAviUtl2から', 'リアルタイムに'), but it does not explicitly mention when not to use it or compare with alternatives such as live_status. The context is clear but no exclusions or alternative guidance is provided.

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

• add_objectsA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It adds important behavioral facts: overlapping frames in the same layer/scene are not handled correctly in AviUtl2 (and should be avoided), and frame_end is inclusive. This goes beyond the schema, though it doesn't cover error handling or permissions.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with purpose, and every sentence serves a purpose: it states what the tool does, gives a critical usage constraint, and clarifies frame_end semantics. No fluff.

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

  Completeness4/5

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

  For a tool with a complex nested schema, the description conveys the core purpose and the most critical constraint (overlapping frames). The schema itself contains detailed parameter descriptions, and there is no output schema requiring return-value explanation. The description could mention error behavior or atomicity, but it is adequate for most usage.

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

  Parameters3/5

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

  The schema already provides descriptions for most parameters, but the description clarifies a key semantic: 'frame_end は終了フレーム(含む)' (frame_end is the end frame inclusive). The overlap warning also implies relationships between layer, scene, and frame ranges. However, it does not add extensive parameter details beyond this.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'プロジェクトにオブジェクトを追加する' (adds objects to a project), and explicitly enumerates supported types (video/image/audio/text/arbitrary effect composition). This distinguishes it from siblings like live_add_object by specifying the 'project' context.

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

  Usage Guidelines3/5

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

  The description gives a clear context for when to use (adding objects to a project) and includes a critical warning not to overlap frame ranges in the same layer/scene. However, it does not explicitly compare with sibling tools like live_add_object or update_object, so guidance on alternatives is only implicit.

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

• read_projectA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It discloses the output format and contents, but does not explicitly state that the tool is read-only (no side effects) or how it handles invalid files or paths. This leaves some behavioral ambiguity, though the name and 'parse' suggest safety.

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

  Conciseness5/5

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

  The description is two sentences: the first gives the core function and output contents, the second adds a practical use case. Every sentence earns its place with no redundancy.

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

  Completeness4/5

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

  With only one parameter and no output schema, the description sufficiently explains what the tool returns and suggests a usage scenario. It omits error handling or edge-case behavior, but for a simple read tool this is adequate and nearly complete.

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

  Parameters3/5

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

  Schema coverage for the single parameter 'path' is 100%, including a clear description in the schema itself. The tool description adds no extra meaning about parameter usage or format, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool parses .aup2 files and returns JSON with specific contents (scene settings, object layers, frame ranges, effects, parameters). It also mentions a useful secondary purpose (learning parameter format), and the verb 'read' distinguishes it from sibling tools that create, update, or delete projects.

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

  Usage Guidelines4/5

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

  The description provides a specific use case: learning parameter formats from GUI-created projects, which implies when to use the tool. It does not explicitly name alternatives or exclusion criteria, but the read-only nature is evident from context and sibling tool naming.

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

• list_assetsA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It adds context about the data source (AviUtl2 data folder) and the categories (kinds), but does not explicitly state that it is a read-only operation or describe return format. The verb 'list' implies non-mutating behavior, but more detail (e.g., output structure) would improve transparency.

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

  Conciseness5/5

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

  The description is a single sentence that front-loads the purpose and compresses the kind listing into a compact parenthetical. Every part is informative, with no wasted words.

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

  Completeness4/5

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

  For a simple tool with one parameter and no output schema, the description covers purpose and parameter semantics well. The main gap is that it does not describe what the listing returns (e.g., names, paths, or objects), which would be useful for the agent to know before invoking the tool.

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

  Parameters5/5

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

  The description explains the single 'kind' parameter by mapping each enum value to a human-readable label (scripts, plugins, figures, transitions, fonts, aliases). The schema only provides enum strings, so this adds significant meaning beyond the structured definition.

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

  Purpose5/5

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

  The description clearly states the tool's function: listing extension elements in AviUtl2's data folder. It uses a specific verb (一覧する) and resource (拡張要素), and enumerates the kinds, distinguishing it from sibling tools like install_script or uninstall_script.

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

  Usage Guidelines3/5

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

  The description implies when to use this tool (when you need to see installed assets) but does not explicitly state alternatives or exclusions. Sibling tools like install_script and uninstall_script suggest related operations, but the description does not position this tool relative to them beyond stating its listing function.

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

• install_live_bridgeA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It reveals the install location, the mechanism (named pipe), the effect (real-time control), the need for a restart, and the non-overwrite guarantee due to an independent file name. This is strong behavioral disclosure for a file-install operation, though it omits potential permission requirements or error conditions.

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

  Conciseness5/5

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

  The description is four sentences, all substantive. It front-loads the primary action (install) and then adds necessary context about the effect, restart requirement, and safety guarantee. No fluff or redundancy.

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

  Completeness4/5

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

  Given the tool's simplicity (one parameter, no output schema), the description covers essential aspects: purpose, path, effect, restart, and non-overwrite. It could additionally mention admin privileges or what happens if already installed, but these are not critical for an install tool with a boolean overwrite flag.

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

  Parameters3/5

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

  The only parameter, 'overwrite', is fully described in the schema (100% coverage) as a boolean with default true. The description does not add extra meaning beyond the schema, which is acceptable given the baseline of 3 for self-explanatory parameters.

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

  Purpose5/5

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

  The description clearly states the tool installs a bundled native plugin (mcp_bridge.dll) to a specific path (C:\ProgramData\aviutl2/Plugin/aviutl2-mcp-bridge.aux2). It explicitly ties this to enabling live_* tools, distinguishing it from sibling tools like install_script and uninstall_script.

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

  Usage Guidelines4/5

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

  The description provides clear usage context by stating the installation enables real-time control of AviUtl2 via named pipes for live_* tools and that a restart is required. It does not explicitly state when not to use it or name alternatives, but the purpose is clear enough for an install action.

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

• launch_aviutl2A
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It adds a valuable caveat: if the same project is already open in AviUtl2, external edits will not be incorporated until the project is reopened. This goes beyond the schema and provides insight into a potential side effect. However, it does not mention return values, error handling, or whether the command blocks, so it is not fully comprehensive.

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

  Conciseness5/5

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

  The description is concise, consisting of a clear main action, a brief explanation of the optional parameter, and a necessary warning. Every sentence serves a purpose, and there is no redundant or vague language. It is well-structured and front-loaded with the primary function.

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

  Completeness4/5

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

  For a simple launcher tool with one optional parameter and no output schema, the description covers the essential information: how to launch AviUtl2, how to open a project, and the relevant caveat about existing open projects. It does not specify failure behavior or return values, but these are less critical for a launch action. Overall, it is sufficiently complete for its complexity.

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

  Parameters3/5

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

  The schema already documents project_path with a description ('開く .aup2 の絶対パス'), and the tool description simply restates that specifying it opens the project. It adds no additional format, constraints, or nuances beyond what the schema provides. Since schema coverage is 100%, 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.

  Purpose5/5

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

  The description clearly states the tool's action: 'AviUtl2 を起動する' (starts AviUtl2) and explains the optional behavior of opening a project when project_path is provided. This specific verb+resource pairing distinguishes it from sibling tools like create_project or read_project, which operate on project files but do not launch the application.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use this tool: to launch AviUtl2 and optionally open a specific project via project_path. It also includes a cautionary note about already-open projects requiring a reopen, which helps the agent decide between launching fresh versus reusing an existing instance. It does not explicitly name alternative tools or state when not to use it, 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.

• package_scriptsA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It explains the internal zip structure (extract and put into Script, with subfolders) and the default inclusion of all files if 'files' is omitted. This provides useful context about side effects and output format, though it does not cover all edge cases (e.g., overwriting existing output).

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary action, and every sentence contributes meaning. The first sentence states the source and action, the second clarifies the output structure and default behavior. No redundant or unnecessary text.

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

  Completeness4/5

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

  For a tool with four parameters and no output schema, the description covers the main aspects: source folder, action, zip structure, and default file inclusion. It is adequate for an agent to select and invoke the tool, though it omits potential edge cases like error handling or existing output file behavior, which are not critical for basic use.

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

  Parameters3/5

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

  The input schema provides 100% coverage with descriptions for all four parameters. The description adds high-level context about the output structure and default behavior, but it does not provide additional per-parameter semantics beyond what the schema already includes. Thus, baseline 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb ('まとめる' / bundle) and resource (scripts in a specific folder) into a distribution zip. It clearly differentiates from sibling tools like install_script/uninstall_script by focusing on creating a package rather than installing/uninstalling.

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

  Usage Guidelines4/5

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

  The description clearly indicates the tool's purpose and when it is relevant: to create a distributable zip from the managed folder. It does not explicitly mention alternatives or exclusions, but the context is clear enough that an agent would know to use this when packaging scripts rather than installing them.

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

• live_statusA
  4.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that this is a connection check (ping) and a prerequisite for live_* tools, but it does not explicitly state that it is read-only, how failures are reported, or any potential side effects. For a simple ping tool, this is a minor but notable gap.

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

  Conciseness5/5

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

  The description is a single sentence that front-loads the purpose ('確認する') and includes the parenthetical 'ping' for immediate understanding. Every word earns its place with no redundancy.

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

  Completeness5/5

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

  For a simple no-parameter status check tool, the description is complete: it states what the tool does and when to call it (before live_* tools). The absence of an output schema is acceptable since return values are not complex for a ping-like operation.

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

  Parameters4/5

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

  The tool has zero parameters, so the description has no need to explain parameter semantics. Per the rubric, the baseline for 0 parameters is 4.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with a specific verb ('確認する' - check/confirm) and resource (connection to running AviUtl2 via bridge plugin), using 'ping' to make it intuitive. It is easily distinguished from sibling live_* tools, which perform state changes or object manipulation.

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

  Usage Guidelines4/5

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

  The description explicitly states when to use the tool: 'call before using live_* tools'. This gives clear contextual guidance. However, it does not mention when not to use it or any alternative tools, so it stops short of a perfect 5.

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

• get_environmentA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It explicitly lists the returned data fields and implies a read-only operation through its name and content. It does not detail side effects or error conditions, but for a getter tool this is acceptable.

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

  Conciseness5/5

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

  The description is a single dense sentence that packs all necessary information, including the recommended usage, without any waste. It is front-loaded and every part earns its place.

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

  Completeness4/5

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

  With no output schema, the description serves as a de facto specification by listing the exact fields returned. It is complete for a simple environment info tool, though it could mention prerequisites like AviUtl2 being installed.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema reflects this with no properties. The baseline of 4 applies, and the description appropriately focuses on the output rather than inputs, which is correct for a no-parameter tool.

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

  Purpose5/5

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

  The description clearly states that the tool returns AviUtl2 installation state including specific fields like path, version, data folder, and running status. This specific verb+resource combination distinguishes it from sibling action tools such as launch_aviutl2 or install_script.

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

  Usage Guidelines4/5

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

  The description recommends calling this tool once first, providing clear context for when to use it as an initialization step. It does not explicitly name alternatives, but no alternative for environment info exists among the siblings, so this is sufficient guidance.

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

• install_scriptA
  4.4/5.0
  Behavior4/5

  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 states the destination folder, the supported file extensions, the need for an AviUtl2 restart after writing, and points to read_docs for Lua specs. However, it does not explicitly disclose behavior when overwrite is false and the file exists, which would be a useful behavioral trait.

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

  Conciseness5/5

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

  The description is three concise sentences that front-load the primary action, then provide extension list, restart requirement, and a documentation pointer. Every sentence adds value with no redundancy or filler.

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

  Completeness4/5

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

  The description covers the essential context: target path, supported extensions, restart requirement, and a pointer for Lua specs. While it does not explain overwrite behavior or return values, these are arguably covered by the schema or are not critical for a simple write tool. Overall, it is complete enough for an AI agent to use correctly.

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

  Parameters4/5

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

  Schema description coverage is 67%, and the description adds meaning beyond the schema by listing the supported file extensions, which informs valid filename values. It also mentions referencing read_docs for Lua specifications, which is relevant to the content parameter. This goes beyond the existing schema descriptions.

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

  Purpose5/5

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

  The description clearly states that the tool writes script files to a specific AviUtl2 script folder, listing the exact path and supported extensions. This distinguishes it from siblings like uninstall_script and package_scripts by its specific verb ('writes') and resource (script folder).

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

  Usage Guidelines4/5

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

  The description gives clear context on when to use the tool (installing scripts to the MCP folder, with supported extensions) and notes that a restart is required. It also refers to read_docs for Lua specifications, implicitly guiding the agent on prerequisites. No explicit exclusions or alternatives are mentioned, but the context is clear.

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

• read_docsA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses that the tool reads documents, maps enum values to actual files, and clarifies that offset/limit are line-based. For a read-only tool, this adequately reveals the key behavior 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.

  Conciseness5/5

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

  The description is two concise sentences, front-loaded with the primary purpose, then efficiently lists the document mappings and pagination details. Every clause contributes value with no redundancy.

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

  Completeness4/5

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

  For a simple document reader with three enum options and pagination, the description covers the essential selection and usage details. It does not explicitly state return format, but reading a document implies text output, and default limits are captured in the schema.

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

  Parameters5/5

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

  The schema only describes limit/offset; the doc parameter is an opaque enum. The description adds essential semantics by mapping each doc value to its file and content, making the parameter meaningful. It also reinforces the line-based interpretation of offset/limit.

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

  Purpose5/5

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

  The description explicitly states the tool reads bundled documents and enumerates three specific documents (readme, lua, style) with their content scope. This is a clear verb+resource and distinguishes it from sibling tools like read_project.

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

  Usage Guidelines4/5

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

  The description gives clear context on what each document covers (e.g., lua for Lua script specs), guiding the agent on which doc to select. It does not explicitly mention when not to use the tool or alternative tools, but the context is sufficient for typical usage.

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