Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@llm-wiki-mcp what does the wiki say about grounding data?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Serve an LLM-maintained markdown wiki to agents over MCP.
If you keep a knowledge base in the shape Andrej Karpathy described — immutable raw sources, a wiki of markdown pages an LLM maintains, and a schema doc describing the conventions — this makes it queryable from any MCP client, without the agent having to walk your directory tree.
uvx llm-wiki-mcp --wiki ~/my-wikiIt is strictly read-only. It never writes to your wiki.
Because an agent given a directory reads the wrong things in the wrong order. It globs, opens files whole, and burns context rediscovering structure you already wrote down. This server front-loads the parts that are cheap and decisive: a curated index, one-line descriptions for every page, a tag vocabulary, and a best-match lookup that returns one page instead of forty snippets.
It also passes your wiki's own conventions doc through as the MCP server instructions — so a remote agent that has never opened your repo still follows your rules about linking, attribution, and what the page types mean.
Related MCP server: llm-wiki-kiss
uv tool install llm-wiki-mcp # or: pipx install llm-wiki-mcp
uv tool install 'llm-wiki-mcp[ask]' # plus server-side synthesisRegister it with a client — for Claude Code:
claude mcp add my-wiki -- llm-wiki-mcp --wiki ~/my-wikiOr in claude_desktop_config.json / any MCP client config:
{
"mcpServers": {
"my-wiki": {
"command": "llm-wiki-mcp",
"args": ["--wiki", "/absolute/path/to/wiki"]
}
}
}Check what it found before wiring anything up:
llm-wiki-mcp --wiki ~/my-wiki --infoAlmost nothing. A directory of markdown files.
| reserved | Your curated catalog. Served by |
| reserved | Append-only history. Served by |
| optional | Immutable source documents. Excluded from search; reachable via |
| optional | Your conventions doc — served as the MCP instructions. |
| optional | A high-level orientation page. |
everything else | your pages | Any directory structure you like. |
Page types are discovered, not configured. A page's type is its frontmatter
type if it declares one, and otherwise the directory it lives in. So
concepts/, people/, notes/ — whatever you use — become filters
automatically. Filters tolerate singular and plural (--page_type concept finds
concepts/).
Frontmatter is plain YAML. Only type and title really matter; description
and tags are what make the cheap tools useful:
---
title: Grounding Data
description: Structured facts a publisher exposes to agents, rather than prose
type: concept
tags: [structured-news, publishing]
---description is load-bearing. It's what list_pages shows and what find_page
ranks on, so a page without one is half-invisible. Keep it to one line.
Tool | What it's for |
| The curated catalog. Read first. |
| The single best page, in full. "What does the wiki say about X?" |
| Every mention across the corpus. "Where is X discussed?" |
| A page by slug, path, or |
| Pages with descriptions; filter by type and tags ( |
| The page types in use, with counts. |
| The tag vocabulary with counts. Read before filtering by tag. |
| Change history. |
| A raw source document, text only. |
| Conformance report. |
| Only if |
| Only if |
Tools that would always fail aren't registered at all — a tool that returns "not configured" costs the client context and invites a wasted call.
find_page vs search_wikisearch_wiki is ripgrep: every hit, as snippets. find_page returns one whole
page, plus the runners-up by name so an agent can pivot.
Ranking weights title and slug — the page's identity — far above tags and
description, and length-normalizes them. This matters more than it sounds: a
page about a person almost never repeats their name in its own description, so
without that weighting an entity's own page loses to every source that cites it.
Short query tokens must match exactly (otherwise the matches authenticity);
longer ones match by containment in either direction, so plurals find singulars.
A wiki written by an agent across many sessions doesn't fail by crashing — it drifts. A page never makes it into the index. A link's target gets renamed. A description picks up a colon and stops being valid YAML, so every consumer that isn't a hand-rolled parser goes blind to it.
llm-wiki-mcp --wiki ~/my-wiki --validate
llm-wiki-mcp --wiki ~/my-wiki --validate --level error # what a hook should runErrors mean malformed — broken for any consumer: invalid YAML, frontmatter
opened and never closed, duplicate slugs that make a wikilink ambiguous.
Warnings mean degraded — still serves, but worse: no type, title,
description or tags; a page missing from the index; an index entry pointing at a
page that doesn't exist; a missing source; a wikilink split across lines by
hard-wrapping. Notes are informational: over-long descriptions, and
unresolved [[red links]] — aggregated per target with a citation count, so the
top of that list is a ranked backlog of pages worth writing.
Absent metadata is deliberately not an error. This server infers a title from the filename and a type from the directory, so a page without them still works — and a checker that fails on what its own server handles fine is a checker people turn off. A minimal wiki with no index, no log, and bare markdown pages passes a hook gating on errors.
Exit codes: 0 clean, 1 errors, 2 couldn't run. --strict fails on warnings
too. A ready-made git hook is in examples/pre-commit.
Two deliberate choices worth knowing about. Red links are notes, not warnings — in a living wiki most are pages you haven't written yet, and one finding per mention buries everything else. And a referenced source that is absent but gitignored is a note explaining why, not a warning: keeping large PDFs out of git is a normal policy, and a check that's mostly false positives teaches you to ignore the whole category.
stdio by default — what most MCP clients expect, and the client is the parent process, so there's nothing to authenticate.
HTTP for serving a wiki to agents on other machines:
LLM_WIKI_TOKEN=$(openssl rand -base64 32) llm-wiki-mcp --http --port 8848Requires a bearer token; refuses to start without one. Install the http extra.
DNS-rebinding protection is off by default (the typical client is a CLI agent
behind a token on a trusted network, not a browser) — set
LLM_WIKI_ALLOWED_HOSTS to turn on the allowlist.
ask toolWith ANTHROPIC_API_KEY set and the ask extra installed, ask(question) runs
a turn-capped sub-agent over the same read-only tools and returns an answer
citing [[wikilinks]]. The index is pinned into a cached system prefix, so
repeated questions reuse it.
Use it when you want a finished answer rather than raw pages. Everything else works without it, and without any API key.
Every flag has an environment variable. Flags win.
Env | Flag | Default |
|
| current directory |
|
|
|
| — | (required for |
|
|
|
| — |
|
| — |
|
| — |
|
| — |
|
| — |
|
| — | unset ( |
Google Cloud's Open Knowledge Format
describes a very similar artifact: markdown plus YAML frontmatter, type
required, index.md and log.md reserved. A Karpathy-format wiki that fills in
description is already close to an OKF bundle at the metadata layer. The
notable divergence is links — OKF uses relative markdown links, this expects
[[wikilinks]], which is what Obsidian and most LLM-maintained wikis actually
use. NRK's okf-mcp serves OKF bundles and is
worth a look if that's your format.
uv sync --all-extras
uv run pytestGNU General Public License v2.0. See LICENSE.
Answer a natural-language question against the wiki and return a cited answer. Use this when you want a finished answer rather than raw pages: it reads the index, searches, reads what matters, and synthesizes.
Args: question: The question to answer.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that it reads the index, searches, reads relevant content, and synthesizes a cited answer. This indicates it is a compound read operation. However, it does not mention any potential side effects, rate limits, or error conditions, which would improve transparency further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences for the main body, one for the arg) and front-loaded with the primary purpose. Every sentence adds value: purpose, usage guideline, and parameter. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no annotations, the description adequately covers the core behavior and usage context. It mentions the output is a cited answer, and since an output schema exists, explicit return value details are not required. However, it does not address potential limitations or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%—the schema only defines 'question' as a string with title 'Question'. The description's Args section adds 'The question to answer,' which provides a basic semantic but lacks detail on format, constraints, or examples. This partially compensates but remains minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it answers a natural-language question against the wiki and returns a cited answer. It clearly distinguishes from sibling tools like search_wiki by specifying it produces a finished answer, not raw pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when you want a finished answer rather than raw pages,' providing clear when-to-use guidance. Also explains the multi-step process (reads index, searches, reads, synthesizes), which helps the agent understand the expected behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the single page that best matches a topic, in full.
Use this for "what does the wiki say about X". Use search_wiki when you want every mention of X across the corpus.
Args: topic: What you're looking for, e.g. 'agent payments'. page_type: Optional type filter. See list_types. tags: Optional tag filter. See list_tags for the vocabulary. match: 'and' (page must carry every tag, default) or 'or' (any).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| match | No | and | |
| topic | Yes | ||
| page_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it returns a single page (not multiple), returns it 'in full', and mentions optional filters. However, it does not explain how the 'best match' is determined, which is a behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet thorough. It front-loads the main purpose and usage guidance, then lists parameter details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It covers the main part (topic search) and optional filters, distinguishes from siblings, and provides enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides clear explanations for all parameters: topic (with example), page_type (with cross-reference to list_types), tags (with cross-reference to list_tags), and match (explains 'and' vs 'or' semantics). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Return the single page that best matches a topic, in full' which clearly specifies the verb, resource, and scope. It also distinguishes itself from the sibling 'search_wiki' by indicating it returns the single best match rather than all mentions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Use this for "what does the wiki say about X".' And when not to: 'Use search_wiki when you want every mention of X across the corpus.' This provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the wiki index — a curated catalog of every page with one-line summaries. Read this first to navigate.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It accurately states that the tool returns a catalog of all pages with summaries, implying a read-only action. However, it omits details like data freshness or performance characteristics, which are minor for this simple operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with the main purpose front-loaded. Every phrase adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, has output schema), the description adequately explains what it returns and when to use it. The existence of an output schema likely details the return structure, so further elaboration is unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so the description does not need to add parameter info. Baseline score of 3 is appropriate as no additional meaning is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the wiki index, a curated catalog of every page with one-line summaries, using specific verb 'Return' and resource 'wiki index'. It distinguishes from siblings like search_wiki and read_page by emphasizing it as a starting point for navigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends 'Read this first to navigate', giving a clear use case for initial orientation. It does not mention when not to use it, but the sibling tools imply alternatives for specific search or page retrieval tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the wiki's change log, newest first — what was added when, and the reasoning recorded at the time. get_index says what the wiki holds; this says how it got there.
Args: since: Optional ISO date (YYYY-MM-DD); only entries on or after it. limit: Max entries. Defaults to a small window, as logs get large.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses ordering (newest first), content (what was added when, reasoning), and default behavior (small window). No annotations provided, so description carries burden fully. Lacks mention of potential for pagination or performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, concise sentences for purpose, followed by clean argument list. No fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so not required to describe return shape. Covers essential context: ordering, reasoning, default limit. Minor gap: no mention of error handling or empty results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully explains both parameters: since as ISO date filter and limit as max entries with default small window, adding critical context missing from schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns the wiki's change log, newest first, and distinguishes from sibling get_index by contrasting 'what the wiki holds' vs 'how it got there'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contrasts with get_index to guide selection, mentions optional since and limit arguments, and notes default small window for logs. Could be more explicit about when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pages with their one-line descriptions, optionally filtered.
Args: page_type: Type to restrict to. See list_types. tags: Frontmatter tags to filter by. See list_tags. match: 'and' (page must carry every tag, default) or 'or' (any).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| match | No | and | |
| page_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that the output is one-line descriptions and describes filtering behavior. However, it lacks details on pagination, maximum results, or any side effects, which are important for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear summary sentence followed by parameter docstrings. No wasted words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, an output schema exists (so return values need not be explained), and the description covers purpose and parameters well. It is missing potential usage limits or ordering, but these are not critical for a simple list tool. Overall adequate for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, meaning no parameter descriptions. The description adds significant value by explaining each parameter: page_type (with reference to list_types), tags (with reference to list_tags), and match (with examples of 'and' and 'or'). This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists pages with one-line descriptions, optionally filtered. It specifies the verb and resource, and implicitly distinguishes from siblings like search_wiki and read_page. However, it could be more explicit about the scope compared to sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter explanations with references to list_types and list_tags, implying when to use those tools. However, it does not explicitly state when to use this tool over alternatives like search_wiki or find_page, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every tag in use with its page count, commonest first. Read this before filtering by tag — it is the only way to learn the vocabulary.
Args: page_type: Optionally restrict to one type.
| Name | Required | Description | Default |
|---|---|---|---|
| page_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool lists all tags, orders by popularity, and returns page counts. It implies read-only behavior. While it could explicitly state it is safe and idempotent, it is sufficient for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an Args section. Front-loaded with the main purpose. Every word adds value. No redundant or tangential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description is nearly complete. It covers behavior, ordering, and parameter purpose. The only minor gap is a lack of details on possible values for page_type, but the output schema presumably provides structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the one parameter: 'Optionally restrict to one type.' The schema has 0% coverage and no enum values. While it adds meaning, it does not specify what 'type' refers to (e.g., page types from list_types). More detail would improve the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List every tag in use with its page count, commonest first.' It identifies a specific verb and resource, distinguishes from sibling tools like list_pages or list_types by focusing on tags and their usage statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Read this before filtering by tag — it is the only way to learn the vocabulary.' This tells the agent when to use the tool (to discover tags before filtering). However, it does not mention alternatives or when not to use it, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the page types this wiki uses, with counts. Types come from
frontmatter type, falling back to the containing directory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description provides full behavioral transparency by detailing that it lists types, includes counts, and explains the derivation logic (frontmatter `type` then directory fallback). This exceeds required disclosure for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and adding key behavioral detail about type derivation. Every word adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is complete. It explains the source of types and the inclusion of counts, which is sufficient for an agent to understand the tool's function and output without further detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters, the description does not need to add parameter semantics. According to the rubric, baseline is 4, and no additional information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists page types with counts, specifying the source from frontmatter `type` field with fallback to directory. This distinctively separates it from sibling tools like list_pages or list_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by explaining what the tool returns (types with counts) and how types are derived. While it does not explicitly mention when not to use it, the context of sibling tools combined with the description provides sufficient guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a page's full content.
Args: name: Page slug ('grounding-data'), relative path ('sources/2026-04-24-caswell.md'), or a [[wikilink]].
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It only says 'return...full content' without mentioning error handling, authorization, or side effects. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose statement and structured Args section. Almost no waste, though the docstring format slightly increases length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and existence of output schema, the description covers input completely. It does not explain output, but output schema fills that gap. Adequate for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, but the description adds concrete examples and explains the three valid formats (slug, path, wikilink), which is essential and superior to the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return a page's full content' specifying the verb and resource. It distinguishes from sibling tools like 'find_page' (search) and 'list_pages' (list) by emphasizing full content retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the input format (slug, path, wikilink) but does not explicitly state when to use this tool versus siblings or provide exclusion criteria. Usage context is implied but not direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the text of a raw source document (transcript, article, notes). Text files only; PDFs and other binaries are not served as text.
Args: path: Path within the raw source directory.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only notes the file type limitation but lacks details about error handling, encoding, size limits, or permissions. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a one-line arg description. Each sentence adds value: purpose, file type restriction, parameter meaning. No fluff, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple read tool with one parameter and an output schema. However, missing info on behavior when path is invalid or points to a directory. Reasonable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description adds 'Path within the raw source directory' for the path parameter, which is basic but insufficient—no format or examples. Does not fully compensate for lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns text of raw source documents, specifying types (transcript, article, notes). It also restricts to text files, which distinguishes from sibling tools like read_page that deal with wiki pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit constraints: only text files, not PDFs/binaries. This tells when to use (text raw sources) and when not to (binaries). No explicit alternatives named, but context implies other tools for non-raw sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across the wiki (excludes raw sources). Returns matching files with line snippets. Use find_page instead when you want one page rather than every mention.
Args: query: Search terms (case-insensitive; regex is accepted). page_type: Optional type filter. See list_types.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| page_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses search behavior (case-insensitive, regex accepted), excludes raw sources, and returns snippets. It does not mention pagination or result limits, but for a search tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief paragraphs: one for purpose and return format, one for parameter details. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 params, 1 required), the description covers search behavior, parameter details, return type (snippets), and exclusion of raw sources. Output schema exists, so return details are not required in description. Sibling references provide alternative usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates. It explains query as case-insensitive and regex-accepted, and page_type as an optional type filter with reference to list_types. This adds meaning beyond the plain schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs full-text search across the wiki, excluding raw sources, and returns matching files with line snippets. It distinguishes from sibling find_page by noting that find_page is for retrieving a single page rather than every mention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions when to use find_page instead, and provides guidance on the optional page_type filter by referencing list_types for available filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the wiki for conformance problems: invalid or incomplete frontmatter, duplicate slugs, pages missing from the index, index entries pointing at pages that no longer exist, references to missing sources, and unresolved or broken wikilinks.
Args: path: Optional single page to check. Omit to check everything. limit: Maximum findings to return.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full transparency burden. It does not explicitly state if the tool is read-only or has side effects. The list of checks implies non-destructive scanning, but safety profile is not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with a summary line and bullet-style parameter list. No redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool, description comprehensively lists all checks. Output schema exists, so return format is not needed. Only 2 parameters with clear descriptions. Complete for the intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameters are well explained: 'path' to optionally scope to a single page, 'limit' for maximum findings. With 0% schema coverage, description fully compensates, making parameters clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with a clear verb ('Check') and specific resource ('wiki'), followed by a detailed list of conformance problems. This easily distinguishes from sibling tools focused on reading, searching, or indexing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies validation context but does not explicitly state when to use this tool over siblings. However, the listed checks clearly indicate it's for detecting broken links, duplicate slugs, etc., which contrasts with read/search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0askfind_pageget_indexget_loglist_pageslist_tagslist_typesread_pageread_sourcesearch_wikivalidate_wikiEvery tool has a distinct purpose. get_index provides an overview, search_wiki and find_page are explicitly differentiated for full-text search vs. single-page retrieval, and read_page, list_pages, list_types, list_tags, get_log, read_source, validate_wiki, and ask each serve unique functions without overlap.
All tool names follow a consistent verb_noun pattern (e.g., get_index, search_wiki, find_page, read_page, list_pages, list_types, list_tags, get_log, read_source, validate_wiki). The only minor deviation is 'ask', but it is still a single verb and fits the pattern of action-oriented names.
With 11 tools, the set is well-scoped. Each tool covers a specific aspect of wiki interaction (index, search, retrieval, listing, logging, raw source access, validation, Q&A) without being excessive or sparse.
The tool set is complete for a read-only wiki interface. It provides everything needed to navigate, search, retrieve, validate, and query a wiki corpus. While write tools are absent, the domain inferred from the tool descriptions is clearly read-only, so no gaps exist.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shared project wiki for AI agents: read and write pages, next actions, and activity logs over MCP.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Serve a folder of Markdown notes as an MCP server: hybrid search, reading, and sourced answers.
Read and write your team's shared, AI-readable wiki from any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kleinmatic/llm-wiki-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
