3dsmax-mcp

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 effectively describes the tool's behavior: it adds modifiers to objects, supports a wide range of modifier types, handles parameter formatting (JSON string for modifier_params), and returns a structured result with success status and details. It doesn't mention error conditions, permissions, or side effects, but covers core operational behavior well.

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

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

The description is well-structured with clear sections: purpose statement, modifier type examples, parameter explanations, return format, and usage examples. It's appropriately sized for a tool with 3 parameters and complex functionality. Some redundancy exists (e.g., listing many modifier types), but overall it's efficient and front-loaded with critical 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?

Given the complexity (3 parameters, 0% schema coverage, no annotations, no output schema), the description is quite complete. It explains what the tool does, details all parameters with examples, describes the return structure, and provides multiple usage scenarios. It could improve by mentioning error cases or integration with sibling tools, but it adequately covers the tool's functionality for an AI agent.

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 description coverage is 0%, so the description must fully compensate. It provides extensive parameter semantics: object_name is explained as '目标物体的名称（场景中已存在的对象）' (name of target object, existing in scene), modifier_type is detailed with a comprehensive list of examples and formatting rules (e.g., using underscores for spaces), and modifier_params is clearly defined as a JSON string with examples. This adds significant value beyond the bare schema.

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

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

The description clearly states the tool's purpose: '为 3ds Max 场景中的指定物体添加修改器(Modifier)' (adds modifiers to specified objects in 3ds Max scenes). It specifies the exact action ('添加' - add) and resource ('修改器' - modifiers), distinguishing it from sibling tools like create_object, delete_object, or set_object_property that handle different operations.

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 by stating it works on '场景中已存在的物体' (existing objects in the scene), suggesting it should be used after object creation. However, it doesn't explicitly state when to use this tool versus alternatives like set_object_property or execute_maxscript for similar effects, nor does it mention prerequisites or exclusions beyond object existence.

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 full burden and does well. It discloses that the tool supports wildcard matching ('*') and comma-separated lists for object_name, explains the priority between material_name and slot_index, specifies the slot_index range (1-24) and default value ('0'), and describes the return format including success status and lists. It doesn't mention error conditions, performance characteristics, or permission requirements, but provides substantial 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 well-structured with clear sections: purpose statement, parameter explanations, return format, and usage examples. Every sentence adds value. It could be slightly more concise by integrating the example calls more tightly with parameter explanations, but overall it's efficiently organized with no wasted text.

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 3-parameter mutation tool with no annotations and no output schema, the description provides comprehensive context. It explains the tool's purpose, parameter usage, return format, and includes multiple usage examples. The main gap is the lack of explicit error handling information or performance considerations, but given the complexity level and absence of structured metadata, it's quite complete.

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

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

With 0% schema description coverage, the description fully compensates by providing rich semantic information for all 3 parameters. It explains object_name supports wildcards and comma-separated lists, material_name searches all scene materials, slot_index uses material editor slots 1-24, and clarifies the priority relationship between material_name and slot_index. The description adds significant value beyond what the bare schema provides.

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

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

The description clearly states the specific action ('将材质赋予' - assign material) and target resource ('3ds Max 场景中的指定物体' - specified objects in 3ds Max scene). It distinguishes from siblings like create_material (which creates rather than assigns) and set_object_property (which sets properties rather than materials). The verb+resource combination is precise and unambiguous.

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

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

The description provides clear context about when to use this tool (to assign existing materials to objects) and distinguishes it from create_material (which creates new materials). It explains the mutual exclusivity between material_name and slot_index parameters. However, it doesn't explicitly state when NOT to use this tool or mention specific alternatives for different scenarios beyond the parameter guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (cloning with three modes), default behaviors (copy mode, default naming, zero offset), and the return format (dictionary with success flag, names, type, position, message). It doesn't mention permissions, rate limits, or error conditions, but covers core operational behavior well for a tool with no annotations.

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

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

The description is well-structured with purpose statement, mode explanations, parameter details, return format, and examples. It's appropriately sized for a 4-parameter tool with behavioral complexity. Some minor redundancy exists (e.g., repeating '克隆' in examples), but overall it's front-loaded and each section 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?

Given the tool's complexity (cloning with three modes), no annotations, 0% schema coverage, and no output schema, the description is complete. It covers purpose, usage, parameters, return values, and provides examples. The return format documentation compensates for the lack of output schema, making it self-sufficient for an agent to understand and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must fully compensate. It provides detailed semantics for all 4 parameters: object_name (source object to clone), clone_type (three modes with explanations), new_name (optional custom name), and offset (format 'x,y,z' with default). The descriptions add meaning beyond schema titles, explaining defaults, formats, and implications (e.g., empty new_name uses default naming).

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

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

The description clearly states the tool's purpose: '克隆 3ds Max 场景中的指定物体' (Clone specified objects in a 3ds Max scene). It specifies the verb '克隆' (clone) and resource '物体' (objects), and distinguishes from siblings like create_object, delete_object, or rename_object by focusing on duplication rather than creation, deletion, or renaming.

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

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

The description provides clear context for when to use this tool: to clone objects in 3ds Max. It explains three clone modes (copy, instance, reference) with their differences, helping users choose based on needs. However, it doesn't explicitly state when NOT to use it or name alternatives among siblings (e.g., create_object for new objects vs. clone_object for duplicates).

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 full burden. It clearly indicates this is a creation/mutation operation ('创建' - create) and provides return value structure, but lacks important behavioral context like whether it requires specific scene states, what happens on failure, or if there are limitations on light counts. The examples help but don't fully cover behavioral traits.

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

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

The description is well-structured with clear sections (purpose, supported types, args, returns, examples) and every sentence adds value. It could be slightly more concise by integrating the examples more tightly, but overall it's efficiently organized with no wasted text.

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 6-parameter creation tool with no annotations and no output schema, the description provides excellent coverage of parameters and return values. It explains what the tool does, documents all parameters thoroughly, shows return structure, and provides multiple usage examples. The main gap is lack of behavioral context about scene requirements or limitations.

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

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

With 0% schema description coverage, the description fully compensates by providing extensive parameter documentation. It explains each parameter's purpose, format, defaults, and provides specific examples for different light types. The light_type parameter gets particularly detailed treatment with descriptions of each supported type, going far beyond what the schema provides.

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

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

The description clearly states the specific action ('创建一个灯光对象' - create a light object) and resource ('在 3ds Max 场景中' - in a 3ds Max scene). It distinguishes itself from sibling tools like create_object or create_material by specifying it creates specifically light objects, not generic objects or materials.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., must have a scene open), compare to similar tools like create_object, or indicate when other lighting methods might be preferable. Usage is implied through examples but not explicitly stated.

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 full burden and does well by explaining that created materials are placed in the material editor, listing supported material types with their characteristics, and describing the return format. It doesn't mention permissions, rate limits, or error conditions, but provides substantial behavioral context for a creation tool.

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

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

Well-structured with purpose statement, behavioral details, parameter explanations, return format, and usage examples. Some redundancy exists (e.g., repeating parameter info in examples), but overall efficient with each section adding value. Could be slightly more front-loaded.

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

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

For a 4-parameter creation tool with no annotations and no output schema, the description provides comprehensive context: purpose, behavioral details, full parameter semantics, return format, and multiple examples. It lacks only some edge cases (error conditions, dependencies like V-Ray plugin requirements beyond mentioning them).

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

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

With 0% schema description coverage, the description fully compensates by providing detailed parameter explanations: material_type with examples and defaults, name behavior when empty, diffuse_color format with examples, and params as JSON string with examples. It adds significant value beyond the bare schema.

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

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

The description clearly states the verb ('创建' - create) and resource ('材质' - material) in 3ds Max, specifying it creates various material types with basic properties. It distinguishes from siblings like 'create_object' or 'create_light' by focusing specifically on materials rather than objects or lights.

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

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

The description implies usage when creating materials in 3ds Max but doesn't explicitly state when to use this vs alternatives like 'assign_material' or 'set_object_property'. It provides context about material types but lacks explicit guidance on tool selection scenarios.

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 of behavioral disclosure. It effectively describes what the tool does (creates objects), includes detailed parameter information, return value structure, and multiple usage examples. However, it doesn't mention potential side effects, error handling, or performance considerations that would be helpful for a mutation tool.

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 comprehensive but lengthy and not optimally structured. While all information is valuable, it could be more front-loaded with the core purpose followed by details. The multiple examples at the end are helpful but contribute to length. Some sections could be more efficiently organized.

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

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

For a mutation tool with no annotations and no output schema, the description provides substantial context: clear purpose, detailed parameters, return structure, and multiple examples. It covers most needs for using the tool effectively. The main gap is lack of error handling or side effect information, which prevents a perfect score.

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

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

With 0% schema description coverage, the description fully compensates by providing extensive parameter semantics. It explains all 4 parameters in detail: object_type with supported values and naming conventions, name with default behavior, position with format examples, and params with JSON format and examples. This adds significant value beyond the bare schema.

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

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

The description clearly states the tool's purpose: '在 3ds Max 场景中创建一个基础几何体对象' (creates a basic geometric object in a 3ds Max scene). It specifies the verb '创建' (create) and the resource '基础几何体对象' (basic geometric object), distinguishing it from sibling tools like create_light or create_material that create different resource types.

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

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

The description implies usage by listing supported geometry types and providing examples, but it doesn't explicitly state when to use this tool versus alternatives like clone_object or set_object_property. No guidance is given on prerequisites, error conditions, or when not to use this tool.

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

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

With no annotations provided, the description carries full burden and does well by: 1) Clearly stating this is a destructive operation (implied by '删除'), 2) Explaining the return format in detail, 3) Warning about the dangerous '*' option. It doesn't mention authentication needs or rate limits, but for a local 3ds Max tool this is reasonable.

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 appropriately sized and front-loaded with the core purpose first. The Args and Returns sections are well-structured. The multiple example calls are helpful but slightly repetitive; they could potentially be condensed while maintaining clarity.

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

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

For a destructive tool with no annotations and no output schema, the description provides excellent completeness: clear purpose, parameter semantics, return format details, usage examples, and appropriate warnings. It gives the agent everything needed to understand and invoke this tool safely and effectively.

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

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

With 0% schema description coverage for the single parameter, the description fully compensates by providing extensive semantic information about 'object_name': exact names, wildcard patterns, comma-separated lists, and the special '*' value. It includes syntax examples and practical usage guidance beyond what the bare schema provides.

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

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

The description clearly states the specific action ('删除' - delete) and target resource ('3ds Max 场景中的指定物体' - specified objects in 3ds Max scene). It distinguishes from siblings like 'rename_object', 'clone_object', and 'select_objects' by focusing on permanent removal rather than modification, duplication, or selection.

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

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

The description provides clear context about when to use this tool (to delete objects by name with wildcard support) and includes a caution about using '*' to delete all objects. However, it doesn't explicitly state when NOT to use it versus alternatives like 'select_objects' for temporary operations or 'rename_object' for identification changes.

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 full burden and does well. It discloses key behavioral traits: that the last expression's value is returned, recommendations for returning complex structures (construct as string or use print), and provides a documentation reference. It doesn't mention error handling, execution time limits, or security implications, but covers the essential execution behavior adequately.

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

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

The description is well-structured with clear sections: purpose statement, usage guidance, execution behavior notes, parameter explanation, return format, and multiple examples. While comprehensive, it's appropriately sized for a powerful execution tool. Some sentences could be more concise, but overall it's efficiently organized with each section adding value.

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

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

For a tool with no annotations, no output schema, and 0% schema coverage, the description provides excellent context. It explains the execution model, return behavior, parameter usage, and includes practical examples. The main gap is lack of explicit error handling information, but given the complexity of executing arbitrary code, it provides substantial guidance for safe and effective use.

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

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

With 0% schema description coverage for the single parameter, the description fully compensates. It clearly explains the 'script' parameter as '要执行的 MAXScript 代码字符串' (MAXScript code string to execute) and provides four concrete examples showing different use cases. The examples demonstrate parameter usage far beyond what the bare schema provides, adding substantial semantic context.

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

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

The description clearly states the tool's purpose: '在 3ds Max 中执行一段 MAXScript 代码并返回结果' (execute MAXScript code in 3ds Max and return results). It specifies the verb ('执行' - execute), resource ('MAXScript 代码' - MAXScript code), and distinguishes it from sibling tools like execute_python_script by explicitly mentioning MAXScript. The purpose is specific and unambiguous.

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

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

The description provides explicit usage guidance: '适用于某些用 MAXScript 更直接或更方便的操作场景' (suitable for scenarios where MAXScript is more direct or convenient). It distinguishes from alternatives by implying MAXScript should be used when it's more appropriate than other methods, though it doesn't name specific sibling tools as alternatives. The guidance is clear about when this tool is preferred.

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 full burden and delivers comprehensive behavioral details: it explains the execution environment (3ds Max's Python environment), how to return results (via `_mcp_max_results` variable), default return behavior when no results are set, and includes practical examples showing both read and write operations (getting object names vs creating a sphere).

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

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

The description is well-structured and front-loaded with purpose, followed by usage instructions, examples, and parameter/return documentation. Every section adds value: the examples are particularly helpful for understanding script structure, and the Args/Returns sections clarify input/output expectations without redundancy.

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

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

For a complex execution tool with no annotations, 0% schema coverage, and no output schema, the description provides complete context: it explains the execution environment, return mechanism, debugging approach, includes practical examples, and documents both input and output expectations. The sibling tool context (execute_maxscript) is appropriately addressed through the Python-specific focus.

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

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

With 0% schema description coverage for the single parameter 'script', the description fully compensates by explaining the parameter's purpose ('要在 3ds Max 中执行的 Python 脚本代码字符串' - Python script code string to execute in 3ds Max), providing syntax guidance, and showing two detailed examples that demonstrate proper script structure and content.

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

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

The description clearly states the tool's purpose: '在 3ds Max 中执行一段 Python 脚本并返回执行结果' (execute a Python script in 3ds Max and return the execution result). It specifies the verb '执行' (execute) and resource 'Python 脚本' (Python script), and distinguishes from sibling tools like 'execute_maxscript' by focusing on Python rather than MAXScript.

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

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

The description provides explicit usage guidelines under '使用说明' (usage instructions), including how to access MAXScript runtime, use print() for debugging, and return results via `_mcp_max_results`. It also distinguishes from 'execute_maxscript' by specifying Python execution environment with access to pymxs and MaxPlus modules.

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 of behavioral disclosure. It effectively describes the tool's behavior: it exports from 3ds Max, supports multiple formats, allows selection scope, and returns a structured result dict. It covers key aspects like success status and message, though it could add more on permissions, file overwriting, or error handling.

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

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

The description is well-structured with clear sections (purpose, supported formats, scope, args, returns, examples) and front-loaded key information. It is appropriately sized but could be slightly more concise by integrating some details (e.g., format list in args) more tightly.

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

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

Given the complexity (export tool with format and scope options), no annotations, and no output schema, the description is largely complete. It covers purpose, parameters, returns, and examples. However, it could improve by mentioning potential side effects (e.g., file system changes) or integration with sibling tools like 'import_file' for a fuller context.

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 description coverage is 0%, so the description must fully compensate. It does so excellently: it explains both parameters ('file_path' and 'selected_only') in detail, including format support, default values, and usage examples. This adds significant meaning beyond the bare schema, fully documenting the parameters.

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

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

The description clearly states the tool's purpose with specific verbs ('从 3ds Max 导出场景或选中的对象到文件') and distinguishes it from siblings by focusing on export functionality. It specifies the resource (scenes or selected objects from 3ds Max) and the action (export to file), making it immediately distinguishable from import, creation, or manipulation tools in the sibling list.

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

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

The description provides clear context for when to use this tool (exporting from 3ds Max) and mentions supported formats and scope options (all objects vs. selected only). However, it does not explicitly state when NOT to use it or name alternatives (e.g., compared to 'import_file' or 'save_scene'), which prevents a perfect score.

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 the full burden. It describes the tool as a read operation that returns environment information, which is clear but lacks details on behavioral traits such as error handling, performance implications, or whether it requires specific permissions or connectivity. The description adds basic context about what information is returned but does not fully compensate for the absence of annotations.

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

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

The description is appropriately sized and front-loaded, starting with the core purpose in the first sentence. The subsequent sentences add necessary details about return values and an example call, with minimal redundancy. However, the inclusion of a detailed 'Returns' section in the description (which could be moved to an output schema) slightly reduces efficiency, though it remains well-structured.

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

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

Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is reasonably complete. It explains the purpose, return values, and provides an example. However, it lacks information on error cases or behavioral nuances, which would enhance completeness for a tool in a 3D modeling context where environment checks might fail.

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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description correctly indicates no parameters by showing an example call 'get_max_version()' without arguments. It adds no semantic details beyond the schema, but since there are no parameters, a baseline score of 4 is appropriate as it adequately addresses the parameter context.

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

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

The description clearly states the specific verb ('获取' meaning 'get') and resource ('3ds Max 的版本信息和环境信息' meaning '3ds Max version and environment information'), distinguishing it from siblings that perform operations like creating objects, executing scripts, or modifying scene elements. It explicitly identifies what information is retrieved (version number, build info, Python version).

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 by stating it 'helps understand the runtime environment,' suggesting it should be used when environment details are needed. However, it does not explicitly state when to use this tool versus alternatives (e.g., get_scene_info for scene-specific data) or provide any exclusions or prerequisites, leaving guidance somewhat vague.

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 clearly describes the read-only nature (获取/returns information) and specifies the comprehensive data returned. However, it doesn't mention potential limitations (e.g., what happens if the object doesn't exist, performance considerations, or whether it works on all object types). The description adds value but lacks some 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 well-structured with a clear purpose statement, detailed returns section, and example calls. Every sentence adds value. It could be slightly more concise by integrating the example calls more tightly, but overall it's efficient and front-loaded with the core purpose.

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

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

Given the complexity of returning detailed 3D object properties with no output schema, the description provides exceptional completeness. It thoroughly documents the return structure including transform data, geometric properties, modifiers, materials, and state flags. This fully compensates for the lack of output schema and makes the tool's behavior completely understandable.

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 description adds significant meaning beyond the input schema. The schema only shows 'object_name' as a string parameter with 0% description coverage. The description explains that this is '目标物体的名称（场景中已存在的对象）' (the name of the target object, which must already exist in the scene), providing crucial context about the parameter's purpose and constraints.

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

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

The description clearly states the tool's purpose: '获取 3ds Max 场景中指定物体的详细属性信息' (Get detailed property information for a specified object in a 3ds Max scene). It specifies the exact resource (object in 3ds Max scene) and verb (get properties), and distinguishes itself from siblings like get_scene_info (scene-level) and get_scene_objects (list of objects).

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

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

The description provides clear context: it's for retrieving detailed properties of a specific object in a 3ds Max scene. It implies when to use it (to understand an object's current state) and distinguishes from siblings like get_scene_objects (which lists objects) and set_object_property (which modifies properties). However, it doesn't explicitly state when NOT to use it or name specific alternatives.

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

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

No annotations are provided, so the description carries the full burden. It describes the tool as returning comprehensive scene information, which implies a read-only operation without side effects, but does not explicitly state this. It also lacks details on error conditions, performance implications, or authentication needs. The description adds some context about what information is included but misses behavioral traits like whether it requires a loaded scene or works on unsaved files.

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 appropriately sized and front-loaded, starting with the purpose and key details. The detailed return structure is necessary for clarity but could be more concise. The example call at the end is helpful but slightly redundant. Overall, most sentences earn their place, though minor trimming is possible.

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

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

Given the tool's complexity (providing comprehensive scene data) and lack of annotations or output schema, the description does a good job of explaining what information is returned. It details the return structure extensively, covering file details, object counts, time range, and units. However, it could improve by mentioning behavioral aspects like error handling or prerequisites, but it's largely complete for a read-only informational tool.

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

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

The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description does not need to add parameter semantics, as there are none to document. It correctly omits parameter details, earning a high baseline score for not introducing unnecessary information.

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

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

The description clearly states the tool's purpose: '获取当前 3ds Max 场景的综合信息' (Get comprehensive information about the current 3ds Max scene). It specifies the verb '获取' (get) and the resource '场景的综合信息' (comprehensive scene information), distinguishing it from siblings like get_scene_objects (which lists objects) or get_object_properties (which focuses on specific objects).

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 by stating it '帮助 AI 了解场景的整体状态' (helps AI understand the overall state of the scene), suggesting it should be used for general scene assessment. However, it does not explicitly state when to use this tool versus alternatives like get_scene_objects or get_object_properties, nor does it provide exclusions or prerequisites for its use.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns object information (name, type, position, hidden status, etc.) and supports filtering, which is good basic behavioral context. However, it doesn't mention potential limitations like performance with large scenes, whether it requires specific scene states, or error conditions. For a read-only tool with no annotations, this is adequate but not comprehensive.

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

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

The description is well-structured with clear sections: purpose, filtering capabilities, parameter details, return format, and examples. It's appropriately sized for a tool with two parameters and complex filtering options. Some redundancy exists (e.g., repeating filtering examples), but overall it's efficient and front-loaded with the core purpose.

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

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

Given the tool's complexity (filtering by type/name), no annotations, and no output schema, the description does a good job of completeness. It explains the purpose, parameters, return format (including all fields in the objects list), and provides multiple examples. The main gap is lack of explicit behavioral warnings or prerequisites, but for a read operation, this is reasonably complete.

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

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

With 0% schema description coverage (schema only has titles 'Object Type' and 'Name Filter' with no descriptions), the description fully compensates by providing detailed semantics for both parameters. It explains object_type can be empty (all objects), superclass names (e.g., 'Geometry'), or specific class names (e.g., 'Box'), with examples. It explains name_filter supports wildcards like '*' and provides usage examples. This adds significant value beyond the bare schema.

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

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

The description clearly states the tool's purpose: '获取当前 3ds Max 场景中的所有对象信息' (get all object information in the current 3ds Max scene). It specifies the verb '获取' (get/retrieve) and the resource '场景中的所有对象信息' (all object information in the scene), distinguishing it from siblings like get_object_properties (which gets properties of specific objects) and get_scene_info (which gets general scene information).

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

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

The description provides clear context for when to use this tool: to list all objects or filter by type/name. It includes examples of different filtering scenarios. However, it doesn't explicitly state when NOT to use it or compare it to alternatives like get_object_properties (for detailed properties of specific objects) or select_objects (for selection rather than information retrieval).

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 full burden. It discloses that imported objects are added to the current scene (behavioral trait) and mentions supported formats, but doesn't address potential limitations like file size constraints, permission requirements, error handling, or whether the operation modifies existing scene data. It provides basic behavioral information but lacks depth for a mutation tool.

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 appropriately sized but not optimally structured. The core purpose is front-loaded, but the format listing could be more concise. The inclusion of both 'Args' and 'Returns' sections (which aren't standard MCP description elements) adds redundancy. Every sentence earns its place, but the organization could be cleaner.

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

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

For a mutation tool with no annotations and no output schema, the description provides adequate basic information but lacks completeness. It covers the what and how of importing, but doesn't address error scenarios, performance implications, or integration with sibling tools. The return format documentation helps, but more behavioral context would be beneficial given the tool's complexity.

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

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

With 0% schema description coverage and only one parameter, the description compensates well by explaining what 'file_path' represents ('complete path of the file to import') and listing supported format extensions. It adds meaningful context beyond the bare schema, though it doesn't specify path format requirements or validation rules.

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 specific action ('import external files') and resource ('in 3ds Max'), distinguishing it from sibling tools like 'export_file', 'open_scene', or 'new_scene'. It specifies that imported objects are added to the current scene, which is a precise scope definition.

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

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

The description provides clear context about when to use this tool (to import various 3D file formats into 3ds Max) and lists supported formats, but doesn't explicitly state when NOT to use it or mention alternatives like 'open_scene' for different file operations. The context is well-defined but lacks explicit exclusions.

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

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

With no annotations provided, the description carries the full burden and does so well. It discloses key behavioral traits: it clears the current scene, creates a new empty one, and explains the 'force' parameter's impact on saving changes. It also mentions the return structure (success and message), though no output schema exists. No contradictions with annotations.

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

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

The description is well-structured and appropriately sized, with a clear purpose statement, parameter details, return information, and examples. Every sentence adds value, though it could be slightly more concise by integrating the examples more tightly. It is front-loaded with the core functionality.

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

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

Given the tool's complexity (a destructive operation with one parameter) and lack of annotations and output schema, the description is quite complete. It covers purpose, behavior, parameters, and returns. However, it could benefit from mentioning potential errors or edge cases, such as what happens if saving fails in non-force mode.

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 0%, so the description must compensate fully. It does so by thoroughly explaining the single parameter 'force': its purpose (whether to force creation without saving), default value ('true'), and the effect of both 'true' and 'false' values. This adds significant meaning beyond the bare schema.

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

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

The description clearly states the specific action ('新建/重置场景' - create/reset scene) and resource ('在 3ds Max 中' - in 3ds Max), distinguishing it from siblings like 'open_scene' or 'save_scene'. It explicitly mentions clearing the current scene and creating a new empty one, providing precise functionality.

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

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

The description provides clear context on when to use this tool (to start fresh or reset a scene) and includes examples for different scenarios (force vs. non-force). However, it does not explicitly state when NOT to use it or compare it to alternatives like 'open_scene' for loading existing files.

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 full burden and does well. It discloses that the tool may prompt to save the current scene (unless force=true), which is important behavioral context for a file-opening operation. It also describes the return format (dict with success, file_path, message). However, it doesn't mention potential errors, performance implications, or authentication requirements.

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 appropriately sized and front-loaded with the core purpose first. The parameter explanations and examples are useful but slightly verbose (could be more concise). Every sentence earns its place by adding necessary information, though the structure could be tighter.

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

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

For a 2-parameter tool with no annotations and no output schema, the description provides good completeness. It covers purpose, parameters with semantics, return format, and examples. However, it lacks information about error conditions, file format compatibility, or what happens if the file doesn't exist, which would make it fully comprehensive.

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

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

With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains that 'file_path' must be a complete path to a .max file with an example, and 'force' controls whether to save current changes with clear true/false meanings and default behavior. This adds substantial value beyond the bare schema.

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

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

The description clearly states the specific action ('打开一个场景文件' - open a scene file) and resource ('.max 场景文件' - .max scene file) in 3ds Max. It distinguishes itself from siblings like 'new_scene' (creates new), 'save_scene' (saves current), and 'import_file' (imports assets rather than opening full scenes). The purpose is unambiguous and well-defined.

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

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

The description provides clear context about when to use this tool (to load .max scene files) and implicitly distinguishes it from 'new_scene' (for creating empty scenes) and 'import_file' (for importing assets). However, it doesn't explicitly state when NOT to use it or name specific alternatives, which prevents a perfect score.

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 full burden for behavioral disclosure. It states this is a rename operation but doesn't mention whether this requires specific permissions, what happens if the new name conflicts with existing objects, whether the operation is reversible, or any rate limits. The return format is documented, but behavioral aspects like error conditions or side effects are missing.

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

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

The description is well-structured with purpose statement, parameter explanations, return format, and example. Every section adds value. It could be slightly more concise by integrating the example more tightly, but overall it's efficiently organized with no redundant 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?

For a mutation tool with no annotations and no output schema, the description does an adequate job explaining the basic operation and return format. However, it lacks important context about error conditions, naming constraints, and how this interacts with other scene operations. The example helps, but more behavioral context would be needed for robust usage.

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

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

With 0% schema description coverage, the description fully compensates by clearly explaining both parameters: 'object_name' as the current name of an existing object, and 'new_name' as the desired new name. The example call further clarifies usage. This provides complete semantic understanding beyond the bare schema.

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

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

The description clearly states the specific action ('重命名' - rename) and target resource ('3ds Max 场景中的指定物体' - specified object in 3ds Max scene). It distinguishes from siblings like 'clone_object' or 'delete_object' by focusing specifically on renaming existing objects rather than creating, modifying properties, or deleting them.

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

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

The description provides no guidance on when to use this tool versus alternatives. While it mentions the object must exist in the scene, it doesn't explain when renaming is appropriate versus using other object manipulation tools like 'set_object_property' or 'clone_object' with renaming. No exclusions or prerequisites are mentioned beyond the object existence.

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 of behavioral disclosure. It effectively describes the tool's behavior: it can save or save-as, requires .max extension for save-as, and explains failure conditions for overwrite saving. However, it doesn't mention permissions, rate limits, or other system constraints that might be relevant.

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

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

The description is well-structured with clear sections (purpose, args, returns, examples) and every sentence adds value. It could be slightly more concise by integrating the examples more tightly, but overall it's efficiently organized and front-loaded with the core functionality.

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

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

Given the tool's complexity (file operations with conditional behavior), no annotations, and no output schema, the description does an excellent job explaining both input parameters and return values. It fully documents the parameter semantics and return structure. The only minor gap is lack of information about error conditions beyond the mentioned failure case.

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 has 0% description coverage for its single parameter, so the description must fully compensate. It provides comprehensive semantic information about the file_path parameter: its dual functionality (empty string for overwrite vs. specified path for save-as), format requirements (.max extension), and concrete examples. This adds significant value beyond the bare schema.

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

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

The description clearly states the tool's purpose with specific verbs ('保存当前 3ds Max 场景文件' - save current 3ds Max scene file) and distinguishes it from siblings like 'new_scene', 'open_scene', 'export_file', and 'import_file'. It explicitly describes saving to a file, differentiating from other scene manipulation tools.

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

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

The description provides explicit guidance on when to use this tool versus alternatives: it explains both overwrite saving (when file_path is empty) and save-as functionality (when file_path is specified). It also mentions the prerequisite that overwrite saving requires the scene to have been previously saved, giving clear usage conditions.

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

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

With no annotations provided, the description carries the full burden. It effectively discloses behavioral traits: it explains the selection modes (replace, add, deselect), clarifies that some actions ignore parameters (e.g., 'clear' ignores object_name), and describes the return format. It lacks details on permissions or rate limits, but covers core behavior well.

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

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

The description is appropriately sized and front-loaded with the purpose, followed by detailed parameter explanations and examples. While comprehensive, some sections (like the full Returns dict) could be slightly condensed, but every sentence adds value for tool invocation.

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

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

Given the complexity (3 parameters, no annotations, no output schema), the description is complete. It covers purpose, usage, parameters, return values, and examples. It fully compensates for the lack of structured data, ensuring the agent can correctly invoke the tool without gaps.

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

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

The schema description coverage is 0%, so the description must fully compensate. It adds extensive meaning beyond the schema: it details object_name formats (exact, wildcard, multiple), object_type examples, and action options with clear semantics. This fully documents all three parameters, making it highly valuable.

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

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

The description clearly states the tool's purpose: '在 3ds Max 场景中选择或取消选择对象' (select or deselect objects in a 3ds Max scene). It specifies the exact action (select/deselect) and resource (objects), and distinguishes itself from siblings like get_scene_objects (which only retrieves) or delete_object (which removes).

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

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

The description provides clear context on when to use this tool (e.g., selecting by name, type, or clearing selections) and includes examples. However, it does not explicitly mention when not to use it or name alternatives among siblings, such as get_scene_objects for listing without selection.

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 of behavioral disclosure. It explains what the tool does (sets keyframes for animation) and provides multiple usage examples, but doesn't mention error conditions, permission requirements, or what happens when multiple properties are set simultaneously. The description doesn't contradict any annotations since none exist.

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

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

The description is well-structured with clear sections: purpose statement, parameter explanations, return format, and multiple usage examples. While comprehensive, it could be slightly more concise as some information in the examples is somewhat repetitive. Every sentence adds value, particularly the examples which demonstrate different usage patterns.

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 7-parameter mutation tool with no annotations and no output schema, the description does an excellent job of explaining what the tool does, how to use it, and what to expect. The inclusion of return format details and multiple concrete examples provides substantial context. The main gap is lack of explicit error handling or edge case 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?

With 0% schema description coverage, the description fully compensates by providing detailed parameter explanations in the Args section. Each of the 7 parameters is clearly explained with format examples (e.g., 'x,y,z' format for position, frame numbers as strings), default behaviors (留空表示不设置 - leave empty means don't set), and relationships between parameters (property_name与property_value配合使用 - property_name used together with property_value).

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

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

The description clearly states the specific action ('设置关键帧' - set keyframe) on specific resources ('指定物体的属性' - specified object's properties) in a specific context ('在 3ds Max 中' - in 3ds Max). It distinguishes from siblings like set_object_transform (which sets transform without keyframing) and set_object_property (which sets properties without keyframing).

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

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

The description provides clear context about when to use this tool - for setting keyframes on object properties in 3ds Max animation workflows. It mentions specific use cases (transform properties vs custom properties) but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the distinction is implied through the tool's specific functionality.

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 full burden and does well by disclosing key behaviors: it supports wildcard '*' for batch operations, returns a structured dict with success status and modified objects list, and specifies value formats for different property types (numeric, boolean, color). It doesn't mention error handling or permission requirements, but covers essential operational traits.

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 appropriately sized but not optimally structured: it front-loads the purpose, but includes extensive examples and parameter details mixed together. While all content is valuable, it could be more streamlined with clearer separation between conceptual explanation and implementation details.

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

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

For a mutation tool with no annotations and no output schema, the description provides complete context: it explains what the tool does, how to use parameters, common property examples, return format details, and multiple usage scenarios. This compensates fully for the lack of structured metadata.

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?

Given 0% schema description coverage, the description fully compensates by explaining all three parameters in detail: 'object_name' supports wildcards for batch setting, 'property_name' includes common examples with specific usage notes (e.g., 'wirecolor' for color), and 'property_value' provides format rules for different data types. It adds substantial meaning beyond the bare schema.

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

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

The description clearly states the specific action ('设置' meaning 'set'), the target resource ('3ds Max 场景中指定物体的属性值' meaning 'property values of specified objects in 3ds Max scene'), and distinguishes from siblings like 'get_object_properties' (read vs write) and 'set_object_transform' (properties vs transform). It provides a precise verb+resource combination.

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 context through examples and property lists (e.g., setting display properties like wirecolor or creation parameters like radius). However, it doesn't explicitly state when to use this tool versus alternatives like 'set_object_transform' for position/rotation or 'assign_material' for material assignment, leaving some ambiguity about property scope boundaries.

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 full burden. It effectively discloses key behavioral traits: it's a mutation tool (sets properties), works on existing objects only (requires 'object_name' of existing object), supports both absolute and relative modes, allows partial updates (empty strings skip changes), and describes the return format. It doesn't mention error conditions, permissions, or rate limits, but covers core behavior well.

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

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

Well-structured with clear sections: purpose statement, parameter explanations, return format, and multiple usage examples. Every sentence adds value. Could be slightly more concise in the examples section (some redundancy), but overall efficiently communicates necessary information.

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

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

For a mutation tool with 5 parameters, 0% schema coverage, and no output schema, the description does an excellent job. It explains parameters thoroughly, describes the return structure, and provides multiple usage examples. The main gap is lack of error handling information, but given the comprehensive parameter coverage and return format description, it's highly complete.

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

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

Schema description coverage is 0%, so the description must fully compensate. It provides excellent parameter semantics: explains each parameter's purpose, format examples, default behaviors (empty strings skip changes), and special cases (single value for uniform scaling). The 'relative' parameter is clearly explained with its default value. This goes far beyond what the bare schema provides.

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

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

The description clearly states the tool 'sets transform properties (position/rotation/scale) for specified objects in a 3ds Max scene.' It specifies the exact action (set), resource (object transform properties), and context (3ds Max scene), distinguishing it from siblings like set_object_property (which sets general properties) or set_keyframe (which sets animation keyframes).

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

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

The description provides clear context for when to use this tool: to modify position, rotation, or scale of existing objects. It mentions support for absolute and relative modes, and that multiple properties can be set simultaneously. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings (e.g., set_object_property for other properties).

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 of behavioral disclosure. It explains that all parameters are optional and only modified if specified, which is helpful. However, it lacks details on permissions, error handling, or side effects (e.g., whether changes affect existing animations). The return format is described but without output schema, leaving some ambiguity.

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

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

The description is well-structured with clear sections (purpose, parameter details, returns, examples) and front-loaded key information. It is appropriately sized, though the examples could be slightly more concise. Every sentence adds value without redundancy.

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

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

Given the complexity (4 parameters, no annotations, no output schema), the description is largely complete. It covers purpose, parameters, returns, and usage examples. However, it could improve by addressing potential errors or constraints (e.g., valid frame ranges). The lack of output schema is mitigated by describing the return dict.

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 description coverage is 0%, so the description must compensate fully. It does so by clearly explaining each parameter's purpose (e.g., start_frame as animation start frame), optional nature, and practical examples (e.g., fps common values like '24' for film). This adds significant meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose with specific verbs ('设置' meaning 'set') and resources ('时间/帧范围参数' meaning 'time/frame range parameters'), distinguishing it from sibling tools like set_keyframe or set_object_property by focusing on animation timing parameters rather than keyframes or object properties.

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

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

The description provides clear context for when to use this tool (to set animation frame ranges, current frame position, and frame rate) and includes practical examples. However, it does not explicitly state when not to use it or mention alternatives among sibling tools, such as set_keyframe for animation keyframes.

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