Skip to main content
Glama
Sign In
MemDrive

MemDrive

by Newmannn91
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

save_file

Saves text or Markdown notes and images, including screenshots taken straight from the clipboard, into your MemDrive library. Creates folders as needed and supports new, overwrite, or append modes.

Instructions

CLIPBOARD FIRST — READ THIS BEFORE ANYTHING ELSE: When the user says to save a screenshot or an image from the clipboard — for example "把截图存下来", "把剪贴板里的图存下来", "save the screenshot", or any equivalent wording — pass images: ["clipboard"]. That is all it takes: the server reads the clipboard directly on the user's own machine. You do NOT need to see the clipboard or the image. NEVER ask the user to paste, upload, or send the image into the chat. NEVER say you cannot read the clipboard, that you cannot see images, or that this memory library can only store text. If the clipboard holds no image, the server reports that in the result and the text is still saved — tell the user to take the screenshot again and retry; do not invent a clipboard failure. Interaction rule — read before calling: Before calling this tool, show the user the EXACT destination path and filename you intend to write (for example: "notes/2026-10-28.md") and get their explicit confirmation in the chat. Never call save_file with a path or filename the user has not confirmed. If the user has not confirmed a location yet, ask them first instead of calling. There is no popup or confirmation dialog: confirmation happens here, in the conversation, through you. Save text (usually Markdown) into the MemDrive memory library. Modes: "new" (default) fails when the file already exists; "overwrite" replaces it; "append" adds to the end, creating the file when missing. Parent directories are created automatically. Tags: two syntaxes are supported — YAML front matter tags: (inline [a, b] or block - a) and body #tag. Proactively suggest adding tags ONLY in these three cases: (1) the user mentions a category or topic while saving (e.g. saving a work plan); (2) the note clearly belongs to a tag already used in the library; (3) the user saves several notes on the same topic in a row (ask once, e.g. whether to tag all of them X). NEVER ask about tags for quick screenshot/clipboard saves, when the user only said "save it" with no topic signal, or after you already asked once in this conversation and the user ignored it or said no. When the user explicitly asks to save with tags, just save with those tags — none of the rules above apply. If the tool result includes a Tip: line about tagging, you MUST say that tip to the user. Images: pass an "images" array with any mix of the literal string "clipboard" (capture the latest screenshot from the OS clipboard — see the clipboard rule above), local file paths, or http(s) image URLs. Images are copied/downloaded/captured into a sibling assets/ folder, renamed "-.", and for Markdown files a standard image reference is appended to the document automatically. The on-disk original is always kept at full quality; only the preview handed to a model is ever downscaled. Clipboard behavior: when the clipboard is empty or holds text instead of an image, the text is still saved and the result explains what to do (re-screenshot). Clipboard capture never crashes the server; in headless environments it reports itself as unsupported and suggests a file path or URL instead. Paths are relative to the library root (MEMDRIVE_ROOT). Absolute paths are accepted only when they stay inside the root. The root is a hard sandbox: "../" escapes and symlinks pointing outside are rejected. Path cleaning: surrounding quotes are stripped, a leading ~ expands to the home directory, and separators are normalized.

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": "save_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoWrite mode: "new" (default, fails if the file exists), "overwrite", or "append".
pathYesDestination file path, relative to the library root (for example "notes/2026-10-28.md"). Must be confirmed with the user before calling.
imagesNoImages to archive with the document — CLIPBOARD FIRST: the literal string "clipboard" captures the latest screenshot/image from the OS clipboard on the machine running the server. Use it whenever the user mentions a screenshot or the clipboard: never ask them to paste the image into the chat, and never claim the clipboard cannot be read. Local file paths and http(s) image URLs are also accepted.
contentYesText content to save (usually Markdown).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does disclose mode failure semantics ("new" fails if the file exists), automatic parent directory creation, the assets/ copy-and-rename behavior with an appended Markdown reference, and original-quality retention. It also explains clipboard failure recovery and the sandbox rule rejecting ../ escapes and outside symlinks. These are useful, but much of the volume is conversational scripting ("NEVER say you cannot read the clipboard") rather than tool behavior, and there is no mention of permission, size, or concurrency limits.

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

Conciseness2/5

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

The definition is heavily padded with bold headings, ALL-CAPS imperatives, Chinese example phrases, and repeated clipboard guidance across three separate sections. The actual purpose appears only after two policy blocks, so the content is not front-loaded around what the tool does, and several sentences duplicate schema text verbatim.

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 four-parameter write tool with no annotations and no output schema, the description covers write modes, path sandboxing, image archival side effects, tag syntax, and failure recovery, which is enough to call it correctly. The only real gap is that return-value shape is described only ad hoc (a `Tip:` line is mentioned) with no output schema to anchor it.

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 mode, path, images and content are already documented in the schema and the description largely restates them. It does add genuine meaning beyond the schema for path handling — the MEMDRIVE_ROOT hard sandbox, absolute paths allowed only inside the root, quote stripping, ~ expansion, separator normalization — which lifts it above the baseline.

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?

The operative sentence "Save text (usually Markdown) into the MemDrive memory library" gives a clear verb and resource, and the mode and image handling make the write semantics unmistakable versus read-side siblings. However, the purpose statement sits below two blocks of interaction policy, so an agent's first read is a clipboard rule rather than what the tool does.

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?

Explicit routing is given for the sibling-adjacent alternative: use images: ["clipboard"] for screenshots instead of asking the user to paste, and fall back to a file path or URL when clipboard capture is unsupported. It also states when NOT to prompt for tags (quick clipboard saves, bare "save it", already-asked cases) and requires destination confirmation before calling.

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