Skip to main content
Glama
aliasunder

Vault Cortex Obsidian MCP Server

by aliasunder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get Daily Note

vault_get_daily_note
Read-onlyIdempotent

Fetch a daily note by date from your Obsidian vault and get its path, content, and whether it exists. Omit the date to read today's note.

Instructions

Read a daily note by date, using the vault's configured Daily Notes folder and filename date format. Each setting comes from the DAILY_NOTES_FOLDER / DAILY_NOTES_FORMAT env vars, falling back to the vault's .obsidian/daily-notes.json (a blank folder there means Obsidian's new-note folder from .obsidian/app.json, the vault root by default; either file counts as absent when unreadable), then to "Daily Notes" and YYYY-MM-DD.

Example: vault_get_daily_note({ date: "2026-05-13" }) Example: vault_get_daily_note({}) — returns today's daily note

When to use: When you need today's or a specific date's daily note. To append content to a daily note section, use the returned path with vault_patch_note. Use vault_recent_notes to review recent vault activity around a date (not date-filtered — returns globally recent notes).

Parameters:

  • date: past and future dates are both valid — the tool resolves the configured path for any date and reports exists: false if the note hasn't been created yet.

Errors:

  • "invalid date" — use YYYY-MM-DD format

  • "… is not a calendar date" — the date has the YYYY-MM-DD form but names a day that doesn't exist, such as 2026-02-30; pass a real date

  • "daily note format contains unsupported token(s): ..." — the configured format uses tokens the server cannot reproduce (ordinals like Do/Mo, dd, d, e, k/kk, w, Q, Z/ZZ, or the L-family localized formats); change the format in Obsidian or set DAILY_NOTES_FORMAT to a supported alternative

  • "path traversal blocked" / "hidden path blocked" / "absolute path blocked" — the configured daily notes folder or format leads outside the vault or into a hidden folder; change it in Obsidian, or set DAILY_NOTES_FOLDER and DAILY_NOTES_FORMAT

  • "EACCES: …" or another filesystem error code — the daily note's file can't be read (permissions, a symbolic link loop); ask the vault's owner to fix it

Returns: JSON with path (string — resolved vault-relative path), content (string|null — full note body, or null when the note doesn't exist), and exists (boolean). When exists is false, create the note with vault_write_note using the returned path.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoYYYY-MM-DD (e.g. "2026-05-13", "2025-12-31"). Defaults to today in the server's timezone. Invalid formats like "May 13" return an error.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.54.7
    • addedInput schema / properties / date / minLength
      Added value: +1
  2. Changed1 schema field changedv0.23.5
    • changedInput schema / properties / date / description
      Previous value: -"Date in YYYY-MM-DD format (defaults to today in server timezone)"New value: +"YYYY-MM-DD (e.g. \"2026-05-13\", \"2025-12-31\"). Defaults to today in the server's timezone. Invalid formats like \"May 13\" return an error."
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description adds substantial behavior: the full setting-resolution chain (env vars → .obsidian/daily-notes.json → app.json → defaults), past/future date validity, exists:false semantics, and a detailed error catalog with causes and remediation for each code.

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 purpose and examples, then cleanly sectioned into When to use, Parameters, Errors, and Returns. The settings-resolution paragraph and error catalog are dense, but each item carries actionable information; only marginal trimming is possible without losing value.

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 no output schema, the description explicitly documents the return shape (path, content, exists) and even prescribes the follow-up action (create with vault_write_note using the returned path when exists is false). For a single-optional-param read tool, nothing an agent needs 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 is 3, but the description adds genuine meaning beyond the schema: both past and future dates are valid, the tool resolves the configured path for any date, and it reports exists: false when the note has not yet been created. The date-format error detail also reinforces the schema's constraint.

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 opens with a specific verb+resource+scope: 'Read a daily note by date, using the vault's configured Daily Notes folder and filename date format.' It names siblings it is not (vault_patch_note, vault_recent_notes), so an agent can route correctly without opening any 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?

There is an explicit 'When to use' section covering today's or a specific date's note, plus concrete alternatives: vault_patch_note for appending content and vault_recent_notes for recent activity (with the caveat that it is not date-filtered). Conditions and exclusions are both stated.

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

Deploy Server

Other Tools