Skip to main content
Glama

ZeroMind (OrigoZero game engine)

write_file

Destructive

Write a file or folder to the world VFS (creating parents). A file the user attached or uploaded goes in with source (one file) or sources (a folder), from the file link the client supplies, so its bytes transfer directly. content is for text; content_b64 only for a small binary you generated in memory, never for a file that exists somewhere. local_path is not the way to send a file from the user's computer: it is read by a native engine on the engine's machine, inside its own transfer directory. Returns bytes written and any LSP diagnostics.

Input Schema

NameRequiredDescriptionDefault
asNoYour own name, when you are one of several agents sharing one connection to this engine (the sub-agents one agent session runs share its connection, so without it the engine sees all of them as one caller). Pass the same name on every call you make. The engine then treats you as a caller of your own: your roster name is this name, and your play session, the play-shadow writes and refusals that say who wrote what, engine.modeOwner, your shell session and your notices are yours alone. Lowercase letters, digits, '-' and '_'. Leave it out when you are the only agent on your connection.
pathYes
quietNoSuppress automatic import callbacks while populating a folder; then run the importer explicitly.
sourceNoFile reference to download into path; maximum 8 MiB. Use instead of inline content.
contentNoUTF-8 text (or base64 when encoding=base64).
durableNoWrite canonical world source while play is running.
sourcesNoFolder contents as file references with relative_path (or file_name). path names the destination folder. Writes in order; on failure reports completed files and the failed path.
encodingNo
local_pathNoRead by the connected native Zero engine, on the engine's machine, and only inside its transfer directory: %LOCALAPPDATA%\OrigoZero\Transfers on Windows, ~/Library/Application Support/OrigoZero/Transfers on macOS, $XDG_DATA_HOME/OrigoZero/Transfers (default ~/.local/share/OrigoZero/Transfers) on Linux. Pass an absolute path inside that directory or a path relative to it, such as Blender/model.glb; something running on that machine must already have put the file there. This is not how to send a file from the user's computer or from yours. For a folder, `path` is the destination folder and every file keeps its path relative to the folder. At most 256 MiB and 10000 files per call; symlinks and junctions are rejected. A browser engine refuses local paths. Not combined with content, content_b64, encoding or source.
awaitImportNoWhen false, the write answers as soon as its bytes land, without waiting for an import they set off to settle, and the answer carries no `import`. For a run of writes that belong together (a model, then the buffer and textures it references), so no file of the run waits on an earlier one's import; `require("@builtin::assetTypes.importer.shared").writeOutcomes(paths, sinceFrame)` then answers where each one's bytes went.
content_b64NoBase64 binary (overrides content), only for a small binary you generated in memory. A file the user attached goes in through `source`, never through here.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructive/openWorld/non-idempotent, and the description still adds substantial behavioral context beyond them: return values ('bytes written and any LSP diagnostics'), parent creation, the 8 MiB source cap, 256 MiB/10000-file local_path cap with symlink rejection, browser-engine refusal, and the import-callback timing controlled by `quiet` and `awaitImport`.

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

Conciseness4/5

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

Purpose is front-loaded in the first clause and every sentence carries actionable information, but the description re-states schema-level detail for local_path and content_b64, and some sentences are long and clause-heavy. Mostly efficient, with minor redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, nested-object mutation tool with no output schema, the description is thorough: it covers the return payload (bytes written + LSP diagnostics), partial-failure behavior for folder writes ('reports completed files and the failed path'), and per-mode size/engine constraints. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 82% schema coverage the baseline is 3, and the description earns above it by explaining cross-parameter semantics the schema does not: mutual exclusivity ('Not combined with content, content_b64, encoding or source'), content_b64 overriding content, and the source-vs-content-vs-local_path decision. It does duplicate some schema text (local_path, content_b64) rather than adding to it, keeping it short of a 5.

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

Purpose5/5

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

Opens with a specific verb+resource: 'Write a file or folder to the world VFS (creating parents).' It then crisply delineates the tool's four content modes (source/sources, content, content_b64, local_path), so an agent understands exactly what this tool does versus edit_file or bash without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use and when-not-to-use rules: attached/uploaded files go through `source`/`sources`, `content` is for text, `content_b64` is only for a small in-memory binary, and `local_path` 'is not the way to send a file from the user's computer.' Alternatives are named and the selecting condition for each is stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.