Engram Obsidian Memory Sync

Write Note

write_note

DestructiveIdempotent

Replace a note's entire content, or create the note if it does not exist. Saves, indexes for search, and syncs to Obsidian. Overwrites whatever the note held. To add text without touching existing content use append_to_note. To change one passage, or one heading's section, use edit_note. To create a note with no risk of overwriting an existing one use create_note; create_note takes a title and picks the folder, not a path. Replacing a note that exists REQUIRES base_hash: read it with get_notes and pass its content_hash. Without one, or if the note changed since your read, nothing is written and you get a version_conflict, so another client's edit is never erased.

Input Schema

Name	Required	Description
`path`	Yes	Full path for the note (e.g. "Health/New Note.md")
`content`	Yes	Full markdown content
`vault_id`	No	Target vault: its name (e.g. "Engram") or its UUID. REQUIRED when you own more than one vault; the server keeps no active-vault state between calls, so it must be passed on every vault-scoped call. Omit only if you have a single vault. Call list_vaults if a name does not resolve.
`base_hash`	No	content_hash from your get_notes read of this note. Required when the note exists; omit only to create a new note. If the note changed since, nothing is written and you get a version_conflict: read it again and retry.

Output Schema

Name	Required	Description
`path`	Yes
`search_note`	No	When search will see this change; use get_notes until then
`search_indexing_starts_in_seconds`	No	At least this many seconds until indexing starts; search can lag further. Use get_notes to read the note until search finds it

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

changedInput schema / properties / base_hash / description

Previous value: -"content_hash from your get_notes read of this note. If the note changed since, nothing is written and you get a version_conflict: read it again and retry. Omit only to overwrite whatever the note holds."New value: +"content_hash from your get_notes read of this note. Required when the note exists; omit only to create a new note. If the note changed since, nothing is written and you get a version_conflict: read it again and retry."

Changed2 schema fields changedNov 1, 2026

addedOutput schema / properties / search_indexing_starts_in_seconds

Added value: +{
+  "description": "At least this many seconds until indexing starts; search can lag further. Use get_notes to read the note until search finds it",
+  "type": "integer"
+}

addedOutput schema / properties / search_note

Added value: +{
+  "description": "When search will see this change; use get_notes until then",
+  "type": "string"
+}

Changed1 schema field changedOct 28, 2026

addedInput schema / properties / base_hash

Added value: +{
+  "description": "content_hash from your get_notes read of this note. If the note changed since, nothing is written and you get a version_conflict: read it again and retry. Omit only to overwrite whatever the note holds.",
+  "type": "string"
+}

Changed1 schema field changedSep 27, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```

Changed1 schema field changedSep 26, 2026

changedInput schema / properties / vault_id / description

Previous value: -"Target vault — its name (e.g. \"Engram\") or its UUID. REQUIRED when you own more than one vault — the server keeps no active-vault state between calls, so it must be passed on every vault-scoped call. Omit only if you have a single vault. Call list_vaults if a name does not resolve."New value: +"Target vault: its name (e.g. \"Engram\") or its UUID. REQUIRED when you own more than one vault; the server keeps no active-vault state between calls, so it must be passed on every vault-scoped call. Omit only if you have a single vault. Call list_vaults if a name does not resolve."

First observedSep 25, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the destructive overwrite behavior, the save/index/sync side effects, the base_hash requirement, and the version_conflict outcome that prevents erasing another client's edit. These are exactly the behavioral details an agent needs before invoking 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.

Conciseness5/5

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

The overwrite behavior and base_hash requirement are front-loaded, followed by clear sibling-routing sentences. Despite its length, every sentence provides decision-relevant information for a destructive tool.

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 destructive write tool with an output schema and full schema coverage, the description covers the essential risks, alternatives, preconditions, and failure mode. No important invocation context is missing.

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 coverage is already 100%, so the schema itself documents path, content, vault_id, and base_hash. The description reinforces the importance and consequence of base_hash, but it adds little parameter meaning beyond what the schema already provides.

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 precise verb and resource: replace a note's entire content or create it if missing. It immediately distinguishes this from append_to_note, edit_note, and create_note by naming each sibling and its differing behavior.

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 routing guidance: use append_to_note to add text, edit_note to change one passage or heading, and create_note when overwriting must be avoided. It also states the critical precondition for replacing an existing note, including how to obtain base_hash and what happens on a conflict.

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

All Engram Obsidian Memory Sync tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.