Store the avatar's current pose as a .pos file for loading later; without a path, CLO writes it to a temporary folder and returns the path.
Save the avatar's current pose as a .pos file, for load_pose later (e.g. after posing it in CLO). Without a path CLO writes it to its temporary folder; the path is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No |
Changes observed during successful MCP inspections.
v0.6.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses the no-path fallback (written to CLO's temporary folder) and that the resulting path is returned. It omits overwrite semantics and format restrictions, but the default-behavior and return-value disclosure is solid for a save 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?
Two compact sentences, front-loaded with the core action, with the fallback behavior and return value appended. No filler.
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 tool with no annotations and no output schema, the description covers purpose, the default path behavior, and the returned path. Only minor details (overwrite behavior, exact file location guarantees) are absent.
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% and the lone file_path parameter is undocumented in the schema, yet the description explains its behavior: optional, and when absent CLO writes to a temporary folder. That compensates for the missing schema description, though it doesn't state accepted path formats or extension 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?
States a specific verb+resource+format: save the avatar's current pose as a .pos file. It explicitly names load_pose as the complementary sibling, so an agent can distinguish the write side from the restore side without inspecting either schema.
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?
Gives clear context for use ('for load_pose later, e.g. after posing it in CLO'), which tells the agent when this tool fits. It does not state exclusions or alternatives beyond load_pose, so it stops 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.