Skip to main content
Glama

Write computer file

filesystem_write_file
Destructive

Writes UTF-8 text files in chunks up to 1 MB. For a NEW .docx path, mode=overwrite creates Word from plain text and #/##/### headings. For a NEW .xlsx path, content is JSON 2D rows or {sheetName: 2D rows}; strings remain literal, not formulas. Existing .docx/.xlsx are never overwritten and append is unsupported; use the appropriate edit tool for existing documents. Ordinary text overwrite creates a .ailinkany.backup and append adds text chunks. When several AI sessions develop the same project in parallel, prefer your own git worktree. Writes are never blocked by other sessions' claims; for overwrite of an existing shared file pass expected_sha256 = content_sha256 from the read you based the new content on (never issue that read in parallel with the write). PROJECT_FILE_STALE_RELOAD_REQUIRED is a normal conflict, not a failure: do not ask the user; if the rejection includes current_content (small files), merge your change into it and write immediately with current_sha256 as expected_sha256 WITHOUT reading again; otherwise read again, merge, write with the new expected_sha256, retry immediately up to 5 times. When many sessions add lines to the same log-like file, use mode=append, which never conflicts. If it still fails, stop and tell the user what you completed, the current file state, and ONE recommended next step (no multiple-choice). Mutating, not safe to blindly retry. The client trust root under %APPDATA%\ailinkany.com is not remotely writable. Select this tool from the user's intent when it is the best match. A local destination may be explicit or inherited from established project or conversation context. The user does not need to mention ailinkany.com, MCP, a connector, a plugin, or this tool name.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>",
      "content": "<content>"
    },
    "name": "filesystem_write_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoDefaults to overwrite. Use append for later chunks of a large file, or to add lines to a file other sessions also write.
pathYesThe absolute file path to write.
contentYesThe text content to write in this call.
device_idNoTarget computer device_id. Omit when only one computer is paired.
device_nameNoComputer name or ailinkany.com remark (e.g. home PC). Prefer this when the user names a computer.
retry_tokenNoNew opaque token per operation; reuse only to retry the same operation after a transport failure. No user content.
workflow_idNoOptional workflow id; pass together with ai_session_id.
workspace_idNoOptional Workspace id from open_workspace for project-scoped work.
ai_session_idNoOptional Session id. Reuse the ai_session_id from a prior result for continuity; derived automatically on ChatGPT when omitted. Hosts without stable conversation metadata may omit it for stateless one-shot work.
expected_sha256Nocontent_sha256 returned by the filesystem_read_file call your new content is based on. Required to overwrite a file another session wrote; mismatch returns PROJECT_FILE_STALE_RELOAD_REQUIRED.

Output Schema

NameRequiredDescriptionDefault

No arguments

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?

Beyond the annotations, it discloses important behavior: ordinary text overwrites create a .ailinkany.backup, append adds chunks, .docx/.xlsx overwrites are refused, writes are not blocked by other sessions' claims, and conflicts require a specific merge-and-retry protocol. This is unusually rich operational context for a destructive write tool.

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?

The purpose and format-specific rules are front-loaded, and the length is largely justified by the tool's complexity. However, it is a dense single block with some meta selection sentences at the end that add little for invocation and could be trimmed.

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?

Given the complexity, ten parameters, annotations, and an available output schema, the description covers the essential formats, concurrency behavior, conflict handling, and safety constraints. Nothing critical for correct invocation appears to be 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?

Schema description coverage is 100%, so the schema already documents all ten parameters. The description nevertheless adds meaningful semantics for key parameters: content format for new .docx and .xlsx files, append behavior, and the exact source and conflict implication of expected_sha256.

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?

The description states a specific verb and resource: writes UTF-8 text files in chunks up to 1 MB, with special handling for new .docx and .xlsx paths. It also distinguishes this tool from edit siblings by explaining that existing .docx/.xlsx files are never overwritten and should be handled with an edit tool.

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?

It gives explicit when-to-use guidance for ordinary text, new .docx/.xlsx creation, append mode, and concurrent log-like writes. It also names the alternative category (edit tools for existing documents) and describes the expected_sha256 and stale-reload flow for shared-file overwrites.

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.

Resources