Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MINDYARD_DATA_ROOTYesDirectory holding vaults/ (one subdirectory per wiki)

Instructions

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

mindyard: personal Markdown knowledge bases (wikis), each a git repository.

Routing: call list_wikis first; pick ONE wiki and pass it on every call. Read its schema file (schema.md by default) before writing: it holds the wiki's domain and conventions. Before any write_batch, present the plan to the user (target wiki, every operation, and the split if several batches are needed, with index and log in the last) and proceed only on explicit agreement.

Reading vs editing: read_page renders for display (wikilinks stripped); never show '[[...]]' to the user. To edit a page you MUST first read it with raw=True to get the verbatim bytes AND its version; build the edit on those bytes and pass the version back as expected_version.

Writing (write_batch, the only write path): a list of typed ops applied atomically in one commit: create / overwrite / replace / delete / rename. Prefer replace (surgical) over overwrite. Modifying, deleting or renaming an existing file requires expected_version from read_page; a stale token is rejected, so re-read and rebuild. raw/ is create-only. The log, index and schema files cannot be deleted or renamed; the log grows by replacing its sentinel line. Writes are confined to the wiki and raw zones plus the index/log/schema files; wiki.yaml is read-only. Include a log entry in the same batch.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
extensions
{
  "io.modelcontextprotocol/ui": {}
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_wikisA

List the caller's wikis as [{id, label, description}].

Call it first in a session: every other tool takes one of these ids as 'wiki'. An empty list means no wiki is set up for this account.

read_pageA

Read one file of the target wiki (confined to its root).

Use it to open a page found with list_pages or search_wiki, and the index, log and schema files at the wiki root. A missing path or one outside the wiki is refused with an error.

Default: rendered for display, Obsidian wikilinks stripped, so never show '[[...]]' to the user. Pass raw=True to get the verbatim bytes before editing a page, so write_batch keeps the '[[...]]' syntax on disk.

offset is 1-based and limit caps the lines returned. Returns {content, version, total_lines, start_line, end_line, truncated}. Pass 'version' back as 'expected_version' when modifying this page.

list_pagesA

List the Markdown files of a zone, to browse a wiki by its structure.

To find pages by their content, use search_wiki instead; to open one, pass its path to read_page. Returns {pages, truncated, total}: paths relative to the wiki root, sorted and capped at limit; total counts every match and truncated says the list was cut.

search_wikiA

Find the lines of a wiki that contain a text, to locate pages by content.

Returns [{page, line, text}], one entry per matching line. Read the full page with read_page (offset=line jumps to the match); to browse by path, use list_pages. An invalid regular expression is refused with an error.

get_lint_reportA

Return the wiki's latest lint report, as Markdown.

The report lists broken links, orphan pages, frontmatter problems and breaches of the rules the wiki declares. It is written by the 'mindyard lint' command, not recomputed by this call, so it may predate recent edits. Use it to review a wiki's health or before a clean-up batch; when no report exists yet, a message says so.

write_batchA

Transactionally apply typed edit operations in one git commit.

Call it only after the user agreed to the plan (target wiki, every operation, any split into several batches). Keep each call under about 30 kB of arguments: split up front, with index and log in the last batch.

Each edit is one {op, ...}, applied in order (chained on the same path):

  • create: {op, path, content}; fails if the path exists.

  • overwrite: {op, path, content, expected_version}; full rewrite.

  • replace: {op, path, old, new, expected_version, replace_all?}; surgical edit, 'old' must be unique unless replace_all=true. Read the page with raw=True first so 'old' matches the bytes on disk.

  • delete: {op, path, expected_version}.

  • rename: {op, path, new_path, expected_version}; wikilinks to the old name are not rewritten, fix them with replace ops in the same batch.

expected_version is the token from read_page; required to modify, delete or rename an existing file, ignored for a path created earlier in this batch. Writes stay under the wiki and raw zones or the index/log/schema files; raw/ is create-only; the log, index and schema cannot be deleted or renamed. Everything is validated first: on any failure nothing is written or committed. Returns {commit, applied}.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: listing wikis, reading a page, browsing pages by path, searching content, retrieving a lint report, and applying transactional edits. Descriptions explicitly cross-reference each other (e.g., 'to find pages by content, use search_wiki instead'), leaving no ambiguity about when to use which tool.

Naming Consistency5/5

All six tool names follow a consistent snake_case verb_noun pattern: list_wikis, read_page, list_pages, search_wiki, get_lint_report, write_batch. There are no mixed conventions or vague verbs.

Tool Count5/5

Six tools is a well-scoped set for a wiki server, covering discovery (list_wikis, list_pages), retrieval (read_page, search_wiki), health checking (get_lint_report), and mutation (write_batch). No tool feels redundant or missing at this level.

Completeness4/5

The page lifecycle is fully covered: read, list, search, and a transactional write_batch that supports create, overwrite, replace, delete, and rename. The only minor gaps are wiki-level operations (e.g., creating or deleting a wiki), which appear intentionally out of scope since wikis are set up externally.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues