Skip to main content
Glama

Write a file in WSL

wsl_write_file
Destructive

Writes or appends UTF-8 text to a file inside a WSL distro without shell quoting issues. Use it instead of heredocs to create config or log files from an AI agent.

Instructions

Write or append UTF-8 text to a file in the distro. The content never passes through a shell, so quoting is not a concern. Prefer this over heredocs in wsl_exec. Parent directories must exist. Refused on a read-only profile, and under /mnt// unless the profile allows Windows writes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute file path in the distro.
appendNoAppend instead of overwrite. Default false.
contentYesText to write.
sessionNoSession id from wsl_connect. Optional — the file tools do not depend on a session's working directory, paths are absolute.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.2

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare the safety profile (destructive, non-idempotent, open-world); the description adds behavior the annotations cannot convey - content bypasses the shell so quoting/escaping is not a concern, parent directories must pre-exist, and specific refusal conditions tied to profile and mount path. That is meaningful operational context beyond structured fields.

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

Conciseness5/5

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

Four short sentences, no filler, and the core action plus the shell-bypass advantage are front-loaded before the constraints. Every sentence adds a distinct fact (capability, quoting safety, prerequisite, refusal conditions).

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?

With no output schema and complete parameter coverage, the description covers what remains: the write semantics, the safety-relevant refusal paths, and the alternative tool. An agent has everything needed to call this correctly or fall back to wsl_exec.

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 description coverage is 100%, so path, content, append, and session are already fully documented in structured data; the description's 'write or append' phrasing only restates the append parameter's meaning. Per the rubric, a 3 baseline is correct when the schema carries the parameter burden.

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 and resource ('Write or append UTF-8 text to a file in the distro') and implicitly scopes it apart from wsl_upload and wsl_exec by emphasizing direct file writes rather than shell/file-transfer routes. An agent can distinguish it from all listed siblings 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?

Explicitly names an alternative and the condition to prefer this one: 'Prefer this over heredocs in wsl_exec.' It also states prerequisites (parent directories must exist) and refusal conditions (read-only profile, /mnt/<drive>/ without Windows-write permission), which is exactly the when/when-not guidance the dimension asks for.

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