Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

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": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_notesA

List notes newest first, filtered by folder, tag or date. This is the tool for "what is new" and "what changed lately": search_notes ranks by relevance and never by recency.

created_* is when a note was made, updated_* when its own text last changed — a rename elsewhere rewriting a [[link]] inside it does not count as an edit here. Each row carries content_length, so you can tell a long note from a short one before spending a get_note call. With trashed:true the other filters are ignored.

get_noteA

Read one note, by id or title.

  • Long notes come back windowed — 20000 chars by default: check content_truncated and pass next_offset back as offset for the rest. A windowed reply carries headings — the H1–H3 outline with character offsets — so name one in section to get that heading and its body alone instead of paging through the note.

  • resolve_links:true also returns the notes this one links to, id/title only unless you add include_content:true, whose text is capped at 4000 chars — call get_note on an id for the whole of one. Targets that match no note are listed as unresolved.

  • Pass the updated_at you read back as expected_updated_at when you write. content_updated_at is the one that moves only on a real edit to this note: a rename elsewhere rewriting a [[link]] inside it touches updated_at but not that.

create_noteA

Create a new note. Embedding is generated automatically in the background. The server instructions' wikilink and tag rules apply: search_notes for the topic first and link the related notes it finds, and call list_tags before coining a new tag.

update_noteA

Update note fields. Re-embeds if title or content changed. Updates wikilinks if title changed. The server instructions' wikilink and tag rules apply when substantially rewriting — in particular, call list_tags before coining a new tag. Pass expected_updated_at (the updated_at you read) to be refused instead of overwriting a change made in between.

append_to_noteA

Add text to a note without resending the rest — prefer it over update_note for journals, logs and running lists. A blank line separates your text from what was there. The note is locked for the read-modify-write, so two sessions appending at the same moment keep both additions instead of the later one overwriting the earlier. Re-embeds in the background like any content change.

replace_in_noteA

Replace exact text in a note without resending the rest. Either find/replace or old_string/new_string — the same pair, either spelling.

For several replacements pass edits rather than the singular fields (one lock and one re-embed for the batch, not one per call); the two forms cannot be combined in one call. Edits apply in order, and each find is matched against the note as the edits before it already changed it — an earlier edit can create the text a later one needs, or destroy it, so sequence them. If any step's count is wrong the whole batch is refused and the note is left untouched, and the error names the failing index.

delete_noteA

Soft-delete a note by id — it disappears from list_notes/search/get_note/the graph, but is recoverable with restore_note for 30 days before being purged for good. Use list_notes with trashed:true to see what's currently in the trash.

restore_noteA

Undo delete_note: brings a soft-deleted note back. Errors if the note isn't in the trash (never deleted, already restored, or purged past the retention window), or if a live note has since taken the same title (rename one of them first, then retry).

search_notesA

Search notes: hybrid (keyword + meaning) by default. Returns ranked excerpts, not whole notes.

  • Use type="text" for an exact identifier, filename, code symbol or quoted phrase; "hybrid" for questions and topics.

  • READ THE SECTION, NOT THE NOTE. A hit's section is the heading its excerpt came from — pass that string to get_note's section to get that part alone. If a long hit has no section, get_note with limit:1000 returns its headings outline; pick one and re-read with section. For prose without headings, a hit's excerpt_offset goes to get_note as offset.

  • A hit is a candidate, not an answer. relevance is relative to the best hit in this response, so the top result always reads 1.0 — an ordering, not a verdict; best_score is that hit's own raw similarity. matched_by says which arms found it: semantic_score alone means "about something similar", never that it confirms your question. Quote the excerpt or open the note — a score is never evidence. exact:true means the query occurs verbatim in that note; text_tier of "or" or "substring" means the strict words missed and a looser pass filled in — recall, not confirmation.

  • A long note such as a book comes back as one hit with one excerpt. To find more places in it, search again with its note_id: results are then places inside that note, best first.

  • Dates here filter, they do not rank. For "what changed lately" use list_notes, which sorts by recency; it is also how you browse by folder or tag, since a query is required here.

  • has_more with next_offset pages the results.

indexing_statusA

Semantic index progress: total/indexed/pending, complete=true when pending is 0. Pending notes are still found by text search; ones never embedded stay out of semantic results until the background pass reaches them.

Also names the active embedding model and the configured similarity cutoff (semantic_min_similarity, null when there is none — the default, meaning nothing is refused for being too dissimilar). Cosines are not comparable between models, which is why the model is named rather than left to be guessed from a score.

list_tagsA

Tags in use with the number of notes carrying each, most-used first. The default limit cuts off the one-off tail — a tag used once is not one worth reusing — so raise it to see those.

list_foldersA

List folders with the full path already resolved — no need to walk parent_id yourself. Pass a folder's own id as parent_id to create_folder/update_folder to nest under it. Sorted by path, so a page is a contiguous slice of the tree read top to bottom; the reply is {folders, has_more, next_offset?}.

create_folderB

Create a new folder. Optionally nested under a parent.

update_folderA

Rename a folder and/or move it under a different parent (set parent_id to null for top level). Provide at least one of name/parent_id. The response includes the resolved path so a rename or move can be confirmed without a follow-up list_folders call.

delete_folderA

Delete a folder and its full subtree of child folders (cascade). Every note inside — including notes in nested subfolders — is soft-deleted into the trash along with it (see delete_note), recoverable via restore_note within the retention window. To preserve organization instead, move notes/subfolders out first.

get_backlinksA

Notes that link to this one via [[Title]] wikilinks, by id or title. Each comes back as id/title/folder_path plus a snippet around the link; include_content:true returns their full text instead, which is expensive when many notes link here — prefer get_note on the ids you actually want. offset and limit count notes, not characters.

get_neighborsA

What is around ONE note in the [[wikilink]] graph, out to depth hops: a flat list of titles, no node indices to decode and no whole-vault payload. For the shape of that neighbourhood — which of them link to each other — use get_graph with root_title instead.

Traversal is undirected: a note linking HERE counts as much as one linked FROM here. links_out/links_in describe the direct relation and appear only at depth 1 — two hops out, "which way does the arrow point" has no answer. Each note appears once, at the shortest depth that reaches it.

These are links people wrote, not similarity: a note on the same subject that nobody linked is not here, and an empty result is a fact about the writing rather than about the topic. Rows carry the title, which is what get_note, get_backlinks and this tool all take.

get_graphA

Many notes at once and the edges between them — the heavy graph tool, and the only one that reaches for the whole vault. For one note's surroundings use get_neighbors; for who links to it, get_backlinks.

Nodes are {t} (t = title). Edges reference nodes BY POSITION in the nodes array: edges[0] = [2, 5] means nodes[2] links to nodes[5]. semantic_edges are undirected and come from embedding similarity rather than written links, with the cosine as a third number. unresolved_links are [[wikilink]] targets matching no note title — dangling, so they have no node index.

Unscoped this reaches for the ENTIRE vault and stops at max_nodes: truncated: true means you hold a recency-ordered prefix, NOT the shape of the vault. Scope with folder_id or root_title+depth rather than raising the cap.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 18 tools

Disambiguation5/5

Each tool targets a distinct verb+resource, and the descriptions actively route between the close pairs (list_notes vs search_notes, append_to_note vs update_note vs replace_in_note, get_backlinks vs get_neighbors vs get_graph). No two tools appear to do the same thing, and the explicit 'use X instead of Y' guidance removes the residual overlap.

Naming Consistency4/5

Nearly everything is a clean verb_noun pattern (create_note, list_folders, get_backlinks, restore_note), with consistent pluralization for collections. The one outlier is indexing_status, which is a noun phrase with no verb prefix and breaks the pattern.

Tool Count4/5

18 tools is on the heavier side but each maps to a real operation in a notes+folders+graph domain; nothing feels like filler. A slightly tighter surface (e.g. folding indexing_status into a broader status call) would make it ideal.

Completeness4/5

Note lifecycle is fully covered (create/read/list/update/append/replace/soft-delete/restore, search, backlinks, graph), and folders have full CRUD with cascade delete. Minor gaps remain: no tag management beyond list_tags (no rename/merge/delete of tags), no permanent purge, and no dedicated trash-listing tool (deferred to list_notes trashed:true).

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues