import_gltf

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

Annotations already mark the tool as destructive (destructiveHint=true) and not read-only (readOnlyHint=false). The description adds value by disclosing the specific error behavior (err.class_missing) when the plugin is absent, which is beyond the annotations. This extra behavioral detail is useful for anticipating failure modes and planning error handling, though it does not describe other side effects (e.g., merging vs. creating a new scene) which are covered by the merge parameter in the schema.

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

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

The description is concise, with two short sentences in bilingual format (Chinese and English). It is front-loaded with the action and includes the essential plugin warning. The dual-language repetition is slightly redundant but acceptable for a global tool. Every sentence earns its place; there is 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?

For a simple import tool with two parameters and no output schema, the description covers the key operational detail (plugin dependency and failure mode). The merge behavior is available in the schema. However, it does not mention what happens after successful import (e.g., objects added to scene, return status) or any post-import steps, but given the tool's simplicity and annotations covering destructiveness, the description is reasonably complete. Not perfect, but adequate.

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 100% description coverage for both parameters (path and merge), so the schema already fully documents their meaning. The tool description does not add any additional semantic detail beyond what the schema provides. Thus, the baseline of 3 is appropriate; the description contributes no extra param 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: '导入 glTF / GLB' (Import glTF/GLB), specifying both verb and resource. The additional note that glTF is a plugin and may fail provides context that distinguishes this import from standard file import tools. The name itself differentiates from siblings like import_fbx, import_obj, and import_usd, and the plugin mention adds an extra distinguishing factor.

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 does not explicitly state when to use this tool over alternatives (e.g., import_obj, import_fbx) or any prerequisites beyond the plugin. It only warns that if the plugin is missing the call fails, which is a failure condition, not usage guidance. No alternatives, exclusions, or contextual selection criteria are provided, leaving the agent to infer the appropriate use case from the resource type alone.

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