wiki-skills
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WIKI_LOCALE | No | Default locale | en |
| WIKI_API_KEY | Yes | ok-wiki API key (JWT) | |
| WIKI_BASE_URL | Yes | Base URL of the ok-wiki instance, e.g. http://localhost:3000 | |
| WIKI_READONLY | No | Set to '1' to register only read tools | 0 |
| WIKI_LOG_LEVEL | No | Diagnostics level, always to stderr | info |
| WIKI_MAX_UPLOAD | No | Max upload size in bytes for wiki_upload_asset (10 MB) | 10485760 |
| WIKI_TIMEOUT_MS | No | Per-request timeout in milliseconds | 15000 |
| WIKI_UPLOAD_ALLOWLIST | No | Colon-separated absolute path prefixes uploads may come from; unset = unrestricted | |
| WIKI_MAX_CONTENT_BYTES | No | Cap on page body returned into context | 100000 |
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 |
|---|---|
| wiki_search_pagesA | Full-text search across ok-wiki pages — the first tool to reach for when asked about anything in the wiki. Matching is substring-ish, not semantic: the default search engine is a database LIKE scan over title, description, and path, so search for literal words that would appear on the page rather than paraphrases. Returns { results, totalHits, suggestions }; results are capped at |
| wiki_get_pageA | Fetch a single ok-wiki page — by numeric |
| wiki_list_pagesA | Enumerate ok-wiki pages without a search query — for "what's under projects/?" or "what's tagged runbook?". Filters by tag server-side; |
| wiki_create_pageA | Create a new markdown page in the ok-wiki at the given path. The path is validated locally first (no dots, spaces, backslashes, or double slashes). If a page already exists at the path, the error says so and points at wiki_update_page — edit rather than re-create. |
| wiki_update_pageA | Edit an existing wiki page with a partial patch, safely: the tool reads the current page, checks for concurrent edits, merges only the fields you supply, and writes the complete page back. Everything you do not supply — title, description, tags, published state, publish window, scripts, path, locale — is preserved exactly as read. Note that tags REPLACES the whole tag list. This tool never moves, renames, or deletes a page; an identical no-op patch writes nothing. |
| wiki_page_historyA | List the revision history of a page: a trail of versions (versionId, versionDate, authorName, actionType — initial/edit/move; a restore shows as an edit here, and the snapshot it created reports action 'restored' via wiki_get_page_version) plus |
| wiki_get_page_versionA | Fetch one historical revision of a page as a full snapshot: content, title, description, tags, path, isPublished, versionDate, authorName. Content is bounded by WIKI_MAX_CONTENT_BYTES under the same rule as wiki_get_page — when cut, the result carries an explicit truncation marker and |
| wiki_restore_page_versionA | Roll a page back to an earlier version from its history — the undo for everything else this connector can do. Restoring is non-destructive in the sense that matters: it appends a new version to the page’s history rather than erasing anything, the intermediate edits stay in the trail, and a mistaken restore can itself be restored away. Get the versionId from wiki_page_history, and preview it with wiki_get_page_version before restoring. |
| wiki_list_tagsA | Lists the wiki's entire tag vocabulary as { tags: [{ tag, title }] }, where tag is the slug used when writing pages and title is its display text. Call this before creating or retagging a page so new pages reuse the existing vocabulary instead of inventing near-duplicate tags. |
| wiki_search_tagsA | Searches the existing tag vocabulary and returns matching tag slugs as { tags: string[] }. Use it before creating a page to check whether a tag you are about to invent already exists in a near-duplicate form, so pages converge on shared vocabulary. |
| wiki_list_assetsA | List the assets (uploaded files) in a wiki asset folder. folderId 0 is the root folder. Returns id, filename, ext, kind, mime, fileSize (bytes), and url per asset; url assumes the root folder — for assets in another folder, prefix its folder path. |
| wiki_create_asset_folderA | Create a new asset folder under a parent folder (parentFolderId 0 = root). If the folder already exists the error says so — reuse the existing folder in that case. |
| wiki_upload_assetA | Upload a local file to the wiki as an asset and return its id, URL, and a ready-to-paste markdown reference. The file is read from the machine running this server, subject to WIKI_MAX_UPLOAD and WIKI_UPLOAD_ALLOWLIST. The returned url and markdown assume the root folder; for a non-root folderId, prefix the folder path. |
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 13 tools
Most tools target a distinct resource and action (search vs list, current vs version, page vs asset). The two tag tools (list_tags and search_tags) overlap in purpose but their descriptions clearly distinguish batch listing from duplicate-checking, so an agent can separate them. Overall low ambiguity.
All tools share the wiki_ prefix and mostly follow verb_noun (list_tags, get_page, create_page). The one exception is wiki_page_history, which is noun_noun rather than a verb form, making it slightly inconsistent. Otherwise the pattern is predictable.
At 13 tools, the set is well-scoped for a wiki server covering pages, tags, history, and assets. Each tool serves a clear function without redundancy. This is within the ideal range and not overwhelming.
The page lifecycle is incomplete: there is no delete or move/rename tool, and update_page explicitly refuses to do so. Asset support also lacks folder listing, deletion, and update, leaving obvious dead ends. These gaps would cause agent failures when cleanup or reorganization is needed.