Skip to main content
Glama
Furkiozknn

local-notes-search-mcp

by Furkiozknn

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
GROQ_API_KEYNoOptional. Enables ask_notes synthesis via Groq (first in the provider chain).
MISTRAL_API_KEYNoOptional. Fallback provider for ask_notes when Groq is unset or fails.
LOCAL_NOTES_SEARCH_DBNoWhere the index lives. One single file for every indexed directory.~/.local-notes-search/index.db
LOCAL_NOTES_SEARCH_MODELNoOverride the default embedding model (paraphrase-multilingual-MiniLM-L12-v2). A mismatched existing index is refused.
LOCAL_NOTES_SEARCH_ALLOWED_ROOTSNoOptional allowlist. When set, index_directory refuses any path that does not resolve inside one of these directories. os.pathsep-separated.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
index_directoryA

Index (or re-index) a local directory for semantic search. Walks recursively, skips .git/node_modules/.venv/etc and files >2MB, and skips any file whose content is unchanged since the last index (cheap: a whole-file hash check before touching the embedding model). Files that were indexed before but no longer exist under path are removed from the index.

Credential-shaped file names (.env, id_rsa, credentials.json, .netrc,
*.pem, ...) are never indexed. If LOCAL_NOTES_SEARCH_ALLOWED_ROOTS is
set, `path` must resolve inside one of its entries; unset (the default)
means any readable directory is indexable.
search_notesA

Semantic search across everything indexed so far. Returns the top matching chunks with file path, line range, and a relevance-ordered snippet - not just a bag of file names.

ask_notesA

Ask a question in natural language about your indexed files. Retrieves the most relevant chunks (same retrieval as search_notes) and asks an LLM (Groq, then Mistral fallback - needs GROQ_API_KEY or MISTRAL_API_KEY) to synthesize an answer grounded ONLY in those chunks, with file:line sources. Without either key configured, degrades to returning the raw retrieved chunks with a note that no LLM is available - never fails outright just because synthesis isn't possible.

list_indexed_filesA

Lists what's currently in the index - file path, chunk count, last indexed time. Useful to check what's covered before searching, or to debug a stale/missing result.

remove_directoryA

Removes every indexed file/chunk under path from the index. The index is persistent local state in ~/.local-notes-search/ (or LOCAL_NOTES_SEARCH_DB) - this is how you clean it up without deleting the whole database file.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.3/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct role: index_directory ingests data, search_notes and ask_notes are differentiated as raw retrieval vs. LLM-synthesized answers, list_indexed_files provides observability, and remove_directory cleans up. Even the two retrieval-based tools are easy to tell apart because their outputs and purposes are explicit.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: index_directory, search_notes, list_indexed_files, ask_notes, remove_directory. There are no mixed conventions or vague generic verbs.

Tool Count5/5

Five tools is a well-scoped surface for a local notes search server: ingest, search, ask, list, and remove each earn their place. The count is neither bloated nor too thin.

Completeness5/5

The index lifecycle is fully covered: create/update via index_directory, read via search_notes and ask_notes, inspection via list_indexed_files, and deletion via remove_directory. Re-indexing handles changed and removed files, so there are no obvious dead ends or missing operations.

Maintenance

ActivityMaintained
ResponsivenessNo issues