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

No annotations are provided, so the description carries the full transparency burden. It uses 'gets' and 'retrieves' implying a read-only operation, which is appropriate for a help tool. It does not mention side effects (none expected) or error handling, but for a simple lookup tool this is adequate.

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

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

The description is concise: two sentences for purpose/usage, followed by a clean Arg block. The main purpose is front-loaded in the first sentence, and every sentence adds value. No unnecessary words or repetition.

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

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

For a tool with one required parameter and no output schema, the description covers all necessary context: what it does, when to use it, why it's needed, and parameter semantics with examples. It is fully self-contained for an agent to invoke correctly.

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

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

The schema has 0% description coverage, but the description explicitly defines 'name' as the command name and gives three concrete examples ('polyBevel', 'skinCluster', 'polyProjection'). This fully compensates for the missing schema description and provides clear meaning beyond the parameter name.

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 'maya.cmds 명령 하나의 플래그 목록과 시그니처를 가져옵니다' (gets the flag list and signature of a single maya.cmds command). This specifies a clear verb and resource, and distinguishes from siblings by limiting to a single command (contrasting with search/execute 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 explicitly says to call it before writing code when flag names or argument formats are uncertain, and gives a reason (Maya versions differ, memory is unreliable). It provides clear when-to-use context, but does not mention alternatives or when-not-to-use, so it falls short of a 5.

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

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

Without annotations, the description carries the full burden and discloses key runtime behaviors: which API namespaces are available (cmds, mel, om), return value conventions, stdout/error capture, and undo chunk semantics. It does not explicitly warn about the potential destructive side effects of arbitrary code execution, but the '임의의 Python 코드' statement makes the power and risk inherently clear.

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 lead sentence, usage guidance, a clear list of available names, and a concise return-contract section. Every sentence adds unique value—no filler or repetition of schema fields—and the content is 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?

For a powerful code-execution tool with no annotations and no output schema, the description is remarkably complete. It explains how to invoke, what parameters mean, how return values and errors are delivered, and when to prefer this tool over dedicated ones. This gives an agent everything needed to use and recover from failures.

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 entirely. It thoroughly explains both parameters: 'code' is the Python code to execute, and 'undo_chunk' is described with its default behavior and user-facing undo impact (Ctrl+Z). It also adds valuable return-format semantics tied to the code input.

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 executes arbitrary Python code inside Maya ('Maya 안에서 임의의 Python 코드를 실행합니다') and positions it as the general-purpose gateway for operations lacking dedicated tools. This distinguishes it from specialized sibling tools like maya_scene_info or maya_unreal_export_fbx by explicitly naming unsupported task categories (rigging, UV, deformers, etc.).

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

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

The description explicitly says to use this tool for tasks without dedicated tools ('전용 툴이 없는 작업...은 전부 이 툴로 하세요'), implying use dedicated tools when available. It also provides batching guidance, stating that combining multiple tasks in one call is faster and cheaper than separate calls, and instructs the agent to read errors and retry on failure.

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 the tool's behavior of checking liveness/version, and adds valuable context that if undo_enabled is false, there is no undo safety net. However, it doesn't explicitly confirm the tool is non-destructive or describe the full return format.

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

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

The description is two short sentences, front-loaded with the main purpose, followed by usage guidance and a key behavioral note. Every sentence earns its place; there is 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?

Given the tool's simplicity (no parameters, no output schema), the description is complete. It covers purpose, usage context, and a critical safety behavior (undo_enabled), which is sufficient for an agent to decide when to invoke it.

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

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

There are no parameters, so parameter semantics are inherently satisfied. The description doesn't need to explain any input fields; the baseline for zero parameters applies.

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

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

The description clearly states the tool checks whether the Maya bridge is alive and its version, using a specific verb ('확인합니다') and resource (Maya bridge). This distinguishes it from sibling tools like maya_execute or maya_scene_info.

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

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

It explicitly says to use this tool when other tools give connection errors, to narrow down the cause. This provides clear usage context, but it doesn't mention exclusions or alternatives explicitly.

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 behavioral burden. It discloses that the tool returns summary info including unit system, up axis, frame range, selection state, and node counts, and it warns about coordinate misplacement if units/up axis are unknown. This adds meaningful behavioral context beyond a simple 'get info' statement, though it does not explicitly confirm non-destructive behavior (which is strongly implied).

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

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

The description is two compact sentences: the first states the tool's action, the second provides usage guidance and justification. Every sentence earns its place, with no redundancy or unnecessary detail.

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

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

For a zero-parameter info tool, the description is fully complete. It enumerates the returned information (units, up axis, frame range, selection, node counts) and explains the practical use case. Since there is no output schema, the description adequately covers return value semantics.

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

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

The tool has zero parameters, so the schema provides complete coverage (100%). The description doesn't need to explain parameters; the baseline score of 4 applies since there is nothing to clarify.

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

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

The description clearly states the tool's function: '현재 씬의 요약 정보를 가져옵니다' (gets summary info of the current scene), specifying both the action and the resource. It also lists the specific information provided (units, up axis, frame range, selection state, node counts), making it distinct from sibling tools like maya_execute or maya_viewport_capture.

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

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

The description gives explicit when-to-use guidance: '작업을 시작하기 전에 한 번 호출해서... 파악하세요' (call once before starting work to understand the scene). It also explains why this is important—knowing units and up axis prevents placing objects in wrong coordinates—which serves as a clear rationale for using this tool first.

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

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

No annotations are provided, so the description must convey behavioral traits. It discloses case-insensitive partial matching and that an empty pattern returns the full list. It does not mention the return format, explicitly confirm it is read-only, or discuss any side effects, leaving room for more transparency.

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

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

The description is concise and front-loaded with purpose, followed by a usage tip and useful examples. The Args section is clear and each sentence contributes value without redundancy.

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

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

For a simple search tool, it covers purpose, usage, and parameters adequately. It lacks an explicit statement about return value format, but given the tool's simplicity and the presence of examples, this is a minor gap.

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

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

The schema has 0% description coverage, but the description fully explains both parameters: pattern is a partial match (case insensitive, empty = all) and limit is the maximum number to return. This completely compensates for the schema's lack of detail.

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 'Finds maya.cmds commands that contain a specific string in the name,' which specifies the verb, resource, and scope. It also differentiates from siblings by advising to call this when unsure of the command name, implicitly contrasting with maya_command_help.

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?

Explicit guidance is given: 'When you are not sure of the command name, don't guess and call this first.' It also explains behavior with empty pattern (full list). However, it does not explicitly name alternatives or state when not to use, so it falls short of a 5.

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

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

With no annotations, the description reveals that maya_execute calls are grouped into a single undo step, so steps=1 reverts the last call entirely. It also constrains steps to 1-50, but doesn't mention side effects like redo history clearing or behavior for non-maya_execute edits.

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

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

Three compact sentences plus an Args line cover everything with zero filler. The main action leads, followed by usage context and parameter meaning.

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

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

For a one-parameter undo tool with no output schema, the description provides purpose, usage guidelines, grouping behavior, and parameter meaning—complete and self-contained.

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

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

The schema provides no description for steps, but the description defines it as '되돌릴 단계 수' (number of steps to revert) and lists the valid range 1-50, fully compensating for the schema gap.

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?

Description opens with '직전 작업을 되돌립니다' (reverts the previous operation), a clear verb+resource statement. It explicitly ties to maya_execute, distinguishing it from the many sibling Maya tools.

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

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

It states 'maya_execute 로 한 작업이 잘못됐을 때 호출하세요' (call when a maya_execute operation goes wrong), providing explicit when-to-use context. It also explains how steps map to undo groups, giving practical guidance beyond the schema.

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

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

With no annotations, the description carries the full burden. It explicitly states '씬을 전혀 바꾸지 않습니다' (does not change the scene at all) and enumerates the checks performed, giving confidence it is non-destructive. It does not describe the output/report format, but the most important behavioral trait (safety) is clearly disclosed.

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

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

The description is well-structured: purpose first, then usage timing, then the list of check items, then parameter details. Every sentence adds meaningful information; the list of check items is the tool's core value and not superfluous. It is concise despite being informative.

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 simple 2-parameter tool with no annotations and no output schema, the description covers purpose, usage timing, parameter semantics, and non-destructive behavior. The only notable omission is the return value/result format, but for a preflight audit tool this is a minor gap; the description is still largely 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?

The schema has 0% description coverage, so the description must fully compensate. It does: objects is explained with wildcard support and fallback behavior (selection → all meshes), and prefix is described with concrete examples ('SM_', 'SK_'). This is excellent parameter documentation.

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

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

The description states '언리얼 익스포트 전 지오메트리 문제를 감사합니다' (audits geometry issues before Unreal export) and explicitly says it does not change the scene. It lists specific check items, distinguishing it as a read-only audit tool among siblings like maya_unreal_check_skeleton and maya_unreal_check_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?

Provides explicit timing instruction: '정리나 익스포트를 하기 전에 항상 먼저 호출하세요' (always call first before cleanup or export). This clearly communicates when to use the tool, but it does not explicitly mention when not to use it or name alternatives, so it falls short of a 5.

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

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

The description discloses that it does not change the scene, which is a key behavioral trait. It also enumerates what it checks. Since no annotations are provided, this is helpful, though it does not describe return values or side effects beyond being read-only.

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?

Structured with a lead statement, rationale, check list, and parameter descriptions. Efficient for the information conveyed, 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?

The description covers purpose, parameters, and safety but omits what the tool returns or how results are presented. Without an output schema, the agent doesn't know what to expect from the invocation, leaving a gap in completeness.

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

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

The description explains both parameters: 'objects' defaults to selection then all meshes if empty, and 'prefix' is the expected material prefix with Unreal convention 'M_'. This fully compensates for the 0% schema coverage.

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

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

The description clearly states it audits material slots and lists specific check items (slot count, default material, naming, face assignment, unused shading groups). The verb '감사합니다' (audit) plus '머티리얼 슬롯' (material slots) is specific and distinguishes from sibling tools like skeleton checks.

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?

States it is worth checking before export due to draw call impact, providing clear when-to-use context. However, it does not explicitly mention alternatives or when not to use, so it lacks exclusion 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 fully discloses that the tool is non-destructive, explains why auto-fixing is dangerous (skin weight breakage), and directs the agent to avoid modifications until instructed. This goes well beyond basic annotations and gives clear 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: main function, non-modification behavior, rationale, inspection list, and parameter explanations. Every sentence adds value—no fluff or redundancy. The use of bold and bullet-like list improves scannability.

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

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

The description covers purpose, parameters, behavioral constraints, and inspection items comprehensively. The main gap is the lack of detail on the output/report format; it mentions 'reported issues' but doesn't specify the exact structure or response type. This is minor given no output schema exists, but slightly reduces completeness.

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

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

Schema coverage is 0%, but the description thoroughly explains each parameter: root (with behavior when empty), primary_axis (with convention guidance), and tolerance_deg (with threshold semantics). This fully compensates for the schema's lack of descriptions.

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

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

The description clearly states the tool's function: auditing joint orientation and Unreal skeleton compatibility. The verb 'audits' is specific and the resource is detailed, distinguishing it from sibling tools like maya_unreal_check_materials or maya_unreal_prepare.

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

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

The description provides strong behavioral guidance: it does not change the scene, does not auto-fix, and instructs to pass issues to the user without taking action. However, it does not explicitly name alternative tools or say when to choose this over siblings, so it falls short of full explicit 'when-to-use' 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 details key behaviors: deleting only shading groups with no members, skipping referenced materials during rename, and supporting dry_run mode to report actions without making changes. It also warns about the need for human judgment in material selection, though it could further emphasize the destructive nature of delete_unused.

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 concise summary, a prominent warning, and a clean Args section. Every sentence adds value: the warning clarifies non-merge behavior, and the parameter list is efficient and readable. No fluff or repetition.

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

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

For a tool with 4 parameters, no output schema, and no annotations, the description covers all essential aspects: purpose, usage boundaries, parameter semantics, and safety behavior. The dry_run explanation implies an output report, which is sufficient for general use. The caution about human decision-making provides important context for AI agents.

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 clear explanations for all four parameters: prefix, rename, delete_unused, and dry_run, including the default behavior and special cases (e.g., referenced materials are skipped). This is comprehensive and adds 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: performing safe material cleanup by deleting unused shading groups and prefix renaming. It distinguishes itself from sibling tools by explicitly stating it does not merge materials and emphasizes safety, which separates it from more aggressive cleanup or audit 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 context on when to use the tool: for safe cleanup only, and explicitly advises against using it when slot reduction requires merging materials, directing the user to show audit results instead. It does not name specific alternative sibling tools but gives clear usage 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 the burden and does well: it discloses export settings (smoothing groups, tangents), exclusions (subdivision results, unnecessary upstream connections, cameras, lights), and fallback behavior for the objects parameter (selection → all meshes). It could mention overwrite behavior or return values, but overall it is informative.

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

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

The description is efficiently structured: a one-sentence summary, a concise behavioral note, a prerequisite, and a clean Args list. Each parameter explanation earns its place, with no fluff despite the large number of parameters.

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 7 parameters, no annotations, and no output schema, this description is remarkably complete. It covers all parameters, prerequisite steps, export behavior, and parameter-specific advice, making it fully actionable for an agent without needing additional 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?

Schema coverage is 0%, so the description fully compensates by explaining all 7 parameters in detail: path with example, objects fallback logic, triangulate rationale, skins when needed, blendshapes, animation, and up_axis options with Unreal conversion 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 exports FBX with Unreal-specific settings, listing exactly what is enabled (smoothing groups, tangents) and excluded (subdivision results, cameras, lights). This distinguishes it from siblings like maya_unreal_import_fbx and maya_unreal_prepare.

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

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

Explicitly instructs to run maya_unreal_prepare before exporting, establishing a clear prerequisite. Parameter guidance (e.g., leave triangulate False for quads, enable skins for skeletal meshes) provides practical usage context, though it does not explicitly mention alternatives beyond the prerequisite.

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

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

The description warns about potential axis/scale issues that can produce rotated or scaled meshes and advises verifying via viewport capture. It also highlights reading `warnings` from the return value. Despite lacking annotations, it does not explicitly state that the import permanently modifies the scene or is undoable, but the parameter explanations for merge modes imply side effects.

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 an intro, scope note, and a parameter list. No redundant sentences; each part serves a 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 (6 parameters, no annotations, no output schema), the description covers purpose, limitations, usage steps, and all parameter semantics. It could also mention error conditions or prerequisites, but it is largely complete for an import 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 schema has no parameter descriptions, so the description fully compensates by explaining each parameter: path, namespace, group, up_axis, scale_factor, and import_mode with its options. It adds practical guidance such as retrying with 'z' if the result is rotated and using namespace when names conflict.

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 'Imports FBX into current Maya scene' and identifies this as the path for receiving Unreal level assets. It also explicitly excludes exporting from Unreal, distinguishing it from the sibling maya_unreal_export_fbx.

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

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

It provides context that this tool is for importing manually exported FBX files and notes that Unreal-side export is out of scope. It instructs to verify results with maya_viewport_capture and read warnings, giving practical usage guidance. However, it does not explicitly name alternative tools for related tasks.

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, so description carries the burden. It discloses the dry_run behavior, the convex hull limitation in Maya 2022, and the export requirement. However, it does not explicitly say whether existing collision meshes are overwritten or if the operation is reversible, which would add more transparency.

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: a one-sentence purpose statement, a critical export note, then a clear Args list. Each piece of information is useful and non-redundant, despite being longer than two sentences.

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 has 5 parameters, no annotations, and no output schema, the description is remarkably complete. It covers purpose, usage, parameter semantics, and a critical workflow integration point (FBX export). The only minor omission is the return value for non-dry-run, but the dry_run description implies it.

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

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

Schema coverage is 0%, but the description explains every parameter in detail: objects (with fallback selection logic), shape (with each option explained), padding, reduce_to, and dry_run. This fully compensates for the lack of schema descriptions.

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

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

The description states the tool creates collision meshes following Unreal rules, with specific prefix naming (UBX_/USP_/UCP_/UCX_). This clearly distinguishes it from sibling tools like maya_unreal_make_lods and maya_unreal_export_fbx.

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

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

Explicitly tells users to include the collision meshes in the same FBX export via maya_unreal_export_fbx, and for convex shapes recommends using Unreal's Auto Convex Collision instead. This is clear when-to-use and 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.

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

Since no annotations are provided, the description carries the full transparency burden. It discloses the original mesh is not reduced, dry_run avoids scene changes, default percentages are [50,25,12], and it warns that silhouette breakage can occur even with normal metrics. It also explains consequences of disabling keep_borders, keep_hard_edges, and keep_uv_borders, which is thorough and beyond mere operation.

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

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

The description is well-structured: a concise intro, three high-value warning sentences about visual verification and reduction policy, and a bulleted Args list. Every sentence earns its place, and the length is justified for a tool with seven parameters and important workflow caveats. It is 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 no output schema and no annotations, the description covers the tool's purpose, all parameters with defaults and implications, and the necessary post-action verification. It also explains how lod_group integrates with the Unreal FBX importer, and dry_run's non-destructive behavior. The description is complete enough for an agent to select and invoke correctly without guessing.

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 zero schema description coverage, the description fully compensates by defining all seven parameters in the Args section. Each parameter gets a clear explanation: objects (targeting logic), keep_percent (ratio, default, example), lod_group (creation and Unreal import), and the three keep_* flags (what happens when off), plus dry_run. This adds substantial meaning beyond the raw schema.

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

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

The description opens with '원본을 복제해 LOD 메시를 만듭니다' (duplicates the original to create LOD meshes) and clarifies '원본(LOD0)은 줄이지 않습니다' (the original LOD0 is not reduced), clearly stating the verb and resource. This distinctly differentiates it from sibling tools like maya_unreal_make_collision or maya_unreal_prepare.

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

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

The description gives explicit workflow guidance: visually check with maya_viewport_capture, do not report done based on numbers alone, and do not set reduction rates arbitrarily. It further advises using defaults then asking the user about adjustments, with asset-type-specific tips (characters 70-80, props more aggressive). It doesn't explicitly name alternatives beyond the verification tool, so it misses the 'when-not' dimension.

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 responsibility. It discloses the single undo unit, the negative-scale caveat (only warns, doesn't fix), the dry_run behavior (no scene mutation), and the selection fallback logic. This is comprehensive behavioral disclosure 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 information-dense yet compact: a one-line summary, a usage note, a caveat, and a parameter list. It is front-loaded with the main purpose and contains no filler sentences.

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 tool with no annotations and no output schema, the description covers purpose, workflow, behavioral edge cases, and all parameter semantics. An agent has sufficient information to decide when to call it and how to set each argument.

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 document parameters. It defines all 7 parameters with clear meaning, enumerates pivot options with concrete definitions ('center', 'base', 'origin', 'keep'), and provides practical guidance on choosing between 'base' and 'origin'. This exceeds what the schema alone offers.

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

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

The description clearly states the tool's function: 'Performs pre-export cleanup in one go (freeze, history, pivot, naming).' This specific verb and resource list distinguish it from sibling tools like maya_unreal_check (diagnostic) and maya_unreal_cleanup_materials (material-specific).

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

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

The description explicitly instructs to first check status with maya_unreal_check, establishing a workflow ordering. It also explains the undo-unit behavior, which informs safe usage. However, it does not explicitly exclude or compare against alternative sibling tools, so the when-not-to-use guidance is somewhat implicit.

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 captures and returns an image, and it adds context about the importance of visual verification and the risk of proceeding without checking. It does not mention output format or error scenarios, but for a capture 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.

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

The description is well-structured and appropriately sized. It opens with the core purpose, includes a valuable usage paragraph, and lists parameter explanations. Every sentence adds value; no fluff.

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 simplicity and good parameter explanations, the description is mostly complete. It lacks explicit details about the return format (e.g., file path vs. base64 image), but this is likely implied by the word 'image'. Overall, it provides enough context for an agent to use it correctly.

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

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

Schema description coverage is 0%, so the description must compensate for the parameters. It does so effectively: width and height are described as pixel dimensions, and ornaments is explained as including HUD/gizmos, adding meaning beyond the raw 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 captures the current viewport as an image and returns it. It uses a specific verb ('captures') and resource ('viewport'), and it is distinct from sibling tools like 'maya_execute' or 'maya_scene_info'.

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

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

The description explicitly states when to use this tool: after visual tasks like modeling, layout, lighting, and LOD work, to verify results. It also explains the rationale (numeric metrics can be normal while shapes are broken). However, it does not mention when not to use it or any alternatives, 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.