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

Obsidian MCP (pgvector + Ollama, self-hosted)

by maxkuminov

Keyword search

keyword_search
Read-onlyIdempotent

Find exact identifiers, code symbols, titles, or phrases in Obsidian notes with PostgreSQL full-text search; supports AND/OR/exclude operators, tag, folder, and frontmatter filters.

Instructions

Full-text keyword search via PostgreSQL tsvector. Use this for exact identifiers, code symbols, proper nouns, titles, or known phrases — anywhere semantic noise hurts.

Exact identifiers, code symbols, titles or known phrases: keyword_search. Conceptual or paraphrased questions: semantic_search. Unsure which: hybrid_search.

Bare terms are ANDed: budget forecast matches only notes containing both stems. Notes matching every term come first, tagged match: all; when they do not fill the page, notes matching some of the terms follow, tagged match: any, in their own rank order. The operators: "exact phrase" (adjacent words), budget OR forecast (either), -draft (exclude; honoured in the any block too). A note's title and frontmatter aliases are indexed above its body, so a query that is a note's title ranks that note first. A note's tags (frontmatter and inline #tags; a nested #a/b also as a and b) are indexed below its title and aliases and above its body.

Each result carries rank (a relative score: a body-only match scores in the thousandths, a title match near 1, and an any row is scored against the fallback query, so ranks compare only within one block of one page), match, matched_in (the parts that alone match: title — title or aliases — tags, body, comma-joined; or, when the terms are split between parts, the first of title+tags, title+body, tags+body, title+tags+body that matches), terms (k/n: how many of the query's terms the note contains), and a second line: snippet: — the matching body text with the matches in «» — or head: — the note's opening words when the body alone does not match or the match is beyond the stored excerpt (a note with no body has no second line). Snippets are computed for the first rows of the page (the header says snippets: first N when the page is longer). The header always carries the all/any counts and how many rows have no stored excerpt yet (notes indexed before this version; the footer names the one-time rebuild). Call read_note on a result's path for the full note.

Args: query: Keywords or phrase to match (websearch tsquery syntax: "foo bar", "foo OR bar", "-bar"). folder: Optional folder prefix (e.g. "Cards/", "Projects/"). limit: Maximum number of results (default 20). tags: Optional list of tag names; only notes carrying ALL listed tags match (e.g. ["project", "active"]). frontmatter: Optional dict of frontmatter key/value pairs; only notes whose JSONB frontmatter contains every pair match. Strict type matching — string "0" does not match integer 0 (e.g. {"status": "draft"}).

Input Schema

NameRequiredDescriptionDefault
tagsNo
limitNo
queryYes
folderNo
frontmatterNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.2
    • addedInput schema / additionalProperties
      Added value: +false
  2. Addedv0.7.0
  3. Removedv0.5.4
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, but the description goes much further. It explains ANDing of bare terms, all/any result blocks, query operators, indexing priority for titles/aliases/tags, ranking caveats, snippet/head behavior, and header metadata. No contradiction with annotations.

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?

The description is front-loaded and well-structured: purpose, then sibling routing, then query/result semantics, then arguments. It is dense but mostly earns its length for a complex search tool. Some result-field explanation may overlap with the existing output schema, keeping it just short of ideal conciseness.

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 five-parameter search tool with 0% schema description coverage, the description compensates thoroughly: it explains every parameter, query syntax, ranking behavior, match blocks, result fields, and follow-up use of read_note. Annotations cover safety, and an output schema exists for return structure, so the definition is complete.

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 all parameter meaning — and it does. It documents query syntax, folder-prefix usage, limit default, tags as ALL-of matching, and frontmatter strict type matching with examples, adding substantial semantics beyond bare schema field names.

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 combination — full-text keyword search via PostgreSQL tsvector — and immediately distinguishes this tool from sibling search modes by listing the exact query types it is meant for. An agent can identify both what the tool does and what makes it different from semantic_search and hybrid_search.

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?

It gives explicit routing guidance: exact identifiers, code symbols, titles, or known phrases use keyword_search; conceptual or paraphrased questions use semantic_search; uncertain cases use hybrid_search. This directly covers when to use this tool and when to choose alternatives.

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