Skip to main content
Glama
Sign In
Vault Cortex Obsidian MCP Server

Vault Cortex Obsidian MCP Server

by aliasunder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get Daily Note

vault_get_daily_note
Read-onlyIdempotent

Read a daily note for today or any specific date using the vault's configured Daily Notes folder and filename format, returning its path, content, and existence status.

Instructions

Read a daily note by date, using the vault's configured Daily Notes folder and filename date format.

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. For recent vault activity, vault_recent_notes lists the most recently changed notes; it has no date filter.

Parameters:

  • date: always YYYY-MM-DD, whatever filename format the vault uses; past and future dates are both valid.

Errors:

  • "invalid date …" / "… is not a calendar date" — pass a real date in YYYY-MM-DD form (2026-02-30 is refused)

  • "daily note format contains unsupported token(s): ..." — the configured date format contains tokens the server cannot reproduce; ask the vault's owner to change the format in Obsidian, or the server's operator to set DAILY_NOTES_FORMAT (the message names the tokens)

  • "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; ask the vault's owner to change it in Obsidian, or the server's operator to set DAILY_NOTES_FOLDER and DAILY_NOTES_FORMAT

  • "ENAMETOOLONG: …" or another filesystem error — the message says what to do

Returns: JSON with path (string — resolved vault-relative path), content (string|null — the note's full text, properties block included, 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "vault_get_daily_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoYYYY-MM-DD (e.g. "2026-05-13", "2025-12-31"). Defaults to today in the server's timezone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.55.1
    • changedInput schema / properties / date / description
      Previous 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."New value: +"YYYY-MM-DD (e.g. \"2026-05-13\", \"2025-12-31\"). Defaults to today in the server's timezone."
  2. Changed1 schema field changedv0.54.16
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed1 schema field changedv0.54.7
    • addedInput schema / properties / date / minLength
      Added value: +1
  4. 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."
  5. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description still adds substantial context: how the date is resolved against vault config, the full error taxonomy with remediation for each, and the explicit recovery path (create with vault_write_note when exists is false).

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, then examples, when-to-use, parameters, errors, and returns in a predictable order. The error section is long and somewhat repetitive, but each entry maps to a distinct failure mode rather than padding.

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?

No output schema exists, yet the description fully specifies the return object (path, content, exists) with types and null semantics, and covers the non-existent-note case. For a single-optional-parameter 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; the description earns above that by clarifying that the input is always YYYY-MM-DD regardless of the vault's filename date format, and that both past and future dates are valid. That is genuinely new meaning about how the value is interpreted.

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 ('Read a daily note by date') and adds the key resolution detail that it uses the vault's configured Daily Notes folder and filename format. This separates it from the generic vault_read_note, which takes a path.

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?

Explicit 'When to use' block plus two named alternatives with the conditions that select them: vault_patch_note for appending to a section using the returned path, and vault_recent_notes for recent activity (noting it has no date filter). An agent can route correctly without inference.

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