Skip to main content
Glama
Sign In
Fulcra MCP Server

Fulcra MCP Server

by fulcradynamics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Write File

write_file

Save text or base64 content to a path in a Fulcra account, creating new versions on overwrite so agents can share data and detect changes.

Instructions

Write a file to the user's Fulcra account.

Writing to an existing path creates a new version; earlier versions are kept and can be restored with restore_file. Other agents can detect the change through get_data_updates (under "file_changes") and read it with read_file, so files are a good way to pass data between agents.

Input Schema

NameRequiredDescriptionDefault
pathYesThe full path to write to (e.g. "/agents/state.json").
contentNoThe text to write, or with encoding="base64", the file's bytes base64-encoded (up to 5 MB). For larger files, or files the user has on their computer, use open_file_manager.
encodingNo"text" (default) or "base64". "upload_link" leaves content empty and returns a link to send a file on disk to, e.g. from a sandbox: `curl -T <file> <link>` (up to 30 MB).text
content_typeNoOptional MIME type; guessed from the file name when left out (e.g. "application/json" for .json).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.18.7
    • removedInput schema / properties / content_type / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / content_type / default
      Removed value: -null
    • addedInput schema / properties / content_type / type
      Added value: +"string"
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null
  2. Changed8 schema fields changedv1.2.4
    • addedInput schema / properties / content / default
      Added value: +""
    • changedInput schema / properties / content / description
      Previous value: -"The text content to write."New value: +"The text to write, or with encoding=\"base64\", the file's bytes\nbase64-encoded (up to 5 MB). For larger files, or files the user\nhas on their computer, use open_file_manager."
    • addedInput schema / properties / content_type / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / content_type / default
      Previous value: -"text/plain"New value: +null
    • changedInput schema / properties / content_type / description
      Previous value: -"Optional MIME type. Defaults to \"text/plain\"; use e.g.\n\"application/json\" when writing JSON."New value: +"Optional MIME type; guessed from the file name when left\nout (e.g. \"application/json\" for .json)."
    • removedInput schema / properties / content_type / type
      Removed value: -"string"
    • addedInput schema / properties / encoding
      Added value: +{
+  "default": "text",
+  "description": "\"text\" (default) or \"base64\". \"upload_link\" leaves content\nempty and returns a link to send a file on disk to, e.g. from a\nsandbox: `curl -T <file> <link>` (up to 30 MB).",
+  "enum": [
+    "text",
+    "base64",
+    "upload_link"
+  ],
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "path",
-  "content"
-]New value: +[
+  "path"
+]
  3. Addedv1.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing non-obvious behavior: overwriting a path keeps prior versions (consistent with destructiveHint=false) and is reversible via restore_file, and writes are observable by other agents through get_data_updates under "file_changes". That side-effect visibility is exactly the kind of trait an agent cannot infer from 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.

Conciseness4/5

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

Front-loads the core action in one sentence, then adds versioning and cross-agent visibility in tight follow-ups. Slightly prose-heavy line wrapping but every sentence carries distinct information.

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

Completeness4/5

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

For a 4-param, fully documented, non-output tool with annotations present, this covers the semantics an agent needs to call it correctly. Only minor gaps, such as permission/auth requirements or path conventions, are left implicit.

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%, with path format, the 5 MB base64 cap, the upload_link flow, and MIME-type guessing all documented inline. The description adds nothing about parameters, so the baseline of 3 applies.

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 a file to the user's Fulcra account") and immediately qualifies the write semantics (new version on existing path). It is clearly separable from read_file, list_files, delete_file, and the chunked upload tools without opening any schema.

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

Usage Guidelines4/5

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

Gives concrete context for when files are the right mechanism ("files are a good way to pass data between agents") and points to restore_file for recovering earlier versions. It does not explicitly route away from start_file_upload/upload_file_chunk in the description itself — that routing lives only in the content param's schema text.

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

Deploy Server

Other Tools