Skip to main content
Glama
Vault Cortex Obsidian MCP Server

Vault Cortex Obsidian MCP Server

Read Note

vault_read_note
Read-onlyIdempotent

Read a markdown note by vault-relative path and return its full content or target just properties, outline, or one heading section, with line paging for large notes.

Instructions

Read a markdown note by its vault-relative path. By default returns the full raw content including properties; optional modes return just the properties, just the heading outline, or just one section.

Example: vault_read_note({ path: "Projects/vault-cortex.md" }) Example: vault_read_note({ path: "TASKS.md", outline: true }) Example: vault_read_note({ path: "TASKS.md", heading: "Active" }) Example: vault_read_note({ path: "TASKS.md", heading: "Done", heading_level: 2 }) Example: vault_read_note({ path: "TASKS.md", heading: "Done", start_line: 1, limit: 20 })

When to use: You know the exact path and need a specific note's content. For a large note (a long Kanban board or doc), use outline: true to see its headings and any text sitting above them, then heading: "..." to read just the one section you need. For a note or section too long for one response, page it with start_line and limit to read a window at a time. To check a note's or section's line count, request start_line: 1 with limit: 1 — one line plus the total. Prefer vault_search when you don't know the path. For task status or order on a board, prefer vault_list_tasks; heading mode returns a lane's Markdown. Prefer vault_get_memory for About Me/ files (returns content without properties). To edit a section you've read, use vault_patch_note. To explore what links to this note or what it links to, use vault_get_backlinks and vault_get_outgoing_links.

Behavior: a section spans from its heading to the next heading with the same or a smaller level number (or EOF), so it includes its child headings. Empty headings ("##" with no text) act as boundaries but cannot be targeted; read the parent section or the full note, and edit them via vault_replace_in_note.

Errors:

  • "note not found" — no note exists at this path; verify it with vault_list_notes

  • "heading not found" — the message lists the available headings

  • "ambiguous heading" — multiple headings match; use heading_level to disambiguate, or read the full note (omit heading) when headings share the same level

  • "outline, heading, and properties_only are mutually exclusive — set at most one"

  • "heading_level requires a heading" — pass heading with it

  • "heading cannot be empty" — heading is whitespace only; pass the heading's text

  • "line paging is not available in outline mode" / "… properties_only mode" — start_line and limit page only a full read or a heading section

  • "start line past the end" — the message states the line count; resend a start_line within it

  • 'path must end in ".md"' — add the extension to a note's path; read other files (images, .canvas, data files) with vault_read_file

  • "absolute path blocked" / "path traversal blocked" / "hidden path blocked" — pass a vault-relative path with no dot-prefixed part

  • "properties block is not valid YAML …" — only properties_only raises it; a full read, outline and heading still work; the error says how to repair it

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

Returns: Raw markdown string (default); JSON object of properties, {} when the note has none (properties_only); JSON outline object, shaped as the outline parameter describes (outline); raw markdown of the section, heading line included (heading). When start_line or limit is given, the result is preceded by a window-metadata text block ("path — lines 1–20 of 250 (continue with start_line: 21)"). Unpaged full reads return the file's exact bytes; heading sections and paged reads use LF line endings. In the outline, bytes at the root is the whole file's size, modified its modification time (ISO 8601), and each heading's bytes the size of the text heading mode returns for that section; an empty heading appears with text: "".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "vault_read_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesVault-relative path to the note, including the ".md" extension (e.g. "About Me/Principles.md"). Use the exact letter case.
limitNoMaximum lines returned (default: all remaining).
headingNoReturn only this section. Case-sensitive exact match.
outlineNoIf true, returns { bytes, modified, leading_callout?, leading_content?, headings } as JSON instead of body content. headings: [{ level, text, bytes }]; leading_callout: { type, title, body } when the note has a top-of-file callout; leading_content: the rest of the body text above the first heading (callout lines excluded) when the note has any.
start_lineNoFirst line to return, 1-based (default 1).
heading_levelNoHeading level (1-6) for disambiguation when multiple headings share the same text
properties_onlyNoIf true, returns parsed properties as JSON instead of full note content

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.55.4
    • changedInput schema / properties / heading_level / description
      Previous value: -"Heading level (1-6) for disambiguation when multiple headings share the same text; only applies with heading"New value: +"Heading level (1-6) for disambiguation when multiple headings share the same text"
    • changedInput schema / properties / outline / description
      Previous value: -"If true, returns { bytes, modified, leading_callout?, leading_content?, headings } as JSON instead of body content — a cheap structure fetch for large notes. headings: [{ level, text, bytes }]; leading_callout: { type, title, body } when the note has a top-of-file callout; leading_content: the rest of the body text above the first heading (callout lines excluded) when the note has any."New value: +"If true, returns { bytes, modified, leading_callout?, leading_content?, headings } as JSON instead of body content. headings: [{ level, text, bytes }]; leading_callout: { type, title, body } when the note has a top-of-file callout; leading_content: the rest of the body text above the first heading (callout lines excluded) when the note has any."
    • changedInput schema / properties / start_line / description
      Previous value: -"First line to return, 1-based (default 1). Pages the text output (full body or a heading section). Not valid for outline or properties_only (JSON modes)."New value: +"First line to return, 1-based (default 1)."
  2. Changed1 schema field changedv0.54.16
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed3 schema fields changedv0.54.9
    • changedInput schema / properties / heading / description
      Previous value: -"Return only this section (heading line + body, through the next same-or-higher heading). Case-sensitive exact match."New value: +"Return only this section. Case-sensitive exact match."
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum lines returned (default: all remaining). A paged read's metadata line states the window, the total line count, and the next start_line."New value: +"Maximum lines returned (default: all remaining)."
    • changedInput schema / properties / start_line / description
      Previous value: -"First line to return, 1-based (default 1). Pages the delivered rendition (full body or a heading section). Not valid for outline or properties_only (JSON modes)."New value: +"First line to return, 1-based (default 1). Pages the text output (full body or a heading section). Not valid for outline or properties_only (JSON modes)."
  4. Changed1 schema field changedv0.54.7
    • changedInput schema / properties / path / description
      Previous value: -"Vault-relative path to the note, including the \".md\" extension (e.g. \"About Me/Principles.md\")"New value: +"Vault-relative path to the note, including the \".md\" extension (e.g. \"About Me/Principles.md\"). Use the exact letter case."
  5. Changed1 schema field changedv0.53.0
    • changedInput schema / properties / outline / description
      Previous value: -"If true, returns { leading_callout?, leading_content?, headings } as JSON instead of body content — a cheap structure fetch for large notes. headings: [{ level, text, bytes }]; leading_callout: { type, title, body } when the note has a top-of-file callout; leading_content: the rest of the body text above the first heading (callout lines excluded) when the note has any."New value: +"If true, returns { bytes, modified, leading_callout?, leading_content?, headings } as JSON instead of body content — a cheap structure fetch for large notes. headings: [{ level, text, bytes }]; leading_callout: { type, title, body } when the note has a top-of-file callout; leading_content: the rest of the body text above the first heading (callout lines excluded) when the note has any."
  6. Changed2 schema fields changedv0.36.0
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "Maximum lines returned (default: all remaining). A paged read's metadata line states the window, the total line count, and the next start_line.",
      +  "maximum": 9007199254740991,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / start_line
      Added value: +{
      +  "description": "First line to return, 1-based (default 1). Pages the delivered rendition (full body or a heading section). Not valid for outline or properties_only (JSON modes).",
      +  "maximum": 9007199254740991,
      +  "minimum": 1,
      +  "type": "integer"
      +}
  7. Addedv0.32.1
  8. Removedv0.32.0
  9. Changed1 schema field changedv0.23.10
    • changedInput schema / properties / path / description
      Previous value: -"Vault-relative path to the note (e.g. \"About Me/Principles.md\")"New value: +"Vault-relative path to the note, including the \".md\" extension (e.g. \"About Me/Principles.md\")"
  10. Changed3 schema fields changedv0.19.2
    • addedInput schema / properties / heading
      Added value: +{
      +  "description": "Return only this section (heading line + body, through the next same-or-higher heading). Case-sensitive exact match.",
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / heading_level
      Added value: +{
      +  "description": "Heading level (1-6) for disambiguation when multiple headings share the same text; only applies with heading",
      +  "maximum": 6,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / outline
      Added value: +{
      +  "description": "If true, returns { leading_callout?, headings } as JSON instead of body content — a cheap structure fetch for large notes. headings: [{ level, text, bytes }]; leading_callout: { type, title, body } when the note has a top-of-file callout.",
      +  "type": "boolean"
      +}
  11. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial behavior beyond them: section boundary semantics (a section includes child headings up to the next same-or-shallower heading), empty headings acting as untargetable boundaries, line-ending differences between paged and unpaged reads, and a window-metadata prefix on paged results. The error catalog explains failure modes and remediation in a way no annotation could.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose and a usage block, which is good, but the five call examples largely restate the schema and the Returns section is dense and long. Every part is informative, yet the definition runs well past the point where an agent needs more text, hurting scannability.

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?

For a 7-parameter, no-output-schema tool, the description covers return shapes per mode, paging metadata, YAML-repair behavior, and a near-exhaustive error-to-fix mapping. Nothing an agent needs to invoke it correctly or recover from failure appears to be 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 constraints the schema cannot express: outline/heading/properties_only are mutually exclusive, heading_level requires heading, and paging is unavailable in outline and properties_only modes. It also documents the non-obvious trick of start_line: 1 with limit: 1 to probe line count.

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?

Opens with a specific verb and resource ("Read a markdown note by its vault-relative path") and enumerates the modes (full, properties_only, outline, heading) that distinguish it from vault_read_file, vault_search, and vault_get_memory. An agent can tell exactly which tool handles exact-path markdown reads.

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" plus named alternatives with the conditions that select them: vault_search for unknown paths, vault_list_tasks for board status, vault_get_memory for About Me/, vault_patch_note to edit, backlinks/outgoing links for link exploration. It also prescribes a concrete workflow (outline first, then heading, then start_line/limit paging).

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