儲存或載入結構

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

Beyond the destructiveHint annotation, the description discloses that disk mode writes actual files to the game world folder on the user's hard drive, persists after closing the game, and should not be used without explicit user request. It also explains that memory mode disappears on shutdown and that same-name saves overwrite silently. These are exactly the behavioral traits an agent needs to avoid destructive mistakes.

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 longer than average but every section earns its place: purpose, mode selection, persistence consequences, and versioning rules. The formatting with bolded headers and bullet-like lines makes it easy to scan, and the most safety-critical warning about disk writes is prominently placed.

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?

With an output schema present and input schema descriptions covering coordinate modes and required parameters, the description covers most operational context: when to use memory vs disk, how versioning works, and what happens on overwrite. The main gap is includeEntities, which has a default but no guidance on when an agent should enable it. Overall it is nearly complete for a destructive-capable 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 description adds significant meaning to saveMode and name that the schema only gestures at: memory vs disk semantics, user-intent-based selection, and versioning via names. It also communicates the action-dependent coordinate roles indirectly. However, includeEntities is left undocumented in both the schema and the description, and parameter coverage is only 71%, so the description does not fully close the 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?

The description clearly states a specific verb and resource: saving a region as a named structure or loading it back into the world, and positions it as the official path for preserving, mass-producing, and transporting AI-built structures. It does not explicitly differentiate from siblings like mc_clone or mc_blueprint_preview, so it lacks explicit sibling contrast, but the core purpose is unambiguous.

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 strong, decision-oriented guidance for saveMode: memory for session-scoped iteration and disk only when the user explicitly asks for persistence. It also warns about same-name overwrites and points to mc_status for listing session saves. It does not explicitly discuss when to use this tool versus alternatives such as mc_clone, but it provides clear context and practical constraints.

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