mcp-wiki-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_docsA | Search internal markdown documentation for a keyword or phrase. Returns matching files with a short snippet of surrounding context. |
| read_docA | Read the full contents of a specific markdown doc by its relative path (as returned by search_docs). |
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 2 tools
The two tools serve clearly distinct purposes: search_docs finds documents by keyword, while read_doc retrieves the full content of a known document by path. There is no overlap or ambiguity between them.
Both tools use a verb_noun pattern (search_docs, read_doc), making the pattern predictable. There is a minor inconsistency in pluralization—search_docs is plural while read_doc is singular—but it does not cause confusion.
With only two tools, the server feels minimally scoped. This is appropriate for a simple read-only wiki, but it is on the thin side and offers no additional utility beyond search and read.
For a read-only documentation server, the search-and-read lifecycle is complete. The only notable gap is the lack of a way to list or browse all documents without a search query, which could be a minor workaround in some cases.