DreamAgent Cloud

Write a project file

dreamagent_write_file

WRITE ACTION — overwrite or create one source file in a DreamAgent project with the exact content given. For CHANGING an existing file, prefer dreamagent_edit_file (small targeted find→replace edits — no need to send the whole file). By default the write is immediately committed and pushed to the project's GitHub repo and recorded in its session history & version history (so the user can restore/revert). Changes go live after the project is rebuilt (dreamagent_build_publish).

CONFIRM BEFORE CALLING — in ONE message show the user: the target path and a summary of the change, then call only after they agree. Never write on the first mention.

MULTI-FILE EDITS: pass auto_commit=false on each write, then call dreamagent_commit_push once at the end — one commit and one history entry for the whole batch.

GUARDS (enforced server-side, the same as the in-app code editor): path stays inside the project, hidden/credential files (.env, .git, keys) are rejected, content is scanned for malware/shell signatures and blocked, 2MB size cap. Failed scans return the reason.

The user can undo damage by editing in the DreamAgent editor or restoring a previous version from version history — still, prefer precise minimal diffs.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`confirm`	No
`content`	Yes
`file_path`	Yes
`project_id`	Yes
`auto_commit`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 12, 2026
- addedInput schema / properties / auto_commit
```
Added value: +{
+  "default": true,
+  "type": "boolean"
+}
```
AddedOct 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that the write is auto-committed and pushed to GitHub, recorded in session and version history, only live after dreamagent_build_publish, and enumerates server-side guards (path confinement, .env/.git/key rejection, malware scanning, 2MB cap) plus the reversibility path via version history. Annotations only cover readOnly/destructive/openWorld, so this description carries real extra context.

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?

Front-loads the core action and uses CAPS-labelled sections (CONFIRM, MULTI-FILE EDITS, GUARDS) that make scanning easy. It is longer than strictly necessary — the guards paragraph and undo guidance overlap somewhat — but every section carries actionable information.

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 a mutation tool with an output schema, no annotation contradiction, and 0% schema coverage, the description supplies the workflow ordering, safety constraints, confirmation requirement, and side effects an agent needs. Return-value details are correctly omitted since an output schema exists.

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?

Schema description coverage is 0%, so the description must compensate. It explains auto_commit's dual role and the batch workflow, and contextualizes content ('exact content given') and path, but never explicitly defines the 'confirm' boolean or the project_id integer, leaving two of five parameters to inference from prose.

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?

States a specific verb+resource+scope: 'overwrite or create one source file in a DreamAgent project with the exact content given.' It also explicitly names the sibling it is not (dreamagent_edit_file) and the distinction (whole-file vs targeted find/replace).

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?

Gives explicit when-to-use and when-not-to-use routing: prefer dreamagent_edit_file for changing an existing file, and pass auto_commit=false plus a single dreamagent_commit_push for multi-file edits. It also imposes a confirmation protocol ('never write on the first mention') — no inference required.

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

All DreamAgent Cloud tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?