vault-cortex
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Logging verbosity: debug, info, warn, or error. | info |
| PUBLIC_URL | No | Public URL clients use to reach the server. Used as the OAuth issuer URL in discovery metadata. | http://localhost:8000 |
| VAULT_PATH | Yes | Absolute path to your Obsidian vault, mounted into the container. | |
| INDEX_DB_PATH | No | SQLite FTS5 index DB path inside the container. | /data/index.db |
| MCP_AUTH_TOKEN | Yes | Bearer token for MCP client authentication. Generate with: openssl rand -hex 32 |
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| completions | {} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vault_read_note | Read a markdown note by its vault-relative path. Returns the full raw content including properties, or just the parsed properties when properties_only is set. Example: vault_read_note({ path: "Projects/vault-cortex.md" }) Example: vault_read_note({ path: "Projects/vault-cortex.md", properties_only: true }) When to use: You know the exact path and need the full content of a specific note. Use properties_only: true when you only need properties (saves tokens on large notes). Prefer vault_search when you don't know the path. Prefer vault_get_memory for About Me/ files (returns content without properties). Returns: Raw markdown string (default), or JSON object of properties (when properties_only: true). |
| vault_write_note | Create or update a markdown note. Body replaces the entire note content — this is a full overwrite, not a partial edit. Properties are passed separately and merged with any existing properties (new keys added, matching keys overwritten, unmentioned keys preserved). Example: vault_write_note({ path: "Projects/notes.md", body: "# Notes\n\nProject notes here.", properties: { tags: ["project"], type: "project" } }) When to use: Creating a new note or fully replacing an existing note's body. Prefer vault_update_properties for property-only edits (no body round-trip). Prefer vault_update_memory for appending dated entries to About Me/ memory files. Limitation: Overwrites the entire body. Do not use for surgical edits to large files — existing content will be lost unless you include it in the body parameter. Obsidian syntax: Body content is rendered as Obsidian Flavored Markdown with no escaping applied. Beyond standard Markdown, watch for Obsidian-specific patterns:
Returns: Confirmation message. |
| vault_patch_note | Surgical edits to a markdown note — append, prepend, replace, or insert content by heading. Frontmatter values are preserved; YAML formatting may be normalized to block style on first edit. Example: vault_patch_note({ path: "TASKS.md", operation: "append", heading: "Active", content: "- [ ] New task" }) Cross-section move (e.g. completing a task on a board):
When to use: Modifying part of an existing note without overwriting the entire body. Prefer vault_write_note for creating new notes or full rewrites. Prefer vault_replace_in_note for in-place text changes (typos, renaming) that stay in the same location. Operations:
Section boundaries: a section spans from its heading to the next heading of the same or higher level (or EOF). Child headings are included in the parent section. Errors:
Obsidian syntax: Content is rendered as Obsidian Flavored Markdown with no escaping applied. Beyond standard Markdown, watch for: #word (no space) = tag, [[ = wikilink, %% = comment block. Escape with # or [[ when unintentional. Structural note: inserting heading-level content (e.g. ## New Section) changes the note's section structure — future patch calls targeting headings may resolve differently. Returns: Confirmation message. |
| vault_replace_in_note | Find and replace text in a markdown note's body. Matches exact text (case-sensitive). Properties are preserved; YAML formatting may be normalized to block style on first edit. Operates on the body only — properties must be edited via vault_update_properties or vault_write_note's properties parameter. Example: vault_replace_in_note({ path: "Projects/plan.md", old_text: "TODO: write summary", new_text: "Summary complete." }) When to use: Targeted text changes within a single location — fixing typos, updating values, renaming terms, or removing a specific line (new_text=""). Replaces text in place; does not move content across sections. To relocate content between headings, use vault_replace_in_note to remove from the source (new_text=""), then vault_patch_note to append at the target. Read the note first with vault_read_note to confirm exact text. Limitation: Exact text match only (no regex). old_text must appear in the note body or an error is returned. Errors:
Obsidian syntax: new_text is rendered as Obsidian Flavored Markdown with no escaping applied. Beyond standard Markdown, Obsidian-specific patterns (#word = tag, [[ = wikilink, %% = comment block) apply to replacement text. Verify replacements won't introduce unintended Obsidian rendering. Returns: Confirmation message with replacement count. |
| vault_list_notes | List .md file paths in the vault, optionally filtered by folder and/or glob pattern. Returns paths only — not content or metadata. Example: vault_list_notes({ folder: "Projects" }) or vault_list_notes({ glob: "**/session-log.md" }) When to use: Browsing what exists in a folder by filename, or finding notes matching a path pattern. Prefer vault_search_by_folder when you need metadata (tags, type, related) along with paths. Prefer vault_search for content-based discovery. Returns: JSON array of vault-relative paths. |
| vault_delete_note | Permanently delete a markdown note. Protected paths (About Me/, Daily Notes/) are refused to prevent accidental deletion of memory or daily notes. Example: vault_delete_note({ path: "Scratch/temp.md" }) When to use: Removing a note you no longer need. Prefer vault_delete_memory for removing individual dated entries from About Me/ memory files. Returns: Confirmation message. |
| vault_update_properties | Update properties on a single note. Merges with existing properties — new keys are added, matching keys are overwritten, unmentioned keys are preserved. Body content is never modified. Example: vault_update_properties({ path: "Projects/todo.md", properties: { status: "active", priority: 1 } }) Read current properties first with vault_read_note({ properties_only: true }) — merge overwrites each key entirely (arrays are replaced, not appended to). When to use: Changing tags, status, type, or any property without reading/rewriting the full note body. Saves tokens on large notes. Prefer vault_write_note when creating a new note or replacing the body. Errors:
Obsidian syntax: Property values follow YAML conventions. Use arrays for multi-value fields (tags: [a, b]), quote wikilink values ("[[Note]]"), keep property types consistent across the vault (string/number/list mismatches cause silent query failures). Returns: Confirmation message. |
| vault_search | Full-text search across all vault notes, ranked by relevance. Supports filtering by folder, tags, type, and properties. Wrap terms in double quotes for exact phrase matching (e.g. '"machine learning"'); unquoted terms use implicit AND with porter stemming. Example: vault_search({ query: "kubernetes networking", filters: { tags: ["reference"] } }) When to use: Finding notes by content when you don't know the exact path. The primary discovery tool for content-based queries. Prefer vault_search_by_tag for tag-only queries without text. Prefer vault_search_by_folder for browsing a folder without a search term. Prefer vault_recent_notes for time-based browsing. Returns: JSON with results array (path, title, snippet, score, tags, folder, type, created, modified) and total count. created is omitted when null. |
| vault_search_by_tag | Find notes with a specific tag. By default uses hierarchical prefix matching — a parent tag matches all children (e.g. "project" matches "project/vault-cortex", "project/blog"). Set exact=true for exact match only. Example: vault_search_by_tag({ tag: "project" }) returns all notes tagged project or project/*. When to use: Exploring tag hierarchies or finding all notes with a specific tag, without needing a text query. Prefer vault_search when you also need text-based relevance ranking. Use vault_list_tags first to discover available tags. Returns: JSON array of note metadata (path, title, tags, related, folder, type, created, modified, additional_properties), sorted by most recently modified. Promoted keys are in top-level fields; additional_properties contains only unpromoted keys. |
| vault_list_tags | List all tags in the vault with their note counts, ordered by count descending. Example: vault_list_tags() returns [{ tag: "session-log", count: 42 }, { tag: "project", count: 15 }, ...] When to use: Discovering what tags exist in the vault before searching by tag. Good first step for vault orientation. Prefer vault_search_by_tag once you know which tag to query. Returns: JSON array of { tag, count } objects. |
| vault_recent_notes | List recently modified or created notes, sorted by timestamp. Returns the most recent notes first — does not filter by date range. Example: vault_recent_notes({ sort_by: "modified", limit: 10 }) When to use: Catching up on vault changes or finding recent work. Prefer vault_search for content-based discovery. Prefer vault_search_by_folder for browsing a specific folder. Returns: JSON array of note metadata (path, title, tags, related, folder, type, created, modified, additional_properties), sorted by chosen timestamp. |
| vault_search_by_folder | Browse notes in a folder with full metadata (tags, type, related, created, modified). Unlike vault_list_notes which returns paths only, this returns rich metadata for each note. Example: vault_search_by_folder({ folder: "Projects" }) or vault_search_by_folder({ folder: "About Me", recursive: false }) When to use: Exploring a folder's contents with full context — tags, type, relationships. Useful for vault orientation and understanding folder structure. Prefer vault_list_notes when you only need paths. Prefer vault_search when you have a text query. Returns: JSON array of note metadata (path, title, tags, related, folder, type, created, modified, additional_properties), sorted by most recently modified. |
| vault_get_memory | Read semantic memory from About Me/ files. These are structured memory files containing dated bullet entries organized under H2 headings. With file: single file content. With file+section: just that H2 section's entries. No args: all files concatenated (frontmatter stripped) — can be large. Returns empty string when no memory files exist yet. Example: vault_get_memory({ file: "Principles", section: "Decision heuristics (newest first)" }) When to use: Reading user preferences, principles, opinions, or other persistent context stored in About Me/ files. Call vault_list_memory_files first to discover valid file and section names. Prefer vault_read_note for reading non-memory notes. Returns: Raw markdown text. |
| vault_update_memory | Append a dated entry to a section of a About Me/ memory file. The server auto-prefixes today's date (format: "- YYYY-MM-DD: entry text"). Call vault_list_memory_files first to discover valid file and section names. Example: vault_update_memory({ file: "Opinions", section: "Code patterns (newest first)", entry: "Prefer immutable data structures" }) When to use: Recording a new preference, principle, opinion, or fact about the user. Pass raw entry text without date prefix. Always call vault_list_memory_files first to discover existing files and sections, and use matching names to keep entries organized alongside existing content. Auto-creates: If the file or section does not exist, it is created automatically. If the section name does not already include "(newest first)", the server appends it (e.g. "Design preferences" becomes "Design preferences (newest first)"). Use the full heading name in subsequent vault_get_memory calls, or call vault_list_memory_files to discover the actual heading names. Use existing file and section names from vault_list_memory_files when available. Prefer vault_write_note for creating entirely new notes (not memory entries). Obsidian syntax: Entry text is rendered inline as Obsidian Flavored Markdown. Watch for: #word = tag, [[ = wikilink. Escape with backslash or backticks when unintentional. Returns: Confirmation message. |
| vault_list_memory_files | Discovery tool — lists About Me/ memory files with their H1/H2 heading structure and per-section entry counts. Does NOT return actual entries. Example: vault_list_memory_files() returns file outlines with headings like "Decision heuristics (newest first)" and entry counts. When to use: Discovering what memory files and sections exist BEFORE calling vault_get_memory, vault_update_memory, or vault_delete_memory. Always call this first to get valid file and section names. Returns: JSON array of file outlines. |
| vault_delete_memory | Delete a single dated entry from a About Me/ memory file. Both date and entry text are required for exact matching — ensures only the intended entry is removed. Example: vault_delete_memory({ file: "Opinions", section: "AI tooling & memory (newest first)", date: "2026-05-01", entry: "Prefer X over Y" }) When to use: Removing an outdated or incorrect entry from a memory file. Call vault_get_memory(file, section) first to see exact entry text for matching. Prefer vault_delete_note for deleting entire non-protected notes. Returns: Confirmation message. |
| vault_get_daily_note | Read a daily note by date, using the vault's configured Daily Notes folder and date format (from .obsidian/daily-notes.json). Defaults to today if no date is provided. Example: vault_get_daily_note({ date: "2026-05-13" }) When to use: When you need today's or a specific date's daily note. Handles path resolution automatically using the vault's Obsidian config — you don't need to know the folder name or filename format. To append content to a daily note section, use the returned path with vault_patch_note. Errors:
Returns: JSON with path (resolved vault-relative path), content (note body or null), and exists (boolean). When exists is false, use vault_write_note with the returned path to create the note. |
| vault_list_property_keys | Discover all property keys in the vault with note counts and sample values. Lets you understand the vault's metadata schema without reading individual notes. Example: vault_list_property_keys() returns [{ key: "tags", count: 342, sample_values: ["session-log", "project"] }, ...] When to use: Discovering what properties exist before searching by property. Good first step for vault orientation alongside vault_list_tags. Prefer vault_list_property_values when you need the full list of values for a specific key. Prefer vault_search_by_property to find notes matching a specific key-value pair. Returns: JSON array of { key, count, sample_values } sorted by count descending. sample_values shows the top 3 most common values for quick orientation. |
| vault_list_property_values | List distinct values for a specific property key with note counts. Useful for discovering the range of values a property takes before searching. Example: vault_list_property_values({ key: "status" }) returns [{ value: "active", count: 47 }, { value: "done", count: 211 }, ...] When to use: Enumerating possible values for a property key before calling vault_search_by_property. Handles both scalar properties (status: "active") and array properties (tags: ["a", "b"]) — array elements are enumerated individually. Call vault_list_property_keys first to discover valid key names. Returns: JSON array of { value, count } sorted by count descending. |
| vault_search_by_property | Find notes where a property matches a value (exact match). Unlike vault_search, this does not require a text query — it searches by metadata only. Handles both scalar properties (status: "active") and array properties (tags contains "project"). Example: vault_search_by_property({ key: "status", value: "in-progress" }) When to use: Finding notes by metadata when you don't have a text query. Fills the gap where vault_search requires search text. Prefer vault_search when you also have a text query (it supports property filters too). Prefer vault_search_by_tag for tag-specific queries (supports hierarchical prefix matching). Returns: JSON array of note metadata (path, title, tags, related, folder, type, created, modified, additional_properties), sorted by most recently modified. |
| vault_get_backlinks | Find all notes that link to a given note (incoming wikilinks and markdown links). Shows which notes reference the target — useful for understanding a note's context and importance in the vault's knowledge graph. Example: vault_get_backlinks({ path: "Projects/vault-cortex.md" }) When to use: When you need to understand what references a note, find related context, or assess a note's connectivity. Core Obsidian concept — backlinks are invisible without a database query. For outgoing links (what a note links TO), use vault_get_outgoing_links. For orphan detection, use vault_find_orphans. Errors:
Returns: JSON with path (the queried note), backlinks (array of { path, title }), and count. |
| vault_get_outgoing_links | Find all notes that a given note links to (outgoing wikilinks and markdown links). Each link includes an exists flag — false means the target note doesn't exist (broken link). Example: vault_get_outgoing_links({ path: "Projects/vault-cortex.md" }) When to use: When you need to see what a note references, navigate the knowledge graph forward, or detect broken links in a specific note. For incoming links (what links TO a note), use vault_get_backlinks. Errors:
Returns: JSON with path (the queried note), outgoing_links (array of { path, title, exists }), and count. |
| vault_find_orphans | Find notes with no incoming links from other notes. Orphan notes are disconnected from the vault's knowledge graph — they may be forgotten or need linking from relevant notes. Example: vault_find_orphans() or vault_find_orphans({ exclude_folders: ["Daily Notes","Templates","About Me"] }) When to use: Vault maintenance and organization. Helps identify notes that might be forgotten or need integration into the knowledge graph. Daily Notes, Templates, About Me folders are excluded by default since those are standalone by design. To add links to an orphan, use vault_patch_note to mention it from a relevant note. Returns: JSON array of note metadata (path, title, tags, related, folder, type, created, modified, additional_properties), sorted by most recently modified. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aliasunder/vault-cortex'
If you have feedback or need assistance with the MCP directory API, please join our Discord server