Create a blank Douyin AR project and save it to a non-existent or empty absolute folder path; requires an open project window. Returns the new window’s PID and official instance ID.
新建一个空白像塑工程并首次保存到 path（目录须不存在或为空）。需要已有任意一个工程窗口开着。返回新窗口的 pid 和官方 instance_id。
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 新工程要保存到的文件夹绝对路径。 |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full disclosure burden. It does useful work by stating the directory-emptiness constraint, the open-window prerequisite, and the return values (pid and instance_id), implying a new window is spawned. It is silent on failure behavior when prerequisites are unmet and on any side effects of a partial save.
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 tight sentences with no waste: action first, then preconditions, then return value. Every clause contributes information an agent needs before calling the tool.
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 single-parameter creation tool with no output schema, the description covers purpose, prerequisites, and return values, which is enough to attempt a correct call. It could go further on error conditions and whether the created window remains open, but nothing essential is missing.
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 100%, so the baseline is 3, but the description adds a real constraint not in the schema: the directory must not already exist or must be empty. That materially affects how an agent must choose the path 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 states a specific verb and resource: create a new blank Xiangsu project and save it to path for the first time. 'New blank project' implicitly distinguishes it from the sibling project_open, though it never names that alternative explicitly.
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?
Clear preconditions are given: the target directory must not exist or must be empty, and an existing project window must already be open. It stops short of naming alternatives (e.g., project_open for existing projects) or explicitly stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.