wikikit
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| wiki_list_pagesA | List all wiki pages (slug, title, type, status, last_verified, summary). Use first to discover what exists before reading or searching. |
| wiki_read_pageB | Read one full wiki page by slug, including metadata and sources. |
| wiki_read_sectionA | Read a single section of a page by heading (case-insensitive substring). Cheaper than wiki_read_page — prefer it when you need one section. |
| wiki_searchB | Keyword search across titles, tags, summaries, headings, and bodies. Returns ranked matches with snippets. |
| wiki_recentB | Pages verified/updated within the last N days (default 14) — the freshness view. |
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 5 tools
Each tool has a distinct retrieval purpose (list, full read, section read, search, freshness), and descriptions explicitly clarify when to prefer one over another. Minor overlap between wiki_list_pages and wiki_recent since both enumerate pages, but the time filter distinguishes them.
All tools share the wiki_ prefix and use snake_case, with mostly verb_noun patterns (list_pages, read_page, read_section). wiki_search and wiki_recent drop the noun but remain readable and consistent with the prefix.
Five tools is well-scoped for a wiki reader: discovery, full read, targeted section read, search, and freshness each earn their place without redundancy.
The read/discovery lifecycle is well covered (list, read, section, search, recent). If the server is strictly read-only this is complete; a create/update path would be the only plausible gap for an editing-capable wiki.