Engram Obsidian Memory Sync

Delete Folder

delete_folder

DestructiveIdempotent

Delete a folder. Empty-only by default: if the folder contains notes or attachments, the call is refused and reports the counts. Pass recursive: true to delete the folder and everything under it. Everything removed moves to trash, restorable with restore_deleted for 7 days on Free and 30 on paid plans, following your plan at the time (a downgrade shortens it; the result says until when). Syncs to all connected devices.

Input Schema

Name	Required	Description
`folder`	Yes	Folder path to delete, e.g. "Projects/Old"
`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.
`recursive`	No	Delete all notes and attachments under the folder (default false)

Output Schema

Name	Required	Description
`notes`	Yes	Notes removed
`folder`	Yes
`attachments`	Yes
`delete_op_id`	Yes	Pass to restore_deleted to undo this call; null when nothing was removed
`restorable_until`	Yes	ISO 8601 time this delete stops being restorable on your current plan; a plan change moves it

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 28, 2026

addedOutput schema / properties / delete_op_id

Added value: +{
+  "description": "Pass to restore_deleted to undo this call; null when nothing was removed",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / restorable_until

Added value: +{
+  "description": "ISO 8601 time this delete stops being restorable on your current plan; a plan change moves it",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "folder",
-  "notes",
-  "attachments"
-]New value: +[
+  "folder",
+  "notes",
+  "attachments",
+  "delete_op_id",
+  "restorable_until"
+]

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

Behavior5/5

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

Beyond the destructive/idempotent annotations, the description discloses that non-empty folders are refused with counts, that recursive removes everything beneath, that deletions go to trash, and that restorability is 7 days on Free and 30 on paid plans, subject to the plan at deletion time. It also notes device syncing and that the result reports the expiry. This is rich, non-obvious behavioral context.

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 description is front-loaded with the core action and default behavior, and every sentence carries operational information. The retention/plan detail is somewhat dense but relevant to an agent deciding whether deletion is recoverable.

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 annotations already mark the tool destructive and idempotent, and an output schema exists, the description covers everything an agent needs: default refusal behavior, recursive consequences, trash/restore semantics, plan-dependent retention, and sync effects. Nothing material is 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 coverage is 100%, so the baseline would be 3. The description adds real meaning to `recursive`: it explains the default empty-only refusal and the consequence of passing true. It doesn't add further detail about `vault_id` or folder path semantics beyond the schema, but the behavioral implication of the recursive flag is a meaningful addition.

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 first sentence names a specific verb and resource ("Delete a folder"), and the rest precisely scopes the operation: empty-only by default, recursive optionally. This clearly distinguishes it from sibling tools like delete_note, delete_attachment, and rename_folder.

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?

It clearly states the default empty-only behavior, the condition for using recursive: true, and the recovery path via restore_deleted. It doesn't compare against other deletion siblings or explain when to delete contents first instead, but the core usage decision is explicit.

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.