Skip to main content
Glama
Sign In
Obsidian MCP (pgvector + Ollama, self-hosted)

Obsidian MCP (pgvector + Ollama, self-hosted)

by maxkuminov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Read file

read_file
Read-onlyIdempotent

Read any vault file, including PDFs, images, and data files, returning text, inline images, or base64 for client-side decoding. Use hash-only mode for metadata without content.

Instructions

Read any file in the vault — including non-markdown (PDFs, images, skill HTML/JS, data files). Peer to read_note, which stays markdown-only.

This is pure byte transport: the server does NOT extract or parse PDFs and cannot interpret binary bytes. Non-text/non-image files come back as an opaque base64 string intended for a client-side skill to decode — not as something the model can read directly.

Encoding:

  • "auto" (default): text-like files (HTML, JSON, CSV, source, …) return as readable text; images (PNG/JPEG/GIF/WebP) return as an inline image block that renders in-client; everything else returns as a labeled base64 string.

  • "text": force a UTF-8 text decode; errors if the file is not valid UTF-8.

  • "base64": force a raw-bytes base64 string regardless of type.

Files larger than MAX_FILE_READ_BYTES (default 10 MB) are refused with a size report. Base64 reads pass through the model context and inflate ~33%, so they are token-heavy — check a file's size with list_files before reading large binaries. Any path with a component starting with . is rejected — dot-directories (.obsidian, .git, .trash, …) and dot-files alike — as is path traversal.

Text results are additionally capped to a context-safe size: the cap bounds the returned window, and a truncated read appends a short notice carrying the offset to continue from. Base64 and image results are not windowed.

The base64 header and hash_only=True return the whole raw file's content_hash (sha256:<64 lowercase hex>), which write/delete tools accept as expected_hash. Their path is a quoted JSON string. Text stays deliberately unenveloped. Use base64 for byte-exact frontmatter bytes; read_note.frontmatter_yaml has normalized line endings.

Encoding is validated first, then hash_only/window compatibility, then ranges. hash_only refuses offset != 0 or any non-None limit; explicitly passing offset=0 is fine. A valid encoding has no effect in this mode.

Args: path: Vault-relative path to the file (e.g. "Reference Docs/spec.pdf"). hash_only: Return only path, byte count, MIME and hash, with no content. encoding: One of "auto" (default), "text", or "base64". offset: Character offset to start a text read from (default 0). Use the value the truncation notice reports to continue. limit: Maximum characters to return for a text read. Only lowers the server cap; it cannot raise it.

Input Schema

NameRequiredDescriptionDefault
pathYes
limitNo
offsetNo
encodingNoauto
hash_onlyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.2
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed1 schema field changedv0.8.1
    • addedInput schema / properties / hash_only
      Added value: +{
+  "default": false,
+  "title": "Hash Only",
+  "type": "boolean"
+}
  3. Changed2 schema fields changedv0.7.0
    • addedInput schema / properties / limit
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Limit"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}
  4. Addedv0.4.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the safety profile, but the description adds substantial context beyond them: the server does not parse PDFs, binary results are opaque base64 meant for client-side decoding, files over MAX_FILE_READ_BYTES (10 MB) are refused, base64 inflates ~33% in context, dot-components and traversal are rejected, and text reads are windowed with a truncation notice. That is exactly the kind of behavior an agent cannot infer from readOnlyHint/idempotentHint.

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 the key caveat (no parsing), then organized into labeled sections for encoding, limits, hash behavior, and args. Dense and mostly waste-free, though the encoding/validation paragraph is verbose enough that a tighter phrasing would improve scanability.

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, and the description compensates by describing return shapes: readable text for text-like files, inline image blocks for PNG/JPEG/GIF/WebP, labeled base64 strings otherwise, JSON-quoted paths in the base64 header, and the sha256 content_hash format that write/delete tools accept as expected_hash. Nothing needed to call it correctly is missing.

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?

Schema description coverage is 0%, so the description must carry parameter meaning entirely — and it does, documenting all five params with defaults, valid values, and interactions (auto/text/base64 semantics, offset/limit windowing, hash_only refusing offset != 0 or a non-None limit, and that limit can only lower the server cap). The validation ordering note further clarifies which errors take precedence.

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?

Names a specific verb and resource ('Read any file in the vault — including non-markdown') and immediately delimits scope against the sibling: 'Peer to `read_note`, which stays markdown-only.' An agent can select between the two without opening either 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?

Gives explicit routing rules: use read_note for markdown, use base64 for byte-exact frontmatter bytes because read_note.frontmatter_yaml normalizes line endings, and check size with `list_files` before reading large binaries. It even states when encoding has no effect (hash_only mode), which is unusual and useful guidance.

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