Engram Obsidian Memory Sync

Append to Note

append_to_note

Add text to the end of a note. Existing text is kept. If the note does not exist it is created with a # <name> title line first. Use for logs, journals and running lists. Set position to start to insert at the top (after any frontmatter) instead. To change existing text use edit_note. To replace the whole note use write_note.

Input Schema

Name	Required	Description	Default
`path`	Yes	Full path for the note
`text`	Yes	Text to append
`position`	No	end (default) appends; start inserts at the top, after any frontmatter	end
`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	Optional content_hash from your get_notes read of this note. If the note changed since, nothing is written and you get a version_conflict: call get_notes again and retry with the new content_hash. Pass it when your change depends on what you read.

Output Schema

Name	Required	Description
`path`	Yes
`created`	Yes	true when the note did not exist and was created
`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

addedInput schema / properties / base_hash

Added value: +{
+  "description": "Optional content_hash from your get_notes read of this note. If the note changed since, nothing is written and you get a version_conflict: call get_notes again and retry with the new content_hash. Pass it when your change depends on what you read.",
+  "type": "string"
+}

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"
+}

Changed2 schema fields changedSep 27, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / position

Added value: +{
+  "default": "end",
+  "description": "end (default) appends; start inserts at the top, after any frontmatter",
+  "enum": [
+    "end",
+    "start"
+  ],
+  "type": "string"
+}

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.4/5.0

Behavior4/5

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds real context beyond them: existing content is preserved, a missing note is created with a title line, and frontmatter is skipped when prepending. It does not discuss separator/newline handling or conflict behavior, though base_hash conflict semantics live in the schema.

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?

Five short sentences, front-loaded with the core action and immediately followed by the auto-create side effect, then positioning, then sibling routing. No filler or redundancy.

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?

An output schema exists and the input schema is fully documented, so return values and parameter detail are covered. The description addresses the two things an agent could get wrong (auto-creation, prepend vs append). The small remaining gap is whether a separator is inserted between existing and new text.

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 the baseline is 3. The description restates position ("start to insert at the top, after any frontmatter"), which largely duplicates the schema enum description, and says nothing about vault_id or base_hash beyond what the schema already documents.

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 ("Add text to the end of a note") plus the key semantics (existing text kept, note auto-created with a `# <name>` title). It explicitly distinguishes itself from edit_note and write_note, so an agent can route correctly without opening the 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?

Gives positive guidance (logs, journals, running lists), an in-tool alternative (position=start for prepending), and names both competing siblings with the exact condition that selects them (edit_note to change existing text, write_note to replace the whole note). No inference required.

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.