Engram Obsidian Memory Sync

Delete Attachment

delete_attachment

DestructiveIdempotent

Delete a single attachment (image, PDF, or other binary file) by path: it 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 the delete to all connected Obsidian devices. Deleting a path with no attachment succeeds and reports deleted: false. For notes use delete_note; to remove a whole folder use delete_folder.

Input Schema

Name	Required	Description	Default
`path`	Yes	Path of the attachment to delete
`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.

Output Schema

Name	Required	Description
`path`	Yes
`deleted`	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: -[
-  "path",
-  "deleted"
-]New value: +[
+  "path",
+  "deleted",
+  "delete_op_id",
+  "restorable_until"
+]

AddedOct 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the destructiveHint=true and idempotentHint=true annotations: it discloses soft-delete-to-trash semantics, the 7-day Free / 30-day paid retention window, that downgrades shorten an existing window, that the response reports the expiry, and that the delete syncs to all connected Obsidian devices. This is exactly the extra context the annotations cannot convey.

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-loaded with the action and resource, and every clause carries information (retention windows, sync behavior, no-op result, sibling routing). The single long sentence chain is dense but not padded; minor readability cost from cramming several behaviors into one paragraph.

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?

With an output schema present (so return shape need not be explained) and annotations covering the safety profile, the description still supplies the retention, sync, and no-op semantics an agent needs to plan a follow-up restore or avoid a false failure. Nothing material is missing for a two-parameter destructive tool.

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 both path and the vault_id targeting rule (required for multi-vault owners, no server-side active-vault state) are already fully documented. The description only reinforces that deletion is keyed by path and adds no syntax or format detail beyond the schema, so baseline 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 (delete) and resource (a single attachment) plus the qualifying file types, and explicitly excludes notes and folders by naming the sibling tools. An agent can distinguish it from delete_note and delete_folder without reading either 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?

Explicitly routes to delete_note for notes and delete_folder for whole folders, and covers the edge case of a nonexistent path (succeeds with deleted: false). The backup/restore window is stated with the exact plan-dependent durations, which tells the agent when restore_deleted remains viable.

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.