Skip to main content
Glama
maxkuminov

Obsidian MCP (pgvector + Ollama, self-hosted)

by maxkuminov

read_note

Read a note or specific section from an Obsidian vault by relative path, returning its content, metadata, and frontmatter in a structured format.

Instructions

Read a note from the Obsidian vault by its relative path.

Returns a structured result, not a rendered document. Metadata and note content sit in separate fields, so there is no envelope to parse and no textual procedure to get wrong — read the fields:

  • content — the selected note text. Whole-note reads: the body with a valid YAML frontmatter block stripped, which is exactly what edit_note(path, content) full replacement accepts. Section reads: the section's body only, which is exactly what edit_note(path, content, section=...) accepts. Pass it straight back; do not add, strip or split anything.

  • heading — section reads only: the matched heading line, with no line terminator. It is not part of content, and a section write must not be sent it — the heading line is never rewritten.

  • path, title, tags — metadata as data.

  • frontmatter_yaml — the frontmatter block's YAML source, fence lines excluded, LF-normalized (a CRLF or lone-CR block comes back with LF terminators — the same declared residual content carries, because this tool normalises and the write tools work on raw bytes; edit_note still reattaches the original block byte-identically). This is the authoritative copy. frontmatter is a best-effort JSON view of the same block for convenience and may be absent — dates, non-string keys, recursive aliases and unpaired-surrogate escapes have no faithful JSON form, and metadata_omissions then says which and why. To change frontmatter use set_frontmatter, or edit the raw block with edit_note(find=...); never write back a round trip of the JSON view.

  • truncated, offset, next_offset, total_chars — truncation as data. outline (whole-note reads that were truncated) lists every section with its #N ordinal so you can fetch the one you want directly, and notice carries the guidance in prose.

  • metadata_omissions — any metadata field this response had to drop, and why. Nothing is ever signalled by a marker inside a field.

  • error — set when the read failed (missing note, bad offset/limit, unknown section). It is a normal result, not a transport error, and the content-bearing fields are absent beside it.

Budgets are per field, not per response: content is bounded by the server's response cap, the outline by its own equal budget, and the metadata fields by a third — so a truncated whole-note read can carry several capped components. Read the one section you need with section= rather than paging a large note.

Round trips. A whole-note content is byte-exact input for edit_note(path, content) only when the read is complete and unwindowed (offset=0 and truncated false); a truncated read must be paged to the end first, or full replacement replaces the whole body with the fragment. A section content is byte-exact input for edit_note(section=...) under the same completeness condition. Byte-identity holds for notes whose body newlines are LF: terminators inside the selected content come back as LF, because this tool normalises and the write tools rewrite raw bytes.

Args: path: Vault-relative path to the note (e.g. "Cards/My Note.md") section: Optional ATX heading to read instead of the whole note. Plain text ("Balance Sheet"), a path-style chain ("Parent/Child") when the heading appears under different parents, or a "#N" ordinal ("#7", 1-based document order) — the ordinal is the only form that can address duplicate headings sharing the same parent. The outline returned with a truncated note carries the ordinal for every section. A bare "#N" always selects by position and is never shadowed by a heading whose text happens to be "#N"; use "Parent/#N" to reach such a heading by title. offset: Character offset to start reading from (default 0). Use the next_offset the response reports to continue. limit: Maximum characters of content to return. Only lowers the server cap; it cannot raise it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
limitNo
offsetNo
sectionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNo
tagsNo
errorNo
titleNo
noticeNo
offsetNo
contentNo
headingNo
outlineNo
truncatedNo
frontmatterNo
next_offsetNo
total_charsNo
frontmatter_yamlNo
metadata_omissionsNo
Install Server

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so exhaustively. It discloses normalization behavior (LF terminators, frontmatter byte-identity restoration), truncation semantics including per-field budgets, the error-result model (normal result, absent content fields), and the exact conditions for byte-exact round trips. Nothing about side effects or return behavior is hidden.

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

Conciseness5/5

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

Although long, the description is tightly structured: purpose first, then a field-by-field breakdown, then round-trip caveats, then parameter docs. Each sentence carries essential operational meaning—there is no filler. The density is appropriate for the tool's complexity, and the structure makes the content navigable.

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?

Given the tool has no annotations and a complex structured response, the description leaves no agent-facing gap: it documents every response field, all parameter behaviors, truncation and paging, failure modes, and integration with editing workflows. The presence of an output schema does not excuse this because the description adds the crucial 'what do I do with this field' semantics that raw schema cannot.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides only parameter titles and zero description coverage, so the description must explain each parameter on its own. It does so in depth: path with a concrete example, section with three addressing forms and the '#N' shadowing caveat, offset with next_offset continuation, and limit with the 'cannot raise it' ceiling. Every parameter's semantics are fully compensated.

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 first sentence states a specific verb, resource, and scope: 'Read a note from the Obsidian vault by its relative path.' It further distinguishes itself from a generic file read by emphasizing it returns 'a structured result, not a rendered document,' which separates it from sibling tools like read_file. The purpose is unmistakable.

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?

The description explicitly routes between alternatives: 'To change frontmatter use set_frontmatter, or edit the raw block with edit_note(find=...)' and warns against writing back the JSON view. It also gives clear within-tool guidance ('Read the one section you need with section= rather than paging a large note') and explains when content is safe to pass directly into edit_note. This fully informs when and how to use the tool.

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

Other Tools

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/maxkuminov/obsidian-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server