mindyard
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MINDYARD_DATA_ROOT | Yes | Directory 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
| Capability | Details |
|---|---|
| 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
| Name | Description |
|---|---|
| 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):
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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
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.
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.
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.
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.