Skip to main content
Glama

ZeroMind (OrigoZero game engine)

edit_file

Destructive

Replace an exact string in a world VFS file.

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.
newNoAlias for new_string
oldNoAlias for old_string
pathYes
quietNoWhen true, write the result without firing write side effects (importer dispatch, assetType onChange, vfs.watch subscribers).
durableNoWhen true, the edited bytes go to canonical /source even while play is RUNNING, and the session stays in play. The affected modules and components hot-reload, so the edit is observed running in the same play session with nothing left to promote — the call for bytes whose destination is known before they are edited, where vfs.promotePlayShadow(path or {paths}) takes bytes already on the shadow with play still running. An edit that cannot become canonical source is an error naming why, instead of a success that landed on the shadow.
new_stringNo
old_stringNo
replace_allNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, and the one-line description adds nothing beyond them. It does not disclose what happens on a failed/ambiguous match, whether the write touches canonical source or a shadow, or the error behavior that the sibling parameters hint at.

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?

A single front-loaded sentence with no wasted words. It is efficient, though arguably too terse for a 9-parameter tool with alias semantics.

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

Completeness2/5

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

For a destructive, non-idempotent mutation tool with 9 parameters, alias pairs, and no output schema, a one-line description is inadequate. It omits usage context, the meaning of the no-op behaviors, and any guidance on matching or promotion semantics that the schema only partially covers.

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

Parameters3/5

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

Schema coverage is a middling 56%: 'as', 'quiet', and 'durable' carry rich descriptions, but 'path', 'new_string', 'old_string', and 'replace_all' are undocumented. The description supplies no parameter meaning at all (no mention of aliases, replace_all, or required fields), so it does not compensate for the gaps.

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

Purpose4/5

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

"Replace an exact string in a world VFS file" gives a specific verb (replace) and resource (an exact string within a VFS file), which is more precise than a generic edit. It does not, however, differentiate from close siblings like write_file, edit, or edit_world_metadata.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus alternatives such as write_file or edit, nor any prerequisites (e.g., that the file must exist or that the old string must match exactly once). The exact-string-match nature is only implied.

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.