import_avatar

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without revealing side effects. It does not say whether the avatar replaces an existing one, whether a project must be open, whether the scene is modified, or what the result/return value is. For a mutation-style operation, this is a significant transparency gap.

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

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

The description is a single, short sentence that front-loads the core action and file formats. It contains no redundant wording, and the optional arrangement mention adds relevant information without bloating the 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 simple two-parameter import tool, the description provides enough to attempt basic invocation, but it is incomplete in important ways. There is no mention of prerequisites, side effects, or behavior after loading, and no output schema exists to fill that gap. Given the simplicity and the absence of annotations, a few extra details about the operation's consequences would make it more 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 description maps the .avt/.avac files to the avatar file path and the .apf file to the arrangement path, adding clear meaning that the schema (0% coverage) entirely lacks. It implicitly identifies file_path as the avatar and apf_path as the optional arrangement. However, it does not explicitly name the parameters or mention path-format requirements, leaving a small amount to inference.

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

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

The description uses the specific verb 'load' with the resource 'avatar' and names the exact file extensions (.avt, .avac), making the tool's scope immediately clear. It also mentions the optional .apf arrangement file, further distinguishing this from generic import_file or avatar-related siblings like get_avatars and show_avatar.

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?

There is no guidance about when to use this tool versus alternatives such as import_file, get_avatars, or show_avatar. The description only states the action, not the conditions under which an agent should select it. No exclusions or prerequisites are given, leaving the decision entirely to inference.

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